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

[Shames, Peter M (312B)]

Dear Marc,

I think that we need to be explicit in the (revised and extended) form to
provide a check box for “flight-less birds”.  I think we should make this
explict on the form for the future.  It may be that organizations will
still wish to use something like a “-SIM” suffix, but I think that is
their perogative.  

For the existing SCID assignemnts I think that a lot of the S/C entries do
include “-SIM” or “-TEST”.  I think we can do an initial “triage” of the
assignments and then verify these with the agencies (with the usual amount
of cajoling, prompting, pleading and hand-holding).

In the proposed changes to the Spacecraft registry I also included a
provision for one or more optional alias names.  These could include all
sorts of local pre- and post- launch naming conventions.  For instance the
two JPL MER rovers, now known as Spirit and Opportunity, were known
pre-launch as MER-A and MER-B, and in planning were known as MER-2 and
MER-1.

Regards, Peter



On 7/31/15, 12:22 PM, "Marc Blanchet" <info at sanaregistry.org> wrote:

>
>
>On 31 Jul 2015, at 14:05, Shames, Peter M (312B) wrote:
>
>> Bonsoir Jean-Marc,
>>
>> I hope you have a relaxing weekend.  I am glad to hear that you like
>> the
>> OID idea, it gives us the best way to provide unqiue, persistent, IDs
>> for
>> all spacecraft and simulators.  We have right now concieved this as a
>> flat
>> namespace, but it could also adopt the approach of a master OID for a
>> spacecraft and sub-names for the real bird, simulators, etc.  That is
>> a
>> separate subject, but I did want to point it out as a possibility.
>>
>> I defer to Marc as to what is the best approach for keeping the names
>> in
>> the database normalized, but do recognize, as Jean-Marc pointed out,
>> that
>> several names in the database now have ³-sim² or ³-simulator²
>> qualifiers
>> appended.  From a quick review it looks like this may be true for
>> roughly
>> 5% of the entries.  We will get some leverage from moving these to a
>> ³Frequency = None² table, but not as much as we might.  Whether we
>> continue this naming pattern in the future is open to discussion, but
>> I do
>> understand Marc¹s concern.
>>
>> Based on this I think that we can adopt Jean-Marc¹s phased approach
>> of
>> first splitting off the ³Frequency = None² table and then sorting
>> the rest
>> into frequency bins. However, since this is essentially a table
>> attribute
>> that allows sorting I suspect that when we create the ³Frequency =
>> None²
>> attribute in the table we will have also created the fields for the
>> other
>> ³bins² as well.
>>
>> Please Marc, confirm if this is correct?
>
>we can do that.
>
>However, I’m concerned that we will be relying on a name extension
>(such as -sim), used not necessarily consistently, to know if a
>spacecraft id is not used in real space.
>
>Marc.
>
>>
>> Once this is done we will need to assign the right frequency bin
>> attributes to those S/C where it is obvious, and to then do the sleuth
>> work to determine the correct bins for those where it is ambiguous.
>> That
>> will take more time, but it is something like a 5-10% effect.  We will
>> already have achieved 90% of the separation and I believe that, in
>> itself,
>> will give us a lot of breathing room.
>>
>> Does this sound like it is overall a workable approach?
>>
>> Best regards, Peter
>>
>>
>> On 7/31/15, 7:56 AM, "Soula Jean-Marc" <Jean-Marc.Soula at cnes.fr>
>> wrote:
>>
>>> Sorry for the confusion : I do not recommend to modify names, I just
>>> say
>>> there are names today that reflect the test/simulator nature of the
>>> asset.
>>>
>>> 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
>>>
>>> -----Message d'origine-----
>>> De : Marc Blanchet [mailto:info at sanaregistry.org]
>>> Envoyé : vendredi 31 juillet 2015 16:53
>>> À : Soula Jean-Marc
>>> Cc : Shames, Peter M (312B); osvaldo.peinado at dlr.de; SANA Steering
>>> Group
>>> (SSG); CCSDS Engineering Steering Group - CESG Exec
>>> Objet : Re: [SSG] [SANA #5270] AW: SCID assignments
>>>
>>>
>>>
>>> On 31 Jul 2015, at 10:38, Soula Jean-Marc wrote:
>>>
>>>> Bonjour
>>>>
>>>> I think all of this is good discussion and I also believe the
>>>> frequency band is a sufficient discriminator to avoid interactions
>>>> between in flight assets.
>>>>
>>>> On the other hand, the OID seems to be an excellent idea but "as it
>>>> doesn't fly", the communicating systems cannot discriminate based on
>>>> OID's between signals and data coming from two sources with same
>>>> SCId
>>>> and frequency.
>>>>
>>>> Just a question on the simulators / testers: how many of them do we
>>>> have today in the SCId data base ?
>>>>
>>>> On this, there is also a question in the request form to indicate if
>>>> the SCId is used only on ground for simulation. If the answers are
>>>> kept in the data base, it could be one way to count.
>>>> Otherwise, the names of the assets having the words "simulator" or
>>>> the
>>>> string of characters "sim" may be counted.
>>>
>>> I would really like to _not_ overload the name of the spacecraft with
>>> an
>>> attribute such as simulator. It just makes normalization wrong.
>>> Instead, if we go that route, it would be an additional attribute of
>>> the
>>> spacecraft transmission that says: no radiation, but not in the name.
>>>
>>> Marc.
>>>
>>>> To improve reliability of this process in this case, requestors
>>>> (owners) of such Ids could be asked to confirm if it is used only on
>>>> ground with no radiation...
>>>>
>>>> If we agree to go with the frequency discrimination, it could be in
>>>> two steps, like:
>>>>
>>>> 1)      All SCID's already allocated to simulators / testers may be
>>>> reallocated "from now" to real Spacecraft ; all new requests for
>>>> simulators / testers may be allocated the value of an in-flight
>>>> system
>>>> ; allocation margins are increased in the short term (in which
>>>> proportion ? = depends on the answer to the above question).
>>>>
>>>> 2)      SCIds allocated to real Spacecraft will be differentiated by
>>>> frequency bands.
>>>>
>>>> Step one creates a first step towards discrimination and may help if
>>>> faster to implement: "no radiation" vs "radiation" are the initial
>>>> categories.
>>>> Then the Step 2 becomes less urgent and we may take time to think
>>>> about the best approach to discriminate on bands, considering the
>>>> current status of the data base (completeness, reliability...). Step
>>>> 2
>>>> is then a refining of the category "radiation" of Step 1.
>>>>
>>>> Just for you to occupy your American afternoon... leaving now for
>>>> the
>>>> week end.
>>>>
>>>> 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
>>>> De : Shames, Peter M (312B) [mailto:peter.m.shames at jpl.nasa.gov]
>>>> Envoyé : jeudi 30 juillet 2015 20:57
>>>> À : Marc Blanchet
>>>> Cc : Soula Jean-Marc; osvaldo.peinado at dlr.de; SANA Steering Group
>>>> (SSG); CCSDS Engineering Steering Group - CESG Exec Objet : Re:
>>>> [SSG]
>>>> [SANA #5270] AW: SCID assignments
>>>>
>>>> Thanks Marc.
>>>>
>>>> Just for chuckles I took what you sent, shoved them into a
>>>> spreadsheet
>>>> (attached) and applied the following heuristics:
>>>>
>>>> 1.  For each stated "frequency" input assign it to the corresponding
>>>> band 2.  If there is more than one band sort them within the "Band"
>>>> bin in order of lowest to highest frequency 3.  Assign a sequence
>>>> number for tracking 4.  Sort by Band and then sequence number The
>>>> resulting spreadsheet is attached.  The total unique bands that are
>>>> used are: VHF (1), L(1), S (14), C (3), X (11), Ku (6), K (1), Ka
>>>> (4),
>>>> None (2), not stated (3)
>>>>
>>>> Purely based on pragmatic considerations I would suggest that we
>>>> could
>>>> create "Band Bins" that looked like this:
>>>>
>>>> *   Everything below S-Band (HF, VHF, UHF, L)
>>>> *   S-Band & C-Band
>>>> *   X-Band
>>>> *   K-Band (Ku, K, Ka)
>>>> *   None or unstated
>>>> That gives us four bins (plus "None) to sort all of these spacecraft
>>>> into, which, with only a few exceptions, is pretty straightforward.
>>>> It does, of course, also give us SCID "growth" room of  2-3 X number
>>>> of unique SCIDs because S, X, and the "K"s contain the bulk of the
>>>> assigned SCIDs, at least in this sample.  I am guessing that this
>>>> sample is sufficiently representative, and that future trends are
>>>> going to be toward X and the K's, thus spreading the users out even
>>>> more into these other bins.  The "Below S" bin may get use if we
>>>> start
>>>> to register CubeSats too.
>>>>
>>>> The other issue, of course, is how to track a single S/C that has
>>>> multiple frequencies, but I think the unique OID is the way to do
>>>> that.
>>>>
>>>> Does this seem like it could be made workable?
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>> On 7/30/15, 11:11 AM, "Marc Blanchet"
>>>> <info at sanaregistry.org<mailto:info at sanaregistry.org>> wrote:
>>>>
>>>>
>>>>
>>>> On 30 Jul 2015, at 13:50, Shames, Peter M (312B) wrote:
>>>>
>>>> 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.
>>>>
>>>> It is a mix of everything. Given exactly that, we tried to normalize
>>>> the data but were not able given the too large variety and that the
>>>> previous operator did not enforce any normalization while entering
>>>> the
>>>> data in the registry (no criticism, just a fact). Therefore, we did
>>>> not try to enforce any normalization yet on new data, so these are
>>>> currently just « strings ».  (similarly, when we took over the RF
>>>> asset registry from IOAC, we tried to normalize the data as much as
>>>> possible, but given that it was often entered like strings with no
>>>> format requirements, then it is just a can of worms for data
>>>> normalization).
>>>>
>>>> Here is just a few samples from a quick visual scan of the registry.
>>>> Far
>>>> from comprehensive, but just to give you a sense of the current
>>>> values
>>>> (yes, values in the frequency column), without the spacecraft
>>>> identification. please don't concentrate on the actual values but
>>>> more
>>>> on the diversity of data we have.
>>>>
>>>> 2048.85 MHz (E-S)
>>>> TC
>>>> 1S-Band (Housekeeping), 1X-Band (IDHT Low Rate), 1X-Band (IDHT High
>>>> Rate)
>>>> S-Band
>>>> 2203 MHz, 2206.5 MHz, 2218 MHz, 2227 MHz, 2254.5 MHz, 2265.5 MHz,
>>>> 2284
>>>> MHz Ku-Band TBD
>>>> 7.1808063 GHz (6 MHz BW)
>>>> X-Band 7156.53 MHz
>>>> X-Band 7166 MHz (CMD 10-2000 b/s and RNG), Ka-Band 34.45 GHz (No CMD
>>>> or
>>>> RNG)
>>>> 8190.0 MHz (primary) and 2252.5 MHz (demonstration purposes only)
>>>> 8429.938271 MHz, 8427.222 MHz (noncoherent)
>>>> 3947-52 MHz (C-Band)
>>>> Category B (Deep Space) D/L X-Band  U/L X-Band X-Band, Ka-Band
>>>> (Category B (Deep Space)
>>>> 2044.25 MHz (center Frequency for TC)
>>>> 2225 MHz (S-E), 2048.85 MHz (E-S)
>>>> Frequency pair unknown at this time
>>>> Around 14 GHz
>>>> S-Band 2215 MHz, S-Band 2039 MHz, X-Band 8.025-8.040 GHz Ku-Band
>>>> (14005.0 MHz (V); 14499 MHz(H)); SHF-Band 8397.5 (RHCP) NA - ground
>>>> use only Around 2000 C-band to be determined from 5000 - 5010MHz and
>>>> Ku-band to be determined from 13750 - 14500MHz
>>>> Fdownlink=[2225.025+-n*3.069]MHz,
>>>> n=0,1,2,3,4;Fdownlink=(240/221)*Fuplink
>>>> N/A
>>>> Ground Use Only (Satellite 5850 MHz - 6426 MHz) Around 14 GHz
>>>> 29.1 GHz-29.3 GHz, 19400 MHz-19600 MHz X-Band 8420 MHz (TLM, RS
>>>> 10-18
>>>> Kb/s Turbo),  Ka-Band 32.02 GHz (Carrier Only - Radio Science)
>>>> Around
>>>> 8400 Mhz and 32000 MHz
>>>> 2210.0 MHz TBD
>>>> 2025-2110 MHz. Center frequency has not been determined HRIT 2040.9
>>>> MHz, LRIT 2037.64 MHz 145.870, 145.930, 2405.00 MHz; 145.870 -
>>>> 145.920
>>>> MHz (Transponder)
>>>>
>>>> I stopped way before reaching the end of the registry...
>>>>
>>>>
>>>> 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?
>>>>
>>>> can't tell. I just want to point out that while, on paper, the
>>>> frequency separation might be a good idea, in practice, the registry
>>>> info we have does not provide that reliable data.
>>>>
>>>>
>>>> As for "clear procedures", yes, we do understand absolutely the need
>>>> for this, for you as SANA Operaotr and for the user / requestor
>>>> community.
>>>>
>>>> yeah, just to point out our expectation of the outcome of this
>>>> discussion, from the operator point of view.
>>>>
>>>> Regards, Marc.
>>>>
>>>>
>>>> Thanks, Peter
>>>>
>>>>
>>>>
>>>>
>>>> On 7/30/15, 8:54 AM, "Marc Blanchet"
>>>> <info at sanaregistry.org<mailto:info at sanaregistry.org><mailto:info at sanar
>>>> egistry.org><mailto:info at sanaregistry.org%3e>>
>>>> wrote:
>>>>
>>>> - 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><mailto:Jean-M
>>>> arc.Soula at cnes.fr><mailto:Jean-Marc.Soula at cnes.fr><mailto:Jean-Marc.So
>>>> ula at cnes.fr%3e%3cmailto:Jean-Marc.Soula at cnes.fr%3e>>
>>>> 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><mailt
>>>> o:peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov><mai
>>>> lto:peter.m.shames at jpl.nasa.gov%3e%3cmailto:peter.m.shames at jpl.nasa.go
>>>> v%3e>>,
>>>>
>>>> 
>>>>"osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.p
>>>>ei
>>>> 
>>>>nado at dlr.de><mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado at dlr.
>>>>de
>>>> %3e%3cmailto:osvaldo.peinado at dlr.de%3e>"
>>>> <osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.
>>>> peinado at dlr.de><mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado@
>>>> dlr.de%3e%3cmailto:osvaldo.peinado at dlr.de%3e>>
>>>> Cc: CCSDS Engineering Steering Group - CESG Exec
>>>> <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org><mailto:cesg at mai
>>>> lman.ccsds.org><mailto:cesg at mailman.ccsds.org><mailto:cesg at mailman.ccs
>>>> ds.org%3e%3cmailto:cesg at mailman.ccsds.org%3e>>,
>>>> "SANA
>>>> Steering Group (SSG)"
>>>> <ssg at mailman.ccsds.org<mailto:ssg at mailman.ccsds.org><mailto:ssg at mailma
>>>> n.ccsds.org><mailto:ssg at mailman.ccsds.org><mailto:ssg at mailman.ccsds.or
>>>> g%3e%3cmailto:ssg at mailman.ccsds.org%3e>>
>>>> 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><mailto:Jean-Ma
>>>> rc.Soula at cnes.fr><mailto:Jean-Marc.Soula at cnes.fr<mailto:Jean-Marc.Soul
>>>> a at cnes.fr%3e%3cmailto:Jean-Marc.Soula at cnes.fr>>
>>>>
>>>> Best regards, Peter
>>>>
>>>>
>>>> De :
>>>> ssg-bounces at mailman.ccsds.org<mailto:ssg-bounces at mailman.ccsds.org><ma
>>>> ilto:ssg-bounces at mailman.ccsds.org><mailto:ssg-bounces at mailman.ccsds.o
>>>> rg<mailto:ssg-bounces at mailman.ccsds.org%3e%3cmailto:ssg-bounces at mailma
>>>> n.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><mailto:osvaldo.p
>>>> einado at dlr.de><mailto:osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dl
>>>> r.de%3e%3cmailto: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><mailto:osvaldo.p
>>>>ei
>>>> 
>>>>nado at dlr.de><mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado at dlr.
>>>>de
>>>> %3e%3cmailto:osvaldo.peinado at dlr.de%3e>"
>>>> <osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.
>>>> peinado at dlr.de><mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado@
>>>> dlr.de%3e%3cmailto:osvaldo.peinado at dlr.de%3e>>
>>>> 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><mailto:osvaldo.p
>>>> einado at dlr.de><mailto:osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dl
>>>> r.de%3e%3cmailto: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<mailto:SSG at mailman.ccsds.org><mailto:SSG at mailman
>>>> .ccsds.org> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg
>>>>
>>>>
>>>> [Screen Shot 2015-07-30 at 10.49.17 AM.png]