Ground Station Network

Abstract

The ground station network (GSN) plays a major role in space missions. It establishes links with the spacecraft and with other control centers, supports specific characteristics of the spacecraft and provides the functionality and safety of the mission. By its nature, GSN participates in cross-support activities between different organizations and agencies. The GSN comprises several functional aspects, the communication path between the control center and the ground stations (online data transport, offline data, voice), the management of the stations and their antennas as well as coordination tasks and station scheduling.

1 Introduction

The communication with the spacecraft as an essential part of the spacecraft's operation is mainly characterized by receiving telemetry (TM), transmitting telecommands (TC) and tracking. Optimizing the communication link can significantly increase the operability, the outcome and last but not least the safety of the mission. E.g., the contact time can be increased, usually by introducing additional ground stations into the network and selecting optimally placed stations. For some missions (such as LANDSAT, SILEX and Sentinel) the use of one or multiple geostationary relay satellites is a viable option. A well-known service here is the TDRS (Tracking and Data Relay Satellites) program (Stampfl and Jones 1970), which supported already the early Space Shuttle flights and is still the backbone of communications in the ISS project. In the meantime, more and more relay satellites are available, and the market is growing—the European Data Relay System (EDRS) features even terminals for optical communications (Böhmer et al. 2012).

The launch and early orbit phase (LEOP) is a particular case, since several critical tasks depend on a safely established contact—via a connection which is set up for the first time in the life of a spacecraft. Here, GSN has the task of shortening the time from the separation of the spacecraft from the launcher to the first acquisition. The initial acquisition station must carry out the first tracking of the satellite to allow an accurate orbit determination, and it needs to receive telemetry in order to assess the condition of the spacecraft after launch. When time permits or if it is required, the first station also performs an uplink to allow time-critical operations such as attitude setting into Sun-pointing mode or unfolding solar panels.

2 Station Selection

When designing the GSN, several technical properties, parameters and requirements must be considered. They are usually provided in the form of the Space to Ground Interface Control Document, while some others can be found in the spacecraft design and requirements documents.

The analysis begins with the main mission feature, the orbit. Based on the knowledge about the position and speed of the satellite during the mission phases, we can decide which ground stations potentially can be used depending on their geographical location (see also Sect. 13.3). For Earth-bound missions, the orbit type may change during LEOP, but remains stable during the routine phase. Orbit types are categorized according to altitude (or, in other words, distance from Earth), the inclination of the orbital plane to the Earth equator, and the shape of the orbit path.

The majority of the satellites are in circular orbits. We distinguish between low Earth orbit (LEO) with altitudes of up to 1,000 km, geostationary Earth orbit (GEO) with about 36,000 km and everything in between, called medium Earth orbits (MEO). The orbits can have different inclinations, with GEO usually at zero degrees, many LEOs in polar orbit close to 90° and all other satellites somewhere in between.

And so, the spacecraft flying in LEO with an inclination of about 55° can only be contacted by stations located at a latitude on Earth, which is smaller than that value. Therefore there is clear dependence between spacecraft orbit inclination and selection of the ground stations.

Polar stations are of major importance for Earth observation missions in polar orbits, since they principally allow communication within practically every orbit (see Fig. 10.1) for an example ground station network supporting polar orbits). However, they cannot be used for missions with low inclinations such as GEO. In such a case, the ground antennas must be ideally distributed along the equator (Fig. 10.2).

Fig. 10.1

Typical LEOP ground station network for LEO Spacecraft. The ground track of the spacecraft is depicted as well as the footprint of the involved ground stations

Fig. 10.2

Typical LEOP ground station network for GEO Spacecraft in GTO. The ground track of the spacecraft is depicted as well as the footprint of the involved ground stations

Other Earth-bound satellites are on highly elliptical (= eccentric) orbits. The significant changes in altitude, ranging from very low (only about 100 km) up to 60,000 km (far beyond GEO) result in a wide variety of spacecraft velocities. The reason to choose such an orbit can be a transfer phase between different orbits (e.g., geostationary transfer orbit, GTO), a footprint optimized for a specific region of the Earth from the ground (e.g., Molniya type orbits) or scientific requirements.

