[CESG] CESG-P-2021-02-002 Approval to release CCSDS 132.0-P-2.1, TM Space Data Link Protocol (Proposed Pink Sheets, Issue 2.1) for CCSDS Agency review

Sat Feb 20 16:18:03 UTC 2021

Dear CESG Members,

Conditions for approval of CCSDS 132.0-P-2.1, TM Space Data Link 
Protocol (Proposed Pink Sheets, Issue 2.1) have been disposed to the 
satisfaction of the AD(s) who voted to approve with conditions. The 
Secretariat will now proceed with CMC polling to authorize release 
for Agency review.

Thomas Gannett
thomas.gannett at tgannett.net
+1 443 472 0805 
-------------- next part --------------
From:	Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent:	Friday, February 19, 2021 11:01 AM
To:	Kazz, Greg J (US 312B)
Cc:	Gian.Paolo.Calzolari at esa.int; Gilles.Moury at cnes.fr; Matt Cosby; Tom 
Gannett
Subject:	Re: [EXTERNAL] SEA Conditions on 132.0-B TM SDLP

Follow Up Flag:	Follow up
Flag Status:	Flagged

Categories:	Poll Condition Closure

Thanks Gippo. 

That works for me.

Peter 
Sent from Peter's JPL iPhone X 

Everything should be made as simple as possible, 
but not simpler.  

~Albert Einstein

On Feb 19, 2021, at 7:54 AM, Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov> wrote:
 OK 
Greg
Sent from my iPhone

On Feb 19, 2021, at 01:19, Gian.Paolo.Calzolari at esa.int wrote:
Peter,  
        I agree that formally speaking "clause 4.1.2.2.3.2 never stated that 
the SCID provided a globally unique identifier" but it somehow induces 
that understanding.  

If it is OK for the other SLS guys in this distribution, I am fine with 
keeping the 3 clauses and amending the note (according to your 
proposal) e.g. as follows 
NOTE   
    The  Space  Assigned  Numbers  Authority  (SANA)  assigns  Spacecr
aft  Identifiers  according to the procedures in reference [7]. SCIDs are 
uniquely assigned within the frequency band in which the spacecraft 
operates; i.e. the same SCID value may also be assigned to a different 
spacecraft operating in another frequency band as per reference [7].  

This should solve any ambiguity without formally calling Q-SCID in this 
book.  

Best regards to you all and have a nice week end.  

Gippo  

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>  
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>  
Cc:        "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>, "Kazz, Greg J (US 
312B)" <greg.j.kazz at jpl.nasa.gov>, "Matt Cosby" <matt.cosby at goonhilly.org>, 
"Tom Gannett" <thomas.gannett at tgannett.net>  
Date:        18-02-21 23:48  
Subject:        Re: [EXTERNAL] SEA Conditions on 132.0-B TM SDLP 

Gippo,

As I stated in my earlier, lengthy, note.  Both 4.1.2.2.3.2 and 4.1.2.2.3.3 
must remain true.  The SCID is static throughout all mission phase.  And 
the SCID provides the identification of the spacecraft which is associated 
with the data contained in the Transfer Frame.  I do not see why this is 
an issue and I believe that removing this clause leads to a falsehood, or 
at the very least, an ambiguity.

That clause 4.1.2.2.3.2 never stated that the SCID provided a globally 
unique identifier.  In fact, given the original sin of 8-bit and 10-bit 
SCIDs that partially overlapped any claims of uniqueness were violated 
years ago.

I recommend that you leave that clause in the spec, along with the 
note.   But I think it would be wise to amend this NOTE with the simple 
statement that these SCIDs are uniquely assigned within the frequency 
band in which the S/C operates.  Details are in ref [7], as you note.

Thanks, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int> 
Date: Thursday, February 18, 2021 at 12:32 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Gilles Moury <Gilles.Moury at cnes.fr>, Greg Kazz 
<greg.j.kazz at jpl.nasa.gov>, Matt Cosby 
<matt.cosby at goonhilly.org>, Tom Gannett 
<thomas.gannett at tgannett.net> 
Subject: Re: [EXTERNAL] SEA Conditions on 132.0-B TM SDLP

Peter,  
       if I understand well, you would like to maintain unchanged the third 
requirement below  
4.1.2.2.3.3    The Spacecraft Identifier shall be static throughout all 
Mission Phases.  

