[Sls-rfm] [SLS-CC] [BULK] Re: [EXTERNAL] RE: Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

Wed Nov 22 17:16:04 UTC 2023

Hi Jorge,

What you propose makes perfect sense to me allowing for future coding entries based upon rate and length.
If I don’t hear any concerns with this approach, I will update the Coding parameter for the S-band directives accordingly.

Many thanks,
Greg

From: Jorge Quintanilla <Jorge.Quintanilla at ext.esa.int>
Date: Wednesday, November 22, 2023 at 3:21 AM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov>, "Rodriguez, Shannon (GSFC-5670)" <shannon.rodriguez-1 at nasa.gov>
Cc: Nicola Maturo <Nicola.Maturo at ext.esa.int>, "Lee, Wing-tsz (GSFC-5670)" <wing-tsz.lee-1 at nasa.gov>, "Kazz, Greg (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org>, "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>, Space Link Coding & Synchronization Working Group <sls-cc at mailman.ccsds.org>
Subject: RE: [SLS-CC] [BULK] Re: [EXTERNAL] RE: Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

Hi Greg, all,

Yes, we (ESA part of the C&S WG) agree with Shannon. In the planned update of 211.2-B for S-band Proximity-1, we only permit those 3 LDPC codes, plus uncoded.

In the general C&S blue book (131.0-B), there are 10 possible LDPC codes, corresponding to the 9 combinations of rates [1/2, 2/3, 4/5] with the block lengths [1024, 4096, 16384] bits, plus the code with rate ~7/8 and block length 7136 bits. For Prox1 we selected 3 among those 10. Other non-Prox1 proximity links (for instance, those defined in LNISv5) might have a wider selection (LNISv5 selects 7 among the 10), but my understanding of the joint meeting in The Hague is that in your Annex we would only list (at least for now) the Prox1 allowed codes.

My proposal is that we list only those 3 LDPC codes (+uncoded) but leaving gaps for the rest of LDPC codes, for instance:

  1.  ‘000000’ = Uncoded;
  2.  ‘000001’ = LDPC(2048,1024);
  3.  ‘000101’=  LDPC(6144,4096);
  4.  ‘001010’ = LDPC(8160,7136);
  5.  other = RESERVED BY CCSDS
(i.e, we leave gaps like 000010, 000011, 000100… for the other combinations of code rates / block lengths, following a sensible order of increasing code rate and increasing length)

Best regards,

Jorge Quintanilla | Senior Consultant
CGI Deutschland B.V. & Co. KG
GOF 9 Frame Contract at ESOC
ESA/ESOC OPS-GSS
Robert-Bosch-Str 5 | 64293 Darmstadt | Germany
+49 6151 902886

From: SLS-CC <sls-cc-bounces at mailman.ccsds.org> On Behalf Of Kazz, Greg (US 312B) via SLS-CC
Sent: Tuesday, November 21, 2023 11:52 PM
To: Rodriguez, Shannon (GSFC-5670) <shannon.rodriguez-1 at nasa.gov>
Cc: Nicola Maturo <Nicola.Maturo at ext.esa.int>; Lee, Wing-tsz (GSFC-5670) <wing-tsz.lee-1 at nasa.gov>; Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>; sls-rfm at mailman.ccsds.org; Space Link Coding & Synchronization Working Group <sls-cc at mailman.ccsds.org>
Subject: Re: [SLS-CC] [BULK] Re: [EXTERNAL] RE: Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Shannon, et all

I wasn’t aware that the list of potential Proximity-1 channel codes for S-band was already reduced based upon a previous agreement.
I included all the potential code lengths based upon what is currently available for LDPC into my table.
If the consensus of the SLP, C&S, and RF&MOD WGs is to just go with the following codes, then I can certainly document that in the S-band directive set.
So if that is the case, we would only permit:

  1.  LDPC(2048,1024) rate ½
  2.  LDPC(6144,4096) rate 2/3
  3.  LDPC(8160,7136) rate 7/8

However, what about uncoded ? (which was a legal option at UHF)
Is uncoded still a reasonable option at S-band ?

If anyone has an issue with those three codes being the exclusive set for Prox-1 S-band, please let us know.

Thanks much,
Greg

From: "Rodriguez, Shannon (GSFC-5670)" <shannon.rodriguez-1 at nasa.gov<mailto:shannon.rodriguez-1 at nasa.gov>>
Date: Tuesday, November 21, 2023 at 1:01 PM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Fong, Wai H. (GSFC-5670)" <wai.h.fong at nasa.gov<mailto:wai.h.fong at nasa.gov>>, Andrea Modenini <Andrea.Modenini at esa.int<mailto:Andrea.Modenini at esa.int>>, "Lee, Dennis K (US 332G)" <dennis.k.lee at jpl.nasa.gov<mailto:dennis.k.lee at jpl.nasa.gov>>, Nicola Maturo <Nicola.Maturo at ext.esa.int<mailto:Nicola.Maturo at ext.esa.int>>, "Lee, Wing-tsz (GSFC-5670)" <wing-tsz.lee-1 at nasa.gov<mailto:wing-tsz.lee-1 at nasa.gov>>
Subject: Re: [BULK] Re: [SLS-CC] [EXTERNAL] RE: Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