The GSN must be carefully adjusted to the mission. With highly elliptical orbits, a spacecraft is visible in apogee for many ground stations over a long period of time (hours); however, the signal strength is significantly decreased. At perigee, on the other hand, the spacecraft will be at a very low altitude with extreme speed. The resulting antenna tracking speed is very high and excludes most antennas.

Missions to the Moon, Mars or further in space are called deep space missions, the spaceship is no longer orbiting the Earth. Due to the large distances and the weak signals, the required antennas are larger in diameter to achieve the required signal sensitivity. For such antennas, a high tracking speed is no longer a design requirement, as the target is quasi-stationary in the sky and its movement is dominated by the Earth's rotation speed (Figs. 10.1 and 10.2).

There are also a bunch of technical parameters, which may also influence the station selection. Most of them are known from basic antenna theory and can be found in respective literature, thus we just list them here for completeness:

• Equivalent isotropically radiated power (EIRP)

• Antenna gain and gain-to-noise temperature (G/T)

• Antenna diameter (in case of reflector antennas)

• Available/supported radio frequencies

• Uplink/transmission capability

• Additional services capability (like ranging, Doppler measurements).

These parameters are then used to preselect the antenna. This may be actually refined through the calculation of the so-called link budget. This value determines the space link quality (see Sect. 3.4.2) and is an indication, how much margin remains under different conditions during the mission.

Further parameters that influence the choice of stations are the downlink and uplink frequencies, which are grouped in so-called frequency bands, as shown in Table 10.1. Not all ground stations have antennas that support all possible frequency bands; often a given station serves a dedicated purpose. For example, stations supporting GEO missions typically have antennas with Ku- and Ka-band capabilities, while LEO stations have S- and X-band capabilities. Deep space antennas typically also support S- and X-band frequencies, but with a much larger dish diameter (to enable better EIRP and G/T).

Table 10.1 Frequency band assignments as used in space operations

The situation becomes even more complex during the LEOP of geostationary satellites. S-band is traditionally used for payload IOT (in-orbit test) and routine operations before switching to Ku-band or Ka-band. This requires a very demanding planning for the spacecraft itself, the mission operations and the ground segment with various systems and equipment.

Despite wide popularity and low cost of the S-band, there is increasing interest to support LEO satellites with Ka-band since a higher bandwidth is available. Furthermore, in particular GEO missions with long contact times and low signal strengths suffer from an increasingly congested S-band and interferences with other spectrum users such as mobile Internet access. Therefore, the necessary infrastructure for telemetry and telecommand in Ka-band is provided in more and more ground stations.

Another aspect of station selection is bandwidth. Most ground stations support the full available downlink data rate in the specific frequency band. However, the uplink is sometimes restricted. So far, relatively low data rates (between 4 and 20 kbps—kilobits per second) have been used for the uplink. The capabilities and equipment of the existing stations have been designed accordingly. A tendency towards increased uplink data rates can be observed to meet trends such as more frequent software uploads. Currently, not all ground stations can support those.

Other parameters that we will not discuss here in detail, but are worth mentioning, are modulation type, encoding, randomization, space link data format, and finally specific tracking requirements for ranging and Doppler. All those factors are standardized, and the CCSDS (Consultative Committee for Space Data Systems) and ECSS (European Cooperation for Space Standardization) standards listed in Table 10.2 describe them to the full extend.

Table 10.2 The most important CCSDS and ECSS standards for space mission communication

