1. INTRODUCTION¶

1.1. Purpose¶

The main purpose of this document is to provide the details of the Mission Planning Interface Point usage by multiple services involved in Copernicus Ground Segment.

1.1.1.1 XML Fixed Header¶

Predicted Orbit File - Fixed Header

XML Tag Name		Value	Description
Level 1	Level 2	Value	Description
File_Name			As defined in section 5.3.1 without EOF extension
File_Description		FOS Predicted Orbit File
Notes		variable	Free text or empty
Mission		Sentinel N#	N indicates spacecraft family: 1, 2, 3 # indicates spacecraft model A, B
File_Class		variable	OPER in routine operations TEST for testing purposes
File_Type		MPL_ORBPRE
Validity_Period
	Validity_Start	variable	UTC Time consistent with validity start date in section 5.3.1. Format: UTC=yyyy-mm-ddThh:mm:ss
	Validity_Stop	variable	UTC Time consistent with validity stop date in section 5.3.1. Format: UTC=yyyy-mm-ddThh:mm:ss
File_Version		variable	Same as described in 5.3.1
Source
	System	FOS
	Creator	variable	Name of tool creating the file (e.g.: NAPEOS)
	Creator_Version	variable
	Creation_Date	variable	Date of file creation. Format: UTC=yyyy-mm-ddThh:mm:ss

1.2. Scope¶

This document is applicable to the Mission Planning Interface Point (MPIP) system, both HTTPS, FTPS, and SFTP servers and to all the MPIP clients.

The main purpose of this document is to describe the relevant policies for data transfer initiators, new data availability, and error handling for each entity interfacing the MPIP.

The main purpose of [AD.1] is to provide the details of the MPIP HTTPS Interfaces and REST API specifications.

The main purpose of [AD.2] is to provide the details of the MPIP FTPS and SFTP Interfaces.

1.3. Applicable and Reference Documents¶

1.3.1. Applicable documents¶

The following documents, of the exact issue shown, form part of this document to the extent specified herein.

Reference	Title	Code	Version	Date
[AD.1]	MPIP Interface Control Document	S12MP_OPMA EV-GMV-ICD- 001	1.2	26/04/2023
[AD.2]	MPIP Interface Control Document for S-3, S-5P and CO2M	S12MP_OPMA EV-GMV-ICD- 002	1.4	26/04/2024
[AD.3]	Earth Explorer File Format Tailoring for the Payload Data Ground Segment for the Sentinel Missions	GMES-GSEG- EOPG-TN- 2010-0099	2.0	13/11/2019
[AD.4]	X-band Ground Station Acquisition Plan Files – File Format Specifications	ESA-EOPG- EOPGCS-SP-1	1.1	11/11/2019
[AD.5]	Sentinels FOS File Format Specification	GM-IC-ESC-FS- 3001	1.9	19/10/2015
[AD.6]	CSC – ESA Framework – Mission Planning Information Overview	ESA-EOPG- EOPGC-TN-50	1.3	15/02/2024
[AD 7]	CO2M Ka-band Ground Station Acquisition Plan Files – File Format Specifications	EUM/COPER- CO2M/SPE/23/ 1370272	1.0	24/08/2023
[AD.8]	Sentinel Expansions FOS File Format Specification	COP-IC-ESC- FS-3001	1.1	29/09/2023

The documents [AD.1] and [AD.2] are complements to this one, with GMV as book captain, the operator of CSC GS Mission Planning service.

1.3.2. Substituted documents¶

The following documents become obsolete as of the release of this document:

Reference	Title	Code	Version	Date
[RD.1]	X-Band Ground Station Data Reception ICD	ESA-EOPG- EOPGM-IF-1	1.1	30/10/2019
[RD.2]	Sentinels to Collaborative Ground Stations ICD	COPE-GSEG- EOPG-ID-15- 0001	1.2	04/08/2018

1.4. Acronyms¶

Acronyms used in this document and needing a definition are included in the following table:

Acronym	Definition
ADGS	Auxiliary Data Gathering Service
API	Application Programming Interface
CD	Coordination Desk
CGS	Core Ground Stations
CO2M	Copernicus Carbon Dioxide Monitoring mission
EDRS	European Data Relay System
EDS	Exchange Data Server
EO	Earth Observation
FOS	Flight Operations Segment
FTPS	File Transfer Protocol Server
GS	Ground System
HKTM	House Keeping Telemetry
HTTPS	Hypertext Transfer Protocol Secure
KML	Keyhole Markup Language
LGS	Local (or Collaborative) Ground Stations
MP	Mission Planning
MPIP	Mission Planning Interface Point
MPC	Mission Performance Cluster
MTL	Mission Planning Timeline (contains MPreport, MP_ALL, SAP, user KML, L0_ACQ, HKTM, EDRS…)
N/A	Not Applicable
NWD	Normal Working Day
OSV	Orbit State Vectors
PDGS	Payload Data Ground Segment
POF	Predicted Orbit File
PPL	Preliminary Pass List
PS	Production Services
REST	Representational State Transfer
S-X	Sentinel satellites
SDP	Station Downlink Plan
SAP	Station Acquisition Plan
SAR	Station Acquisition Report
SPINU	SAP for Inuvik
SPSGS	SAP for Svalbard
SUR	Station Unavailability Report
TBD	To Be Defined
TLE	FOS Two Lines Element File

2. MPIP OVERVIEW¶

2.1. MPIP Interface Details¶

The Mission Planning Interface Point (MPIP) is a repository interface point containing files managed by the Mission Planning operations and required by the various Ground Segment operations consumers. The files metadata and download features are provided by a REST API. Additional service details and API definition can be found in the document [AD.1].

Additional interfaces exposed to MPIP have been implemented for S-3 and S-5P GS to push files via SFTP and FTPS protocol respectively. For each transfer, the data passed across the interface is file based. S-3 and S-5P are linked to MPIP via WAN, over the Internet. The S-3 interface is also planned to be used in the future for CO2M (Copernicus Carbon Dioxide Monitoring mission). Additional details about this interface can be found in the specific document [AD.2].

2.2. Overview of Involved Services¶

2.2.1. Mission Planning (MP)¶

MPIP represents the main data circulation point between all files in relation to the Mission Planning service and all other services involved in Copernicus Ground Segment. As a unified interface, the exchange server will interface in general many data reception subsystems.

MPIP provides two types of interfaces:

HTTPS: for all services except for services using FTPS interface,
SFTP: for S-3 GS as well as for CO2M GS in the future, and
FTPS: for S-5P (GS and CGS services).

A circulation rule is established between servers to guarantee the availability of files in the requested location.

2.2.2. Core (X-band) Ground Stations (CGS)¶

