[Css-csts] Re: New SLE Issues and Errata since Cleveland

Tue Apr 9 11:53:34 EDT 2013

John,

Thank you very much for collecting the 'since Cleveland' SLE issues in a
single Word document. As regards the preparation of the Pink Sheets / updates
of the SLE Books, my view on the issues is as listed below, but I hope that
we find a bit of time during the Bordeaux meeting to see if we have a
consensus position in the WG.

1. RCF Errata and Question

1.1 MC and VC Channels

I agree that the NOTE 3 under section 3.4.2.7.1 is incorrect and that the
revised text that you propose reflects the original intent of the NOTE.

As regards the possibility that a user can choose between Master Channels
using a single RCF service instance, your observation that the intent has
been not to allow more than one Master Channel for any RCF service instance
as part of the permitted GVCID set is correct. I also agree that this intent
is not spelled out very clearly and you are also correct that the data type
specifications currently do not enforce such constraint. Unfortunately, I do
not remember why this constraint was intended in the first place. I suggest
that before modifying the RCF Book in this respect, we reach agreement in the
WG if this constraint shall be retained or not. Either way, the changes to be
made to the RCF Book are fairly straightforward.

1.2. RAF service instance vs. RAF channel

I agree that the RCF Book shall be updated as you suggest.

1.3 Concurrent delivery of more than one VC frame stream by a single RCF
service instance

I can confirm that such capability was discussed at some point. I remember
that Hans Uhrig was strongly opposed to it. If my memory serves me well, his
argument was that such delivery mechanism might suggest that the relative
sequence of the frames associated with different VCs would have any
significance which is not the case. Therefore anybody wishing to receive
several VC frame streams concurrently should do so by using one RCF service
instance per VC. I also recall that Hans was in favour of permitting the
delivery of space packets associated with more than one APID via a single RSP
service instance stating that in that case the timely order of the packets is
significant even if having different APIDs. I tried to find some
justification for the latter in CCSDS 132.0 and CCSDS 133.0, but I did not
succeed. Perhaps our SLS colleagues can help us regarding that question.

I'm not convinced that the possibility of retrieving several VC streams using
a single RCF service instance offers a significant operational benefit,
however, if then we have to deal with sets of permitted GVCIDs being
permitted or not, the data structures become more complex.

2. SLE RAF permitted-frame-quality-set Managed Parameter

If we consider the provider side only, I concur with what has been discussed.
And given that in essence we specify in the RAF-Book the provider behaviour,
the proposed changes may be considered appropriate. On the other hand, from
the very beginning when JPL and ESA discussed in the initial implementation
and the associated SLE API, one design principle has always been that error
conditions that can be detected locally shall be handled locally without
bothering the peer SLE entity. Taking the specific case of the permitted
frame quality parameter, at least in the existing ESA implementation it is
assumed that service management (also the currently used ad-hoc
implementation) ensures that the configuration of a service instance is
consistent on both user and provider side. The permitted frame quality is one
of the parameters of the RAF service instance configuration file. If that
parameter would e.g. be set to allow only the selection of good frames, then
on the ESA SLE MMI the other options are greyed out and the operator cannot
select a frame quality different from the permitted settings. As a
consequence, it is not possible to create an RAF-START invocation with a
frame quality selection that is not permitted for the given service instance.
As a consequence, any provider interacting with the ESA user implementation
will never have to deal with this error condition. If we can assume that
whichever form of service management is in use ensures consistent
configuration of user and provider, then there is actually no need to modify
the RAF Book as the error case in question cannot happen as long as the user
side is correctly implemented. If the WG position is that such assumption is
too optimistic, then I agree that we need to modify the RAF Book.

I agree with Martin's observation that the present version of CCSDS 915.1
does not deal with the permitted frame quality parameter. However, the
permitted GVCID set in RCF is dealt with correctly in CCSDS 915.2. I cannot
think of a reason why these two managed parameters should not be handled in
the same way and therefore tend to conclude that CCSDS 915.1 needs to be
modified accordingly. If that is the agreed way forward, we still need to
decide if and to which extent the RAF Book needs to be updated in that
regard.

