<font size=2 face="sans-serif">Dear Peter,</font>
<br><font size=2 face="sans-serif">A quick feedback although not conclusive
yet. You have triggered a discussion in the CSS Area which presumably results
in some changes with respect to FR definitions. We have already discussed
that in the CSTS group, today it will be discussed in the CSSM group. I
think that the changed FR definition approach under discussion will address
your concerns, although we may still scope the initial set of FRs for an
ESLT - simply for time and budget reasons. However, it is important to
note that this 'initial ESLT scope' will not exclude in any way future
FR updates, widening the FR scope. </font>
<br>
<br><font size=2 face="sans-serif">We will let you know once we came to
a conclusion seek your opinion.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int>, "css-csts@mailman.ccsds.org"
<css-csts@mailman.ccsds.org>, "Kazz, Greg J (312B)" <greg.j.kazz@jpl.nasa.gov>,
"Greenberg, Edward (312B)" <edward.greenberg@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"Wilmot, Jonathan
J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov>, "Burleigh,
Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>, "Gian
Paolo Calzolari" <Gian.Paolo.Calzolari@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">03/07/2019 19:48</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [EXTERNAL]
[Css-csts] Fw: Merging of FRs dealing with variable length frames</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="Calibri">Dear CSTS WG (and others),</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Recently I have been involved in looking
at the relationships among two of the CCSDS areas, particularly SOIS, and
MOIMS, and how they use the services of the other four areas. And
this work that you are doing in CSS, to develop a model of Functional Resources,
touches on these areas and also, of course, SLS and SIS. In fact,
we have a side discussion starting among SOIS, SIS, and CSS to talk about
the relationships among the CSS FR models, the SOIS EDS/DoT component &
behavior models, and the SIS network management models. There seem
to be some areas of overlap here, and at any event we will benefit from
looking at these from a global, instead of local, perspective.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">It occurs to me that this discussion about
Functional Resources (FR), and which aspects and variations of space links
they cover, could also benefit from stepping back to gain a broader perspective.
There is always a danger in doing this of "trying to boil the
ocean", but in this case I think taking a look at this is warranted.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Here are some assertions that I would like
you to consider:</font>
<br><font size=3 face="Calibri"> </font>
<ol>
<li value=1><font size=3 face="Calibri">CCSDS Space Data Links are made
to be used in space-to-ground, ground-to-space, and space-to-space contexts.</font>
<li value=2><font size=3 face="Calibri">Some CCSDS space data links are
designed to only operate in one of these contexts, others are intended
to operate in all three.</font>
<li value=3><font size=3 face="Calibri">SLS has defined both fixed length
SDL blocks and variable length SDL frames. This notionally includes
all three operational contexts.</font>
<li value=4><font size=3 face="Calibri">CCSDS coding and synchronization
approaches are also intended to operate in all three contexts, with similar
specializations.</font>
<li value=5><font size=3 face="Calibri">SLS has defined both fixed and
variable length coding schemes, and fixed length block and "sliced"
alignment and ASM schemes, but there is not yet a complete treatment of
all of these.</font>
<li value=6><font size=3 face="Calibri">FR, as defined in CSS CSSM, were
developed in the context of ground data systems for cross support.</font>
<li value=7><font size=3 face="Calibri">FRs define a set of abstract data
communication functions that are intended to be combined in known ways,
and that may be implemented in multiple different ways and associated with
different real components.</font>
<li value=8><font size=3 face="Calibri">FR concepts and definitions, with
little modification, could equally well be adopted in the context of space
communications components, not just on the ground.</font>
<li value=9><font size=3 face="Calibri">EDS /DoT provides mechanisms for
describing those comm components, their interfaces, and behaviors.</font></ol><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">I assume that you will all agree with these
assertions, and I fully expect to hear from you if you do not. Assuming
that there is agreement, I propose that we ensure that the definitions
that we adopt for CSS FRs cover all of these possibilities and that we
not artificially adopt limiting constraints on what these FRs are or where
they may be applied. This concern about constraints is especially
true for USLP, which has both fixed and variable length frame structures
and is explicitly intended for deployment in all three operational contexts.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Given this approach, and with all due respect,
I suggest that you not adopt Wolfgang's stated assumption:</font>
<p><font size=3>My assumption is that variable length frames will be used
on the forward link only and therefore we do not need to investigate which
parameters are required for the return link. </font>
<p><font size=3>Using similar logic, I suggest that you also not adopt
this simplifying assumption:</font>
<p><font size=3>My understanding is that the FR specifications deal only
with the Forward Link as emitted by an ESLT, but not with inter-spacecraft
communications.</font>
<p><font size=3>If those assumptions I stated earlier are "correct",
or if we can agree on some such set of assumptions, how much work would
it be to do what is suggested, and to define all of the necessary FR so
that these conditions can be met? If we do this I think that these
FR concepts could see much broader use.</font>
<p><font size=3>Thanks for listening.</font>
<p><font size=3>Peter</font>
<p><font size=3> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>CSS-CSTS <css-csts-bounces@mailman.ccsds.org>
on behalf of "Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int><b><br>
Date: </b>Wednesday, July 3, 2019 at 5:13 AM<b><br>
To: </b>CSTS-WG <css-csts@mailman.ccsds.org><b><br>
Subject: </b>[EXTERNAL] [Css-csts] Fw: Merging of FRs dealing with variable
length frames</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Arial">Dear CSTS WG,</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
Please have a look at Wolfgang's email below. Feedback is appreciated!</font><font size=3 face="Calibri">
<br>
</font><font size=3 face="Arial"><br>
Regards,</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="Calibri"> <br>
</font><font size=3 face="Arial"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="Calibri">
</font><font size=3 color=#800080 face="Arial"><br>
----- Forwarded by Holger Dreihahn/esoc/ESA on 03/07/2019 14:09 -----</font><font size=3 face="Calibri">
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
From: </font><font size=3 face="Arial">"Wolfgang
Hell" <wo_._he@t-online.de></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">"Holger
Dreihahn" <Holger.Dreihahn@esa.int></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Cc: </font><font size=3 face="Arial">"John
Pietras" <john.pietras@gst.com></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">02/07/2019
14:49</font><font size=3 face="Calibri"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">Merging
of FRs dealing with variable length frames</font><font size=3 face="Calibri">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Calibri"><br>
<br>
<br>
Hi Holger, </font>
<p><font size=3>can you please forward this material to the CSTS-WG? I'm
copying John directly, because I suspect that he may have some more or
less immediate comments while the other WG members presumably will need
more time to digest this input (as for John's input for the fixed length
frames). Any early feedback WG members might have will of course be helpful.
</font>
<p><font size=3>My assumption is that variable length frames will be used
on the forward link only and therefore we do not need to investigate which
parameters are required for the return link. </font>
<p><font size=3>The only Sync and Coding sublayer that may be used in combination
with variable length USLP frames are CCSDS 231.0-B-3 and CCSDS 211.0-B-5,
where the latter addresses the proximity link. My understanding is that
the FR specifications deal only with the Forward Link as emitted by an
ESLT, but not with inter-spacecraft communications. Therefore only CCSDS
231.0-B-3 needs to be taken into account in the FR specification context.
That means that the Sync and Coding layer is the same for both USLP and
TC frames and no merging of separate FR types is needed in that respect.
For the sake of completeness the attached spreadsheet comparing the USLP
and TC cases presents also the managed parameters of the sync and coding
sublayer, i.e., of CCSDS 231.0-B-3.If deemed useful, I can add the VOP-1
managed parameters to the next issue of the spreadsheet. Again, these parameters
are common for variable length USLP and for TC frames. </font>
<p><font size=3>I have applied the following color coding in the spreadsheet:
Those parameters that are identical or reasonably similar so that they
can be used both to monitor and, if applicable, control USLP and TC frame
handling have a green background. Those parameters that apply only to one
frame type have a blue background. A red background indicates that I see
a problem with merging USLP and TC or where I have a problem with the specification
of the managed parameters ar generated by the space link folks. </font>
<p><font size=3>As the next steps I plan to crosscheck my findings and
suggestions against the material generated by John and to suggest an initial
mapping of the parameters to FR types. Hopefully we can reach some related
conclusions on July 9 such that we have a reasonably stable starting point
for reworking some of the FR type specifications. </font>
<p><font size=3>Best regards, </font>
<p><font size=3>Wolfgang </font>
<br><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or</font>
<br><font size=3 face="Courier New">protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received</font>
<br><font size=3 face="Courier New">this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures
to protect</font>
<br><font size=3 face="Courier New">personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (dpo@esa.int).</font>
<br>
<br><PRE>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@esa.int).
</PRE>