Core (X-band) Ground Station	Username
Inuvik (KSAT)	cgs-inu
Inuvik (DLR)	cgs-ind
Inuvik (SSC)	cgs-ins
Kiruna (Esrange)	cgs-kse
Matera	cgs-mti
Maspalomas	cgs-mps
Neustrelitz	cgs-nsg
Punta Arenas	cgs-par
Svalbard	cgs-sgs
Troll	cgs-tra

2.2.3. Local Ground Stations (LGS)¶

Circulation of files to the local ground stations (also referred to as collaborative ground stations) happens only through MPIP. Local ground stations are applicable only for S-1. The following X-Band Local Ground Stations are considered:

Local Ground Station	Username	Center Code
Athens (Greece)	lgs-ath	ATHL
Brest (France)	lgs-vig	VIGL
Caceres (Spain)	lgs-cac	CACL
Krakow (Poland)	lgs-krk	KRKL
Matera (Italy)	lgs-mti	MTIL
Neustrelitz (Germany)	lgs-nsg	NSGL
Santa Maria (Portugal)	lgs-sma	SMAL
Skarfia (Greece)	lgs-ska	SKAL
Sodankyla (Finland)	lgs-sod	SODL
Svalbard (Norway)	lgs-sgs	SGSL
Puertollano (Spain)	lgs-pue	PUEL
Toulouse (France)	lgs-tls	TLSL
Tromso (Norway)	lgs-trs	TRSL

2.2.4. ADGS¶

The Auxiliary Data Gathering System (ADGS) serves as the single interface point between MPIP and other Copernicus Ground Segment services such as S-1/2 Production Services, MPC, the Reference System, and the Coordination Desk, for sharing the Mission Planning Timeline information.

2.2.5. S-3/S-5P GS (& CO2M GS)¶

The exchange of files with the Core Ground Stations can be done through the MPIP via both HTTPS and FTPS interfaces.

The same procedure as for S-3 will be implemented for CO2M. Details on CO2M interface will be further defined in the future before the launch date of CO2M satellites, currently expected between 2025 and 2026.

2.3. Files Exchange Summary Table¶

The following table describes the files circulation through MPIP involving multiple services of Sentinels Ground System. All files comply with the tailoring of EO File Format Standard for Sentinel Missions PDGS (Payload Data Ground Segment), described in [AD.3].

Service	Direction	File Type	Interface
MP	Push	SAP, SDP, TLE, PPL, MTL, POF	MPIP
ADGS	Retrieve	MTL	MPIP
S-1/S-2 CGS	Retrieve	SAP, TLE, PPL	MPIP
S-1 LGS	Retrieve	SAP, SDP, TLE, POF	MPIP
S-3 GS	Push	SAP (SPSGS) and TLE	MPIP SFTP
S-3 GS	S-3 CGS	Retrieve	MPIP
S-5P GS	Push	SAP (SPINU and SPSGS) and TLE	MPIP FTPS
S-5P CGS	Retrieve		MPIP FTPS/HTTPS
CO2M GS	Push	SAP and TLE	MPIP SFTP
CO2M CGS	Retrieve	SAP and TLE	MPIP

The retrieval of SAR and SUR (e.g., station reports), is not applicable anymore as of the release of this document.

3. HTTPS INTERFACE DESCRIPTION¶

3.1. Station Acquisition Plan (SAP)¶

3.1.1. Interface Summary¶

IF Logical Name	Station Acquisition Plan
Interface Type	File based
Description	Xml file type containing all information relevant to Satellite contacts formatted as a xml hierarchy.
Objective	To provide the mission planned Satellite(s) contacts within a defined time range. This file will support the scheduling of the acquisition systems for each of the satellite contacts defined.
Publication Frequency	Every NWD for S-1/S-3, every day for S-2, every week for S-5P. Note: For S-1, the plan can be sent also during non- working days in case an emergency request is triggered. Note: For CO2M the information is described in [AD- 7].
Coverage	S-1: it covers 12 days of operations. The first acquisition event contained in the file may take place within 8h after the delivery of the file. This first acquisition event is nominally already included in the acquisition plan provided on the previous day. S-2: it covers 6 days of operations. The plan will be provided at least 24 hours before the first acquisition event contained in the file. S-3: it covers 21 days of operations. The plan will be provided at least 24 hours before the first acquisition event contained in the file.
	S-5P: it covers 2 weeks of operations, starting on Monday. The plan is generated once a week, usually on Thursday. CO2M: the information is described in [AD-7].
File Scope	Contains all antenna acquisition segments over the validity period of the file.
Data Volume	~ few MB per file.
Format	[AD.4] ([AD.7] for CO2M)

3.1.2. Protocol¶

Details	Values
Network Protocol	HTTPS
Server	MPIP
File Integrity	Ensured by the HTTPS Protocol
Syntax Check	Data Consumers
Time Outs	No
User Name	See Section 2 for each Ground Station
Password	[provided separately]

3.1.3. Retrieval Procedure¶

An overview of the SAP file retrieval procedure is given here, more details can be found in the document [AD.1].

As an exception, for S-5P CGS can also retrieve this file through MPIP FTPS interface (see Section 4).

3.1.3.1. Authentication¶

The user must be authenticated with a token to use MPIP API. To get this token it is necessary to make a request to the authentication server domain, using the following POST request:

POST /REALMS/MPIP/PROTOCOL/OPENID-CONNECT/TOKEN

Table Error! No text of specified style in document.-1 Request body for Log in API request

Request Body Field	Field Type	Field Description	Value
username	String	Account username	Username delivered by email
password	String	Account password	Credential delivered by email
client_id	String	Id of the client	mpip-api
client_secret	String	Client credential	Secret delivered by email
grant_type	String	Way the authentication server gets the access token	password

Table Error! No text of specified style in document.-2 Request response for Log in API request

Response Field	Field Type	Field Description
authToken	String	Authentication token

3.1.3.2. Search¶

To search available SAP files published after a specific date, the following POST request shall be used:

POST /mpip/file

With request body

code¶

{
    "filetypes": [
        "X"
    ],
    "extensions": [
        "EOF"
    ],
    "platform": [
        "S1A"
    ],
    "ingestionDate": "2023-01-31T00:00:00.000+00:00"
}

With filetype X, “MPL_SPL” for local ground stations, and “MPL_SP” for core ground stations.

Please note that request body accepts other fields to filter data. A complete description can be found in [AD.1].

The response body will contain the following info:

Response Field	Field Type	Field Description
files	Array	List of objects containing information about the files matching the request filtering criteria. The file metadata will display the following fields: - Filetype - Extension - Platform - File class (if available) - Filename - Validity Start Date (if available) - Validity Stop Date (if available) - EDRS Creation Date (if available) - Session ID (if available) - Active - Version (if available) - The ingest date

Where “filename” can be used to downlink the file as explained below.

3.1.3.3. Download¶

