[CESG] Re: [SSG] [SANA #5270] AW: SCID assignments
Marc Blanchet
info at sanaregistry.org
Thu Jul 30 15:54:40 UTC 2015
- clarifications below enclosed in <SANA> </SANA>.
Marc.
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
> 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.
<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.
</SANA>
> 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
> 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?
<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
> 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.
>
>
>
>
> [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
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg
More information about the CESG
mailing list