Hi Greg and others,

I see more than 1 coding block size for each coding option, which differs from the notes I had from Spring 2023 meeting and I cant track in the WG feedback (written) that we requested this. Maybe I am drawing a blank from our Fall meeting. Did we want those other options?

Here what I see in the online version you have:

[image]

Here what we had in Spring MOM:

[Graphical user interface, text, application    Description automatically generated][image]

From: SLS-CC <sls-cc-bounces at mailman.ccsds.org<mailto:sls-cc-bounces at mailman.ccsds.org>> on behalf of "Kazz, Greg (US 312B) via SLS-CC" <sls-cc at mailman.ccsds.org<mailto:sls-cc at mailman.ccsds.org>>
Reply-To: "Kazz, Greg J (JPL-312B)[JPL Employee]" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Date: Thursday, November 16, 2023 at 3:58 PM
To: DONA' Gabriele <gabriele.dona at thalesaleniaspace.com<mailto:gabriele.dona at thalesaleniaspace.com>>, "Kazz, Greg via SLS-SLP (US 312B)" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>, "Shames, Peter M (JPL-312B)[JPL Employee]" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, Ignacio Aguilar Sanchez <Ignacio.Aguilar.Sanchez at esa.int<mailto:Ignacio.Aguilar.Sanchez at esa.int>>, "Lee, Dennis K (JPL-332G)[JPL Employee]" <dennis.k.lee at jpl.nasa.gov<mailto:dennis.k.lee at jpl.nasa.gov>>, "Andrews, Kenneth S (JPL-332B)[JPL Employee]" <kenneth.s.andrews at jpl.nasa.gov<mailto:kenneth.s.andrews at jpl.nasa.gov>>, Andrea Modenini <Andrea.Modenini at esa.int<mailto:Andrea.Modenini at esa.int>>, "sls-rfm at mailman.ccsds.org<mailto:sls-rfm at mailman.ccsds.org>" <sls-rfm at mailman.ccsds.org<mailto:sls-rfm at mailman.ccsds.org>>, Space Link Coding & Synchronization Working Group <sls-cc at mailman.ccsds.org<mailto:sls-cc at mailman.ccsds.org>>
Cc: "Brice.Dellandrea at esa.int<mailto:Brice.Dellandrea at esa.int>" <Brice.Dellandrea at esa.int<mailto:Brice.Dellandrea at esa.int>>
Subject: [BULK] Re: [SLS-CC] [EXTERNAL] RE: Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

Hi Gabriele,

Nice to meet you, even if it is only via email.
I included the entire SLP WG on this distribution, since the topic is an important one.
The Prox-1 physical layer standard (CCSDS 211.1-B-4) specifies Channel 1 as the hailing channel for UHF at Mars in which Ch 1 is defined as 435.6 MHz forward and 404.4 MHz return.

I realize that the Mars Program deviated from this standard and utilized Channel 0 as their Hailing Channel and their working channel.
So this difference is a de-facto vs de-jure issue.

CCSDS 211.1-B-4 also says in a NOTE (which is non-normative) that “Enterprise-specific hailing channel frequencies can be defined in the default configuration of the Physical Layer parameters”. Furthermore, in another follow on NOTE (non-normative) in the same section, it says, “if transceivers are compatibly configured, hailing can occur on an agreed-to channel. The first generation transceivers are fixed frequency and use Channel 0”.

So, I believe the Mars Program backward compatibility issue has been documented in 211.1-B-4. Would you agree ?

From an international cross-support CCSDS standard point of view, what I have documented in this proposed Annex for default session control parameters is correct i.e., The Prox-1 standard (CCSDS 211.1-B-4) specifies Channel 1 as the hailing channel for UHF at Mars at those frequencies above. Also per 211.1-B-4, Ch 0 is defined as the forward 437.1 MHz frequency, and the return frequency 401.585625.

Best regards,
Greg
From: DONA' Gabriele <gabriele.dona at thalesaleniaspace.com<mailto:gabriele.dona at thalesaleniaspace.com>>
Date: Thursday, November 16, 2023 at 1:35 AM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Brice.Dellandrea at esa.int<mailto:Brice.Dellandrea at esa.int>" <Brice.Dellandrea at esa.int<mailto:Brice.Dellandrea at esa.int>>
Subject: [EXTERNAL] RE: Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

Dear Greg,

I’m not sure whether I should reply to you or to the whole WGs. Anyway here’s my comment about the default parameters used to establish hailing.

In Section A1.1 UHF BAND HAILING CHANNEL PARAMETERS, I believe the default hailing channel should be Channel 0 and not Channel 1. That is important to keep backward compatibility with existing transceivers. By the way, there is a typo:  Ch 0 (404.4 MHz) should read Ch 1 (404.4 MHz) instead. Then, if the intention is to allow hailing on other channels (e.g. channel 1), on specific cases/missions, then I have no objections.