The operation to download one or more files is based on a list of filenames. The following GET request shall be used:

GET /mpip/download

If the list of filenames contains one filename it will download the file. If the list of filenames contains more than one file name, the MPIP will generate a zip file with the files entered by the user. The filename of the download zip follows the format “mpip_download_currentDate.zip”.

Request example to download one file:

GET 'https://MPIPHOS/mpip/download?filename=S2B_OPER_MPL_SPSGS_20220405T000000_V20220405T160000_20220417T180000.EOF’

Response example of downloading one file:

The relevant download file will have this name:

S2B_OPER_MPL_SPSGS_20220405T000000_V20220405T160000_20220417T180000.EOF

3.2. Preliminary Pass List (PPL)¶

3.2.1. Interface Summary¶

IF Logical Name	Preliminary Pass List
Interface Type	File based
Description	Xml file type
Objective	To provide the requested Satellite(s) contacts within a defined time range (mid-term booking). File contains all antenna acquisition segments over the validity period of the file.
Publication Frequency	Weekly, every Monday at noon
Coverage	S-1: not used S-2: it covers 10 days of operations. The plan will be provided at least one week before the first acquisition event containing the file. In case of not consolidated information the creation of the preliminary plan can miss the foreseen generation frequency. In any case the next available plan will be generated and circulated on next Monday at noon. S-3: not used S-5P: not used CO2M: not used
File Scope	Contains all antenna acquisition segments over the validity period of the file.
Data Volume	~ few MB per file.
Format	[AD.4]

3.2.2. Protocol¶

Details	Values
Network Protocol	HTTPS
Server	MPIP
File Integrity	Ensured by the HTTPS Protocol
Syntax Check	Data Consumers
Time Outs	No
User Name	See Section 2 for each Core Ground Station
Password	[provided separately]

3.2.3. Retrieval Procedure¶

An overview of the PPL file retrieval procedure is given here, more details can be found in the document [AD.1].

3.2.3.1. Authentication¶

The user must be authenticated with a token to use MPIP API. To get this token it is necessary to make a request to the authentication server domain, using the following POST request:

POST /REALMS/MPIP/PROTOCOL/OPENID-CONNECT/TOKEN

Table Error! No text of specified style in document.-3 Request body for Log in API request

Request Body Field	Field Type	Field Description	Value
username	String	Account username	Username delivered by email
password	String	Account password	Credential delivered by email
client_id	String	Id of the client	mpip-api
client_secret	String	Client credential	Secret delivered by email
grant_type	String	Way the authentication server gets the access token	password

Table Error! No text of specified style in document.-4 Request response for Log in API request

Response Field	Field Type	Field Description
authToken	String	Authentication token

3.2.3.2. Search¶

To search available PPL files published after a specific date, the following POST request shall be used:

POST /mpip/file

With request body

code¶

{
    "filetypes": [
        "MPL_PP"
    ],
    "extensions": [
        "EOF"
    ],
    "platform": [
        "S2A"
    ],
    "ingestionDate": "2023-01-31T00:00:00.000+00:00"
}

Please note that request body accepts other fields to filter data. A complete description can be found in [AD.1].

The response body will contain the following info:

Response Field	Field Type	Field Description
files	Array	List of objects containing information about the files matching the request filtering criteria. The file metadata will display the following fields: - Filetype - Extension - Platform - File class (if available) - Filename - Validity Start Date (if available) - Validity Stop Date (if available) - EDRS Creation Date (if available) - Session ID (if available) - Active - Version (if available) - The ingest date

Where “filename” can be used to downlink the file as explained below.

3.2.3.3. Download¶

The operation to download one or more files is based on a list of filenames. The following GET request shall be used:

GET /mpip/download

If the list of filenames contains one filename it will download the file. If the list of filenames contains more than one file name, the MPIP will generate a zip file with the files entered by the user. The filename of the download zip follows the format “mpip_download_currentDate.zip”.

3.3. TLE Predicted Orbit (TLE)¶

3.3.1. Interface Summary¶

IF Logical Name	TLE Predicted Orbit
Interface Type	File based - tar-gzipped packaged file.
Description	ZIP file type (standard filename is <FOS_TLE_Filename>.TGZ). See [AD.5] ([AD.8] for CO2M) for the ZIP package and naming description. The file contains the orbit predicted by the FOS, defined as standard Two-line elements set covering the file applicability period.
Objective	To provide the station with predicted Two-line Elements for the Spacecraft. This file will support the management of the antennas according to the relevant spacecraft orbit.
Publication Frequency	Daily
Coverage	Configurable (typically one week forward from TLE creation date/time).
File Scope	Contains the orbit predicted by the FOS over the validity period of the file, defined as a standard Two- line elements set.
Data Volume	~ few MB per file.
Format	[AD.5] ([AD.8] for CO2M)

3.3.2. Protocol¶

Details	Values
Network Protocol	HTTPS
Server	MPIP
File Integrity	Ensured by the HTTPS Protocol
Syntax Check	Data Consumers
Time Outs	No
User Name	See Section 2 for each Core Ground Station
Password	[provided separately]

3.3.3. Retrieval Procedure¶

An overview of the TLE file retrieval procedure is given here, more details can be found in the document [AD.1].

As an exception, for S-5P CGS can also retrieve this file through MPIP FTPS interface (see Section 4).

3.3.3.1. Authentication¶

The user must be authenticated with a token to use MPIP API. To get this token it is necessary to make a request to the authentication server domain, using the following POST request:

POST /REALMS/MPIP/PROTOCOL/OPENID-CONNECT/TOKEN

Table Error! No text of specified style in document.-5 Request body for Log in API request

Request Body Field	Field Type	Field Description	Value
username	String	Account username	Username delivered by email
password	String	Account password	Credential delivered by email
client_id	String	Id of the client	mpip-api
client_secret	String	Client credential	Secret delivered by email
grant_type	String	Way the authentication server gets the access token	password

Table Error! No text of specified style in document.-6 Request response for Log in API request

Response Field	Field Type	Field Description
authToken	String	Authentication token

Authentication request example:

code¶

POST 'https://keycloak.s12mpip.com/realms/mpip/protocol/openid-connect/token'

header 'Content-Type: application/x-www-form-urlencoded'

{'client_id':'mpip-api' 

'client_secret': 'client-secret-received'
'username': 'username-received'
'password': 'password-received'
'grant_type': 'password'}

3.3.3.2. Search¶

To search available TLE files published after a specific date, the following POST request shall be used:

POST /mpip/file

With request body

code¶

{
    "filetypes": [
        "TLEPRE"
    ],
    "extensions": [
        "TGZ"
    ],
    "platform": [
        "S1A"
    ],
    "ingestionDate": "2023-01-31T00:00:00.000+00:00"
}

