[CESG] RE: [SSG] [SANA #5270] AW: SCID assignments
Soula Jean-Marc
Jean-Marc.Soula at cnes.fr
Fri Jul 31 14:38:41 UTC 2015
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. 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 sanaregistry.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-Marc.Soula at cnes.fr><mailto:Jean-Marc.Soula at cnes.fr><mailto:Jean-Marc.Soula 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><mailto:peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov%3e%3cmailto:peter.m.shames at jpl.nasa.gov%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 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 at 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 mailman.ccsds.org><mailto:cesg at mailman.ccsds.org><mailto:cesg at mailman.ccsds.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 mailman.ccsds.org><mailto:ssg at mailman.ccsds.org><mailto:ssg at mailman.ccsds.org%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-Marc.Soula at cnes.fr><mailto:Jean-Marc.Soula at cnes.fr<mailto:Jean-Marc.Soula 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><mailto:ssg-bounces at mailman.ccsds.org><mailto:ssg-bounces at mailman.ccsds.org<mailto:ssg-bounces at mailman.ccsds.org%3e%3cmailto:ssg-bounces at mailman.ccsds.org>>
[mailto:ssg-bounces at mailman.ccsds.org] De la part de Shames, Peter M
(312B)
Envoyé : mercredi 29 juillet 2015 18:18
À :
osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado at dlr.de><mailto:osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.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.peinado 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 at 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.peinado at dlr.de><mailto:osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150731/df9bc841/attachment.html>
More information about the CESG
mailing list