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

Shames, Peter M (312B) peter.m.shames at jpl.nasa.gov
Thu Jul 30 17:50:45 UTC 2015

Thanks for the clarifications Marc.  That helps a lot.

One question for you is whether what we have in the “TM & TC frequencies” slots are actually frequencies, as in 2380 Ghz, or if they are frequency bands, as in “S Band”.  I think that we may get enough relief from just using the frequency bands (see attached table) that this in itself may be adequate, but I do recognize that there may be issues even at that level.

As you pointed out:

that the reliability of that data is unknown for
various reasons, such as: data was not entered properly by the operator,
data was not provided by the requestor, frequencies were changed from
the time of the registration request to the time of the launch and the
requestor never sent the information back to the registry operator

Do you have any faith that if we were to attempt to apply the “separation by frequency bands” approach that we would have success at the 95% plus level, or would we be more at the 75% or 50% level?

As for “clear procedures”, yes, we do understand absolutely the need for this, for you as SANA Operaotr and for the user / requestor community.

Thanks, Peter

On 7/30/15, 8:54 AM, "Marc Blanchet" <info at sanaregistry.org<mailto:info at sanaregistry.org>> wrote:

- clarifications below enclosed in <SANA> </SANA>.


On 29 Jul 2015, at 17:22, Shames, Peter M (312B) wrote:

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

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><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><mailto:peter.m.shames at jpl.nasa.gov>>,
"osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado at dlr.de>"
<osvaldo.peinado at dlr.de<mailto: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><mailto:cesg at mailman.ccsds.org>>, "SANA
Steering Group (SSG)"
<ssg at mailman.ccsds.org<mailto: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.

<SANA>Currently, as discussed a while ago when we took over the
spacecraftid registry, frequencies are kept internally in the database
but are not exposed.

However, one has to understand that, as we did a giant cleanup of the
registry, it is clear that the reliability of that data is unknown for
various reasons, such as: data was not entered properly by the operator,
data was not provided by the requestor, frequencies were changed from
the time of the registration request to the time of the launch and the
requestor never sent the information back to the registry operator,
etc…  Therefore, as we have seen for some IDs that were allocated
simultaneously to multiple missions, it took a long time to get the
space agencies involved to find the real frequencies used for those
missions. Therefore, the use of the frequency data for concurrent use of
spacecraft ids are a challenge.  Moreover, we also heard that
spacecraftids are also used within information systems to uniquely
identify the spacecraft, and that id does not include the frequencies.
Therefore, the collision may also happen in information systems.

One also has to remember that we have been accepting requests and
provided assignments of spacecraft ids that were requested to be hidden
publicly (for various reasons such as military). Therefore, the public
version of the registry is not a full view of the database.

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.

<SANA>we can certainly make it happen</SANA>

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

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 = 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  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?

<SANA>From the point of view of SANA, it would be good for our
operations point of view that we had clear and written and
agreed/approved recommendations on the way forward. Written so we can
refer the requestors to the document that describes the (new) policy. It
does not need to be a full blown book, but some document that shows the
new policy that we are using as our base assignment policy.</SANA>

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
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><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>
[mailto:ssg-bounces at mailman.ccsds.org] De la part de Shames, Peter M
Envoyé : mercredi 29 juillet 2015 18:18
À : osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado at dlr.de>
Cc : CCSDS Engineering Steering Group - CESG Exec; SANA Steering Group
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

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><mailto:osvaldo.peinado at dlr.de>"
<osvaldo.peinado at dlr.de<mailto: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
you had any constraint on the two SCIDs being assigned at the same
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><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
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)
82234 Wessling
-----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.

[CCSDS OID Tree flat 10Jul15 v6.pdf]

[Spacecraft ID, name, & characteristics v1.pdf]

[CCSDS SCID Registry relationships v3.pdf]
SSG mailing list
SSG at mailman.ccsds.org<mailto:SSG at mailman.ccsds.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150730/4d7a18ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-07-30 at 10.49.17 AM.png
Type: image/png
Size: 301953 bytes
Desc: Screen Shot 2015-07-30 at 10.49.17 AM.png
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150730/4d7a18ee/attachment.png>

More information about the CESG mailing list