Please note that request body accepts other fields to filter data. A complete description can be found in [AD.1].

The response body will contain the following info:

Response Field	Field Type	Field Description
files	Array	List of objects containing information about the files matching the request filtering criteria. The file metadata will display the following fields: - Filetype - Extension - Platform - File class (if available) - Filename - Validity Start Date (if available) - Validity Stop Date (if available) - EDRS Creation Date (if available) - Session ID (if available) - Active - Version (if available) - The ingest date

Where “filename” can be used to downlink the file as explained below.

3.3.3.3. Download¶

The operation to download one or more files is based on a list of filenames. The following GET request shall be used:

GET /mpip/download

If the list of filenames contains one filename it will download the file. If the list of filenames contains more than one file name, the MPIP will generate a zip file with the files entered by the user. The filename of the download zip follows the format “mpip_download_currentDate.zip”.

3.4. Station Downlink Plan (SDP)¶

This file is only retrieved by S-1 Local Ground Stations.

3.4.1. Interface Summary¶

IF Logical Name	Station Downlink Plan
Interface Type	File based – Xml file type
Description	A Downlink Plan will contain planned data stream
Objective	This interface provides a Local Ground Station with planned Local Ground Station acquisitions for Sentinel-1 in direct downlink-mode.
Publication Frequency	Frequency depends on the actual planning over the LGS, it may be LGS dependant (typically once per NWD).
Coverage	S-1: it covers 12 days of operations. The first acquisition event contained in the file may take place within 8h after the delivery of the file. This first acquisition event is nominally already included in the acquisition plan provided on the previous day.
File Scope	It contains information on data takes downlinked over the LGS. Only data takes in direct-downlink mode
	(PASS THROUGH) over the LGS are included in this file.
Data Volume	~ few kB per file.
Format	Annex A

3.4.2. Protocol¶

Details	Values
Network Protocol	HTTPS
Server	MPIP
File Integrity	Ensured by the HTTPS Protocol
Syntax Check	Data Consumers
Time Outs	No
User Name	See Section 2 for each Local Ground Station
Password	[provided separately]

3.4.3. Retrieval Procedure¶

An overview of the SDP file retrieval procedure is given here, more details can be found in the document [AD.1].

3.4.3.1. Authentication¶

The user must be authenticated with a token to use MPIP API. To get this token it is necessary to make a request to the authentication server domain, using the following POST request:

POST /REALMS/MPIP/PROTOCOL/OPENID-CONNECT/TOKEN

Table Error! No text of specified style in document.-7 Request body for Log in API request

Request Body Field	Field Type	Field Description	Value
username	String	Account username	Username delivered by email
password	String	Account password	Credential delivered by email
client_id	String	Id of the client	mpip-api
client_secret	String	Client credential	Secret delivered by email
grant_type	String	Way the authentication server gets the access token	password

Table Error! No text of specified style in document.-8 Request response for Log in API request

Response Field	Field Type	Field Description
authToken	String	Authentication token

3.4.3.2. Search¶

To search available SDP files published after a specific date, the following POST request shall be used:

POST /mpip/file

With request body

code¶

{
    "filetypes": [
        "MPL_DPL"
    ],
    "extensions": [
        "EOF"
    ],
    "platform": [
        "S1A"
    ],
    "ingestionDate": "2023-01-31T00:00:00.000+00:00"
}

Please note that request body accepts other fields to filter data. A complete description can be found in [AD.1].

The response body will contain the following info:

Response Field	Field Type	Field Description
files	Array	List of objects containing information about the files matching the request filtering criteria. The file metadata will display the following fields: - Filetype - Extension - Platform - File class (if available) - Filename - Validity Start Date (if available) - Validity Stop Date (if available) - EDRS Creation Date (if available) - Session ID (if available)
		- Active - Version (if available) - The ingest date

Where “filename” can be used to downlink the file as explained below.

3.4.3.3. Download¶

The operation to download one or more files is based on a list of filenames. The following GET request shall be used:

GET /mpip/download

If the list of filenames contains one filename it will download the file. If the list of filenames contains more than one file name, the MPIP will generate a zip file with the files entered by the user. The filename of the download zip follows the format “mpip_download_currentDate.zip”.

3.5. Mission Planning Timeline (MPL_TIMELINE)¶

3.5.1. Interface Summary¶

IF Logical Name	Mission Planning Timeline
Interface Type	File based
Description	Folder compressed in a .tgz file
Objective	The Mission Planning Timeline contains the instrument acquisition schedule and the satellite downlink activities over the available Ground Segment acquisition resources.
Publication Frequency	S-1: daily S-2: weekly
Coverage	S-1: one cycle (12 days) S-2: nominally 2 cycles (20 days)
File Scope	Contains various files, depending on the satellite, as defined in [AD.6]
Data Volume	~1MB
Format	[AD.6]

3.5.2. Protocol¶

Details	Values
Network Protocol	HTTPS
Server	MPIP
File Integrity	Ensured by the HTTPS Protocol
Syntax Check	Data Consumers
Time Outs	No
User Name	adgs-user
Password	[provided separately]

3.5.3. Retrieval Procedure¶

An overview of the MTL file retrieval procedure is given here, more details can be found in the document [AD.1].

3.5.3.1. Authentication¶

The user must be authenticated with a token to use MPIP API. To get this token it is necessary to make a request to the authentication server domain, using the following POST request:

POST /REALMS/MPIP/PROTOCOL/OPENID-CONNECT/TOKEN

Table Error! No text of specified style in document.-9 Request body for Log in API request

Request Body Field	Field Type	Field Description	Value
username	String	Account username	Username delivered by email
password	String	Account password	Credential delivered by email
client_id	String	Id of the client	mpip-api
client_secret	String	Client credential	Secret delivered by email
grant_type	String	Way the authentication server gets the access token	password

Table Error! No text of specified style in document.-10 Request response for Log in API request

Response Field	Field Type	Field Description
authToken	String	Authentication token

3.5.3.2. Search¶

To search available MTL files published after a specific date, the following POST request shall be used:

POST /mpip/file

With request body

code¶

{
    "filetypes": [
        "MPL_TIMELINE"
    ],
    "extensions": [
        "tgz"
    ],
    "platform": [
        "S2A"
    ],
    "ingestionDate": "2023-01-31T00:00:00.000+00:00"
}

Please note that request body accepts other fields to filter data. A complete description can be found in [AD.1].

The response body will contain the following info:

Response Field	Field Type	Field Description
files	Array	List of objects containing information about the files matching the request filtering criteria. The file metadata will display the following fields: - Filetype - Extension - Platform - File class (if available) - Filename - Validity Start Date (if available) - Validity Stop Date (if available) - EDRS Creation Date (if available) - Session ID (if available) - Active - Version (if available) - The ingest date

Where “filename” can be used to downlink the file as explained below.

