[CESG] SCID assignments for spacecraft using multiple frequencies

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Tue Aug 4 10:44:12 UTC 2015

Dear All,
        looking through the barrage of emails on this subject is not easy 
at all and somehow the conclusions (if any) and/or the proposal should be 
summarized somehow for a "live" discussion (i.e not via e-mail).

I'd like to intervene shortly on the multiple frequencies topic.

Eric says: "if we have a different spacecraft number because of a 
different frequency band for the same spacecraft that this opens the door 
for confusion for the receiving ground systems."
I would not care too much about the receiving ground systems. They can be 
easily be configured and TM frames retrieved with different SCIDs can 
easily be converted into a unique processing system at a given Control 
Center. IMO The real issue is likely to be onboard where the onboard 
computer may generate frames without knowing on which band those frames 
will eventually be transmitted.

Peter says: "assignment of the same number in different frequency bands 
should be the default, but as time goes on that may also become 
Why? It would only be problematic if we allow that a given SCID may be 
assigned to different missions using disjoint bands. In general assigning 
a single mission to a mission should always be better that assign two 
values. Why granting a Pay 1 Buy Two offer?

Peter says also: "as it has for assigning the same SCIDs for different 
space link versions" and I fully agree that this cannot be guaranteed.

Finally, indeed  "We may have to allow, at some point, that ?X-Band TC 
SCID = x37 but Ka-Band TM SCID = x228. " but not to impose (unless 
unavoidable, and if this happens we are in deep... mud).


Gian Paolo

From:   "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:     "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>, Soula 
Jean-Marc <Jean-Marc.Soula at cnes.fr>, Marc Blanchet 
<info at sanaregistry.org>, 
Cc:     "SANA Steering Group \(SSG\)" <ssg at mailman.ccsds.org>, 
"osvaldo.peinado at dlr.de" <osvaldo.peinado at dlr.de>, CCSDS Engineering 
Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Date:   01/08/2015 02:42
Subject:        [CESG] Re: [SSG] [SANA #5270] AW: SCID assignments
Sent by:        cesg-bounces at mailman.ccsds.org

Dear Eric,

Actually, if you look through the barrage of emails on this subject you
will find that the occurance of multiple frequencies for one spacecraft
was discussed.  I think we all recognize that this may be the case and
that it needs to be accommodated.

I also agree that the assignment of the same number in different frequency
bands should be the default, but as time goes on that may also become
problematic, as it has for assigning the same SCIDs for different space
link versions.  Sometimes the assigners (the SANA Operator) have a real
problem looking for open slots where they can meet this ?default? without
collisions with other assignments.  With some added breathing room with
will be less of an issue than it is now, but yes, it will be an issue.

I get your ?attributes? issue, but one could say that frequency, and space
link version, and even coding and modulation are all just ?attributes? of
the comm services.  Isn?t a CDMA scheme just using the ?code division?
attribute to disciminate among entities sharing the same channel?
Likewise MSPA for that matter.

So I agree that we are going to need to be careful, but it is rocket
science so care is to be expected.  ;-}   We may have to allow, at some
point, that ?X-Band TC SCID = x37 but Ka-Band TM SCID = x228.  It?s still
unambiguous, just a little more finnicky.

And if we had as much namespace as cell phone providers we would not have
this problem.  It would be great to have 10 digits of number space, PLUS a
country code.  We will have the OIDs, but I doubt anyone wants to start
using those over the space link.

Regards, Peter

On 7/31/15, 12:32 PM, "Barkley, Erik J (3970)"
<erik.j.barkley at jpl.nasa.gov> wrote:

>Bon après-midi Peter, Jean-Marc, et al,
>A devil's advocate note:  in this frequency band binning scheme there
>appears to be an assumption that spacecraft only fly with a single
>frequency band.  There are missions that fly multi-band downlinks (e.g, X
>and Ka for Cassini, Mars Reconnaissance Orbiter).  Presumably in this
>scheme care will have to be taken to ensure that the same number is used
>in the different frequency bands.  This may take away some of the
>"breathing room".  It seems to me that if we have a different spacecraft
>number because of a different frequency band for the same spacecraft that
>this opens the door for confusion for the receiving ground systems.  I
>understand the problem we are trying to solve but at the same time my
>experience tells me that when you overload attribute information for
>purposes it was not originally intended (here we are in affect
>overloading frequency band which is really an attribute of communications
>services for identification purposes) you are opening the door for
>software bugs.  In general, the scheme seems a bit like saying my
>worldwide globally unique cell phone number must be further qualified by
>the modulation scheme being used by my cell phone service provider.
>And a question: Will the frequency-band based identification scheme also
>apply to space-to-space proximity links?
>-----Original Message-----
>From: cesg-bounces at mailman.ccsds.org
>[mailto:cesg-bounces at mailman.ccsds.org] On Behalf Of Shames, Peter M
>Sent: Friday, July 31, 2015 11:06 AM
>To: Soula Jean-Marc <Jean-Marc.Soula at cnes.fr>; Marc Blanchet
><info at sanaregistry.org>
>Cc: CCSDS Engineering Steering Group - CESG Exec
><cesg at mailman.ccsds.org>; SANA Steering Group (SSG)
><ssg at mailman.ccsds.org>; osvaldo.peinado at dlr.de
>Subject: [CESG] Re: [SSG] [SANA #5270] AW: SCID assignments
>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?
>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
>>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
>>-----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
>>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 
>>> 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
>>> 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 sana
>>> r 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.S
>>> o 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><mail
>>> t 
>>> o:peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov><ma
>>> i 
>>> lto:peter.m.shames at jpl.nasa.gov%3e%3cmailto:peter.m.shames at jpl.nasa.g
>>> o
>>> v%3e>>,
>>>"osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.
>>>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 = 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-M
>>> a 
>>> rc.Soula at cnes.fr><mailto:Jean-Marc.Soula at cnes.fr<mailto:Jean-Marc.Sou
>>> l 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><m
>>> a 
>>> 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 mailm
>>> a 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 d
>>> l 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.
>>>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 d
>>> l 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 mailma
>>> n .ccsds.org> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg
>>> [Screen Shot 2015-07-30 at 10.49.17 AM.png]
>CESG mailing list
>CESG at mailman.ccsds.org

CESG mailing list
CESG at mailman.ccsds.org

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

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

More information about the CESG mailing list