I hope this comments helps.

Regards,
Gabriele.

P.S. In case you wandered, I am the engineering responsible for the UHF subsystems of the ExoMars missions for Thales Alenia Space.

Gabriele Donà, Ph.D.
Thales Specialist
Head of Data Systems & Communication Department

Phone: +39 011 7180 555
Mobile: +39 380 591 6240
Personal Meeting Room: 3080044019
Link: https://join3.thalesgroup.com/<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fjoin3.thalesgroup.com*2F__*3B!!PvBDto6Hs4WbVuu7!L1wAVo628dCMgtpAAumuBTZAr-X3maH_jE88g_kNyAIz5t8dXwpN9AfIWXmU1LBJ8LslZfBgCPKTxNV-al8m1fXa6YllEl-cROvbRj7H*24&data=05*7C01*7Cgreg.j.kazz*40jpl.nasa.gov*7C6bd82a8784d54ec3ebc908dbead4e655*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C638361972358380601*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=kGy*2F9lUNVWnvE0J3uUkFnJ206KtfhWDEuA5zczIal5Y*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!NYSi5qAX73LVfnYbu5I9PALycDVAuXN2Whx6UQwAiO4OEXoRXPuUrSXHgHmtF7Gsh1CBDamPNbN31LK4I590Nb0VuU5JTMxf$>
Participant PIN: 988 455

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> On Behalf Of Kazz, Greg (US 312B) via SLS-SLP
Sent: 15 November 2023 23:29
To: Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>; Space Link Coding & Synchronization Working Group <sls-cc at mailman.ccsds.org<mailto:sls-cc at mailman.ccsds.org>>; sls-rfm at mailman.ccsds.org<mailto:sls-rfm at mailman.ccsds.org>
Cc: Brice Dellandrea <Brice.Dellandrea at esa.int<mailto:Brice.Dellandrea at esa.int>>
Subject: [Sls-slp] Updated Proximity-1 Directives and Default Session Control Parameters for Lunar Operations

Dear CCSDS SLP, C&S, and RFM WGs,

I took the liberty of updating both the Proximity-1 Directive Set as well as the Default Session Control Parameters for Lunar Operations, based upon the inputs provided at the Fall CCSDS Meeting recently concluded in The Hague (Joint meeting held on Nov. 10, 2023).

The update to both the Lunar Proximity directives and the default session parameters is in the CWE now under this SLP WG directory:
https://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2Fsls%2Fdocs%2FSLS%2DSLP%2FMeeting%20Materials%2F2023%2FFall%2FPost%20Meeting%20Prox%201%20work&FolderCTID=0x012000439B56FF51847E41B5728F9730D7B55F&View=%7BAE8FB44C%2DE80A%2D42CF%2D8558%2DFB495ABB675F%7D<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fcwe.ccsds.org*2Fsls*2Fdocs*2FForms*2FAllItems.aspx*3FRootFolder*3D*2Fsls*2Fdocs*2FSLS*2DSLP*2FMeeting*20Materials*2F2023*2FFall*2FPost*20Meeting*20Prox*201*20work*26FolderCTID*3D0x012000439B56FF51847E41B5728F9730D7B55F*26View*3D*7BAE8FB44C*2DE80A*2D42CF*2D8558*2DFB495ABB675F*7D__*3BJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!L1wAVo628dCMgtpAAumuBTZAr-X3maH_jE88g_kNyAIz5t8dXwpN9AfIWXmU1LBJ8LslZfBgCPKTxNV-al8m1fXa6YllEl-cRGoUqlwQ*24&data=05*7C01*7Cgreg.j.kazz*40jpl.nasa.gov*7C6bd82a8784d54ec3ebc908dbead4e655*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C638361972358380601*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=vI5ApVKJqs5v8HUPtnvBxM*2Bukb5wazD5AqHpaa3f79A*3D&reserved=0__;JSUlJSUlJSUlJSUlJSoqKioqKioqKioqKiolJSUlKioqKioqJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!NYSi5qAX73LVfnYbu5I9PALycDVAuXN2Whx6UQwAiO4OEXoRXPuUrSXHgHmtF7Gsh1CBDamPNbN31LK4I590Nb0VuXWL0ftQ$>

There are still several TBDs remaining to be resolved including the action items taken by the RFM WG (e.g., define specific hailing and working channel frequencies at S-band, etc)
I am also interested to know if you have specific values for the new parameter: Mod Index.

Please let me know if you have comments, so that I can incorporate them into these two normative annexes which will reside in the restructured Space Data Link Protocol Session Control Blue Book.

Best regards,
Greg
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20231122/425c0656/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 261419 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20231122/425c0656/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 185899 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20231122/425c0656/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 237548 bytes
Desc: image003.png
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20231122/425c0656/attachment-0002.png>