Full technical compatibility between spacecraft and the station is essential, so it is not enough to rely on standards. Before the spacecraft is launched, a radio frequency (RF) compatibility test (often referred to as RF comptest) is usually performed. This test ensures that the radio interface is working and allows to prepare the station configuration for its use during LEOP. The RF comptest is typically conducted at least six months before the launch, as soon as the so-called “RF suitcase” is available. The RF suitcase contains the flight model of the RF equipment with some parts of the on-board computer (OBC). In some cases, even the entire spacecraft is transported to the ground station for testing. In the latter case, however, a clean room must be available.

It is also important to mention the accuracy of the carrier spacing between signals from multiple satellite antennas or multiple satellites in general, as interferences may occur that render individual or all space links unusable. This can lead to exclusions of up- or downlinks over certain geographical regions or at certain times, which in turn results in specific ground station selection.

A further important aspect for the layout of the GSN is the autonomy of the spacecraft. A satellite with very high autonomy can operate and survive for a long time without commands or surveillance from ground. In such a case the GSN can be very simple for the mission, e.g., with only one antenna and without high redundancy. On the other hand, with low autonomy or critical applications (e.g., precise orbit keeping) the demands on GSN increase. Finally, constraints on board may also require more frequent contact times (e.g., limited data storage on board).

3 Station Communication

The selected ground stations are connected to the control center via a communication network. Different levels of network communication characteristics must be considered and used. Here, the decisions made for a dedicated mission are based on some basic requirements such as the bandwidth needed to support the mission, availability at specific locations and the total cost throughout the mission.

3.1 Communication Paths

Commonly used are so called leased lines, which basically describes the actual technology used, but their name rather describes the type of use (exclusive use for a particular customer or connection). The backbone technology of these lines is in the hands of the telecommunications provider and the spacecraft control center may have a choice to select between different ones. But even if the selection of the actual WAN technology is not possible, we shall know it in order to assess the quality of the connection, which in turn may have influence on operations. Keywords here are SDH (synchronous digital hierarchy), ATM (asynchronous transfer mode) or MPLS (multi-protocol label switching), the last of which is the current state of the art (Fig. 10.3). Previously often used technology of ISDN (Integrated Services Digital Network) has already been decommissioned.

Fig. 10.3

Example of redundant ground station connection. A connection between networks of KSAT (Kongsberg Satellite Services) and GSOC in Oberpfaffenhofen is shown

A specific variant of communication is the so-called roof-to-roof communication, which is typically implemented by VSAT (very small aperture terminal). Here, satellite dishes are installed on the premises of the mission control center (MCC) and its partner center or station and the information exchange is established via a geostationary communication satellite. The advantage is an extremely high flexibility (the MCC can be connected to virtually any point on Earth) at reasonable bandwidths. However, the solution is usually quite expensive (rental of the GEO transponder) and considerable delays in data streaming are introduced.

Although it is not a communication path, but an encryption protocol, a few words about virtual private network (VPN) shall be included here. In most cases, VPN is associated with a connection over the internet. This option may look very attractive because the internet is cheap, offers virtually unlimited bandwidth and is available everywhere. However, also the disadvantages should be considered: the corresponding MCC shares its communication medium with an indefinite number of other users, and there is no support in case of problems. The bandwidth varies constantly, and a good access is site-dependent. VPN can provide a decent data security, but no reliability. Additionally, many operational systems may not be connected directly to a network with Internet access (due to many reasons, like security or above-mentioned availability). For many years, it was generally not recommended to use the internet as a transport technology for real-time TM/TC or other critical applications where reliability, security and data integrity play a role. It is still a viable solution for offline data transfer and for the connection between MCC and the manufacturer site, for simulations and tests with the central checkout system (CCS). This may change now, but still the decision has to be made individually, depending on tradeoff between cost, security and general usability aspects.

Communication for space missions is typically installed with respective redundancy (example shown on Fig. 10.3). Depending on availability, cost factors and considerations like security or physical access, the redundancy may be set up as a combination of previously mentioned technologies (MPLS and VSAT or MPLS and VPN over internet).

3.2 Data Transfer Methods

