[Sls-slp] RE: Updated Draft USLP White Book for SLP WG and interested parties review

Fri Jul 10 01:06:32 UTC 2015

Massimo,  I sorry you didn't put me on your distribution, because I can provide you the rationale for the assumptions in USLP.  Your comments are enumerated blow in Black, My response is in RED.

1)       As discussed in the past, with a variable frame size, as intended by USLP, C&S would have a very hard time delimiting the frames, a much cleaner solution would be to have USLP itself to take care of the delimiting (while C&S would do the same for the codewords). Currently in the TC books (most similar to USLP with variable frame size) the behavior is that the protocol sublayer performs frame delimiting while the coding sublayer performs delimiting of data units (consisting of one or more Transfer Frames).
            It results that the functions actually performed in USLP may/shall adapt to the setting for variable or fixed length frames.
            I have no problem moving frame sync to data services sublayer, except the sublayer below is called coding and sync.  It provides sync and coding for code block and should provide sync and CRC coding for the frame.  GP has been adamant about the interface to the C&S sublayer be the frame: this requires the C&S to delimit the received frame adding CRC is totally in line with C&S.

2)      Is this really the case? Undetected error rate with BCH is rather good (even w/o the use of optional CRC), as can be seen in CCSDS230.1-G, sec 9.5.3

This is only true if the SNR is above 10**-3, if it is below that and in anomalous conditions it may very well be.  Another is if you get false sync you have significant error problems.

3)      As of today, the security of the TC is apparently a concern for NE (LEO) missions, not so much for DS (or NE not LEO), so it's difficult to accept that everything should change because of this requirement. This seems to be Green material, more than (future) Blue, in any case.

This is a leading STD hopefully for many years.  Are you sure who your allies will be?

4)      While this is true for (TM) transmitters (modulators), I believe it is still a bit premature for transponders

NASA is already working on a universal transceiver, can ESA be far behind?

5)      A)  I would recommend avoiding this sort of grand and general statements. Especially for FPGAs, a number of Agencies are still facing very serious issues with qualification, preventing effective use of the most recent and powerful devices (for critical units as transponders or transmitters) for a number of years to come. Besides, this seems Green Book material more than (future) Blue.

B) Possibly software-defined radio transponders...but certainly not "software transponders"

NASA is already working on a universal transceiver, can ESA be far behind? Can Transponders be far behind?

6)      It's not up to USLP to indicate which codes should be used

We were not putting down SCCC.  LDPC was an example.

7)      --As far as USLP is concerned, it is enough to mention coding and sync functions. This part should be deleted altogether.

--Not clear why a new book would be required (when USLP is still so far away from needing it, anyway)

USLP is being designed for all links, It would be nice to have a C&S for all links.  You are forward looking and are pushing SCCC.  We are trying to be forward looking for Link Layer as well.

8)      Why C&S operations should be specified in a protocol book? This is leading to an increase confusion, against the protocol segregation principle. I'm very much against it. If anything, refer to the existing coding books.

Note that every Blue book describes the services provided by the layers above and below.  That is why C&S is included.  IT would be much easier to say that the interface between the data services sublayer and C&S is a Frame!!!!   And today we only have C&S for TC or TM/AOS or Prox.....We need something for all links so that an orbiter needs only 1 link layer protocol.

Thanks for your review.  It is important to get comments from all the WGs.  If C&S has yet to address these issue I think that it might be time to do so.

From: Kazz, Greg J (312B)
Sent: Thursday, July 09, 2015 9:46 AM
To: Greenberg, Edward (312B)
Cc: Sank, Victor J. (GSFC-560.0)[AS and D, Inc.]
Subject: FW: Updated Draft USLP White Book for SLP WG and interested parties review

Ed,

Reading though Massimo's comments for the most part, I guess we really gave him major hemorrhoids on this one. Did you find anything of value in what he commented on ?

Greg

From: "Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>" <Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>>
Date: Tuesday, July 7, 2015 at 7:08 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Hamkins, Jon (3320)" <jon.hamkins at jpl.nasa.gov<mailto:jon.hamkins at jpl.nasa.gov>>, "Andrews, Kenneth S (332B)" <kenneth.s.andrews at jpl.nasa.gov<mailto:kenneth.s.andrews at jpl.nasa.gov>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>, "Sank, Victor J. (GSFC-560.0)[AS and D, Inc.]" <victor.j.sank at nasa.gov<mailto:victor.j.sank at nasa.gov>>, "Marco.Rovatti at esa.int<mailto:Marco.Rovatti at esa.int>" <Marco.Rovatti at esa.int<mailto:Marco.Rovatti at esa.int>>
Subject: Re: Updated Draft USLP White Book for SLP WG and interested parties review

Greg,

please find a few comments specifically on the interface USLP-C&S.

On the point 3 below, I'm afraid I'm completely against the approach taken: unless you are suggesting to disband the C&S WG, I don't see how SLP can propose a new C&S book at all, without having even discussed this
in the C&S WG.

Best regards,
Massimo

---------------------------------------------------
Massimo Bertinelli
Communication Systems Engineer
ESA/Estec

Tel. +31 (0)71 5653435
--------------------------------------------------

From:        "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
To:        "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>,
Cc:        "Sank, Victor J. (GSFC-560.0)[AS and D, Inc.]" <victor.j.sank at nasa.gov<mailto:victor.j.sank at nasa.gov>>, "Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>" <Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>>, "Hamkins, Jon (3320)" <jon.hamkins at jpl.nasa.gov<mailto:jon.hamkins at jpl.nasa.gov>>, "Andrews, Kenneth S (332B)" <kenneth.s.andrews at jpl.nasa.gov<mailto:kenneth.s.andrews at jpl.nasa.gov>>
Date:        07/07/2015 01:14
Subject:        Updated Draft USLP White Book for SLP WG and interested parties review
________________________________

All,

Please find an updated USLP White Book in the SLP WG area of the CWE under this URL for the Fall CCSDS meeting in Darmstadt, Germany:

http://tinyurl.com/nuu9xt8

I would very much appreciate it if you would please review this document and send me back you comments. Ideally I would like you to do this before August 1. Note that this draft white book contains references to several new draft books under construction below:

1.        COP-U (a draft specification that attempts to create a COP for both Proximity and Telecommand Applications). See http://tinyurl.com/q4d5fyy
2.        SOM - Session Operations Management Sublayer of USLP - Currently our thought is to make this separate from the USLP White Book. (Note that the USLP White Book is modeled based upon the existing TC, TM, AOS Space Data Link Layer books and NOT the Proximity-1 Space Data Link Book which doesn't conform as well to the other three.) See http://tinyurl.com/p55g3oj
3.        C&S-USLP (a draft specification to gather our thoughts about the interactions between USLP and the C&S sublayer). Clearly this work will eventually be done by the C&S WG, when the time comes to undertake it. http://tinyurl.com/od43f9t
Best regards,

Greg Kazz
Chairman SLS-SLP WG

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-slp/attachments/20150710/73280a97/attachment.html>