[SLS] Your opinion required: [CESG] CSS Area Technical Note: Functional Resource Model

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Fri Sep 2 08:42:14 UTC 2016


Dear All,
        please let me know if - after Erik mail - it is clear 
1) the kind of feedback expected from your WG, and
2) which sections are really of interest to your WG 

Thanks

Gian Paolo. 
----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 02/09/2016 10:37 -----

From:   "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:     "CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org) 
(cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org>, "SLS - Space Link 
Services Area" <sls at mailman.ccsds.org>
Date:   02/09/2016 03:05
Subject:        RE: [CESG] CSS Area Technical Note:  Functional Resource 
Model



Dear Gian Paolo,
 
Perhaps if I work from an example it will help.
 
If you look at figure 2-2, and following the ?wiring? from the Forward 
Frame CSTS Provider box, we see 3 possible outputs: a) all TC VC frames 
for one VC to the TC VC Mux function, b) AOS VC frames for one VC to an 
AOS Mux function, and c) all MC CADUs for one physical channel symbol 
stream to a Fwd AOS Sync and Channel Encoding function.   And if you study 
the diagram you can see that there are other logical entry points for the 
Mux/Encoding functions (e.g, if we enter the functionality from forward 
file or CFDP sender).     A key question is if this abstraction of 
functionality/process is correct? We believe it to be so, but 
input/checking will be appreciated.  Very closely related is 
If we then jump to the details on the Forward AOS Synchronization and 
Channel Encoding type, its functions are described as:
 
??
a)     the multiplexing and idle data unit insertion that is nominally 
specified in the AOS Space Data Link Recommended Standard to be performed 
on transfer frames. In the IOAG service set, these functions are performed 
on already-coded and synch-markered channel access data units (CADUs) 
instead, in order to provide the CADU mode of the Forward Frames CSTS. The 
resultant waveform on the space link carrier is the same as that produced 
by conformance to the AOS Space Data Link Protocol and TM Synchronization 
and Channel Coding Recommended Standards.; and
b)     the (optional) frame randomization, block (Reed Solomon, Turbo, or 
LDPC) encoding, frame synchronization marker attachment, and (optional) 
convolutional encoding functions specified in the TM Synchronization and 
Channel Coding Recommended Standard.
?? 
 
So this would be kind of the first order check ? that wiring and 
associated functional descriptions are correct. 
 
A 2nd order consideration is then the various profiles listed later in the 
document which we believe are what the ?sensible? (leading to 
standardized) combinations of these functional resources are.  This then 
influences such things as what and how CSTS identifies standardized 
monitor data, service control directives, etc. 
 
I realize this is a non-trivial document, so I think just looking at the 
diagram and checking that the pathways make sense will be a good first 
step.
 
Best regards,
-Erik 
 
From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] 
Sent: Thursday, August 25, 2016 6:06 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org) 
(cesg at mailman.ccsds.org) <cesg at mailman.ccsds.org>; SLS - Space Link 
Services Area <sls at mailman.ccsds.org>
Subject: Re: [CESG] CSS Area Technical Note: Functional Resource Model
 
Dear Erik, 
        you say " I believe it will be of particular interest for the SLS 
Area as we believe these are the experts that will really know if the 
wiring makes sense". 
However the document - even accepting changes - is about 190 pages, so it 
would be nice to understand what kind of feedback you expect from SLS Area 
as well as knowing which sections would really be of interest of any given 
WG in SLS. I think specially the latter would prevent misunderstanding and 
overlooking of interesting items. 

Thanks 

Gian Paolo 



From:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov> 
To:        "CESG -- CCSDS-Engineering Steering Group (
cesg at mailman.ccsds.org) (cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org> 

Date:        24/08/2016 20:45 
Subject:        [CESG] CSS Area Technical Note:  Functional Resource Model 

Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org> 




CESG Colleagues, 
  
Following up from the spring 2016 CESG meeting notes,  I have the action 
?EB to distribute TN?.  The TN referred to here is the Functional 
Resources Model which is now one of the  key ?pillars? for standards being 
developed in the CSS Area.  It can be viewed as the next logical layer 
down from the Cross Support Architecture documents.   You may recall at 
the last CESG meeting I noted that it will be good to have CESG review and 
comment on this.  As this can also be viewed as the abstract ?wiring? 
diagram for cross-support component at the link level, I believe it will 
be of particular interest for the SLS Area as we believe these are the 
experts that will really know if the wiring makes sense. 
  
Here are some notes/background to help guide you in reading through this: 
  
a)      In general, the Cross Support Services Area has the job of 
developing recommended standards to facilitate cross support between 
agencies between the various agency ground station networks and the 
various spacecraft. This means that we are faced with the problem of 
identifying the various components that render the various cross support 
services without discussing these in terms of specific equipment 
implementation details. The functional resource model represents our 
current best understanding of the various service resources required in 
the cross support setting but at an abstract level. 
b)      In general, the cross support services area recommendations have 
to allow for extensibility. For example, as optical communication becomes 
more and more of a reality, presumably we do not want to have the cross 
support services recommendations being redeveloped from scratch to address 
the management of optical space links versus the more traditional radio 
frequency space links. The functional resource model supports such an 
extensible capability. 
c)      Please ignore the editorial comments in the document ? these are 
essentially status notes from the technical note author and are 
indications for the work that we in the cross support services area need 
to do on the functional resource model. However the main body of the 
technical note is sufficiently intact that I believe it is more beneficial 
to take a look now rather than waiting for the updates to be performed. 
d)      If you are pressed for time and/or to gain some basic familiarity 
my suggestion is to look at figures/diagrams 2-1 through 2-4. 
  
I realize this is a rather substantial technical note (it is sufficiently 
substantial that it may one day be put on a normative document track), but 
any comments you may have by the time of the Rome meetings will be 
appreciated.  Given the non-trivial nature of this I think we can also 
consider more discussions at the San Antonio meetings as well. 
  
Best regards, 
-Erik 
  
  
From: cesg-bounces at mailman.ccsds.org [
mailto:cesg-bounces at mailman.ccsds.org] On Behalf Of Nestor.Peccia at esa.int
Sent: Monday, April 11, 2016 4:15 PM
To: CESG -- CCSDS-Engineering SteeringGroup(
cesg at mailman.ccsds.org)(cesg at mailman.ccsds.org) <cesg at mailman.ccsds.org>
Subject: [CESG] CESG Meeting on 11th April 2016 : Draft Motes 
  
Dear all, 
draft notes attached 


Comments by Friday 15th April 2016 cob 

ciao 
nestor 
This message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 
  
Please consider the environment before printing this email.[attachment 
"FunctResRefModel_TechNote-TN-0.11-160707.docx" deleted by Gian Paolo 
Calzolari/esoc/ESA] _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee 
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete 
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the 
sender.
 
Please consider the environment before printing this email.

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls/attachments/20160902/33031bbf/attachment.html>


More information about the SLS mailing list