The data types that are to be exchanged via the communication lines must be considered. Telemetry, telecommand and voice interfaces require a good, reliable real-time connection with medium bandwidth, while the transfer of management information, planning, tracking and pointing can be organized more cost-effectively.

Nowadays, practically all traffic is based on the TCP/IP protocol, whereas in the past some proprietary transport protocols were used (Wikipedia DECnet 2021; Wikipedia X25 2021).

At the application level, the CCSDS Space Link Extension (SLE) standard is widely used for real-time communication, while FTP is the main file transfer mechanism. Here, some changes are expected in the future, especially for file transfer and exchange of management information, the corresponding standardization work is currently being carried out. Further online services and mission operational services will be provided. The use of cloud-based systems, centralized databases and message-based middleware enables a wide range of alternatives to the old-fashioned file transfer via FTP.

When considering the operational aspects of the GSN, it should be remembered that all connections must be tested before LEOP. The arrangement and integration of communication lines and ground stations must be done at the right time. Staff must be trained to operate the network. Procedures for different operational scenarios need to be prepared and validated.

3.3 GSN Examples

Now that we know all aspects of the GSN, we can take a look at the example shown in Fig. 10.4. The GSN and the communication infrastructure for the LEOP of a geostationary satellite are shown. The MCC (in this case the German Space Operations Center—GSOC) is located at the bottom. Solid lines represent voice communication, while dashed lines represent data connections (in the form of real-time TM/TC).

The MCC features a voice communications link, either via a dedicated voice system or telephone, with the launch site, the Weilheim ground station and the respective network management centers of external partners (like PrioraNet, CNES and ISRO). The data connections are implemented completely redundantly via different routes. Weilheim is integrated with two SDH 2 Mbps connections, while the connections to the PrioraNet stations are available via two levels of network management centers (NMCs) with VSAT terminal and ISDN. The CNES and ISRO networks were also integrated with one NMC each.

It can be clearly seen that the expansion of the GSN requires the partnerships with external suppliers and agencies, resulting in a complex network to support spacecraft and increasing overall reliability to a very high level. On the other hand, a such complex network needs to be managed, planned, and maintained. In many cases, it is not the technical aspects but rather the contractual and financial dimensions that are the biggest effort, with questions like: Do we always get the highest priority at the respective station? How much does it cost in the long run? Is it possible to get some discounts if we consolidate our requirements to only one provider? What are the compromises if we decided to exclude a particular station? (Fig. 10.4).

Fig. 10.4

Communication within GSN for the LEOP of a typical GEO mission

3.4 Cloud Based Services

In recent years, many capabilities around cloud computing and cloud services have emerged. This has significantly supported the changes in many areas related to space operations but was so far a rather specific part of the general infrastructure puzzle. This has changed recently with the emergence of cloud-based ground station services (especially Amazon Web Service Ground Station—AWS GS, as described in Gnat et al. 2019). Providers of such services are trying to encapsulate the entire ground station environment and related tasks into one easy-to-use and easy-to-charge unified service that is offered as a commodity. This approach could be interesting, and when setting up the GSN for a mission, the possibilities of such cloud-based services should definitely be considered.

Let's take a quick look at the advantages and disadvantages of a cloud-based solution. It allows customers to easily set up the ground station infrastructure with minimal hardware investment. Due to the fact, that the used systems require very high bandwidth between software defined radio in the cloud and the antenna, ground stations are placed in close proximity to the cloud providers’ existing data centers. The customer books the time on an antenna and plans a contact with the satellite. The downloaded data is immediately inserted into the customer's cloud environment for further processing. In extreme cases, this can reduce the infrastructure required to operate a satellite to a workstation with internet access. In terms of cost, cloud services often do not distinguish between uplinks and downlinks or other variants of space communications. The service itself is charged per unit of time of use (typically per minute) and the cost of the service is relatively low (in the range of $ 3–22 per minute, depending on the service level). This allows new users to get started quite easily, they are no longer tied to a specific location and the services are offered from the cloud. Users can choose the services according to their needs and, for example, apply the “pay-per-use” principle.