Conversely, since the SCID - opposite to Q-SCID - does not allow unique 
identification, it is acceptable to remove the second requirement below  
4.1.2.2.3.2    The Spacecraft Identifier shall provide the identification of 
the spacecraft which is associated with the data contained in the 
Transfer Frame.  
Of course this would also be possible as we keep the folowiing note (we 
never wanted to delete):  
NOTE   
    The  Space  Assigned  Numbers  Authority  (SANA)  assigns  Spacecr
aft  Identifiers  according to the procedures in reference [7].  

Correct?  

This would be OK for me unless Greg or the other SLS guys complain.  

Regards  

Gian Paolo  

PS I understand that the second requirement could be modified to refer 
to the Q-SCID but I fear this would be too cumbersome i this standard 
also because the Q-SCID would need to be introduced out of the blue 
with suitable explanation.  

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>  
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>  
Cc:        "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>, 
"Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>, "Matt Cosby" 
<matt.cosby at goonhilly.org>, "Tom Gannett" <thomas.gannett at tgannett.net>  
Date:        18-02-21 01:43  
Subject:        Re: [EXTERNAL] SEA Conditions on 132.0-B TM SDLP 

Hi Gippo,

It continues to be that case that every entity that uses CCSDS link 
layer protocols is expected to have a unique SCID assigned.  This 
includes all the separate parts of a vehicle, as in your example, that 
splits into three parts, such as lander, rover, and orbiting cruise 
stage.  If each of these entities uses CCSDS link layer protocols 
then each should have a unique SCID assigned.  Those SCIDs, as I 
am sure you are aware, are each now assigned in frequency bins, 
and these are called Q-SCIDs.  If all three use, for instance X-band 
then three X-band Q-SCIDs need to be assigned.  If one of these, 
such as the orbiter, also uses Ka-Band for high rate downlink then 
a separate Ka-Band Q-SCID also needs to be assigned.

These Q-SCIDs are valid from the time they are assigned until the 
S/C is removed from service (for whatever reason).  After that the 
Q-SCID may be re-assigned to another operating spacecraft.  As 
has always been the case, because these SCIDs may be re-assigned 
it is recommended that ground data systems do not use the Q-
SCIDs as some sort of lifetime spacecraft identifier.  The SANA 
registration does provide a unique, assigned forever, ISO OID for 
each registered spacecraft.  This is a globally unique (with the ISO 
world), permanently assigned spacecraft identifier that can be 
mapped to each and every Q-SCID assigned to the S/C for comm 
link purposes.

I hope this short description of what is stated at more length in 
CCSDS 320.0-M-7, and on the SANA SCID registration page, is 
sufficient for you to make sure that all of these protocol docs, 
when they define SCID, also mention that they are unique within 
the operating frequency band(s) of the S/C, that a S/C may have 
more than one, that they must be assigned by the SANA, and that 
there is a documented process for doing this.

Thanks, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int> 
Date: Wednesday, February 17, 2021 at 1:51 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Gilles Moury 
<Gilles.Moury at cnes.fr>, Matt Cosby 
<matt.cosby at goonhilly.org>, Tom Gannett 
<thomas.gannett at tgannett.net> 
Subject: [EXTERNAL] SEA Conditions on 132.0-B TM SDLP

Dear Peter,  
      after SLS coordination with the SLP WG chairs  you find here below 
the reply to your conditions.  
---------------------------------------------------------------------------------------- 
SEA AD        Peter Shames        APPROVE WITH CONDITIONS (state 
conditions that must be satisfied)          
Please explain why sec 4.1.2.2.3 SCID was changed.  For what reason 
was the reference to the SCID being assigned to the S/C, and being 
fixed for all time, removed from the spec?  
------------------------------------------------------------------------------------------

a) 4.1.2.2.3.2 (second requirement)  was removed because, SCID 
is no longer unique any more after the introduction of the Q-SCID.  
b) 4.1.2.2.3.3 (third requirement)  was removed, SLP WG felt it 
was too restrictive for future missions that may morph and change 
their functionality based upon mission phase e.g., a cruse stage 
which morphs and contains 3 components after Orbit Insertion and 
Entry, Descent, and Landing: lander, rover, and orbiting cruse 
stage could require 3 SCIDs instead of 1.  
------------------------------------------------------------------------------------------  

I hope this explanation will be sufficient to remove your condition and 
proceed to Agency Review.  

Best regards  

Gian Paolo 
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).
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).
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).