[Css-csts] [EXTERNAL] Fw: Merging of FRs dealing with variable length frames

Tue Jul 16 07:19:39 UTC 2019

Dear Peter,
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. 

We will let you know once we came to a conclusion seek your opinion.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc

From:   "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:     "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>, 
"css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org>, "Kazz, Greg J 
(312B)" <greg.j.kazz at jpl.nasa.gov>, "Greenberg, Edward (312B)" 
<edward.greenberg at jpl.nasa.gov>
Cc:     "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, 
"Burleigh, Scott C (312B)" <scott.c.burleigh at jpl.nasa.gov>, "Gian Paolo 
Calzolari" <Gian.Paolo.Calzolari at esa.int>
Date:   03/07/2019 19:48
Subject:        Re: [EXTERNAL] [Css-csts] Fw: Merging of FRs dealing with 
variable length frames

Dear CSTS WG (and others),

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.

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.

Here are some assertions that I would like you to consider:

CCSDS Space Data Links are made to be used in space-to-ground, 
ground-to-space, and space-to-space contexts.
Some CCSDS space data links are designed to only operate in one of these 
contexts, others are intended to operate in all three.
SLS has defined both fixed length SDL blocks and variable length SDL 
frames.  This notionally includes all three operational contexts.
CCSDS coding and synchronization approaches are also intended to operate 
in all three contexts, with similar specializations.
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.
FR, as defined in CSS CSSM, were developed in the context of ground data 
systems for cross support.
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.
FR concepts and definitions, with little modification, could equally well 
be adopted in the context of space communications components, not just on 
the ground.
EDS /DoT provides mechanisms for describing those comm components, their 
interfaces, and behaviors.

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.

Given this approach, and with all due respect, I suggest that you not 
adopt Wolfgang's stated assumption:
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. 
Using similar logic, I suggest that you also not adopt this simplifying 
assumption:
My understanding is that the FR specifications deal only with the Forward 
Link as emitted by an ESLT, but not with inter-spacecraft communications.
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.
Thanks for listening.
Peter

From: CSS-CSTS <css-csts-bounces at mailman.ccsds.org> on behalf of 
"Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Date: Wednesday, July 3, 2019 at 5:13 AM
To: CSTS-WG <css-csts at mailman.ccsds.org>
Subject: [EXTERNAL] [Css-csts] Fw: Merging of FRs dealing with variable 
length frames

Dear CSTS WG, 
Please have a look at Wolfgang's email below. Feedback is appreciated! 

Regards, 
Holger 

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc 
----- Forwarded by Holger Dreihahn/esoc/ESA on 03/07/2019 14:09 ----- 

From:        "Wolfgang Hell" <wo_._he at t-online.de> 
To:        "Holger Dreihahn" <Holger.Dreihahn at esa.int> 
Cc:        "John Pietras" <john.pietras at gst.com> 
Date:        02/07/2019 14:49 
Subject:        Merging of FRs dealing with variable length frames 

Hi Holger, 
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. 
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. 
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. 
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. 
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. 
Best regards, 
Wolfgang 
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).

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...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20190716/05457b69/attachment.html>