There are also some drawbacks of cloud solutions. The most obvious one is that the data is not stored on the operator’s local infrastructure. In many cases, this is not a problem and may even be desirable (due to availability), but there may also be (technical or legal) issues with data ownership, proprietary information, confidentiality and data security. Frequently, the interfaces provided by cloud providers do not correspond exactly to the typical interfaces used so far. In other words, some money can be saved on the ground stations as such, but more investment is required to adapt the interfaces. Cloud providers tend to offer cheap services only if the missions can accept satellite contacts as proposed by the service. As soon as the mission requires its own station usage plan, the price of the service increases. This is obvious because inexpensive services can only be offered if the service provider can maximize the use of his resources, and this can only happen if the operator can independently decide on resource usage.

In the end, each mission has to define how much risk and third-party influence it wants to take in order to reduce overall costs.

4 LEOP and Routine Operations

Within this chapter, we will look a bit more at the operational aspects of the control center infrastructure, network and GSN. The operational work is distributed to several specialized teams, where the so-called ground data systems (GDS) team performs most of the coordination work as well as GSN operations.

The GDS team acts as an interface between the satellite operations teams and the other communication and ground station support groups. It manages the GSN for the satellite missions and is responsible for the interfaces with external partners supporting the missions. In other words, the GDS manages operational internal and external interfaces of MCC.

The GDS accompanies each satellite project within MCC from the very early phases (mission studies, phase A, see Chap. 4) until the very end (phase F, decommissioning). Within the project, the GDS is one of the project’s subsystems, where it works on fulfilling the GDS part of the project requirements, and acts as an expert for GSN and control center infrastructure for the whole MCC for the missions. This construct allows project managers to bundle all communication and infrastructure questions and requests to one person (the designated project responsible from GDS). That person manages and coordinates within his department, to the network and ground station departments or with external partners. This allows high synergy, a high reuse of resources, and an optimal work distribution. Other tasks and areas of responsibility of GDS include:

• Participation in meetings and project reviews (preliminary design review—PDR, critical design review—CDR, technical acceptance review—TAR, etc.)

• Responsibility for the project’s ground station network offline and on console

• Management of interfaces to the external partners, including contractual and technical agreements

• Provision of first level expertise for all network, communication, and infrastructure questions and issues

• Coordination for all operations related activities between all parties

• Preparation of work packages, work package description

• Preparation of cost calculations related to communication and infrastructure

• Preparation of relevant project documentation (requirements, design, test plans, reports, ICDs—interface control documents, DMRs—detailed mission requirements)

• Assessment and implementation of new operational solutions for communication and infrastructure

• Participation in international standardization organizations with operational communication topics.

Most of these tasks, especially the ones related to specific project, are conducted by nominated GDS manager, who in principle plays a role of sub-project manager.

In the example of GSOC, the GDS team includes three specific subgroups, which have their own tasks. Details on the tasks of these subgroups are provided in consecutive sections.

4.1 GDS Engineering Team (NOPE)

The GDS NOPE (network operations project engineer) team is a group of engineers taking care of the technical and organizational tasks related to specific satellite missions. Typically, each mission has a designated GDS engineer who accompanies the project from phase C (see Chap. 4), participates in project meetings, and plays the role of point of contact in the absence of the GDS manager. The most important tasks of the GDS engineers are:

• Mission preparation

• LEOP preparation (configuration, coordination)

• Active mission support during LEOP (also on shift)

• Performance of tests (data flow tests—DFT, connection tests, configuration tests)

• Preparation of the configuration for all data connections for the mission

• Configuration coordination with external partners

• Preparation of reports

• Troubleshooting and failure analysis.

4.2 Systems Team (Network and Systems Control)

