[CESG] AW: AW: [SANA #5270] AW: SCID assignments

Thu Jul 30 10:56:09 UTC 2015

Hi All,
Thank you very much for your comments / answer and the good discussion.
Personally I like the option 4, but I think that need to be discussed and agree.
Is that something to be discussed in Darmstadt or need to be earlier?
Thanks again, I already talk to the project and they were not so happy but accepted the rejection of the SIM SCID.

May be a last point for the discussion:
------
You are correct, but we seem to have a bit of an issue.  While the transmitting frequencies (TM & TC) are on the form (http://sanaregistry.org/cgi/spacecraftid) they do not appear in the available database in SANA (http://sanaregistry.org/r/spacecraftid/spacecraftid.html).  We will have to check with the SANA operator to see if this information is, in fact, in the database but is just hidden in what is displayed.   We will also have to accommodate spacecraft that use more than one frequency, as in S / X or X / Ka.  I do not know that the database in its current form accommpodates that.
------

We are having more and more Satellites with more than a frequency (S/Ks e.g) , that is a point that may be should also clarified and Peter and Jean-Marc point it out
Best Regards
Osvaldo

Von: Shames, Peter M (312B) [mailto:peter.m.shames at jpl.nasa.gov]
Gesendet: Mittwoch, 29. Juli 2015 23:22
An: Soula Jean-Marc; Peinado, Osvaldo Luis
Cc: CCSDS Engineering Steering Group - CESG Exec; SANA Steering Group (SSG)
Betreff: Re: AW: [SANA #5270] AW: SCID assignments

Dear Jean-Marc,

I agree completely that this is not a settled issue by any means, and I am glad that you and Osvaldo are engaged more actively in the discussion.  As I noted, this has been discussed for some time, but this is the first effort to try and come to terms with it and to actually identify a workable solution.  I believe that open dialogue is essential, since this ultimately affects all agencies (and other organizations) who use CCSDS standards.

Once we identify an agreed path forward we must then, as quickly as we can, get all of the involved elements (registries, documents, procedures), revised so that everyone knows what to expect.  In the meantime I think we are in a transitional state where we really must retain as much of the limited "SCID namespace" as we can in order to not find ourselves at an abruopt halt when we run out of available numbers.

Other comments are in-line, below.

Very best regards, Peter

From: Jean-Marc Soula <Jean-Marc.Soula at cnes.fr<mailto:Jean-Marc.Soula at cnes.fr>>
Date: Wednesday, July 29, 2015 at 10:49 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>" <osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, "SANA Steering Group (SSG)" <ssg at mailman.ccsds.org<mailto:ssg at mailman.ccsds.org>>
Subject: RE: AW: [SANA #5270] AW: SCID assignments

Bonjour à tous,

I share the Oswaldo's concern on which explanations or which solutions may be offered by CCSDS to the projects requesting multiple SCId and being rejected for those assets pertaining to the simulator / tester ... category.
I understand the rules have changed (and I do not object the arguments for that) but the procedures were not yet revised (the abstracted blue text below clearly shows that simulators / testers were valid assets to obtain a SCId) ... nor alternate solutions are offered (which we should discuss further now).

You are correct in that the current, published, SCID document does not discriminate against simulators nor testers.  And yet we have this problem that we must resolve in some way that does not halt the ability of new spacecraft to be flown, by as many different users as can be accommodated.  In the immediate term the only way that I can see to handle this is to only give out new (or re-cycled) SCIDs to the real spacecraft.  Your support for a set of registries sorted by frequency, and inclusion of a "Frequency = none" category may be a rapid way forward.

I think we can, through discussion, arrive at an agreed recommendation to agencies re how to deal with the similator / tester issue.  I hope that this is the start of an active discussion where we try and arrive at that agreement, because so far the discussion jhas ben of the nature "We have a problem ..... What do we do?"

In CNES we also have several projects for which simulators have been assigned a SCId, different from the one assigned to the SC.
Some more may come soon with similar requirements...

I hope that is sufficient motivation to have you and your staff, among others from different agencies, get engaged in the discussion.

CCSDS should offer a workaround way to answer these requests and not just reject the request because of the lack of Ids.

I agree we need a work-around.  And I think we need to find one quickly and document it.

Meanwhile, if we do not modulate requests for multiple SCIDs what is to stop anyone from requesting several SCIDs for one spacecraft and using up what little resource we have left?

Out of your list of activities below, Peter, I see Number 3 as quite promising in terms of solving our SCId capacity issue, but I am not 100% sure if Number 4 could be another solution or not.

In more details:

Number 3: if SANA may allocate the same SCId to several missions, based on the frequency discrimination,  the issue of the testers / simulators may be solved as they fall in the category "no radiation" (meaning "no frequency"). Frequencies are already part of the SCId request form and the information is already available for a majority of missions (I hope).

You are correct, but we seem to have a bit of an issue.  While the transmitting frequencies (TM & TC) are on the form (http://sanaregistry.org/cgi/spacecraftid) they do not appear in the available database in SANA (http://sanaregistry.org/r/spacecraftid/spacecraftid.html).  We will have to check with the SANA operator to see if this information is, in fact, in the database but is just hidden in what is displayed.   We will also have to accommodate spacecraft that use more than one frequency, as in S / X or X / Ka.  I do not know that the database in its current form accommpodates that.

As you suggest, perhaps we can, for a while, adopt that "no frequency" approach and still manage the simulator / tester assignments within SANA.  I think that is an interesting approach to discuss.

Number 4: I saw a lot of emails on registries but could not spend enough time with them to be sure of the meaning of "Object Id (OId)" and how it may be used in practice to differentiate the assets of a same satellite project and the assets of multiple projects between them.  It could be, assuming some verifications, that the OID is another way to allow SANA to allocate several times the same SCId to several missions, based on the OID discrimination this time.

The concept of the OID is an ISO construct that the Cross Support Services area first started to use.  It is a tree structured name space where "CCSDS" (ISO OID = 1.3.112.4) forms the base of the tree and we then get to determine which classes of objects we will assign unique numbers to.  A proposal for how to manage that namespace is in the draft Registry Policy document and there is an information model for it as well.  Both are attached here.  What has been proposed is that there is a branch of the OID tree for spacecraft, and that every spacecraft, simulator, or tester would have a unique SCID assigned.  That Spacecraft OID, as proposed, is just a number, of the form 1.3.112.4.7.nnn.  This OID is assigned when any registeration request is made and it remains associated with that spacecraft forever.  In that way it can be used to unambiguously tag the spacecraft data and allows the SCIDs to just be used on the transmitted spacelink.

The rest of the Spacecraft information will be stored in the Spacecraft database, as it is now, along with the SCID (during the valid period) and the OID (which is permanent).  The model of the spacecraft database is also attached for reference.  Most of these fields are in the current database, but any shown in red are newly added.  It does occur to me now that we will probably need to add both transmitting and receiving frequencies, and to add the ability to have a spacecraft with multiple frequency bands.

So if we adopt some such approach I agree that we can re-allocate the same SCID, using the Version Number (protocol type) and Frequency(s).  On the ground we can use just the OID as a unique identifier since it is permanent.  But unless there is a way to adopt the OID on the spacelink I do not think that gives us any discrimination in radiated space communication.

Those two options should be explored quickly, and I believe this is the idea in the messages below, to confirm that the activity Number 2 may be cancelled and there is enough room then to continue the allocation to  simulators / testers.
Does it make sense ?

Based on this discussion, and if others agree with the use of frequency band (including = none) , then I think that we could continue to use the SANA to regsiter simulators and testers, as long as we can use that distinction as well.  For that matter, since these simulators and testers will each belong to some single organization that "owns" that asset you could even imagine a "Frequency = None" namespace on a per agency / organization basis.  There is no fear then of collisions in communications and the OID can be used for unambiguous identification of datasets.  It is a little more complicated than what we now do, but it is quite "future proof" and avoids any risk of ambiguity.

In any case, one criteria to decide is how long it may take to put a solution in place.
If too long, then we have a risk of overflow on the SCIds in the meantime ; if doable in a reasonable time span, it would be a pity to have rejected some requests for SCIds and have a solution for them a few months later...

I agree, but contingent on getting rapid agreement on having a "Frequency = none" SCID registry immediately set up, either on a global basis or on an agency / organization basis.  Does that sound agreeable to you (and others)?

I think, for practicality, that we also need to reach agreement on a set of SCID registries separated by frequency band (including None) so that we can immediately re-gain some SCID breathing room/

Does that sound workable as well?

So my recommendation would be to work on activities 3 or 4, with the objective not to apply number 2.
Of course activities number 1 and 5 should continue, with less pressure on number1 if a solution is found ... and no pressure on number 5 which anyway is a long term and maybe not a global solution.

For further discussions I believe...

Yes.  Indeed.

Best regards

Jean-Marc Soula
CNES - DCT/OP/C-STA
Advisor, GN Operations
18 Avenue Edouard Belin
31401 Toulouse Cedex 9 - France
Tel.: +33 (0)5 61 2 74647
Fax.: +33 (0)5 61 2 73135
Email: Jean-Marc.Soula at cnes.fr<mailto:Jean-Marc.Soula at cnes.fr>

Best regards, Peter

De : ssg-bounces at mailman.ccsds.org<mailto:ssg-bounces at mailman.ccsds.org> [mailto:ssg-bounces at mailman.ccsds.org] De la part de Shames, Peter M (312B)
Envoyé : mercredi 29 juillet 2015 18:18
À : osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>
Cc : CCSDS Engineering Steering Group - CESG Exec; SANA Steering Group (SSG)
Objet : [SSG] Re: AW: [SANA #5270] AW: SCID assignments
Importance : Haute

Dear Osvaldo,

As I think you are aware, the CCSDS is in danger of running out of available spacecraft ID (SCID) numbers.  You could say that we are now being hurt by our own success because there are so many spacecraft using CCSDS data link and related standards that we no longer can assign a SCID for the spacecraft, the simulator, and other possible "flight-less birds".

In the current SCID document, CCSDS 320.0-B-6C1, we have this statement (emphasis added):

Section 2.1 Purpose of the CCSDS SCID

Because the SCID field is only eight or ten bits long, the SCID is not intended to provide unique identification for all times.
 It is inevitable that the SCIDs will have to be reused; however, at any one time, the number of vehicles under simulation,
test, or active operational control is not anticipated to exceed the available numbering domains.

Clearly this is no longer the case and the SSG, SLS and CESG have been discussing this for at least the last three meetings.  There are several loosely coordinated activities which are now in process that relate to this:

1) We have requested the Agency Representatives to relinquish all assigned SCIDs for spacecraft that are no longer operational.  This has been somewhat successful, but we need to do it again.
2) We are in the process of revising the SCID assignment procedures to no longer allow assignment of multiple SCID for a spacecraft (simulators, testers, etc)
3) We are considering the use of frequency separation as well as the current Version Number (VN) separation that is now in use.  This could relatively easily increase the number assignment space.
4) Under the new registry approach that is now in discussion we will be assigning unique, permanent, object identifiers (OID) to all spacecraft, similators, flightless birds, etc.  These will persist through time.
5) We are working on a new protocol, USLP, with a larger SCID number space.

We have not yet discussed in any depth what recommendation we can make to organizations who wish to have a separate, unique, SCID that they can use internally to distinguish the spacecraft from any other simulators or test gigs.  Clearly this is a concern, but it is may be treated as an internal issue that can be managed locally.  It does not have the same potential for cross agency impact because any such signals will not be broadcast.

If you (or anyone else on this thread) has any other ideas or wishes to contribute to the discussion please do so.  I think that this is an important enough issue for us to work quickly (as quickly as CCSDS can move) to come up with a resolution.

Best regards, Peter

On 7/29/15, 7:43 AM, "osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>" <osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>> wrote:

Dear Audric,
I know about the problem of SCIDs becoming rare.
You can process the satellite one, and discard the SIM one, BUT ....I need to have for the project anyways and official answer from SANA.
It should be possible to inform the users about the situation and in case of rejecting a request indicate a reference to a document and to propose a solution, like "use the same ID as the Spacecraft or something that you like, because your system is a closed one", as example , can you do that?
I have another question:
I need to submit a request for another Satellite and it looks like the link to do the request from the SANA page simply disappear, it is only an E-mail.
It is that correct?
Thanks and best Regards
O. Peinado

-----Ursprüngliche Nachricht-----
Von: SANA [mailto:info at sanaregistry.org]
Gesendet: Mittwoch, 29. Juli 2015 16:07
An: Peinado, Osvaldo Luis
Betreff: Re: [SANA #5270] AW: SCID assignments

Dear Mr. Peinado,

We were waiting for the SSG answer before getting back to you and see if
you had any constraint on the two SCIDs being assigned at the same time
or not.

If you tell us that we can go and process the non-sim request, we will
happily do that.

Thank you.

--
Best regards,
Audric Schiltknecht
Space Assigned Numbers Authority

Le 2015-07-29 09:47, osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de> a écrit :
Dear Audrich
Thank you for your answer.
I´m aware about the discussion about the SIM SCID and that till now is nothing written down to deal with it, but what happened with the SCID for the satellite?
I sent two separate request.
I do not see it also in the list of registry updates, why?
Best Regards
Osvaldo
-----------------------------------
Dr. Osvaldo Peinado
Ground Operations Manager
German Space Operations Center (GSOC)
Tel:  +49 8153 28 3010
Fax:  +49 8153 28 1456
Mobile: +491729410099
German Aerospace Center (DLR)
Oberpfaffenhofen
82234 Wessling
Germany
-----Ursprüngliche Nachricht-----
Von: Space Assigned Numbers Authority [mailto:info at sanaregistry.org]
Gesendet: Dienstag, 28. Juli 2015 22:35
An: Peinado, Osvaldo Luis
Cc: Space Assigned Numbers Authority
Betreff: SCID assignments
Dear Mr. Peinado,
SANA are currently discussing some issues regarding your recent SCID
requests with the SSG (Sana Steering Group).
When all is sorted out, we will inform you of the result.
Thank you for your understanding.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150730/b6143264/attachment.html>