<font size=2 face="sans-serif">Dear All,</font>
<br><font size=2 face="sans-serif"> 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).</font>
<br>
<br><font size=2 face="sans-serif">I'd like to intervene shortly on the
multiple frequencies topic.</font>
<br>
<br><font size=2 face="sans-serif">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."</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Peter says: "</font><tt><font size=2>assignment
of the same number in different frequency bands should be the default,
but as time goes on that may also become problematic</font></tt><font size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif">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?</font>
<br>
<br><font size=2 face="sans-serif">Peter says also: "</font><tt><font size=2>as
it has for assigning the same SCIDs for different space link versions</font></tt><font size=2 face="sans-serif">"
and I fully agree that this cannot be guaranteed.</font>
<br>
<br><font size=2 face="sans-serif">Finally, indeed "</font><tt><font size=2>We
may have to allow, at some point, that “X-Band TC SCID = x37 but Ka-Band
TM SCID = x228. </font></tt><font size=2 face="sans-serif">" but not
to impose (unless unavoidable, and if this happens we are in deep... mud).</font>
<br>
<br><font size=2 face="sans-serif">Regards</font>
<br>
<br><font size=2 face="sans-serif">Gian Paolo</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Barkley, Erik
J (3970)" <erik.j.barkley@jpl.nasa.gov>, Soula Jean-Marc <Jean-Marc.Soula@cnes.fr>,
Marc Blanchet <info@sanaregistry.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"SANA Steering
Group \(SSG\)" <ssg@mailman.ccsds.org>, "osvaldo.peinado@dlr.de"
<osvaldo.peinado@dlr.de>, CCSDS Engineering Steering Group - CESG
Exec <cesg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">01/08/2015 02:42</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[CESG] Re: [SSG]
[SANA #5270] AW: SCID assignments</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cesg-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Dear Eric,<br>
<br>
Actually, if you look through the barrage of emails on this subject you<br>
will find that the occurance of multiple frequencies for one spacecraft<br>
was discussed. I think we all recognize that this may be the case
and<br>
that it needs to be accommodated.<br>
<br>
I also agree that the assignment of the same number in different frequency<br>
bands should be the default, but as time goes on that may also become<br>
problematic, as it has for assigning the same SCIDs for different space<br>
link versions. Sometimes the assigners (the SANA Operator) have a
real<br>
problem looking for open slots where they can meet this “default” without<br>
collisions with other assignments. With some added breathing room
with<br>
will be less of an issue than it is now, but yes, it will be an issue.<br>
<br>
I get your “attributes” issue, but one could say that frequency, and
space<br>
link version, and even coding and modulation are all just “attributes”
of<br>
the comm services. Isn’t a CDMA scheme just using the “code division”<br>
attribute to disciminate among entities sharing the same channel?<br>
Likewise MSPA for that matter.<br>
<br>
So I agree that we are going to need to be careful, but it is rocket<br>
science so care is to be expected. ;-} We may have to allow,
at some<br>
point, that “X-Band TC SCID = x37 but Ka-Band TM SCID = x228. It’s
still<br>
unambiguous, just a little more finnicky.<br>
<br>
And if we had as much namespace as cell phone providers we would not have<br>
this problem. It would be great to have 10 digits of number space,
PLUS a<br>
country code. We will have the OIDs, but I doubt anyone wants to
start<br>
using those over the space link.<br>
<br>
Regards, Peter<br>
<br>
<br>
On 7/31/15, 12:32 PM, "Barkley, Erik J (3970)"<br>
<erik.j.barkley@jpl.nasa.gov> wrote:<br>
<br>
>Bon après-midi Peter, Jean-Marc, et al,<br>
><br>
>A devil's advocate note: in this frequency band binning scheme
there<br>
>appears to be an assumption that spacecraft only fly with a single<br>
>frequency band. There are missions that fly multi-band downlinks
(e.g, X<br>
>and Ka for Cassini, Mars Reconnaissance Orbiter). Presumably
in this<br>
>scheme care will have to be taken to ensure that the same number is
used<br>
>in the different frequency bands. This may take away some of
the<br>
>"breathing room". It seems to me that if we have a
different spacecraft<br>
>number because of a different frequency band for the same spacecraft
that<br>
>this opens the door for confusion for the receiving ground systems.
I<br>
>understand the problem we are trying to solve but at the same time
my<br>
>experience tells me that when you overload attribute information for<br>
>purposes it was not originally intended (here we are in affect<br>
>overloading frequency band which is really an attribute of communications<br>
>services for identification purposes) you are opening the door for<br>
>software bugs. In general, the scheme seems a bit like saying
my<br>
>worldwide globally unique cell phone number must be further qualified
by<br>
>the modulation scheme being used by my cell phone service provider.<br>
><br>
>And a question: Will the frequency-band based identification scheme
also<br>
>apply to space-to-space proximity links?<br>
><br>
>-Erik<br>
><br>
>-----Original Message-----<br>
>From: cesg-bounces@mailman.ccsds.org<br>
>[</font></tt><a href="mailto:cesg-bounces@mailman.ccsds.org"><tt><font size=2>mailto:cesg-bounces@mailman.ccsds.org</font></tt></a><tt><font size=2>]
On Behalf Of Shames, Peter M<br>
>(312B)<br>
>Sent: Friday, July 31, 2015 11:06 AM<br>
>To: Soula Jean-Marc <Jean-Marc.Soula@cnes.fr>; Marc Blanchet<br>
><info@sanaregistry.org><br>
>Cc: CCSDS Engineering Steering Group - CESG Exec<br>
><cesg@mailman.ccsds.org>; SANA Steering Group (SSG)<br>
><ssg@mailman.ccsds.org>; osvaldo.peinado@dlr.de<br>
>Subject: [CESG] Re: [SSG] [SANA #5270] AW: SCID assignments<br>
><br>
>Bonsoir Jean-Marc,<br>
><br>
>I hope you have a relaxing weekend. I am glad to hear that you
like the<br>
>OID idea, it gives us the best way to provide unqiue, persistent, IDs
for<br>
>all spacecraft and simulators. We have right now concieved this
as a<br>
>flat namespace, but it could also adopt the approach of a master OID
for<br>
>a spacecraft and sub-names for the real bird, simulators, etc. That
is a<br>
>separate subject, but I did want to point it out as a possibility.<br>
><br>
>I defer to Marc as to what is the best approach for keeping the names
in<br>
>the database normalized, but do recognize, as Jean-Marc pointed out,
that<br>
>several names in the database now have ³-sim² or ³-simulator² qualifiers<br>
>appended. From a quick review it looks like this may be true
for roughly<br>
>5% of the entries. We will get some leverage from moving these
to a<br>
>³Frequency = None² table, but not as much as we might. Whether
we<br>
>continue this naming pattern in the future is open to discussion, but
I<br>
>do understand Marc¹s concern.<br>
><br>
>Based on this I think that we can adopt Jean-Marc¹s phased approach
of<br>
>first splitting off the ³Frequency = None² table and then sorting the<br>
>rest into frequency bins. However, since this is essentially a table<br>
>attribute that allows sorting I suspect that when we create the<br>
>³Frequency = None² attribute in the table we will have also created
the<br>
>fields for the other ³bins² as well.<br>
><br>
>Please Marc, confirm if this is correct?<br>
><br>
>Once this is done we will need to assign the right frequency bin<br>
>attributes to those S/C where it is obvious, and to then do the sleuth<br>
>work to determine the correct bins for those where it is ambiguous.
That<br>
>will take more time, but it is something like a 5-10% effect. We
will<br>
>already have achieved 90% of the separation and I believe that, in<br>
>itself, will give us a lot of breathing room.<br>
><br>
>Does this sound like it is overall a workable approach?<br>
><br>
>Best regards, Peter<br>
><br>
><br>
>On 7/31/15, 7:56 AM, "Soula Jean-Marc" <Jean-Marc.Soula@cnes.fr>
wrote:<br>
><br>
>>Sorry for the confusion : I do not recommend to modify names, I
just<br>
>>say there are names today that reflect the test/simulator nature
of the<br>
>>asset.<br>
>><br>
>>Jean-Marc Soula<br>
>>CNES - DCT/OP/C-STA<br>
>>Advisor, GN Operations<br>
>>18 Avenue Edouard Belin<br>
>>31401 Toulouse Cedex 9 - France<br>
>>Tel.: +33 (0)5 61 2 74647<br>
>>Fax.: +33 (0)5 61 2 73135<br>
>>Email: Jean-Marc.Soula@cnes.fr<br>
>><br>
>>-----Message d'origine-----<br>
>>De : Marc Blanchet [</font></tt><a href=mailto:info@sanaregistry.org><tt><font size=2>mailto:info@sanaregistry.org</font></tt></a><tt><font size=2>]
Envoyé : vendredi 31<br>
>>juillet 2015 16:53 À : Soula Jean-Marc Cc : Shames, Peter M (312B);<br>
>>osvaldo.peinado@dlr.de; SANA Steering Group (SSG); CCSDS Engineering<br>
>>Steering Group - CESG Exec Objet : Re: [SSG] [SANA #5270] AW: SCID<br>
>>assignments<br>
>><br>
>><br>
>><br>
>>On 31 Jul 2015, at 10:38, Soula Jean-Marc wrote:<br>
>><br>
>>> Bonjour<br>
>>><br>
>>> I think all of this is good discussion and I also believe
the<br>
>>> frequency band is a sufficient discriminator to avoid interactions<br>
>>> between in flight assets.<br>
>>><br>
>>> On the other hand, the OID seems to be an excellent idea but
"as it<br>
>>> doesn't fly", the communicating systems cannot discriminate
based on<br>
>>> OID's between signals and data coming from two sources with
same SCId<br>
>>> and frequency.<br>
>>><br>
>>> Just a question on the simulators / testers: how many of them
do we<br>
>>> have today in the SCId data base ?<br>
>>><br>
>>> On this, there is also a question in the request form to indicate
if<br>
>>> the SCId is used only on ground for simulation. If the answers
are<br>
>>> kept in the data base, it could be one way to count.<br>
>>> Otherwise, the names of the assets having the words "simulator"
or<br>
>>> the string of characters "sim" may be counted.<br>
>><br>
>>I would really like to _not_ overload the name of the spacecraft
with<br>
>>an attribute such as simulator. It just makes normalization wrong.<br>
>>Instead, if we go that route, it would be an additional attribute
of<br>
>>the spacecraft transmission that says: no radiation, but not in
the name.<br>
>><br>
>>Marc.<br>
>><br>
>>> To improve reliability of this process in this case, requestors<br>
>>> (owners) of such Ids could be asked to confirm if it is used
only on<br>
>>> ground with no radiation...<br>
>>><br>
>>> If we agree to go with the frequency discrimination, it could
be in<br>
>>> two steps, like:<br>
>>><br>
>>> 1) All SCID's already allocated to simulators
/ testers may be<br>
>>> reallocated "from now" to real Spacecraft ; all
new requests for<br>
>>> simulators / testers may be allocated the value of an in-flight<br>
>>> system ; allocation margins are increased in the short term
(in which<br>
>>> proportion ? = depends on the answer to the above question).<br>
>>><br>
>>> 2) SCIds allocated to real Spacecraft
will be differentiated by<br>
>>> frequency bands.<br>
>>><br>
>>> Step one creates a first step towards discrimination and may
help if<br>
>>> faster to implement: "no radiation" vs "radiation"
are the initial<br>
>>> categories.<br>
>>> Then the Step 2 becomes less urgent and we may take time to
think<br>
>>> about the best approach to discriminate on bands, considering
the<br>
>>> current status of the data base (completeness, reliability...).
Step<br>
>>> 2 is then a refining of the category "radiation"
of Step 1.<br>
>>><br>
>>> Just for you to occupy your American afternoon... leaving
now for the<br>
>>> week end.<br>
>>><br>
>>> Best regards<br>
>>><br>
>>> Jean-Marc Soula<br>
>>> CNES - DCT/OP/C-STA<br>
>>> Advisor, GN Operations<br>
>>> 18 Avenue Edouard Belin<br>
>>> 31401 Toulouse Cedex 9 - France<br>
>>> Tel.: +33 (0)5 61 2 74647<br>
>>> Fax.: +33 (0)5 61 2 73135<br>
>>> Email: Jean-Marc.Soula@cnes.fr<br>
>>> De : Shames, Peter M (312B) [</font></tt><a href=mailto:peter.m.shames@jpl.nasa.gov><tt><font size=2>mailto:peter.m.shames@jpl.nasa.gov</font></tt></a><tt><font size=2>]<br>
>>> Envoyé : jeudi 30 juillet 2015 20:57<br>
>>> À : Marc Blanchet<br>
>>> Cc : Soula Jean-Marc; osvaldo.peinado@dlr.de; SANA Steering
Group<br>
>>> (SSG); CCSDS Engineering Steering Group - CESG Exec Objet
: Re: [SSG]<br>
>>> [SANA #5270] AW: SCID assignments<br>
>>><br>
>>> Thanks Marc.<br>
>>><br>
>>> Just for chuckles I took what you sent, shoved them into a<br>
>>> spreadsheet<br>
>>> (attached) and applied the following heuristics:<br>
>>><br>
>>> 1. For each stated "frequency" input assign
it to the corresponding<br>
>>> band 2. If there is more than one band sort them within
the "Band"<br>
>>> bin in order of lowest to highest frequency 3. Assign
a sequence<br>
>>> number for tracking 4. Sort by Band and then sequence
number The<br>
>>> resulting spreadsheet is attached. The total unique
bands that are<br>
>>> used are: VHF (1), L(1), S (14), C (3), X (11), Ku (6), K
(1), Ka<br>
>>> (4), None (2), not stated (3)<br>
>>><br>
>>> Purely based on pragmatic considerations I would suggest that
we<br>
>>> could create "Band Bins" that looked like this:<br>
>>><br>
>>> * Everything below S-Band (HF, VHF, UHF, L)<br>
>>> * S-Band & C-Band<br>
>>> * X-Band<br>
>>> * K-Band (Ku, K, Ka)<br>
>>> * None or unstated<br>
>>> That gives us four bins (plus "None) to sort all of these
spacecraft<br>
>>> into, which, with only a few exceptions, is pretty straightforward.<br>
>>> It does, of course, also give us SCID "growth" room
of 2-3 X number<br>
>>> of unique SCIDs because S, X, and the "K"s contain
the bulk of the<br>
>>> assigned SCIDs, at least in this sample. I am guessing
that this<br>
>>> sample is sufficiently representative, and that future trends
are<br>
>>> going to be toward X and the K's, thus spreading the users
out even<br>
>>> more into these other bins. The "Below S"
bin may get use if we<br>
>>> start to register CubeSats too.<br>
>>><br>
>>> The other issue, of course, is how to track a single S/C that
has<br>
>>> multiple frequencies, but I think the unique OID is the way
to do<br>
>>> that.<br>
>>><br>
>>> Does this seem like it could be made workable?<br>
>>><br>
>>> Regards, Peter<br>
>>><br>
>>><br>
>>> On 7/30/15, 11:11 AM, "Marc Blanchet"<br>
>>> <info@sanaregistry.org<</font></tt><a href=mailto:info@sanaregistry.org><tt><font size=2>mailto:info@sanaregistry.org</font></tt></a><tt><font size=2>>>
wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On 30 Jul 2015, at 13:50, Shames, Peter M (312B) wrote:<br>
>>><br>
>>> Thanks for the clarifications Marc. That helps a lot.<br>
>>><br>
>>> One question for you is whether what we have in the "TM
& TC<br>
>>> frequencies" slots are actually frequencies, as in 2380
Ghz, or if<br>
>>> they are frequency bands, as in "S Band". I
think that we may get<br>
>>> enough relief from just using the frequency bands (see attached<br>
>>> table) that this in itself may be adequate, but I do recognize
that<br>
>>> there may be issues even at that level.<br>
>>><br>
>>> It is a mix of everything. Given exactly that, we tried to
normalize<br>
>>> the data but were not able given the too large variety and
that the<br>
>>> previous operator did not enforce any normalization while
entering<br>
>>> the data in the registry (no criticism, just a fact). Therefore,
we<br>
>>> did not try to enforce any normalization yet on new data,
so these<br>
>>> are currently just « strings ». (similarly, when we
took over the RF<br>
>>> asset registry from IOAC, we tried to normalize the data as
much as<br>
>>> possible, but given that it was often entered like strings
with no<br>
>>> format requirements, then it is just a can of worms for data<br>
>>> normalization).<br>
>>><br>
>>> Here is just a few samples from a quick visual scan of the
registry.<br>
>>> Far<br>
>>> from comprehensive, but just to give you a sense of the current<br>
>>> values (yes, values in the frequency column), without the
spacecraft<br>
>>> identification. please don't concentrate on the actual values
but<br>
>>> more on the diversity of data we have.<br>
>>><br>
>>> 2048.85 MHz (E-S)<br>
>>> TC<br>
>>> 1S-Band (Housekeeping), 1X-Band (IDHT Low Rate), 1X-Band (IDHT
High<br>
>>> Rate)<br>
>>> S-Band<br>
>>> 2203 MHz, 2206.5 MHz, 2218 MHz, 2227 MHz, 2254.5 MHz, 2265.5
MHz,<br>
>>> 2284 MHz Ku-Band TBD<br>
>>> 7.1808063 GHz (6 MHz BW)<br>
>>> X-Band 7156.53 MHz<br>
>>> X-Band 7166 MHz (CMD 10-2000 b/s and RNG), Ka-Band 34.45 GHz
(No CMD<br>
>>> or<br>
>>> RNG)<br>
>>> 8190.0 MHz (primary) and 2252.5 MHz (demonstration purposes
only)<br>
>>> 8429.938271 MHz, 8427.222 MHz (noncoherent)<br>
>>> 3947-52 MHz (C-Band)<br>
>>> Category B (Deep Space) D/L X-Band U/L X-Band X-Band,
Ka-Band<br>
>>> (Category B (Deep Space)<br>
>>> 2044.25 MHz (center Frequency for TC)<br>
>>> 2225 MHz (S-E), 2048.85 MHz (E-S)<br>
>>> Frequency pair unknown at this time<br>
>>> Around 14 GHz<br>
>>> S-Band 2215 MHz, S-Band 2039 MHz, X-Band 8.025-8.040 GHz Ku-Band<br>
>>> (14005.0 MHz (V); 14499 MHz(H)); SHF-Band 8397.5 (RHCP) NA
- ground<br>
>>> use only Around 2000 C-band to be determined from 5000 - 5010MHz
and<br>
>>> Ku-band to be determined from 13750 - 14500MHz<br>
>>> Fdownlink=[2225.025+-n*3.069]MHz,<br>
>>> n=0,1,2,3,4;Fdownlink=(240/221)*Fuplink<br>
>>> N/A<br>
>>> Ground Use Only (Satellite 5850 MHz - 6426 MHz) Around 14
GHz<br>
>>> 29.1 GHz-29.3 GHz, 19400 MHz-19600 MHz X-Band 8420 MHz (TLM,
RS 10-18<br>
>>> Kb/s Turbo), Ka-Band 32.02 GHz (Carrier Only - Radio
Science) Around<br>
>>> 8400 Mhz and 32000 MHz<br>
>>> 2210.0 MHz TBD<br>
>>> 2025-2110 MHz. Center frequency has not been determined HRIT
2040.9<br>
>>> MHz, LRIT 2037.64 MHz 145.870, 145.930, 2405.00 MHz; 145.870
-<br>
>>> 145.920 MHz (Transponder)<br>
>>><br>
>>> I stopped way before reaching the end of the registry...<br>
>>><br>
>>><br>
>>> As you pointed out:<br>
>>><br>
>>> that the reliability of that data is unknown for various reasons,<br>
>>> such<br>
>>> as: data was not entered properly by the operator, data was
not<br>
>>> provided by the requestor, frequencies were changed from the
time of<br>
>>> the registration request to the time of the launch and the
requestor<br>
>>> never sent the information back to the registry operator<br>
>>><br>
>>> Do you have any faith that if we were to attempt to apply
the<br>
>>> "separation by frequency bands" approach that we
would have success<br>
>>> at the 95% plus level, or would we be more at the 75% or 50%
level?<br>
>>><br>
>>> can't tell. I just want to point out that while, on paper,
the<br>
>>> frequency separation might be a good idea, in practice, the
registry<br>
>>> info we have does not provide that reliable data.<br>
>>><br>
>>><br>
>>> As for "clear procedures", yes, we do understand
absolutely the need<br>
>>> for this, for you as SANA Operaotr and for the user / requestor<br>
>>> community.<br>
>>><br>
>>> yeah, just to point out our expectation of the outcome of
this<br>
>>> discussion, from the operator point of view.<br>
>>><br>
>>> Regards, Marc.<br>
>>><br>
>>><br>
>>> Thanks, Peter<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On 7/30/15, 8:54 AM, "Marc Blanchet"<br>
>>> <info@sanaregistry.org<</font></tt><a href=mailto:info@sanaregistry.org><tt><font size=2>mailto:info@sanaregistry.org</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:info@sana><tt><font size=2>mailto:info@sana</font></tt></a><tt><font size=2><br>
>>> r egistry.org><</font></tt><a href=mailto:info@sanaregistry.org%3e><tt><font size=2>mailto:info@sanaregistry.org%3e</font></tt></a><tt><font size=2>>><br>
>>> wrote:<br>
>>><br>
>>> - clarifications below enclosed in <SANA> </SANA>.<br>
>>><br>
>>> Marc.<br>
>>><br>
>>> On 29 Jul 2015, at 17:22, Shames, Peter M (312B) wrote:<br>
>>><br>
>>><br>
>>> Dear Jean-Marc,<br>
>>><br>
>>> I agree completely that this is not a settled issue by any
means, and<br>
>>> I am glad that you and Osvaldo are engaged more actively in
the<br>
>>> discussion. As I noted, this has been discussed for
some time, but<br>
>>> this is the first effort to try and come to terms with it
and to<br>
>>> actually identify a workable solution. I believe that
open dialogue<br>
>>> is essential, since this ultimately affects all agencies (and
other<br>
>>> organizations) who use CCSDS standards.<br>
>>><br>
>>> Once we identify an agreed path forward we must then, as quickly
as<br>
>>> we can, get all of the involved elements (registries, documents,<br>
>>> procedures), revised so that everyone knows what to expect.
In the<br>
>>> meantime I think we are in a transitional state where we really
must<br>
>>> retain as much of the limited "SCID namespace" as
we can in order to<br>
>>> not find ourselves at an abruopt halt when we run out of available<br>
>>> numbers.<br>
>>><br>
>>> Other comments are in-line, below.<br>
>>><br>
>>> Very best regards, Peter<br>
>>><br>
>>><br>
>>> From: Jean-Marc Soula<br>
>>> <Jean-Marc.Soula@cnes.fr<</font></tt><a href="mailto:Jean-Marc.Soula@cnes.fr"><tt><font size=2>mailto:Jean-Marc.Soula@cnes.fr</font></tt></a><tt><font size=2>><</font></tt><a href="mailto:Jean-"><tt><font size=2>mailto:Jean-</font></tt></a><tt><font size=2><br>
>>> M <br>
>>> arc.Soula@cnes.fr><</font></tt><a href="mailto:Jean-Marc.Soula@cnes.fr"><tt><font size=2>mailto:Jean-Marc.Soula@cnes.fr</font></tt></a><tt><font size=2>><</font></tt><a href="mailto:Jean-Marc.S"><tt><font size=2>mailto:Jean-Marc.S</font></tt></a><tt><font size=2><br>
>>> o ula@cnes.fr%3e%3cmailto:Jean-Marc.Soula@cnes.fr%3e>><br>
>>> Date: Wednesday, July 29, 2015 at 10:49 AM<br>
>>> To: Peter Shames<br>
>>> <peter.m.shames@jpl.nasa.gov<</font></tt><a href=mailto:peter.m.shames@jpl.nasa.gov><tt><font size=2>mailto:peter.m.shames@jpl.nasa.gov</font></tt></a><tt><font size=2>><mail<br>
>>> t <br>
>>> o:peter.m.shames@jpl.nasa.gov><</font></tt><a href=mailto:peter.m.shames@jpl.nasa.gov><tt><font size=2>mailto:peter.m.shames@jpl.nasa.gov</font></tt></a><tt><font size=2>><ma<br>
>>> i <br>
>>> lto:peter.m.shames@jpl.nasa.gov%3e%3cmailto:peter.m.shames@jpl.nasa.g<br>
>>> o<br>
>>> v%3e>>,<br>
>>> <br>
>>>"osvaldo.peinado@dlr.de<</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo><tt><font size=2>mailto:osvaldo</font></tt></a><tt><font size=2>.<br>
>>>pei <br>
>>>nado@dlr.de><</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo.peinado@dlr><tt><font size=2>mailto:osvaldo.peinado@dlr</font></tt></a><tt><font size=2><br>
>>>.de %3e%3cmailto:osvaldo.peinado@dlr.de%3e>"<br>
>>> <osvaldo.peinado@dlr.de<</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo><tt><font size=2>mailto:osvaldo</font></tt></a><tt><font size=2>.<br>
>>> <br>
>>>peinado@dlr.de><</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo.peinado@><tt><font size=2>mailto:osvaldo.peinado@</font></tt></a><tt><font size=2><br>
>>> dlr.de%3e%3cmailto:osvaldo.peinado@dlr.de%3e>><br>
>>> Cc: CCSDS Engineering Steering Group - CESG Exec<br>
>>><cesg@mailman.ccsds.org<</font></tt><a href=mailto:cesg@mailman.ccsds.org><tt><font size=2>mailto:cesg@mailman.ccsds.org</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:cesg@mai><tt><font size=2>mailto:cesg@mai</font></tt></a><tt><font size=2><br>
>>> <br>
>>>lman.ccsds.org><</font></tt><a href=mailto:cesg@mailman.ccsds.org><tt><font size=2>mailto:cesg@mailman.ccsds.org</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:cesg@mailman.ccs><tt><font size=2>mailto:cesg@mailman.ccs</font></tt></a><tt><font size=2><br>
>>> ds.org%3e%3cmailto:cesg@mailman.ccsds.org%3e>>,<br>
>>> "SANA<br>
>>> Steering Group (SSG)"<br>
>>> <br>
>>><ssg@mailman.ccsds.org<</font></tt><a href=mailto:ssg@mailman.ccsds.org><tt><font size=2>mailto:ssg@mailman.ccsds.org</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:ssg@mailma><tt><font size=2>mailto:ssg@mailma</font></tt></a><tt><font size=2><br>
>>> <br>
>>>n.ccsds.org><</font></tt><a href=mailto:ssg@mailman.ccsds.org><tt><font size=2>mailto:ssg@mailman.ccsds.org</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:ssg@mailman.ccsds.or><tt><font size=2>mailto:ssg@mailman.ccsds.or</font></tt></a><tt><font size=2><br>
>>> g%3e%3cmailto:ssg@mailman.ccsds.org%3e>><br>
>>> Subject: RE: AW: [SANA #5270] AW: SCID assignments<br>
>>><br>
>>> Bonjour à tous,<br>
>>><br>
>>> I share the Oswaldo's concern on which explanations or which<br>
>>> solutions may be offered by CCSDS to the projects requesting
multiple<br>
>>> SCId and being rejected for those assets pertaining to the
simulator<br>
>>> / tester ... category.<br>
>>> I understand the rules have changed (and I do not object the<br>
>>> arguments for that) but the procedures were not yet revised
(the<br>
>>> abstracted blue text below clearly shows that simulators /
testers<br>
>>> were valid assets to obtain a SCId) ... nor alternate solutions
are<br>
>>> offered (which we should discuss further now).<br>
>>><br>
>>><br>
>>> You are correct in that the current, published, SCID document
does<br>
>>> not discriminate against simulators nor testers. And
yet we have<br>
>>> this problem that we must resolve in some way that does not
halt the<br>
>>> ability of new spacecraft to be flown, by as many different
users as<br>
>>> can be accommodated. In the immediate term the only
way that I can<br>
>>> see to handle this is to only give out new (or re-cycled)
SCIDs to<br>
>>> the real spacecraft. Your support for a set of registries
sorted by<br>
>>> frequency, and inclusion of a "Frequency = none"
category may be a<br>
>>> rapid way forward.<br>
>>><br>
>>> I think we can, through discussion, arrive at an agreed<br>
>>> recommendation to agencies re how to deal with the similator
/ tester<br>
>>> issue. I hope that this is the start of an active discussion
where<br>
>>> we try and arrive at that agreement, because so far the discussion<br>
>>> jhas ben of the nature "We have a problem ..... What
do we do?"<br>
>>><br>
>>> In CNES we also have several projects for which simulators
have been<br>
>>> assigned a SCId, different from the one assigned to the SC.<br>
>>> Some more may come soon with similar requirements...<br>
>>><br>
>>><br>
>>> I hope that is sufficient motivation to have you and your
staff,<br>
>>> among others from different agencies, get engaged in the discussion.<br>
>>><br>
>>> CCSDS should offer a workaround way to answer these requests
and not<br>
>>> just reject the request because of the lack of Ids.<br>
>>><br>
>>> I agree we need a work-around. And I think we need to
find one<br>
>>> quickly and document it.<br>
>>><br>
>>> Meanwhile, if we do not modulate requests for multiple SCIDs
what is<br>
>>> to stop anyone from requesting several SCIDs for one spacecraft
and<br>
>>> using up what little resource we have left?<br>
>>><br>
>>> Out of your list of activities below, Peter, I see Number
3 as quite<br>
>>> promising in terms of solving our SCId capacity issue, but
I am not<br>
>>> 100% sure if Number 4 could be another solution or not.<br>
>>><br>
>>> In more details:<br>
>>><br>
>>> Number 3: if SANA may allocate the same SCId to several missions,<br>
>>> based on the frequency discrimination, the issue of
the testers /<br>
>>> simulators may be solved as they fall in the category "no
radiation"<br>
>>> (meaning "no frequency"). Frequencies are already
part of the SCId<br>
>>> request form and the information is already available for
a majority<br>
>>> of missions (I hope).<br>
>>><br>
>>> You are correct, but we seem to have a bit of an issue. While
the<br>
>>> transmitting frequencies (TM & TC) are on the form<br>
>>> (</font></tt><a href=http://sanaregistry.org/cgi/spacecraftid><tt><font size=2>http://sanaregistry.org/cgi/spacecraftid</font></tt></a><tt><font size=2>)
they do not appear in the<br>
>>> available database in SANA<br>
>>> (</font></tt><a href=http://sanaregistry.org/r/spacecraftid/spacecraftid.html><tt><font size=2>http://sanaregistry.org/r/spacecraftid/spacecraftid.html</font></tt></a><tt><font size=2>).
We will<br>
>>> have to check with the SANA operator to see if this information
is,<br>
>>> in fact, in the database but is just hidden in what is displayed.<br>
>>><br>
>>> <SANA>Currently, as discussed a while ago when we took
over the<br>
>>> spacecraftid registry, frequencies are kept internally in
the<br>
>>> database but are not exposed.<br>
>>><br>
>>> However, one has to understand that, as we did a giant cleanup
of the<br>
>>> registry, it is clear that the reliability of that data is
unknown<br>
>>> for various reasons, such as: data was not entered properly
by the<br>
>>> operator, data was not provided by the requestor, frequencies
were<br>
>>> changed from the time of the registration request to the time
of the<br>
>>> launch and the requestor never sent the information back to
the<br>
>>> registry operator, etc... Therefore, as we have seen
for some IDs<br>
>>> that were allocated simultaneously to multiple missions, it
took a<br>
>>> long time to get the space agencies involved to find the real<br>
>>> frequencies used for those missions. Therefore, the use of
the<br>
>>> frequency data for concurrent use of spacecraft ids are a
challenge.<br>
>>> Moreover, we also heard that spacecraftids are also used within<br>
>>> information systems to uniquely identify the spacecraft, and
that id<br>
>>> does not include the frequencies.<br>
>>> Therefore, the collision may also happen in information systems.<br>
>>><br>
>>> One also has to remember that we have been accepting requests
and<br>
>>> provided assignments of spacecraft ids that were requested
to be<br>
>>> hidden publicly (for various reasons such as military). Therefore,<br>
>>> the public version of the registry is not a full view of the
database.<br>
>>> </SANA><br>
>>><br>
>>> We will also have to accommodate spacecraft that use more
than one<br>
>>> frequency, as in S / X or X / Ka. I do not know that
the database in<br>
>>> its current form accommpodates that.<br>
>>><br>
>>> <SANA>we can certainly make it happen</SANA><br>
>>><br>
>>><br>
>>> As you suggest, perhaps we can, for a while, adopt that "no
frequency"<br>
>>> approach and still manage the simulator / tester assignments
within<br>
>>> SANA. I think that is an interesting approach to discuss.<br>
>>><br>
>>> Number 4: I saw a lot of emails on registries but could not
spend<br>
>>> enough time with them to be sure of the meaning of "Object
Id (OId)"<br>
>>> and how it may be used in practice to differentiate the assets
of a<br>
>>> same satellite project and the assets of multiple projects
between<br>
>>> them. It could be, assuming some verifications, that
the OID is<br>
>>> another way to allow SANA to allocate several times the same
SCId to<br>
>>> several missions, based on the OID discrimination this time.<br>
>>><br>
>>><br>
>>> The concept of the OID is an ISO construct that the Cross
Support<br>
>>> Services area first started to use. It is a tree structured
name<br>
>>> space where "CCSDS" (ISO OID = 1.3.112.4) forms
the base of the tree<br>
>>> and we then get to determine which classes of objects we will
assign<br>
>>> unique numbers to. A proposal for how to manage that
namespace is in<br>
>>> the draft Registry Policy document and there is an information
model<br>
>>> for it as well. Both are attached here. What has
been proposed is<br>
>>> that there is a branch of the OID tree for spacecraft, and
that every<br>
>>> spacecraft, simulator, or tester would have a unique SCID
assigned.<br>
>>> That Spacecraft OID, as proposed, is just a number, of the
form<br>
>>> 1.3.112.4.7.nnn. This OID is assigned when any registeration
request<br>
>>> is made and it remains associated with that spacecraft forever.
In<br>
>>> that way it can be used to unambiguously tag the spacecraft
data and<br>
>>> allows the SCIDs to just be used on the transmitted spacelink.<br>
>>><br>
>>> The rest of the Spacecraft information will be stored in the<br>
>>> Spacecraft database, as it is now, along with the SCID (during
the<br>
>>> valid period) and the OID (which is permanent). The
model of the<br>
>>> spacecraft database is also attached for reference. Most
of these<br>
>>> fields are in the current database, but any shown in red are
newly<br>
>>> added. It does occur to me now that we will probably
need to add<br>
>>> both transmitting and receiving frequencies, and to add the
ability<br>
>>> to have a spacecraft with multiple frequency bands.<br>
>>><br>
>>> So if we adopt some such approach I agree that we can re-allocate
the<br>
>>> same SCID, using the Version Number (protocol type) and Frequency(s).<br>
>>> On the ground we can use just the OID as a unique identifier
since it<br>
>>> is permanent. But unless there is a way to adopt the
OID on the<br>
>>> spacelink I do not think that gives us any discrimination
in radiated<br>
>>> space communication.<br>
>>><br>
>>> Those two options should be explored quickly, and I believe
this is<br>
>>> the idea in the messages below, to confirm that the activity
Number 2<br>
>>> may be cancelled and there is enough room then to continue
the<br>
>>> allocation to simulators / testers.<br>
>>> Does it make sense ?<br>
>>><br>
>>><br>
>>> Based on this discussion, and if others agree with the use
of<br>
>>> frequency band (including = none) , then I think that we could<br>
>>> continue to use the SANA to regsiter simulators and testers,
as long<br>
>>> as we can use that distinction as well. For that matter,
since these<br>
>>> simulators and testers will each belong to some single organization<br>
>>> that "owns" that asset you could even imagine a
"Frequency = None"<br>
>>> namespace on a per agency / organization basis. There
is no fear<br>
>>> then of collisions in communications and the OID can be used
for<br>
>>> unambiguous identification of datasets. It is a little
more<br>
>>> complicated than what we now do, but it is quite "future
proof"<br>
>>> and avoids any risk of ambiguity.<br>
>>><br>
>>> In any case, one criteria to decide is how long it may take
to put a<br>
>>> solution in place.<br>
>>> If too long, then we have a risk of overflow on the SCIds
in the<br>
>>> meantime ; if doable in a reasonable time span, it would be
a pity to<br>
>>> have rejected some requests for SCIds and have a solution
for them a<br>
>>> few months later...</font></tt>
<br><tt><font size=2>>>><br>
>>> I agree, but contingent on getting rapid agreement on having
a<br>
>>> "Frequency = none" SCID registry immediately set
up, either on a<br>
>>> global basis or on an agency / organization basis. Does
that sound<br>
>>> agreeable to you (and others)?<br>
>>><br>
>>> I think, for practicality, that we also need to reach agreement
on a<br>
>>> set of SCID registries separated by frequency band (including
None)<br>
>>> so that we can immediately re-gain some SCID breathing room/<br>
>>><br>
>>> Does that sound workable as well?<br>
>>><br>
>>> <SANA>From the point of view of SANA, it would be good
for our<br>
>>> operations point of view that we had clear and written and<br>
>>> agreed/approved recommendations on the way forward. Written
so we can<br>
>>> refer the requestors to the document that describes the (new)
policy.<br>
>>> It<br>
>>> does not need to be a full blown book, but some document that
shows<br>
>>> the new policy that we are using as our base assignment<br>
>>> policy.</SANA><br>
>>><br>
>>><br>
>>><br>
>>> So my recommendation would be to work on activities 3 or 4,
with the<br>
>>> objective not to apply number 2.<br>
>>> Of course activities number 1 and 5 should continue, with
less<br>
>>> pressure on number1 if a solution is found ... and no pressure
on<br>
>>> number 5 which anyway is a long term and maybe not a global
solution.<br>
>>><br>
>>> For further discussions I believe...<br>
>>><br>
>>><br>
>>> Yes. Indeed.<br>
>>><br>
>>> Best regards<br>
>>><br>
>>> Jean-Marc Soula<br>
>>> CNES - DCT/OP/C-STA<br>
>>> Advisor, GN Operations<br>
>>> 18 Avenue Edouard Belin<br>
>>> 31401 Toulouse Cedex 9 - France<br>
>>> Tel.: +33 (0)5 61 2 74647<br>
>>> Fax.: +33 (0)5 61 2 73135<br>
>>> Email:<br>
>>> Jean-Marc.Soula@cnes.fr<</font></tt><a href="mailto:Jean-Marc.Soula@cnes.fr"><tt><font size=2>mailto:Jean-Marc.Soula@cnes.fr</font></tt></a><tt><font size=2>><</font></tt><a href="mailto:Jean-M"><tt><font size=2>mailto:Jean-M</font></tt></a><tt><font size=2><br>
>>> a <br>
>>> rc.Soula@cnes.fr><</font></tt><a href="mailto:Jean-Marc.Soula@cnes.fr"><tt><font size=2>mailto:Jean-Marc.Soula@cnes.fr</font></tt></a><tt><font size=2><</font></tt><a href="mailto:Jean-Marc.Sou"><tt><font size=2>mailto:Jean-Marc.Sou</font></tt></a><tt><font size=2><br>
>>> l a@cnes.fr%3e%3cmailto:Jean-Marc.Soula@cnes.fr>><br>
>>><br>
>>> Best regards, Peter<br>
>>><br>
>>><br>
>>> De :<br>
>>> ssg-bounces@mailman.ccsds.org<</font></tt><a href="mailto:ssg-bounces@mailman.ccsds.org"><tt><font size=2>mailto:ssg-bounces@mailman.ccsds.org</font></tt></a><tt><font size=2>><m<br>
>>> a <br>
>>> ilto:ssg-bounces@mailman.ccsds.org><</font></tt><a href="mailto:ssg-bounces@mailman.ccsds"><tt><font size=2>mailto:ssg-bounces@mailman.ccsds</font></tt></a><tt><font size=2>.<br>
>>> o <br>
>>> rg<</font></tt><a href="mailto:ssg-bounces@mailman.ccsds.org%3e%3cmailto:ssg-bounces@mailm"><tt><font size=2>mailto:ssg-bounces@mailman.ccsds.org%3e%3cmailto:ssg-bounces@mailm</font></tt></a><tt><font size=2><br>
>>> a n.ccsds.org>> [</font></tt><a href="mailto:ssg-bounces@mailman.ccsds.org"><tt><font size=2>mailto:ssg-bounces@mailman.ccsds.org</font></tt></a><tt><font size=2>]
De la part de<br>
>>> Shames, Peter M<br>
>>> (312B)<br>
>>> Envoyé : mercredi 29 juillet 2015 18:18 À :<br>
>>> osvaldo.peinado@dlr.de<</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo><tt><font size=2>mailto:osvaldo</font></tt></a><tt><font size=2>.<br>
>>> p <br>
>>> einado@dlr.de><</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2><</font></tt><a href=mailto:osvaldo.peinado@d><tt><font size=2>mailto:osvaldo.peinado@d</font></tt></a><tt><font size=2><br>
>>> l r.de%3e%3cmailto:osvaldo.peinado@dlr.de>><br>
>>> Cc : CCSDS Engineering Steering Group - CESG Exec; SANA Steering<br>
>>> Group<br>
>>> (SSG)<br>
>>> Objet : [SSG] Re: AW: [SANA #5270] AW: SCID assignments Importance
:<br>
>>> Haute<br>
>>><br>
>>> Dear Osvaldo,<br>
>>><br>
>>> As I think you are aware, the CCSDS is in danger of running
out of<br>
>>> available spacecraft ID (SCID) numbers. You could say
that we are<br>
>>> now being hurt by our own success because there are so many<br>
>>> spacecraft using CCSDS data link and related standards that
we no<br>
>>> longer can assign a SCID for the spacecraft, the simulator,
and other<br>
>>> possible "flight-less birds".<br>
>>><br>
>>> In the current SCID document, CCSDS 320.0-B-6C1, we have this<br>
>>> statement (emphasis added):<br>
>>><br>
>>> Section 2.1 Purpose of the CCSDS SCID<br>
>>><br>
>>> Because the SCID field is only eight or ten bits long, the
SCID is<br>
>>> not intended to provide unique identification for all times.<br>
>>> It is inevitable that the SCIDs will have to be reused; however,
at<br>
>>> any one time, the number of vehicles under simulation, test,
or<br>
>>> active operational control is not anticipated to exceed the
available<br>
>>> numbering domains.<br>
>>><br>
>>> Clearly this is no longer the case and the SSG, SLS and CESG
have<br>
>>> been discussing this for at least the last three meetings.
There are<br>
>>> several loosely coordinated activities which are now in process
that<br>
>>> relate to this:<br>
>>><br>
>>> 1) We have requested the Agency Representatives to relinquish
all<br>
>>> assigned SCIDs for spacecraft that are no longer operational.
This<br>
>>> has been somewhat successful, but we need to do it again.<br>
>>> 2) We are in the process of revising the SCID assignment procedures<br>
>>> to no longer allow assignment of multiple SCID for a spacecraft<br>
>>> (simulators, testers, etc)<br>
>>> 3) We are considering the use of frequency separation as well
as the<br>
>>> current Version Number (VN) separation that is now in use.
This<br>
>>> could relatively easily increase the number assignment space.<br>
>>> 4) Under the new registry approach that is now in discussion
we will<br>
>>> be assigning unique, permanent, object identifiers (OID) to
all<br>
>>> spacecraft, similators, flightless birds, etc. These
will persist<br>
>>> through time.<br>
>>> 5) We are working on a new protocol, USLP, with a larger SCID
number<br>
>>> space.<br>
>>><br>
>>> We have not yet discussed in any depth what recommendation
we can<br>
>>> make to organizations who wish to have a separate, unique,
SCID that<br>
>>> they can use internally to distinguish the spacecraft from
any other<br>
>>> simulators or test gigs. Clearly this is a concern,
but it is may be<br>
>>> treated as an internal issue that can be managed locally.
It does<br>
>>> not have the same potential for cross agency impact because
any such<br>
>>> signals will not be broadcast.<br>
>>><br>
>>> If you (or anyone else on this thread) has any other ideas
or wishes<br>
>>> to contribute to the discussion please do so. I think
that this is <br>
>>> an important enough issue for us to work quickly (as quickly
as CCSDS <br>
>>> can<br>
>>> move) to come up with a resolution.<br>
>>><br>
>>> Best regards, Peter<br>
>>><br>
>>><br>
>>> On 7/29/15, 7:43 AM,<br>
>>> <br>
>>>"osvaldo.peinado@dlr.de<</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo><tt><font size=2>mailto:osvaldo</font></tt></a><tt><font size=2>.<br>
>>>pei <br>
>>>nado@dlr.de><</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo.peinado@dlr><tt><font size=2>mailto:osvaldo.peinado@dlr</font></tt></a><tt><font size=2><br>
>>>.de %3e%3cmailto:osvaldo.peinado@dlr.de%3e>"<br>
>>> <osvaldo.peinado@dlr.de<</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo><tt><font size=2>mailto:osvaldo</font></tt></a><tt><font size=2>.<br>
>>> <br>
>>>peinado@dlr.de><</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo.peinado@><tt><font size=2>mailto:osvaldo.peinado@</font></tt></a><tt><font size=2><br>
>>> dlr.de%3e%3cmailto:osvaldo.peinado@dlr.de%3e>><br>
>>> wrote:<br>
>>><br>
>>> Dear Audric,<br>
>>> I know about the problem of SCIDs becoming rare.<br>
>>> You can process the satellite one, and discard the SIM one,
BUT ....I <br>
>>> need to have for the project anyways and official answer from
SANA.<br>
>>> It should be possible to inform the users about the situation
and in <br>
>>> case of rejecting a request indicate a reference to a document
and to <br>
>>> propose a solution, like "use the same ID as the Spacecraft
or <br>
>>> something that you like, because your system is a closed one",
as <br>
>>> example , can you do that?<br>
>>> I have another question:<br>
>>> I need to submit a request for another Satellite and it looks
like <br>
>>> the link to do the request from the SANA page simply disappear,
it is <br>
>>> only an E-mail.<br>
>>> It is that correct?<br>
>>> Thanks and best Regards<br>
>>> O. Peinado<br>
>>><br>
>>><br>
>>><br>
>>> -----Ursprüngliche Nachricht-----<br>
>>> Von: SANA [</font></tt><a href=mailto:info@sanaregistry.org><tt><font size=2>mailto:info@sanaregistry.org</font></tt></a><tt><font size=2>]<br>
>>> Gesendet: Mittwoch, 29. Juli 2015 16:07<br>
>>> An: Peinado, Osvaldo Luis<br>
>>> Betreff: Re: [SANA #5270] AW: SCID assignments<br>
>>><br>
>>> Dear Mr. Peinado,<br>
>>><br>
>>> We were waiting for the SSG answer before getting back to
you and see <br>
>>> if you had any constraint on the two SCIDs being assigned
at the same <br>
>>> time or not.<br>
>>><br>
>>> If you tell us that we can go and process the non-sim request,
we <br>
>>> will happily do that.<br>
>>><br>
>>> Thank you.<br>
>>><br>
>>> --<br>
>>> Best regards,<br>
>>> Audric Schiltknecht<br>
>>> Space Assigned Numbers Authority<br>
>>><br>
>>> Le 2015-07-29 09:47,<br>
>>> osvaldo.peinado@dlr.de<</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:osvaldo><tt><font size=2>mailto:osvaldo</font></tt></a><tt><font size=2>.<br>
>>> p <br>
>>> einado@dlr.de><</font></tt><a href=mailto:osvaldo.peinado@dlr.de><tt><font size=2>mailto:osvaldo.peinado@dlr.de</font></tt></a><tt><font size=2><</font></tt><a href=mailto:osvaldo.peinado@d><tt><font size=2>mailto:osvaldo.peinado@d</font></tt></a><tt><font size=2><br>
>>> l r.de%3e%3cmailto:osvaldo.peinado@dlr.de>><br>
>>> a écrit :<br>
>>> Dear Audrich<br>
>>> Thank you for your answer.<br>
>>> I´m aware about the discussion about the SIM SCID and that
till now <br>
>>> is nothing written down to deal with it, but what happened
with the <br>
>>> SCID for the satellite?<br>
>>> I sent two separate request.<br>
>>> I do not see it also in the list of registry updates, why?<br>
>>> Best Regards<br>
>>> Osvaldo<br>
>>> -----------------------------------<br>
>>> Dr. Osvaldo Peinado<br>
>>> Ground Operations Manager<br>
>>> German Space Operations Center (GSOC)<br>
>>> Tel: +49 8153 28 3010<br>
>>> Fax: +49 8153 28 1456<br>
>>> Mobile: +491729410099<br>
>>> German Aerospace Center (DLR)<br>
>>> Oberpfaffenhofen<br>
>>> 82234 Wessling<br>
>>> Germany<br>
>>> -----Ursprüngliche Nachricht-----<br>
>>> Von: Space Assigned Numbers Authority [</font></tt><a href=mailto:info@sanaregistry.org><tt><font size=2>mailto:info@sanaregistry.org</font></tt></a><tt><font size=2>]<br>
>>> Gesendet: Dienstag, 28. Juli 2015 22:35<br>
>>> An: Peinado, Osvaldo Luis<br>
>>> Cc: Space Assigned Numbers Authority<br>
>>> Betreff: SCID assignments<br>
>>> Dear Mr. Peinado,<br>
>>> SANA are currently discussing some issues regarding your recent
SCID <br>
>>> requests with the SSG (Sana Steering Group).<br>
>>> When all is sorted out, we will inform you of the result.<br>
>>> Thank you for your understanding.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> [CCSDS OID Tree flat 10Jul15 v6.pdf]<br>
>>><br>
>>> [Spacecraft ID, name, & characteristics v1.pdf]<br>
>>><br>
>>> [CCSDS SCID Registry relationships v3.pdf] <br>
>>> _______________________________________________<br>
>>> SSG mailing list<br>
>>> SSG@mailman.ccsds.org<</font></tt><a href=mailto:SSG@mailman.ccsds.org><tt><font size=2>mailto:SSG@mailman.ccsds.org</font></tt></a><tt><font size=2>><</font></tt><a href=mailto:SSG@mailma><tt><font size=2>mailto:SSG@mailma</font></tt></a><tt><font size=2><br>
>>> n .ccsds.org> </font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg</font></tt></a><tt><font size=2><br>
>>><br>
>>><br>
>>> [Screen Shot 2015-07-30 at 10.49.17 AM.png]<br>
><br>
><br>
>_______________________________________________<br>
>CESG mailing list<br>
>CESG@mailman.ccsds.org<br>
></font></tt><a href=http://mailman.ccsds.org/mailman/listinfo/cesg><tt><font size=2>http://mailman.ccsds.org/mailman/listinfo/cesg</font></tt></a><tt><font size=2><br>
<br>
_______________________________________________<br>
CESG mailing list<br>
CESG@mailman.ccsds.org<br>
</font></tt><a href=http://mailman.ccsds.org/mailman/listinfo/cesg><tt><font size=2>http://mailman.ccsds.org/mailman/listinfo/cesg</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>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.
</PRE>