[Sea-sa] ESLT vs. ground tracking asset // was: DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Thu Feb 4 14:13:05 UTC 2021
can you please clarify what is the relationship between the ESLT
and the ground tracking asset mentioned by IOAG Catalogs?
In the CCSDS document the definition for the Earth Space Link Terminal
Earth Space Link Terminal (ESLT): The CSSE that provides space
services between the Earth User Node and the Space User Node. It includes
station control and management systems. The ESLT has space link protocol
supports terrestrial SLE and CSTS interfaces. The ESLT also has a service
interface that is controlled by the UE that is responsible for managing
the space link.
In IOAG Catalogs the ground tracking asset follows this definition:
Ground Tracking Assets may be Ground Stations, Ground Data System or a
combination of both.
I think it is essential to state something about their coincidence and/or
Is ESLT as a synonym for ground station? or is ESLT a a synonym for ground
Surely it makes a big point for what you call the <infamous IOAG “CFDP
file delivery service”, and the even more ephemeral “IOAG Packet file
From: "Shames, Peter M\(US 312B\) via SEA-SA" <sea-sa at mailman.ccsds.org>
To: "SEA-SA" <sea-sa at mailman.ccsds.org>
Date: 02-02-21 19:20
Subject: [Sea-sa] DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021
Sent by: "SEA-SA" <sea-sa-bounces at mailman.ccsds.org>
SCCS-ARD Revision Meeting Notes, 1 Feb 2021
Attendees: Peter Shames, John Pietras, Ramon Krosley, Costin Radulescu,
Ricard Abello, Holger Dreihahn
Reviewed the latest “Issues” file that John Pietras presented including
the intended fixes for several identified issues.
Specific issues were identified for three sections of the document. These
are covered in the file and are just named here for reference, along with
an decisions made during discussion:
Sec 4: agreed to add R-OCF to the other SLE services, for completeness.
Agreed to add a few sentences to further clarify the means intended with
[Future] standards and also (recommended) notations
Agreed to clarify that ABA is intended to convey deployments that
essentially use data link layer frames as the top layer supported
protocol, in the ESLT and end-to-end. Further clarify that other
protocols, CFDP, voice /video, and even DTN Bundles MAY be carried
end-to-end, but that the ESLT remains ignorant of this “upper layer”
Discussed that the now infamous IOAG “CFDP file delivery service”, and the
even more ephemeral “IOAG Packet file delivery service” depart from this
baseline and require use of FF-CSTS (not SLE F-CLTU) and also other, upper
layer, processing to be provisioned in the ESLT. This is a distinct
departure from “traditional ABA ESLT” deployments.
Agreed to change references from RF & Mod to Physical Channel, so as to
accommodate both RF and Optical.
Sec 6: agreed to use separate diagrams for the various protocol stacks, to
Agreed to change the form of the RQ stated in Sec 6 to focus on the
visible top layer protocol that is supported by the end-to-end ABA
entities. This will be files, packets, or frames, as well as ancillary
data like ranging and D-DOR.
Agreed to use those complicated tables, and example diagrams, to document
all of the viable and supported configurations.
Agreed to edit those tables to more accurately reflect D-DOR, the D-DOR
architecture, and DOR tones.
Agreed to check with the D-DOR WG about their use of TGFT. It appears
that a) they do not use it, b) they use another, existing, high speed bulk
transfer protocol, and c) TGFT may not even support their bulk transfer
needs anyhow since it appears to depend on single stream, rather than
parallel, transfers over HTTPS and TLS.
Adopted other changes to Sec 6 protocol tables as discussed. This
includes handling of SCCC and DVB coding and modulation, since they are
distinct from the “mainline” CCSDS coding, synch, and modulation
standards. Peter provided a marked-up set of proposed issues / updates.
During the meeting we also discussed a couple of related topics, as
There was discussion, and agreement to not incorporate the “adapted CFDP
File Delivery Service”, which puts the CFDP agent into the ESLT, and also
augments that with a new kind of “lost segment signaling” and
“retransmission request signaling” between the CFDP agent in the ESLT and
the Earth User Node (EUN). This approach, which is non standard, will
probably remain as a useful, but agency local, adaptation.
This subject is still up to the CSS, and other areas involved, to try and
reach some consensus about just just what is proposed, or planned, for
both the “IOAG CFDP File Delivery Service” and this adaptation. Separate
discussions are underway. The “IOAG Packet Service” is even more vague
and it is not clear that any such service will be developed by CCSDS.
The redundant sounding appellation “service management service”, and the
association of MD-CSTS and SC-CSTS with Service Management document
formats, and future interfaces, was briefly discussed. The IOAG has
associated these, and there is a technical argument that can be made that
these are all related, since the SM sets the configurations and plans and
schedules the contacts, and MD and SC are used to monitor and control data
transfer services during the contact. MD-CSTS and SC-CSTS are clearly
“service interfaces” in the true sense of the definition. It will also be
the case, once there is a “service interface protocol binding” for SM that
they will be, in some sense, “service interfaces”. That said, I still
find that calling these “service management services” sounds wordy and
redundant. I would prefer that we keep the “service” appellation for
those interfaces that actually transport data of various types, separate
from those that manage service elements. This distinction also shows up
in RASDS, sec 3.4, “characteristics of objects” and is shown in fig 3-2 as
“management interfaces”. I think it is a useful distinction to maintain,
since the “data plane” and the “control plane” are often distinguished in
Several other topics remain from the earlier meetings:
Recognize that work must be done to sort out the relationships between the
CSS Functional Resource Model (FRM), which was characterized as a database
of knowledge about component functions that get assembled to provide
services, and the SOIS Electronic Data Sheet (EDS), which was
characterized as a way to document hardware and software component
interfaces so as to facilitate development of software for those
Recognize that work must be done to disambiguate the different ‘flavors”
of “service”: as in CSS services, arbitrary “application services” like
packet transfer without formal application layer protocols, protocol layer
Service Access Points (SAP), SM&C “Services”, service interface binding
signatures, and the related protocol stacks that implement service
transfers. Focus is to be on services, protocols, and interfaces and not
Discussed the effect of the relatively new Q-SCID specs, from CCSDS
320.0-M-7, and the new USLP protocol with its 16-bit SCID, on the existing
SLE and CSTS protocols. This is apparently being addressed within the CSS
The files for review, and any added / background materials, will be placed
in the CWE at:
=> Next telecon, 1 MAR 2021: Review the updated approach for Sec 4 and Sec
6, to be produced by John Pietras, incorporating the agreed changes.
=> John and Peter to review a couple of “sticky” issues and bring that
proposal back to the rest of the WG.
=> Peter Shames to continue with separate working session, including CSS,
SLS, SIS and SEA, to look into the issues around the proposed CFDFP File
Delivery service , as discussed above, and the DTN alternative.
=> Peter has set up sub-folders for background, draft docs, and working
=> Request for the team to familiarize with these background materials
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SEA-SA