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

Takahiro Yamada tyamada at isas.jaxa.jp
Fri Mar 28 06:17:48 EST 2014


Peter,

I'm sorry for my late response. I have been busy with the role of Utilization Management for our next asteroid mission this week. I hope you have arrived in Amsterdam safely.

> As for the meetings themselves, we have a bit of a scheduling problem.  It
> appears that the CSA meeting that is on the meeting room schedule for
> Tuesday AM (see attached) did not appear in the registration list. As a
> result no one signed up for that session.

I'm available until 5 pm (which is 12 pm in Japan) on Tuesday, so I can join you if you need me on Tuesday.

> We do have people signed up for
> the Thursday AM & PM sessions.  But the compressed four (4) day work
> schedule also has the Boot Camp and the CSA WG scheduled on Thursday in
> the afternoon.  I must be there to present the Boot Camp materials for the
> first hour.  The CSA WG could meet in the AM and then from from 1430 to
> 1600 in the afternoon if people are wiling.  Please let me know your
> availability.

I thought you were going to the SEA plenary after the Boot Camp on Thursday, but I will be available any time on Thursday. Please let me know the time you want me to join. 

> An example of this added specificity is stating a user requirement for TC
> frames and then also stating a requirement to do encoding, produce CLTUs,
> and (optionally) perform the COP.  The reason for taking this approach is
> that there are at least three different specs involved in this, TC (33),
> TC sync & channel coding (11), the COP (75) and the SCID (34).  Unless
> someone is familiar with all of these and how they are to be stacked up it
> may not be obvious that they are all needed nor how they should be used.
> We could combine this sort of thing into one requirement with a specific
> list of sub-clauses for clarity, but I do not know that this helps with
> the size of the document. We could also drop all of the more specific
> references, but at some loss of clarity for those not familiar with these
> specs.

In this case, TC sync & channel coding and COP (whether you do retransmission or not) must also be used if TC SDLP is used. So why don't you just specify the necessary recommendations. For example: 

"ABA Earth Use Node shall implement either (1) TC SDLP [33], TC sync & channel coding [11] (except for the Physical Layer Operations Procedures), and COP [75], or (2) AOS SDLP [12] and TM sync & channel coding [24] ." 

This covers everything mentioned in 5.2.2.1.14 through 5.2.2.1.18, and does not lose any information.

SCID should be addressed in a separate clause. 

I don't think we should mention functions defined in the recommendations. For example, you don't need to mention acquisition and idle sequences anywhere in this document because they are mandatory parts of the SLE F-CLTU production function (see 2.4.1 of [45]). 

Clauses 5.2.1.8 through 5.2.1.10 should also be rewritten by just citing the SLE F-CLTU production function as follows:

"ABA ESLT shall implement the SLE F-CLTU production function [45]."

This covers everything mentioned in 5.2.1.8 through 5.2.1.10, and does not lose any information.

All of this requires rewriting of many clauses, but I believe this will increase both readability and accuracy of the document.

If you have different opinions, let's discuss them next week.

Best regards,
Takahiro Yamada




More information about the CESG-all mailing list