[Sls-slp] Revision of Composite Directive for Lunar

[Kazz, Greg (US 312B)]

Hi Stuart,
We need it because Prox-1 supports it. And the forcing mechanism in COP to force a resetting of the sequence counter is the SET V(R) directive. I also agree that it won’t be used very frequently. But I can’t just omit it. What I could do, is maybe burn 3 bits to create 8 type 3 sub-directives under type 3 SPDU, in which each subtype has it’s own fixed length and make the following assignments:
Subtype 0 = link establishment/control, 1 = link status, 2 = set control parameters, 3 = COP-P control , 4 thru 7 undefined for future assignments.
I know it is more than one size fits all model, but I need provision for these protocol features. If one doesn’t need subtype 1,2,3 then they simply don’t implement them.
What do you think?
Greg

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Stuart Golden <sgolden at vulcanwireless.com>
Sent: Thursday, May 11, 2023 18:07
To: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>; Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>; Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <victor.j.sank at nasa.gov>
Subject: [EXTERNAL] RE: Revision of Composite Directive for Lunar

             The Set V(R) is a function of COP-P, which seems out-of-place to me. Do we need that?  Isn’t this only used for resyncing. If we get out of sync, doesn’t everything reset naturally?

Similarly, I think PLCW requests are not really needed. Is that true? I think it is best to minimize COP-P influence.


From: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>
Sent: Thursday, May 11, 2023 2:30 PM
To: Stuart Golden <sgolden at vulcanwireless.com>; Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>; Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <victor.j.sank at nasa.gov>
Subject: Revision of Composite Directive for Lunar

Dear SLP WG,

Attached is a revision of the Lunar Prox-1 directive (SPDU).
It differs from the one I presented at the meeting, because in the joint RF&MOD/C&S/SLP WG meeting, it was decided that all of the Type 1 SPDU directives would only be used at UHF band and NOT apply to Lunar. However, there are some parameters such as duplex, RNMD, SET V(R), etc that are required by the protocol which are not currently defined in the draft SPDU Type 3 (Lunar SPDU). Ergo, I added them, which only leave 1 spare bit. I ended up reducing the MODCOD field from 21 bits to 13 bits, which I still feel is adequate.

Part of the problem here is that some of these fields won’t be used as frequently as some of the other parameters but overall I don’t think it will be an efficiency killer.
Please review this latest version, and really take a close look to see if the number of bits assigned to each field is adequate or too much.

Thanks much,
Greg

Greg Kazz
Principal Engineer
Technical Group Supervisor,
312B Project Protection, Project Software, and End to End Information System Engineering
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20230512/b7a5a33b/attachment-0001.htm>