3.5.3.3. Download¶

The operation to download one or more files is based on a list of filenames. The following GET request shall be used:

GET /mpip/download

If the list of filenames contains one filename it will download the file. If the list of filenames contains more than one file name, the MPIP will generate a zip file with the files entered by the user. The filename of the download zip follows the format “mpip_download_currentDate.zip”.

3.6. Predicted Orbit File (POF)¶

3.6.1. Interface Summary¶

IF Logical Name	Predicted Orbit File
Interface Type	File based – Xml file type
Description	This file contains the Orbit State Vectors (OSV) predicted by the FOS based on the orbit determination. The OSVs are at epochs of ascending node crossings (i.e., one per orbital revolution). The State Vectors will be in the reference frame specified in the variable header.
Objective	The file may be used by the LGS for X-Band station antenna planning.
Publication Frequency	Daily
Coverage	Configurable S-1: it covers one week of OSVs with span of one state vector per orbit.
File Scope	Contains the orbit state vector predicted by the FOS over the validity period of the file.
Data Volume	~ few MB per file.
Format	Annex B

3.6.2. Protocol¶

Details	Values
Network Protocol	HTTPS
Server	MPIP
File Integrity	Ensured by the HTTPS Protocol
Syntax Check	Data Consumers
Time Outs	No
User Name	See Section 2 for each Local Ground Station
Password	[provided separately]

3.6.3. Retrieval Procedure¶

An overview of the POF file retrieval procedure is given here, more details can be found in the document [AD.1].

3.6.3.1. Authentication¶

The user must be authenticated with a token to use MPIP API. To get this token it is necessary to make a request to the authentication server domain, using the following POST request:

POST /REALMS/MPIP/PROTOCOL/OPENID-CONNECT/TOKEN

Table Error! No text of specified style in document.-11 Request body for Log in API request

Request Body Field	Field Type	Field Description	Value
username	String	Account username	Username delivered by email
password	String	Account password	Credential delivered by email
client_id	String	Id of the client	mpip-api
client_secret	String	Client credential	Secret delivered by email
grant_type	String	Way the authentication server gets the access token	password

Table Error! No text of specified style in document.-12 Request response for Log in API request

Response Field	Field Type	Field Description
authToken	String	Authentication token

3.6.3.2. Search¶

To search available POF files published after a specific date, the following POST request shall be used:

POST /mpip/file

With request body

code¶

{
    "filetypes": [
        "ORBPRE"
    ],
    "extensions": [
        "EOF"
    ],
    "platform": [
        "S1A"
    ],
    "ingestionDate": "2023-01-31T00:00:00.000+00:00"
}

Please note that request body accepts other fields to filter data. A complete description can be found in [AD.1].

The response body will contain the following info:

Response Field	Field Type	Field Description
files	Array	List of objects containing information about the files matching the request filtering criteria. The file metadata will display the following fields: - Filetype - Extension - Platform - File class (if available) - Filename - Validity Start Date (if available) - Validity Stop Date (if available) - EDRS Creation Date (if available) - Session ID (if available) - Active - Version (if available) - The ingest date

Where “filename” can be used to downlink the file as explained below.

3.6.3.3. Download¶

The operation to download one or more files is based on a list of filenames. The following GET request shall be used:

GET /mpip/download

If the list of filenames contains one filename it will download the file. If the list of filenames contains more than one file name, the MPIP will generate a zip file with the files entered by the user. The filename of the download zip follows the format “mpip_download_currentDate.zip”.

4. SFTP/FTPS INTERFACES DESCRIPTION¶

4.1. Station Acquisition Plan (SAP)¶

4.1.1. Interface Summary¶

IF Logical Name	Station Acquisition Plan
Interface Type	File based
Description	Xml file type containing all information relevant to Satellite contacts formatted as a xml hierarchy.
Objective	To provide the mission planned Satellite(s) contacts within a defined time range. This file will support the scheduling of the antennas according to the Satellite(s) contacts.
Publication Frequency	Event driven. Every NWD for S-3, every week for S- 5P. Note: For CO2M the information is described in [AD- 7].
Coverage	S-3: it covers 21 days of operations. The plan will be provided at least 24 hours before the first acquisition event contained in the file. S-5P: it covers 2 weeks of operations, starting on Monday. The plan is generated once a week, usually on Thursday. Note: For CO2M the information is described in [AD- 7].
File Scope	Contains all antenna acquisition segments over the validity period of the file.
Data Volume	~ few MB per file.
Format	[AD.4] ([AD 7] for CO2M)

4.1.2. Protocol¶

