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

[Marc Blanchet]

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.pei
>>> 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.pei
>>> 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]