[Sls-sea-dls] FW: [EXTERNAL] RE: Augmenting directives to Proximity-1

Thu Mar 2 18:16:35 UTC 2023

Hi All,

Sharing with you some good feedback from the radio developers at JPL concerning the Vulcan Wireless proposal (which will be talked about at our Spring 2023 CCSDS meeting) to modify the proximity directives beyond the use of Mars missions. The most likely home for them might be the USLP blue book. TBD. For your comment and review.

Thanks,
Greg

Date: Tuesday, February 21, 2023 at 8:39 AM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov>
Subject: Re: [EXTERNAL] RE: Augmenting directives to Proximity-1

I do see some benefit in both sides – the simplicity of a fixed format, and the flexibility of a variable format. Some ideas to consider:

  1.  If people are willing to look up a table of ModCod values to interpret, why not also a table of frequency/symbol-rate values? Then you might only need 2 bytes for “FreqRate” instead of 10 bytes for Frequency and Symbol Rate
     *   Wouldn’t the Symbol Rate be determined from the Frequency and the ModCod? Does the Symbol Rate need to be specified explicitly?
  2.  Just one fixed format does not allow for future-proofing with backwards compatibility. Maybe a compromise would be the ability to select among a defined set of fixed formats. So a SPDUType byte right after the Control Word. One defined SPDUType might be as Stuart diagrammed below, another defined SPDUType might be like Stuart’s except without “Time Stamp, RX Link SNR, RX Decode Percentage, and Range Estimate”, for missions without those abilities, etc.
     *   This has the risk/benefit that missions might roll their own and ignore the standard. Maybe a defined range of SPDUType values would be allowed to be “mission specific” (and maybe further distinguished by the Source ID to avoid type value collisions)?
     *   Would want to avoid defining so many different SPDUTypes that only vary by one field that you effectively create a variable-length format. Make the SPDUTypes “far enough apart” that they aim at different mission classes.
     *   Stuart’s idea of Query/Response could be used for radios to agree on a supported SPDUType if needed. Would perhaps be best if the Control and the SPDUType are in the same location in every type of SPDU, so even if two radios do not support any SPDUType in common, they can still discover that sad fact. (This is why I suggested the SPDUType be after the Control Word instead of before.)

From: Stuart Golden <sgolden at vulcanwireless.com>
Date: Thursday, February 2, 2023 at 3:46 PM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov>
Cc: "Davarian, Faramaz (US 9700)" <faramaz.davarian at jpl.nasa.gov>, "Shihabi, Mazen M (US 337K)" <mshihabi at jpl.nasa.gov>, Kevin Lynaugh <klynaugh at vulcanwireless.com>, "ahmed.m.fadl at NASA.gov" <ahmed.m.fadl at nasa.gov>
Subject: [EXTERNAL] RE: Augmenting directives to Proximity-1

Hi Greg,

I understand what you are proposing and what you are going for. But, I am thinking of it differently. I have different design principles than what was suggested. My suggestion would be to create USLP 2.0 that would deprecate the current USLP and all of the current space layers: (USLP, Prox, AOS, TC, TM,….), and would “not” be legacy compatible with previous space layers.
USLP 2.0 would work with all of the existing sync & coding layers & physical layer documents: Prox, TC, TM, DVBS2,…. That is USLP 2.0 is compatible with all sync and coding lower layers.
The cost of variable size transfer frame headers and backwards compatibility at the space layer adds complexity and is not efficient.  Also as seen with SSTL they are deviating enough from the standard which means they are not providing compatibility either.
A simple new format would be very beneficial, and can be used for RF to Optical.

USLP 2.0 would define the PLTU which consists of a fixed frame transfer header and SPDU. Rather than having a bunch of different SPDUs, I would propose a single “large” fixed size SPDU that is used for telemetry and all control.
I would choose the PLTU that contains the SPDU to be “large” but small enough to fit into a reasonable codeword size and the PLTU would be locked into  the codeword such that the SPDU would not be split into multiple codewords. For our implementation, we are using a 512 Bytes( 4096 bit) information codeword. I think this codeword size is small for modern communications,  DVBS2 is much larger. But for this PLTU with SPDU, I would pick it in even smaller than the 512 Bytes. I would propose something like 128 Bytes.

Here is an example of what I would think the PLTU would look like:

Regards,
Stuart

[cid:image001.png at 01D94CF0.1181C6C0]

From: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>
Sent: Wednesday, February 1, 2023 3:28 PM
To: Stuart Golden <sgolden at vulcanwireless.com>
Cc: Davarian, Faramaz (US 9700) <faramaz.davarian at jpl.nasa.gov>
Subject: Augmenting directives to Proximity-1

Hi Stuart,

A subset of the CCSDS Space Link Protocol WG meet recently to discuss how we would augment the directive set in Prox-1, keeping it backward compatible with Mars but adding the needed functionality for Lunar Ops. It was attended by reps from ESA such as Brice Dellandrea and others who are aware of what is happening on the European side of the interface.

So, please let me know if you have any comments regarding this proposed addition.

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-sea-dls/attachments/20230302/c16f0c35/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 146518 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20230302/c16f0c35/attachment-0001.png>