Source	Data Circulation S/S	Destination	MPIP
Details		Values
Network Protocol		SFTP(S-3)/FTPS(S-5
Method		PUSH
Temp. files		“.filename”
Server		MPIP
Client		Data Circulation S/S
Transfer Initiator		Data Circulation S/S
File Integrity		Ensured by the SFTP(S-3)/FTPS(S-5P) Protocol
Syntax Chec		Data Consumers
Communication Errors handling		Alarms raised by Data Circulation S/S
Time Outs		No

Exceptional protocol applicable to the retrieval of S-5P files from some CGS:

Source	MPIP	Destination	Data Reception S/S
Details		Values
Network Protocol		FTPS
Method		PULL
Server		MPIP FTPS
Client		Data Reception S/S
Transfer Initiator		Data Reception S/S
File Integrity		Ensured by the FTPS Protocol
Syntax Chec		Data Reception S/S
Communication Errors handling		Alarms raised by Data Reception S/S
Time Outs		Data Reception S/S

4.1.3. Details¶

Data Circulation Client Details
Parameter	Value
User Name	s3pdgs
Password	[provided separately]
Path	/eds/cgs-sgs/STATION_ACQUISITION_PLAN/
Parameter	Value
User Name	s5ppdgs
Password	[provided separately]
Path	/eds/[cgs-sgs, cgs-ins, cgs-ind]/STATION_ACQUISITION_PLAN/

User name and path for CO2M are TBD.

Only applicable to S-5P (some CGS files retrieved through FTPS):

Data Reception Client Details
Parameter	Value
User Name	See Section 2 for each Ground Station
Password	[provided separately]
Path	/eds/[cgs-sgs, cgs-ind]/STATION_ACQUISITION_PLAN/

4.2. TLE Predicted Orbit (TLE)¶

4.2.1. Interface Summary¶

IF Logical Name	TLE Predicted Orbit
Interface Type	File based - tar-gzipped packaged file.
Description	ZIP file type (standard filename is <FOS_TLE_Filename>.TGZ). See [AD.5] ([AD.8] for CO2M) for the ZIP package and naming description.
	The file contains the orbit predicted by the FOS, defined as standard Two-line elements set covering the file applicability period.
Objective	To provide the station with predicted Two-line Elements for the Spacecraft. This file will support the management of the antennas according to the relevant spacecraft orbit.
Publication Frequency	Daily
Coverage	Configurable (typically one week forward from TLE creation date/time).
File Scope	Contains the orbit predicted by the FOS over the validity period of the file, defined as a set of Two-line elements set.
Data Volume	~ few MB per file.
Format	[AD.5] ([AD.8] for CO2M)

4.2.2. Protocol¶

Source	Data Circulation S/S	Destination	MPIP
Details		Values
Network Protocol		SFTP(S-3)/FTPS(S-5P)
Method		PUSH
Temp. files		“.filename”
Server		MPIP
Client		Data Circulation S/S
Transfer Initiator		Data Circulation S/S
File Integrity		Ensured by the SFTP(S-3)/FTPS(S-5P) Protocol
Syntax Check		Data Consumers
Communication Errors handling		Alarms raised by Data Circulation S/S
Time Outs		No

Exceptional protocol applicable to the retrieval of S-5P files from some CGS:

Source	MPIP	Destination	Data Reception S/S
Details		Values
Network Protocol		FTPS
Method		PULL
Server		MPIP FTPS
Client		Data Reception S/S
Transfer Initiator		Data Reception S/S
File Integrity		Ensured by the FTPS Protocol
Syntax Check		Data Reception S/S
Communication Errors handling		Alarms raised by Data Reception S/S
Time Outs		Data Reception S/S

4.2.3. Details¶

Data Circulation Client Details
Parameter	Value
User Name	s3pdgs
Password	[provided separately]
Path	/eds/cgs-sgs/FOS_TLE_PREDICTED_ORBIT/
Parameter	Value
User Name	s5ppdgs
Password	[provided separately]
Path	/eds/[cgs-sgs, cgs-ins, cgs-ind]/FOS_TLE_PREDICTED_ORBIT/

User name and path for CO2M are TBD.

Only applicable to S-5P (some CGS files retrieved through FTPS):

Data Reception Client Details
Parameter	Value
User Name	See Section 2 for each Ground Station
Password	[provided separately]
Path	/eds/[cgs-sgs, cgs-ind]/FOS_TLE_PREDICTED_ORBIT/

5. ANNEXES¶

5.1. Annex A: SDP File Format¶

5.1.1. Naming convention¶

The filename convention is as follows:

MMM_CCCC_MPL_DP###_PDMC_yyyymmddThhmmss_VyyyymmddThhmmss_YYYY MMDDTHHMMSS.EOF

Where:

MMM is the Mission ID S1A is for Sentinel 1A S1C is for Sentinel 1C

CCCC is the File Class OPER for “Routine Operations” files

### is the LGS identification as defined in Section 2.2.3

yyyymmddThhmmss is the creation date of the file

yyyymmddThhmmss is the validity Start Time of the planning file

YYYYMMDDTHHMMSS is the validity End Time of the planning file

Example:

S1A_OPER_MPL_DPMTIL_PDMC_20160601T120000_V20160613T121100_20160625T14 1100.EOF

S1A_OPER_MPL_DPNSGL_PDMC_20160601T120000_V20160613T121100_20160625T1 41100.EOF

S1A_OPER_MPL_DPTRSL_PDMC_20150601T120000_V20150613T121100_20150625T14 1100.EOF

S1A_OPER_MPL_DPVIGL_PDMC_20150601T120000_V20150613T121100_20150625T14 1100.EOF

S1A_OPER_MPL_DPSMAL_PDMC_20160601T120000_V20160613T121100_20160625T1 41100.EOF

S1A_OPER_MPL_DPSODL_PDMC_20160601T120000_V20160613T121100_20160625T1 41100.EOF

S1A_OPER_MPL_DPSGSL_PDMC_20160601T120000_V20160613T121100_20160625T14 1100.EOF

S1C_OPER_MPL_DPSMAL_PDMC_20160601T120000_V20160613T121100_20160625T1 41100.EOF S1C_OPER_MPL_DPSODL_PDMC_20160601T120000_V20160613T121100_20160625T1 41100.EOF S1C_OPER_MPL_DPSGSL_PDMC_20160601T120000_V20160613T121100_20160625T1 41100.EOF S1C_OPER_MPL_DPPUEL_PDMC_20160601T120000_V20160613T121100_20160625T14 1100.EOF S1C_OPER_MPL_DPPUEL_PDMC_20160601T120000_V20160613T121100_20160625T14 1100.EOF S1C_OPER_MPL_DPTLSL_PDMC_20180701T120000_V20180713T121100_20180725T14 1100.EOF S1C_OPER_MPL_DPTLSL_PDMC_20180701T120000_V20180713T121100_20180725T14 1100.EOF

5.1.2. Data Structure and Definition¶

The Station Downlink Plan is a XML file in EOF format.

The following two data structures are specified:

XML Header (Fixed and Variable headers)
Data Block (section inside the XML file)

5.1.2.1. XML Fixed Header¶

Station Downlink Plan Fixed Header

XML Tag Name Level 1	Level 2	Value	Description
File_Name			As defined in Section 5.1.1 without the extension.
File_Description		DownlinkPlan File
Notes		Variable	Free Text
Mission		Sentinel N#	N indicates the spacecraft family; 1 # indicates the spacecraft model; A, B
File_Class		Variable	Consistent with file class in Section 5.1.1 e.g. “OPER”
File_Type		MPL_DP####	Same as File Type in Section 5.1.1
Validity_Period
	Validity_Start	Variable	UTC time consistent with Validity Start Date in Section 5.1.1 Format: UTC=yyyy-mm-ddThh:mm:ss
	Validity_Stop	Variable	UTC time consistent with Validity Stop Date in Section 5.1.1 Format: UTC=yyyy-mm-ddThh:mm:ss
File_ Version		0001	These files will not be revised by version
Source
	System	PDMC	Code of the centre in which the file has been generated.
	Creator	MPL	Name of the SW tool used to create the final file
	Creator_Version	Variable	Version of the SW tool used to create the final file
	Creation_Date	Variable	Date of creation of the file, in CCSDS ASCII format, same as Creation Date in File Name

Station DownlinkPlan Variable Header

XML Tag Name
Level 1

Level 2

Value

Description

The Variable Header is empty.

5.1.2.2. XML Data Block¶

The Data Block is composed by an XML structure as specified in the following table:

Station Downlink Plan - Data Block

Level	Field name	Format	Description
0	List_Of_Downlinks	-	XML root tag
1	\|› Downlink, attribute “orbitNumber”	Number	Absolute orbit number for the downlink pass
2	\|› Channel, attribute “number”	Number	Possible values: 1 or 2
3	\|› List_Of_Datatakes	-
4	\|› Datatake	-
5	\|› Datatake_Id_Dec	Number	Mission Data take unique identifier in decimal
5	\|› Datatake_Id_Hex	Number	Mission Data take unique identifier in hexadecimal
5	\|› VCID	Number	Virtual Channel ID corresponding to the on board Packet Store ID
5	\|› APID	Number	SAR APID
5	\|› Mode	String	Instrument mode for the datatake. Possible values: IW or EW or S1…S6
5	\|› Polarisation	String	Datatake polarisation. Possible values: • HH (for the HH component of a dual polarisation HH-HV datatake) • HV (for the HV component of a dual polarisation HH-HV datatake) • VV (for the VV component of a dual polarisation VV-VH datatake) • VH (for the VH component of a dual polarisation VV-VH datatake) • SH (for a single polarisation HH datatake) • SV (for a single polarisation VV datatake)
5	\|› Sensing_Start	CCSDS ASCII format	Data take sensing start time in UTC (approximate time): UTC=<YYYY>-<MM>-<DD>T<hh:mm:ss.sss>
5	\|› Sensing_Stop	CCSDS ASCII format	Data take sensing stop time in UTC (approximate time): UTC=<YYYY>-<MM>-<DD>T<hh:mm:ss.sss>
5	\|› Downlink_Start	CCSDS ASCII format	Data take downlink start time UTC (approximate time): UTC=<YYYY>-<MM>-<DD>T<hh:mm:ss.sss>
5	\|› Downlink_Stop	CCSDS ASCII format	Data take downlink stop time UTC (approximate time): UTC=<YYYY>-<MM>-<DD>T<hh:mm:ss.sss>

5.1.3. File Example¶

code¶

<?xml version="1.0" ?>
<earth_explorer_file xmlns="http://eop-cfi.esa.int/CFI">
  <earth_explorer_header>
    <fixed_header>
      <file_name>S1A_OPER_MPL_DPVIGL_PDMC_20150601T120000_V20150613T121100_20150625T141100</file_name>
      <file_description>Downlink Plan File</file_description>
      <notes/>
      <mission>S1A</mission>
      <file_class>OPER</file_class>
      <file_type>MPL_DPVIGL</file_type>
      <validity_period>
        <validity_start>UTC=2013-06-13T12:11:00</validity_start>
        <validity_stop>UTC=2013-06-25T14:11:00</validity_stop>
      </validity_period>
      <file_version>0001</file_version>
      <source>
        <system>PDMC</system>
        <creator>MPL</creator>
        <creator_version>300</creator_version>
        <creation_date>UTC=2013-06-01T12:00:00</creation_date>
      </source>
    </fixed_header>
    <variable_header/>
  </earth_explorer_header>
  <data_block type="xml">
    <list_of_downlinks>
      <downlink orbitnumber="1340">
        <channel number="1">
          <list_of_datatakes>
            <datatake>
              <datatake_id_dec>34</datatake_id_dec>
              <datatake_id_hex>22</datatake_id_hex>
              <vcid>39</vcid>
              <apid>1052</apid>
              <mode>IW</mode>
              <polarisation>HH</polarisation>
              <sensing_start>UTC=2015-06-14T11:25:07.130</sensing_start>
              <sensing_stop>UTC=2015-06-14T11:25:10.130</sensing_stop>
              <downlink_start>UTC=2015-06-14T11:25:07.130</downlink_start>
              <downlink_stop>UTC=2015-06-14T11:25:10.130</downlink_stop>
            </datatake>
            <datatake>
              <datatake_id_dec>35</datatake_id_dec>
              <datatake_id_hex>23</datatake_id_hex>
              <vcid>39</vcid>
              <apid>1052</apid>
              <mode>EW</mode>
              <polarisation>HH</polarisation>
              <sensing_start>UTC=2015-06-15T11:25:18.000</sensing_start>
              <sensing_stop>UTC=2015-06-15T11:27:00.000</sensing_stop>
              <download_start>UTC=2015-06-15T11:25:18.000</download_start>
              <download_stop>UTC=2015-06-15T11:27:00.000</download_stop>
            </datatake>
            ...
            <datatake>
              <datatake_id_dec>37</datatake_id_dec>
              <datatake_id_hex>25</datatake_id_hex>
              <vcid>39</vcid>
              <apid>1052</apid>
              <mode>IW</mode>
              <polarisation>SV</polarisation>
              <sensing_start>UTC=2015-06-17T11:30:20.000</sensing_start>
              <sensing_stop>UTC=2015-06-17T11:35:20.000</sensing_stop>
              <download_start>UTC=2015-06-17T11:30:20.000</download_start>
              <download_stop>UTC=2015-06-17T11:35:20.000</download_stop>
            </datatake>
          </list_of_datatakes>
        </channel>
        <channel number="2">
          <list_of_datatakes>
            <datatake>
              <datatake_id_dec>34</datatake_id_dec>
              <datatake_id_hex>22</datatake_id_hex>
              <vcid>40</vcid>
              <apid>1052</apid>
              <mode>IW</mode>
              <polarisation>HV</polarisation>
              <sensing_start>UTC=2015-06-14T11:25:07.130</sensing_start>
              <sensing_stop>UTC=2015-06-14T11:25:10.130</sensing_stop>
              <download_start>UTC=2015-06-14T11:25:07.130</download_start>
              <download_stop>UTC=2015-06-14T11:25:10.130</download_stop>
            </datatake>
            <datatake>
              <datatake_id_dec>35</datatake_id_dec>
              <datatake_id_hex>23</datatake_id_hex>
              <vcid>41</vcid>
              <apid>1052</apid>
              <mode>EW</mode>
              <polarisation>HV</polarisation>
              <sensing_start>UTC=2015-06-15T11:25:18.000</sensing_start>
              <sensing_stop>UTC=2015-06-15T11:27:00.000</sensing_stop>
              <downlink_start>UTC=2015-06-15T11:25:18.000</downlink_start>
              <downlink_stop>UTC=2015-06-15T11:27:00.000</downlink_stop>
            </datatake>
          </list_of_datatakes>
        </channel>
      </downlink>
    </list_of_downlinks>
  </data_block>
</earth_explorer_file>

5.2. Annex B: POF File Format¶

5.2.1. Naming Convention¶

The filename convention is as follows:

MMM_CCCC_MPL_ORBPRE_yyyymmddThhmmss_YYYYMMDDTHHMMSS_0001.EOF

Where:

MMM is the Mission ID S1A is for Sentinel 1A S1C is for Sentinel 1C

CCCC is the File Class OPER for “Routine Operations” files

MPL_ORBPRE is the file-type for FOS Predicted Orbit OSV

yyyymmddThhmmss is the Start Validity Time of the file YYYYMMDDTHHMMSS is the Stop Validity Time of the file

vvvv is the value of the version of the generated file starting from 0001 and incremented by one any time a file with the same validity is regenerated.

Example: S1A_OPER_MPL_ORBPRE_20150408T200548_20150415T200548_0001.EOF

5.2.2. Data Structure and definition¶

The FOS Predicted Orbit is a XML file in EOF format.

The following two data structures are specified:

XML Header (Fixed and Variable headers)
Data Block (section inside the XML file)

5.2.2.1. XML Variable Header¶

Predicted Orbit File - Variable Header

XML Tag Name		Value	Description
Level 1	Level 2	Value	Description
Ref_Frame		variable	OSV coordinate system reference frame. It can be one of the following values in NAPEOS: GEO_MEAN_2000 MEAN_DATE TRUE_DATE EARTH_FIXED
Time Reference		UtC	The value supplied will be used by the target system to define which of the time values supplied for each OSV will be used as the base time.

5.2.2.2. XML Data Block¶

Predicted Orbit File - Data Block

XML Tag Name		Value	Description
Level 1	Level 2	Value	Description
List_of_OSVs		List	See table below for details of OSV element content

Predicted Orbit File - Data Block (OSV element)

XML Tag Name	Type	Unit	Precision	C Format	Description
TAI	date	string			TAI date and time of OSV, in ASCII standard time format, including time reference and micro-seconds. Format: TAI=yyyy-mm-ddThh:mm:ss.ssssss
UTC	date	string			UTC date and time of OSV, in ASCII standard time format, including time reference and micro-seconds. Format: UTC=yyyy-mm-ddThh:mm:ss.ssssss
UT1	date	string			UT1 date and time of OSV, in ASCII standard time format, including time reference and micro-seconds. Format: UT1=yyyy-mm-ddThh:mm:ss.ssssss
Absolute_Orbit	int			%+05ld	Absolut orbit counter. This counter is incremented by a single unit from one record to the next. It must be differentiated with the real absolute orbit number on which the state vector belongs i.e : If the Z value of the OSV is >= 0 then “real” absolute orbit number equals the absolute orbit counter. If the Z value of the OSV is < 0 then “real” absolute orbit number equals the absolute orbit counter minus 1.
X	float	m	10-3	%+012.3lf	X position in defined coordinate system
Y	float	m	10-3	%+012.3lf	Y position in defined coordinate system
Z	float	m	-310	%+012.3lf	Z position in defined coordinate system
VX	float	m/s	-610	%+012.6lf	X velocity in defined coordinate system
VY	float	m/s	10-6	%+012.6lf	Y velocity in defined coordinate system
VZ	float	m/s	10-6	%+012.6lf	Z velocity in defined coordinate system
Quality	string	string		%s13	This parameter is added to keep format compatibility with Cryosat format. Default (“not used”) value is: “0000000000000”

5.2.3. File Example¶

code¶

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<earth_explorer_file schemaversion="2.1" xmlns="http://eop-cfi.esa.int/CFI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://eop-cfi.esa.int/CFIhttp://eop-cfi.esa.int/CFI/EE_CFI_SCHEMAS/EO_OPER_MPL_ORBPRE_0201.XSD">
  <earth_explorer_header>
    <fixed_header>
      <file_name>S1A_OPER_MPL_ORBPRE_20150408T200548_20150415T200548_0001</file_name>
      <file_description>FOS Predicted Orbit File</file_description>
      <notes>
      </notes>
      <mission>SENTINEL 1A</mission>
      <file_class>OPER</file_class>
      <file_type>MPL_ORBPRE</file_type>
      <validity_period>
        <validity_start>UTC=2015-04-08T20:05:48</validity_start>
        <validity_stop>UTC=2015-04-15T20:05:48</validity_stop>
      </validity_period>
      <file_version>0001</file_version>
      <source>
        <system>FOS</system>
        <creator>NAPEOS</creator>
        <creator_version>3.0</creator_version>
        <creation_date>UTC=2015-04-08T20:04:15</creation_date>
      </source>
    </fixed_header>
    <variable_header>
      <ref_frame>EARTH FIXED</ref_frame>
      <time_reference>UTC</time_reference>
    </variable_header>
  </earth_explorer_header>
  <data_block type="xml">
    <list_of_osvs count="102">
      <osv>
        <tai>TAI=2015-04-08T21:26:15.205004</tai>
        <utc>UTC=2015-04-08T21:25:40.205004</utc>
        <ut1>UT1=2015-04-08T21:25:39.619541</ut1>
        <absolute_orbit>+05398</absolute_orbit>
        <x unit="m">+4426739.980</x>
        <y unit="m">-5521678.657</y>
        <z unit="m">+0000000.000</z>
        <vx unit="m/s">-1241.329802</vx>
        <vy unit="m/s">-0983.731252</vy>
        <vz unit="m/s">+7430.103421</vz>
        <quality>0000000000000</quality>
      </osv>
      <osv>
        <tai>TAI=2015-04-08T23:04:59.746401</tai>
        <utc>UTC=2015-04-08T23:04:24.746401</utc>
        <ut1>UT1=2015-04-08T23:04:24.160846</ut1>
        <absolute_orbit>+05399</absolute_orbit>
        <x unit="m">+1716164.366</x>
        <y unit="m">-6865790.638</y>
        <z unit="m">-0000000.000</z>
        <vx unit="m/s">-1538.462830</vx>
        <vy unit="m/s">-0375.409927</vy>
        <vz unit="m/s">+7430.234941</vz>
        <quality>0000000000000</quality>
      </osv>
      <osv>
        <tai>TAI=2015-04-09T00:43:44.394152</tai>
        <utc>UTC=2015-04-09T00:43:09.394152</utc>
        <ut1>UT1=2015-04-09T00:43:08.808493</ut1>
        <absolute_orbit>+05400</absolute_orbit>
        <x unit="m">-1307942.093</x>
        <y unit="m">-6954977.921</y>
        <z unit="m">+0000000.000</z>
        <vx unit="m/s">-1554.531180</vx>
        <vy unit="m/s">+0301.431570</vy>
        <vz unit="m/s">+7430.381036</vz>
        <quality>0000000000000</quality>
      </osv>
      ...
      <osv>
        <tai>TAI=2015-04-15T19:39:17.662597</tai>
        <utc>UTC=2015-04-15T19:38:42.662597</utc>
        <ut1>UT1=2015-04-15T19:38:42.067495</ut1>
        <absolute_orbit>+05499</absolute_orbit>
        <x unit="m">+6437784.375</x>
        <y unit="m">-2939214.499</y>
        <z unit="m">-0000000.000</z>
        <vx unit="m/s">-0665.951434</vx>
        <vy unit="m/s">-1437.084697</vy>
        <vz unit="m/s">+7430.190434</vz>
        <quality>0000000000000</quality>
      </osv>
    </list_of_osvs>
  </data_block>
</earth_explorer_file>