[Cesg-all] Current draft of the Space Communication Cross Support Architecture Requirements Document (SCCS-ARD)

[Shames, Peter M (312G)]

Dear CSS-CSA colleagues (and others),

The current version of the SCCS-ARD has been loaded to the CWE at in the CSS-CSA Draft Documents folder:  http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS-CSA%2FDraft%20Documents%2FCross%20Support%20Architecture&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View={8045374D-F8E0-4356-83CA-993252A38FE8}.

I am taking the unusual step of sending this draft to the CSS-CSA WG members, but also to the rest of the CESG-All list.  The reason is that this document cross cuts several CCSDS Areas.  Since these protocol stacks start at the physical layer, and include both link and network layer, the breadth of coverage includes: SLS, SIS, CSS and SEA.  If we can get early feedback from the other WG that would be ideal.

All of the ABA requirements are completed, and the references updated (along with some new ones for future, "in process", imaginary standards like SC-CSTS).  It does not yet have all of that same level of work done for the SSI, but I'm working on that next.  Any SSI guys, however, might look at the sorts of underpinnings described for the future forward frame services, since these will also appear "underneath" all of the SSI network layer plumbing.

What the SCCS-ARD does have is a completely normalized and cross-checked set of views, as follows:

a)     a service view;

b)    a physical view;

c)     a communications view;

d) an end-to-end deployment view.
There is an identified relationship among the different elements that appear in each of these views.  The service views shows top-level terrestrial elements that offer or use service interfaces, both terrestrial and for space communications.  The physical views introduce all of the different classes of physical elements (nodes) that are described and their internal functions and behavior.  Their interfaces are identified in the physical views but the interface binding signatures, i.e. the stack of protocols required to actually communicate with them, is specified in the communications views.  The communications views also provide the connection between the interface details and the internal functional details described in the physical views.  The end-to-end views show how to assemble those nodes, and their protocol stacks, to create mission space communications deployments that will interoperate.
All of the views in this document focus only on the communications protocols up to the link (ABA) or network (SSI) layer.  The only application layer protocols that are described are those involved in transporting data (such as files and messages).   Mission operations and other applications protocols will have to be treated elsewhere.
The presentation sequence of requirements starts at the service level and drills all the way down to the RF.  The sections now include all of the aspects of forward and return services, AOS, TC, and TM, ranging, Delta-DOR, COP, PLOP, etc, etc.  New CSTS services are included as [Future] elements.  The next gen space link and optical comm are not yet included since they seem just too "young" yet.
The bulk of the diagrams (many new) are in Sec 6 (communications view).  These have all been vetted ith the JPL leads for these specific standards.  They need a broader review.
I would particularly like to encourage the CSS-CSA WG members to review the whole document.  Please take a look, at least at Sec 6, for the specific topics you are interested in, and see if it all makes sense.
For the rest of you, in other WGs, please search for the specific topics you are interested in, coding, link, modulation, cross support, ranging, D-DOR, etc and see if what is presented appears to give adequate, and accurate, coverage at this level of detail.  The intention here is to provide broad coverage of all of these topics so that readers can see how the pieces fit together.  The expectation is that they will then drill down to the other existing specs as needed to deepen that understanding.
Feedback prior to the upcoming CCSDS working meeting will be most useful, if at all possible.
Thanks, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg-all/attachments/20140225/255cc6a3/attachment-0001.html