If we agree on that, then we shall definitely change the RAF Book suc that
the permitted frame quality becomes a gettable parameter so that this managed
parameter is really handled the same way as the permitted GVCID set in RCF.

3. CLCW-PLOP-Production Status State Tables

On this issue we may need to talk a bit more in Bordeaux, although generally
speaking we are at least very close to an agreement on how to resolve the
various issues.

If Greg and Ed are okay with using the same idle sequence length preceding
and following a CLTU when PLOP-1 is applicable, I won't object. I wasn't
aware that this question had been addressed with them and certainly CCSDS
231.0 does not provide an unambiguous specification. But with PLOP-1 not to
be used for any future missions, we really do not need to worry too much. By
the way, I have not seen any PLOP-1 mission using the optional idle sequence.

As concerns when to re-sweep, I don't quite understand your statement "
Regarding your proposed simple solution of re-sweeping prior to every command
in PLOP-1 I don't personally have a problem with it ...". I at least did not
intend to propose this. The loss of bit lock should definitely not occur
while we are in CMM-3 or CMM-4. The bit-lock status shall be ignored while we
are in CMM-1 or CMM-2. As long as no bit-lock loss occurs in CMM-3 or CMM-4,
no re-sweep will be triggered prior to the radiation of the next command.
That was at least the intent of my comments of how to overcome the problem
discovered by the NASA SGSS Project.

If and for how long we need to consider PLOP-1 in the CLTU-Book is a very
interesting question. CCSDS 231.0 states:

6.1.3 PLOP-2 shall be used for missions whose planning begins after September
2010.
6.1.4 PLOP-1 may still be used in ground equipment for the support of legacy
missions.

Given that in the past we have regarded F-CLTU and RAF as those services that
can also be used in support of missions that are not fully CCSDS compliant,
we probably should retain PLOP-1 at least as an option in the CLTU-Book.

Did you get any feedback if the NASA SGSS Project can live with the updates
of the CLTU-Book that we are proposing?

4. “CRC” Not Actually Used in RAF

I fully agree with your suggestion to remove all occurrences of 'CRC' in RAF
and to update section 1.6.1.5. and annexes C and D accordingly.

Best regards,

Wolfgang

|------------>
| From:      |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |John Pietras <john.pietras at gst.com>                                                                                                                   |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |"Wolfgang.Hell at esa.int" <Wolfgang.Hell at esa.int>                                                                                                       |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>                                                                              |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |22/03/2013 15:51                                                                                                                                      |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |New SLE Issues and Errata since Cleveland                                                                                                             |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|

Wolfgang,
As promised yesterday, here’s a Word document containing the emails regarding
SLE issues and errata since Cleveland. Regarding the CLCW-PLOP-production
status issues (item 3 in the attachment), I think that we’ve resolved
everything with the possible exception of the re-sweep on every command issue
for PLOP-1. As I wrote in yesterday’s email, I personally I don’t have a
problem with it but I was concerned that it might not agree with some
existing implementations. I’m now (today) re-thinking that position, since
there will be a pink sheet review in any case. We could (unless anyone in the
WG has an objection) just proceed with your solution and get the pink sheets
written and reviewed. Those of us that might be concerned about the impacts
can raise the issue(s) during their agencies’ reviews of the pink sheets.

Best regards,
John

John Pietras
Principal Engineer
GST, Inc.
7855 Walker Drive, Suite 200
Greenbelt, MD 20770
240-542-1155
 (See attached file: NewSleIssuesSinceCleveland.docx)

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 --------------
A non-text attachment was scrubbed...
Name: NewSleIssuesSinceCleveland.docx
Type: application/octet-stream
Size: 44603 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20130409/c8a29b7b/NewSleIssuesSinceCleveland-0001.obj