The first large scale European Space Agency (ESA) mission that will adopt a file bas ed approach to operations is Euclid, which is expected to be launched in 2021 and will explore dark energy and dark matter in order to understand the evolution of the Universe since the Big Bang and, in particular, its present accelerating expansion. It will have an operational orbit around Sun-Earth-Li beration-Point 2 and will generate about 100 GB of science data per day. To transfer these data to ground a high telemetry rate via K-band is required. The weather dependent quality of a K-band link requires a failure detecting downlink protocol with automatic retransmissions of corrupted or missing data segments. For this purpose, the CCSDS File Delivery Protocol (Ref.[1]) (CFDP) class 2 (reliable) has been selected. The operations concept for Euclid is that it will be an "offline" mission, i.e. there is a high level of on-board autonomy for routine operations and failure discovery, isolation and recovery. Scientific data and housekeeping telemetry (instruments and service module) will be recorded in the Mass Memory Unit (MMU) and daily ground contact will be of the order of 4 hours. Data will be downlinked as files from the MMU and telecommands uplinked in files to the Mission Timeline. Due to the guaranteed available bandwi dth between the Operational Control Centre (OCC) and the ground stations to be used for the normal operations phase of the mission (the ESA Deep Space Antennas at Malargüe, Argentina and Cebreros, Spain), it is not possible to rely on all the data being delivered to the OCC in real-time in a reliable way. In view of this, it has been necessary to make some modifications to the way in which the CFDP entity is deployed to cater for this. Essentially this requires the instantiation of a CFDP assembly at the ground station where the downlinked files are reconstituted, whilst CFDP control PDUs are routed to the control system at the OCC for uplink to the spacecraft. The routing of the CFDP PDUs for the uplink is largely a consequence of the use of the CLTU protocol for uplinking -CLTU only supports one command source. No changes to the underlying CFDP protocol are required.

No abstract

This paper describes the migration from the current manual ESTRACK ground station allocation and scheduling process towards an automated approach. The automated approach will finally be implemented by the ESTRACK Management System (EMS), which provides the means to automatically plan ground station allocation, generate executable ground station schedules and monitor correct ground station schedule execution. The migration process will be discussed in the light of the experience gained during the acceptance tests of the first two (out of three) implemented EMS sub-systems, namely the ESTRACK Planning System (EPS) and the ESTRACK Scheduling System (ESS).

In the recent years ESA has adopted the CCSDS Recommendations for Space Link Extension (SLE) transfer services [1] as a standard interface for their TT&C station network (ESTRACK). Both ESA and external space missions interface ESTRACK Network via SLE services, which decouple the ESTRACK Users to a good extent from network implementation details. However, as of today, the SLE User (mission) requires some knowledge of the ground station configuration in order to establish the SLE links to the active communication chain. Furthermore, in case of a failure in the ground station active chain, mission and network operators need to coordinate the eventually required swap to the back-up chain. To overcome this relatively complex process, a discussion to simplify the current approach for the ESA Tracking Network has been started. In this context the idea of SLE Routing has been proposed and analyzed. SLE Routing shall basically route SLE Users' connection to the ground station active chain without requiring the User to know a priori the station configuration; effectively the SLE User connects to the station only. This paper discusses in detail the requirements for the SLE Routing. Reliability and backwards compatibility, as well as failover scenarios and interoperability considerations are covered. We will discuss these requirements in the light of several implementation options. The importance of minimum impact on the current infrastructure to enable a robust, cost-and schedule-efficient solution is highlighted. The paper concludes with the trade-off of the considered options, which range from solutions based on connection routing to dynamic DNS (Domain Name Service) based approaches, and the preferred candidate solution. Finally, the current status is presented.

No abstract