The network and systems control (sometimes also called network management center or systems team) is, at least from the communications point of view, in charge of on-console MCC operations. The team consists of a number of operators, who work on shift to cover 24/7 operations, and support engineers who coordinate the shift team and manage the work and operational processes within the network control room (systems room). “Systems” can be compared to a central phone switch board, where all connections (operational and technical) from all MCC control rooms are routed (switched) to the ground stations worldwide. Systems also plays the role of a voice center, as it is permanently staffed and has contact (either via telephone or a special voice system) with all projects and all stations, allowing quick reaction in case of contingencies or emergencies. This function is used to coordinate extraordinary contract requests on holidays or at night, for example, when the scheduling office is not staffed. Tasks of the systems team are:

• Network control during routine operations (establishment of connections on project request and along the schedule)

• Support for NOPE during LEOP

• Monitoring of the connections and network within GSOC and to external partners

• Support of contingency and emergency scheduling and operations.

4.3 Scheduling Office

A dedicated scheduling office is a functionality which becomes necessary with increasing numbers of missions and available antennas of a control center. In principle, every antenna or antenna network is available for multiple missions, especially in terms of cross-support agreements. Therefore, we talk here about a n-to-n resource coordination problem. This is essential to avoid conflicts and to increase synergy between missions, and the scheduling office defines its role in high extend due to this. The scheduling office tasks can be performed by one person and needs to be operated during office hours only. The tasks of scheduling are:

• Reception of ground station support requests from projects and coordination of allocations at the organization’s own and at external ground stations

• Contact planning according to mission requirements applying mission priority rules

• Publishing of the weekly contact plan (schedule) for all MCC missions and resources

• Support and provision of solutions in case of conflicts.

When we look at the operations work aligned to the mission lifetime, most of the work may be divided into three phases: preliminary preparation (design), detailed preparation (design), and mission execution, which contains specific events like a LEOP.

4.4 General Tasks Throughout the Project

In the preliminary preparation phase, the main work focuses mainly on the analysis of the customer requirements. This consists of checking whether the existing system fulfills the requirements or whether changes or upgrades have to be considered. This analysis is important because the latter case will increase the costs. Based on that, detailed requirements for the subsystems are defined.

Another task is to prepare the general design (concept), which includes interface specification. This part is continued in the detailed design definition phase, where also test and verification plans need to be created.

The implementation phase is typically very busy for everybody in a space mission project, which is in particular true for the control center infrastructure, network, GDS and GSN. It is necessary to implement and integrate all subsystems, which encompass hardware, software, and service procurement (like communication lines), installation, and testing. Sometimes, hard- or software has to be delivered to cooperating partners, which means, necessary export licenses have to be issued on time.

Aside from that, the radio frequencies have to be coordinated and licensed. This is typically done at national level for ground stations. The spacecraft owner needs to apply at the International Telecommunication Union (ITU) for the allocation of the communication frequencies.

A specification for external partners needs to be prepared and issued in form of detailed mission requirements (DMR) as well. This, however, can be done only as soon as the respective contracts with these partners are signed. As one can see, there is a lot of paperwork which needs to be taken care of in advance.

At the end of that phase, the complex set of technical and operational tests and validations is performed. It is based on previously prepared test plans, and include all subsystems, from data processing, through communication, and conclude with end to end tests (including all components) and simulations. These, in particular, are important for validation of previously prepared operational procedures (e.g., emergency procedures). Technical and operational staff planning and training are equally important as well.

LEOP marks the border between the preparation phase and routine operations. All systems need to be handed over to the operational team before LEOP, typically performed formally during the operational readiness review (ORR).

During operations (including LEOP), there are a number of tasks performed repeatedly, like scheduling of ground contacts, preparation and execution of passes, reporting, and accounting. At the same time, the whole GSN and MCC infrastructure needs to be monitored and controlled; maintenance needs to be performed. The interfaces to external partners, to all ground stations, and of course the internal interfaces need to be handled. In case of any anomalies and failures, actions need to be performed according to procedures, error reports need to be generated, and any anomaly or failure shall be tracked with a dedicated discrepancy report to avoid such cases in the future.