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

Fri Sep 2 07:32:54 UTC 2016

I will see the comments from SLS chairs.....

Sent from my iPhone

> On 02 Sep 2016, at 03:05, Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov> wrote:
> 
> 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/24a75f1b/attachment.html>