[Css-csa] Re: CCSDS RID dispositioning - SCCS-ARD, 901x1r1
Wolfgang Hell
Wolfgang_._Hell at t-online.de
Mon Jan 19 16:19:30 UTC 2015
Dear CSA colleagues,
I realize that my further inputs to the review of CCSDS 901.1-R-1 come
late in the game, but as Peter was aware, I had to get the okay to spend
effort dedicated to CSTS on CSA matters. Due to the holiday season and
an email problem on my part I got that okay only recently. Anyway, here
is my contribution to an "entertaining" teleconference.
In addition to my "high energy" comments sent earlier that Peter in the
meantime has incorporated into the RIDs spreadsheet, here are further
comments, mostly of the "low energy" type such as typos.
Section 1.5, page 1-4, last bullet, typo. Text should read "... and a
list of ..." (delete the n).
Section 1.6.1, page 1-5, CCSDS-compliant credential , typo. Text should
read "... that have the minimum ..." (add the e).
Section 1.6.1, page 1-9, space link extension, SLE, definition appears
to be incorrect. Probably just the word "provider" is missing, i.e. the
text should read: "A set of specific cross support services that provide
reliable, access-controlled transfer of spaceflight mission-related data
between ground cross support serviceproviders and user elements."
Section 1.6.1, page 1-9, virtual channel, typo. Text should read: "A
logical subdivision of a single physical or master channel (add the word
of).
Section 2.6.1, page 2-9, last para. While I agree that what is stated in
this paragraph reflects what is happening today because of the specifics
of the available SLE services, given that this section contains
introductory material, it might be confusing to a reader being new to
cross support. The lack of symmetry on the user side (sending encoded
frames, receiving decoded frames) looks arbitrary. We could either
assume at this point availability of the CSTS F-Frame service which
permits a symmetric interface or we should add a few words explaining
the lack of symmetry.
Section 4.1, page 4-1, 2nd para. The CSRM [1] does NOT assume that the
service provider is a ground station. On the contrary, "staging" of
services is envisaged by hosting the different Functional Groups at
different entities (e.g. ground station, MOC, science center). Although
this feature is not exploited in practice, this is what the CSRM advocates.
Section 4.3.1.1, page 4-6, figure 4-2: This figure needs some formatting
work. Right now, there are several cases where the text does not fit
into the associated boxes.
Section 4.3.2, page 4-8: As I understand the purpose of this section, it
shall capture the requirements on SSI user nodes. However, all
requirements in this section use the term "SSI Earth User Node". If that
were correct, we would miss any requirements on the SSI Space User Node.
Presumably in this section we should use the generic term "SSI User Node".
Section 4.3.3.1.5, page 4-9. This requirement is redundant and should be
deleted. Due to requirement 4.3.3.1.1 the SSI Earth routing node
inherits all requirements of section 4.2.3, which includes requirement
4.2.3.2.6. The latter makes this requirement (4.3.3.1.5) a duplication.
Section 4.3.4.2, page 4-10. This requirement is a verbatim copy of
4.3.4.1 and should be deleted.
Section 5.2.1.1, page 5-2 3rd para., typo. Text should read: "... is
described in more detail ..." (add the word in).
Section 5.2.2.27, page 5-4. Reference [51] does not provide a real
specification of a tone ranging system. It rather offers some design
considerations for such system. Also, in practice different agencies
provide different ranging systems with different characteristics in
particular in terms of ambiguity resolution which might not be tone
based, but in most cases range measurements can be performed as long as
the spacecraft ranging channel is ´reasonably´ transparent. I propose to
either soften the requirement by permitting proprietary ranging systems
compatible with a transparent spacecraft ranging channel or a system as
per [53] which can be used with either a transparent or a regenerative
spacecraft ranging channel.
Section 5.2.2.47, page 5-6. Why are directives addressed in the context
of the MD CSTS? The same issue affects 5.2.3.3.12.
Section 5.2.3.2.26, page 5-8. Still remembering 5.2.2.36, I got confused
when reading this for the first time, since 5.2.2.36 allocates the DDOR
raw data correlation to the ESLT, while 5.2.3.2.26 makes sense only if
the correlation job is left to the Earth user node. A note following
5.2.2.36 sting that the correlation function may also be assigned to the
Earth user node would be helpful.
Sections 5.2.3.4.2 and 5.2.3.4.3, page 5-10. It is not uncommon that a
spacecraft supports more than one physical link. Shall this case be
modeled as separate Space user nodes? If not, then we should change the
requirements to read something like
"5.2.3.4.2 ABA Space User Nodes shall implement one or more RF
space-link reception functions to receive data (reference [51]).
5.2.3.4.3 ABA Space User Nodes shall implement one or more
CCSDS-compliant forward space-link data reception functions (references
[13], [48])."
This issue also applies to 5.2.3.4.18.
Section 5.2.3.4.8, page 5-11. No question, the COP breaks with extended
RTLT. However, at least part of the FARM still needs to be functioning,
in particular the discarding of duplicate frames. Such duplicates may be
the consequence of the repeated frame transmission (aka hammering mode).
The requirement should be rephrased accordingly.
5.2.3.4.20, page 5-11. Possibly I´m biased by ESA jargon, but I don´t
think that coherency is the point here. Isn´t the point rather that the
space user node may implement a transparent or a regenerative ranging
channel (or both)?
Section 6.1.2.2, page 6-3, table 6-1. The second column of this table is
supposed to list the applicable communication protocols. None of the 3xx
CCSDS Recommendations specifies a communication protocol and therefore I
suggest removing them from the table. Why are the proximity protocols
listed for the ABA scenario? Do the Proximity protocols not always imply
some kind of relay and are therefore used in multi-hop scenarios, but
not for ABA?
Section 6.1.2.3, page 6-4, table 6-2. The CSTS Specification Framework
is not a protocol and should therefore probably be removed from table
6-2. In case we want to keep it there, the version should be changed to
Red-2.
Section 6.2.1.2, page 6-6, table 6-4. Given that SLE peer entities are
interoperable only if they use the same mapping to an underlying
transport protocol, I suggest adding reference [74] to the table.
Section 6.2.2.2.23, page 6-13, copy and paste problem? Presumably the
text should read: "... users with means to securely control space
communication services".
Section 6.2.2.2.24, page 6-13. Is this constraint necessary in all
cases? Depending on which FRs are made accessible, this requirement can
be lifted.
Figures 6-8 and 6-9, pages 6-16 and 6-17 and associated requirements.
Both the figures and the associated requirements appear to rule out an
implementation of CFDP service classes 2 and 4 at the ESLT. Is that
intentional?
Note 1 after 6.2.2.4.7, page 6-20. Having written FSP, I of course
completely agree, but one of the reasons why certain missions did not
want to go for FSP was the odd feeling that there was something kind of
autonomously commanding their spacecraft. This note implies the same
ground station autonomy. I´m surprised that we did not get a RID against
that.
Section 6.2.2.4.9, page 6-21. I fail to understand this requirement in
the sense that I do not see, why an Earth user node would ever have to
implement the FARM side of the COP and signal something to the FOP.
Please explain the overall scenario / configuration.
Section 6.2.2.6.1, page 6-25. It appears that the data flow direction is
not correct in this requirement. Shouldn´t it read: "ABA Space User
Nodes receiving framed data shall implement a forward space link
communication protocol stack using compliant RF and demodulation,
decoding and synchronization, and TC or AOS frame processing and
demultiplexing (references [51], [12], [49], [48], [13]) (figure 6-13a)."
Sections 6.2.2.8.6 and 6.2.2.9.5, page 6-30, contain broken Word cross
references.
Section 6.2.2.9.4, page 6-30. The second sentence of this requirement
needs to be formatted as a NOTE.
Section 6.2.3.7.2.18, page 6-46. This requirement should presumably
apply to SSI space routing nodes. As it stands, it is a duplication of
6.2.3.7.2.13.
Section 7.2.1.3, page 7-2. Why does this requirement rule out the TC
frame option? Except for very high uplink rates, TC framing is adequate.
The same question applies to 7.3.4.1.
Figure 7-1, page 7-2.The Earth User Node as shown is misleading in the
sense that it assumes that an F-CLTU application would be run above the
C&S layer. The figure would be correct for an F-Frame user application.
Section 7.4, page 7-5, middle of the last but one paragraph. Delete the
duplicate words "may be".
I'll talk with you on Tuesday.
Best regards,
Wolfgang
Am 17.01.2015 um 03:25 schrieb Barkley, Erik J (3970):
>
> CSA Colleagues,
>
> Attached please find my inputs on the proposed RID dispositions. I am
> sure it will be an entertaining discussion on Tuesday.
>
> Best regards,
>
> -Erik
>
> *From:*Shames, Peter M (312B)
> *Sent:* Friday, January 09, 2015 5:06 PM
> *To:* Barkley, Erik J (3970); Wolfgang Hell; Takahiro Yamada;
> css-csa at mailman.ccsds.org
> *Subject:* Re: CCSDS RID dispositioning - SCCS-ARD, 901x1r1
> *Importance:* High
>
> Dear CSA Colleagues,
>
> Attached please find an updated version of the RID disposition
> spreadsheet and also a marked up copy of the Red Book in PDF form, as
> it was sent out for review.
>
> In the Red Book I have added text and notes that reflect all of the
> proposed dispositions so you can see the effect that these will have.
> While the document looks, on some pages, like it has the measles (red
> spots), the changes are really rather modest. Hopefully you will be
> able to read the notes on whatever software you have that handles PDF
> files.
>
> In the RID spreadsheet I have added a "Status" column to reflect just
> which sections were changed in order to disposition the RIDs. The
> most significant changes, not unexpected, where the changes to add
> R-OCF, that required several new requirements. Where there are RIDs
> that touch on related subjects I have added cross references back to
> the first one that occurred.
>
> There are still a number of items marked "discuss" in the status
> column. These are ones where I thought that there might be some
> issues that we needed to talk through. See you all on Tues, 20 Jan
> 2015 at 0700 Pacific.
>
> Thanks for the support, Peter
>
> *From: *<Shames>, Peter Shames <peter.m.shames at jpl.nasa.gov
> <mailto:peter.m.shames at jpl.nasa.gov>>
> *Date: *Wednesday, January 7, 2015 at 11:51 AM
> *To: *Erik Barkley <Erik.J.Barkley at jpl.nasa.gov
> <mailto:Erik.J.Barkley at jpl.nasa.gov>>, Wolfgang Hell
> <Wolfgang_._Hell at t-online.de <mailto:Wolfgang_._Hell at t-online.de>>,
> Takahiro Yamada <tyamada at pub.isas.jaxa.jp
> <mailto:tyamada at pub.isas.jaxa.jp>>, "css-csa at mailman.ccsds.org
> <mailto:css-csa at mailman.ccsds.org>" <css-csa at mailman.ccsds.org
> <mailto:css-csa at mailman.ccsds.org>>
> *Subject: *Re: CCSDS RID dispositioning - SCCS-ARD, 901x1r1
>
> Dear Colleagues,
>
> I have incorporated the comments from Wolfgang and Erik as "RIDs"
> in this updated version and added proposed dispositions for them.
> This was my extraction from the email exchanges and replies, it
> may or may not reflect their specific issues and needs review.
>
> I propose that we review these all, in order, when we have our
> telecon. I think that the "Accept" RIDs, shown in Green, are
> mostly non-controversial. The "Discuss" ones, and others that are
> in that awful yellow color, are things I think we need to discuss
> and reach agreement on. The "Reject", red items, and also likely
> to need discussion.
>
> I look forward to our telecon.
>
> Best regards, Peter
>
> *From: *Peter Shames <peter.m.shames at jpl.nasa.gov
> <mailto:peter.m.shames at jpl.nasa.gov>>
> *Date: *Tuesday, January 6, 2015 at 12:29 PM
> *To: *Erik Barkley <Erik.J.Barkley at jpl.nasa.gov
> <mailto:Erik.J.Barkley at jpl.nasa.gov>>, Wolfgang Hell
> <Wolfgang_._Hell at t-online.de
> <mailto:Wolfgang_._Hell at t-online.de>>, Takahiro Yamada
> <tyamada at pub.isas.jaxa.jp <mailto:tyamada at pub.isas.jaxa.jp>>,
> "css-csa at mailman.ccsds.org <mailto:css-csa at mailman.ccsds.org>"
> <css-csa at mailman.ccsds.org <mailto:css-csa at mailman.ccsds.org>>
> *Subject: *CCSDS RID dispositioning - SCCS-ARD, 901x1r1
>
> When: Tuesday, January 20, 2015 7:00 AM-9:00 AM. (UTC-08:00) Pacific Time (US & Canada)
>
> Where: WebEx - Details below
>
>
>
> *~*~*~*~*~*~*~*~*~*
>
> Dear Colleagues,
>
> This date & time is the one that the participants who
> responded to the Doodle poll agreed would be the best. I am
> attaching here the integrated set of RIDs and proposed
> dispositions in spreadsheet form. I will take the liberty of
> adding new RIDs as suggested by Wolfgang following his careful
> reading of the document and send these by early next week (14
> Jan at the latest). If any of you have additional editorial
> items we will resolve them during the telecon or you can mail
> them to me separately and I will deal with them.
>
> After we have reviewed and dispositioned the RIDs we can
> determine if we think the document can then go out for
> publication or if the changes are of a magnitude and
> significance that we need another agency review.
>
> I am using the ISO WebEx service because it includes
> internaitonal, toll-free, call in numbers (see below). It
> also supports use of your computer micro-phone & speakers (or
> headsets). */ I recommend that you log in to this ISO site
> ahead of time, do a download of their app, and test your
> speaker / mic or headset configuration. This will save time
> during the call./*
>
> Thanks again for your support, Peter
>
> ================================================================================================================
>
> *WEBEX INFO*
>
> Hello ,
>
> Shames Peter invites you to attend this online meeting.
>
> Topic: RID Dispositioning, CCSDS SCCS-ARD
> Date: Tuesday, January 20, 2015
> Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
> Meeting Number: 951 607 289
> Meeting Password: SCCS-ARD
>
>
> -------------------------------------------------------
> To join the online meeting (Now from mobile devices!)
> -------------------------------------------------------
> 1. Go to
> https://iso-meetings.webex.com/iso-meetings/j.php?MTID=mac589ccb006734c272bffc942bcfa641
> 2. If requested, enter your name and email address.
> 3. If a password is required, enter the meeting password:
> SCCS-ARD
> 4. Click "Join".
>
> To view in other time zones or languages, please click the link:
> https://iso-meetings.webex.com/iso-meetings/j.php?MTID=md257990878b258ed7ab39a860449b637
>
> -------------------------------------------------------
> To join the audio conference only
> -------------------------------------------------------
> To receive a call back, provide your phone number when you
> join the meeting, or call the number below and enter the
> access code.
> Call-in toll-free number (UK): 0800-051-3810
> Call-in toll number (UK): +44-203-478-5289
> Global call-in numbers:
> https://iso-meetings.webex.com/iso-meetings/globalcallin.php?serviceType=MC&ED=327735727&tollFree=1
> Toll-free dialing restrictions:
> http://www.webex.com/pdf/tollfree_restrictions.pdf
>
> Access code:951 607 289
>
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://iso-meetings.webex.com/iso-meetings/mc
> 2. On the left navigation bar, click "Support".
>
> You can contact me at:
> peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov>
>
>
> To add this meeting to your calendar program (for example
> Microsoft Outlook), click this link:
> https://iso-meetings.webex.com/iso-meetings/j.php?MTID=m9f7870247cb532efdd2c34728a4df288
>
> The playback of UCF (Universal Communications Format) rich
> media files requires appropriate players. To view this type of
> rich media files in the meeting, please check whether you have
> the players installed on your computer by going to
> https://iso-meetings.webex.com/iso-meetings/systemdiagnosis.php.
>
>
>
>
> http://www.webex.com <http://www.webex.com/>
>
> CCP:+442034785289x951607289#
>
> IMPORTANT NOTICE: This WebEx service includes a feature that
> allows audio and any documents and other materials exchanged
> or viewed during the session to be recorded. By joining this
> session, you automatically consent to such recordings. If you
> do not consent to the recording, discuss your concerns with
> the meeting host prior to the start of the recording or do not
> join the session. Please note that any such recordings may be
> subject to discovery in the event of litigation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csa/attachments/20150119/566b7326/attachment.html>
More information about the CSS-CSA
mailing list