<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);">
<div>Thanks Marc.</div>
<div><br>
</div>
<div>Just for chuckles I took what you sent, shoved them into a spreadsheet (attached) and applied the following heuristics:</div>
<ol>
<li>For each stated “frequency” input assign it to the corresponding band</li><li>If there is more than one band sort them within the “Band” bin in order of lowest to highest frequency</li><li>Assign a sequence number for tracking</li><li>Sort by Band and then sequence number</li></ol>
<div>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)</div>
<div><br>
</div>
<div>Purely based on pragmatic considerations I would suggest that we could create “Band Bins” that looked like this:</div>
<ul>
<li>Everything below S-Band (HF, VHF, UHF, L)</li><li>S-Band & C-Band</li><li>X-Band</li><li>K-Band (Ku, K, Ka)</li><li>None or unstated</li></ul>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Does this seem like it could be made workable?</div>
<div><br>
</div>
<div>Regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>On 7/30/15, 11:11 AM, "Marc Blanchet" <<a href="mailto:info@sanaregistry.org">info@sanaregistry.org</a>> wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div><br>
</div>
<div>On 30 Jul 2015, at 13:50, Shames, Peter M (312B) wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>Thanks for the clarifications Marc. That helps a lot.</div>
<div><br>
</div>
<div>One question for you is whether what we have in the “TM & TC </div>
<div>frequencies” slots are actually frequencies, as in 2380 Ghz, or if </div>
<div>they are frequency bands, as in “S Band”. I think that we may get </div>
<div>enough relief from just using the frequency bands (see attached table) </div>
<div>that this in itself may be adequate, but I do recognize that there may </div>
<div>be issues even at that level.</div>
</blockquote>
<div><br>
</div>
<div>It is a mix of everything. Given exactly that, we tried to normalize the </div>
<div>data but were not able given the too large variety and that the previous </div>
<div>operator did not enforce any normalization while entering the data in </div>
<div>the registry (no criticism, just a fact). Therefore, we did not try to </div>
<div>enforce any normalization yet on new data, so these are currently just </div>
<div>« strings ». (similarly, when we took over the RF asset registry </div>
<div>from IOAC, we tried to normalize the data as much as possible, but given </div>
<div>that it was often entered like strings with no format requirements, then </div>
<div>it is just a can of worms for data normalization).</div>
<div><br>
</div>
<div>Here is just a few samples from a quick visual scan of the registry. Far </div>
<div>from comprehensive, but just to give you a sense of the current values </div>
<div>(yes, values in the frequency column), without the spacecraft </div>
<div>identification. please don’t concentrate on the actual values but more </div>
<div>on the diversity of data we have.</div>
<div><br>
</div>
<div>2048.85 MHz (E-S)</div>
<div>TC</div>
<div>1S-Band (Housekeeping), 1X-Band (IDHT Low Rate), 1X-Band (IDHT High </div>
<div>Rate)</div>
<div>S-Band</div>
<div>2203 MHz, 2206.5 MHz, 2218 MHz, 2227 MHz, 2254.5 MHz, 2265.5 MHz, 2284 </div>
<div>MHz</div>
<div>Ku-Band</div>
<div>TBD</div>
<div>7.1808063 GHz (6 MHz BW)</div>
<div>X-Band 7156.53 MHz</div>
<div>X-Band 7166 MHz (CMD 10-2000 b/s and RNG), Ka-Band 34.45 GHz (No CMD or </div>
<div>RNG)</div>
<div>8190.0 MHz (primary) and 2252.5 MHz (demonstration purposes only)</div>
<div>8429.938271 MHz, 8427.222 MHz (noncoherent)</div>
<div>3947-52 MHz (C-Band)</div>
<div>Category B (Deep Space) D/L X-Band U/L X-Band</div>
<div>X-Band, Ka-Band (Category B (Deep Space)</div>
<div>2044.25 MHz (center Frequency for TC)</div>
<div>2225 MHz (S-E), 2048.85 MHz (E-S)</div>
<div>Frequency pair unknown at this time</div>
<div>Around 14 GHz</div>
<div>S-Band 2215 MHz, S-Band 2039 MHz, X-Band 8.025-8.040 GHz</div>
<div>Ku-Band (14005.0 MHz (V); 14499 MHz(H)); SHF-Band 8397.5 (RHCP)</div>
<div>NA - ground use only</div>
<div>Around 2000</div>
<div>C-band to be determined from 5000 - 5010MHz and Ku-band to be determined </div>
<div>from 13750 - 14500MHz</div>
<div>Fdownlink=[2225.025+-n*3.069]MHz, </div>
<div>n=0,1,2,3,4;Fdownlink=(240/221)*Fuplink</div>
<div>N/A</div>
<div>Ground Use Only (Satellite 5850 MHz - 6426 MHz)</div>
<div>Around 14 GHz</div>
<div>29.1 GHz-29.3 GHz, 19400 MHz-19600 MHz</div>
<div>X-Band 8420 MHz (TLM, RS 10-18 Kb/s Turbo), Ka-Band 32.02 GHz (Carrier </div>
<div>Only - Radio Science)</div>
<div>Around 8400 Mhz and 32000 MHz</div>
<div>2210.0 MHz TBD</div>
<div>2025-2110 MHz. Center frequency has not been determined</div>
<div>HRIT 2040.9 MHz, LRIT 2037.64 MHz</div>
<div>145.870, 145.930, 2405.00 MHz; 145.870 - 145.920 MHz (Transponder)</div>
<div><br>
</div>
<div>I stopped way before reaching the end of the registry…</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>As you pointed out:</div>
<div><br>
</div>
<div>that the reliability of that data is unknown for</div>
<div>various reasons, such as: data was not entered properly by the </div>
<div>operator,</div>
<div>data was not provided by the requestor, frequencies were changed from</div>
<div>the time of the registration request to the time of the launch and the</div>
<div>requestor never sent the information back to the registry operator</div>
<div><br>
</div>
<div>Do you have any faith that if we were to attempt to apply the </div>
<div>“separation by frequency bands” approach that we would have </div>
<div>success at the 95% plus level, or would we be more at the 75% or 50% </div>
<div>level?</div>
</blockquote>
<div><br>
</div>
<div>can’t tell. I just want to point out that while, on paper, the </div>
<div>frequency separation might be a good idea, in practice, the registry </div>
<div>info we have does not provide that reliable data.</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>As for “clear procedures”, yes, we do understand absolutely the </div>
<div>need for this, for you as SANA Operaotr and for the user / requestor </div>
<div>community.</div>
</blockquote>
<div><br>
</div>
<div>yeah, just to point out our expectation of the outcome of this </div>
<div>discussion, from the operator point of view.</div>
<div><br>
</div>
<div>Regards, Marc.</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>Thanks, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On 7/30/15, 8:54 AM, "Marc Blanchet" </div>
<div><<a href="mailto:info@sanaregistry.org">info@sanaregistry.org</a><<a href="mailto:info@sanaregistry.org>">mailto:info@sanaregistry.org></a>> wrote:</div>
<div><br>
</div>
<div>- clarifications below enclosed in <SANA> </SANA>.</div>
<div><br>
</div>
<div>Marc.</div>
<div><br>
</div>
<div>On 29 Jul 2015, at 17:22, Shames, Peter M (312B) wrote:</div>
<div><br>
</div>
<div><br>
</div>
<div>Dear Jean-Marc,</div>
<div><br>
</div>
<div>I agree completely that this is not a settled issue by any means, and</div>
<div>I am glad that you and Osvaldo are engaged more actively in the</div>
<div>discussion. As I noted, this has been discussed for some time, but</div>
<div>this is the first effort to try and come to terms with it and to</div>
<div>actually identify a workable solution. I believe that open dialogue</div>
<div>is essential, since this ultimately affects all agencies (and other</div>
<div>organizations) who use CCSDS standards.</div>
<div><br>
</div>
<div>Once we identify an agreed path forward we must then, as quickly as we</div>
<div>can, get all of the involved elements (registries, documents,</div>
<div>procedures), revised so that everyone knows what to expect. In the</div>
<div>meantime I think we are in a transitional state where we really must</div>
<div>retain as much of the limited “SCID namespace” as we can in order</div>
<div>to not find ourselves at an abruopt halt when we run out of available</div>
<div>numbers.</div>
<div><br>
</div>
<div>Other comments are in-line, below.</div>
<div><br>
</div>
<div>Very best regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>From: Jean-Marc Soula</div>
<div><<a href="mailto:Jean-Marc.Soula@cnes.fr">Jean-Marc.Soula@cnes.fr</a><<a href="mailto:Jean-Marc.Soula@cnes.fr><mailto:Jean-Marc.Soula@cnes.fr>">mailto:Jean-Marc.Soula@cnes.fr><mailto:Jean-Marc.Soula@cnes.fr></a>></div>
<div>Date: Wednesday, July 29, 2015 at 10:49 AM</div>
<div>To: Peter Shames</div>
<div><<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a><<a href="mailto:peter.m.shames@jpl.nasa.gov><mailto:peter.m.shames@jpl.nasa.gov>">mailto:peter.m.shames@jpl.nasa.gov><mailto:peter.m.shames@jpl.nasa.gov></a>>,</div>
<div>"<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de></a>"</div>
<div><<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de></a>></div>
<div>Cc: CCSDS Engineering Steering Group - CESG Exec</div>
<div><<a href="mailto:cesg@mailman.ccsds.org">cesg@mailman.ccsds.org</a><<a href="mailto:cesg@mailman.ccsds.org><mailto:cesg@mailman.ccsds.org>">mailto:cesg@mailman.ccsds.org><mailto:cesg@mailman.ccsds.org></a>>,
</div>
<div>"SANA</div>
<div>Steering Group (SSG)"</div>
<div><<a href="mailto:ssg@mailman.ccsds.org">ssg@mailman.ccsds.org</a><<a href="mailto:ssg@mailman.ccsds.org><mailto:ssg@mailman.ccsds.org>">mailto:ssg@mailman.ccsds.org><mailto:ssg@mailman.ccsds.org></a>></div>
<div>Subject: RE: AW: [SANA #5270] AW: SCID assignments</div>
<div><br>
</div>
<div>Bonjour à tous,</div>
<div><br>
</div>
<div>I share the Oswaldo’s concern on which explanations or which</div>
<div>solutions may be offered by CCSDS to the projects requesting multiple</div>
<div>SCId and being rejected for those assets pertaining to the simulator /</div>
<div>tester … category.</div>
<div>I understand the rules have changed (and I do not object the arguments</div>
<div>for that) but the procedures were not yet revised (the abstracted blue</div>
<div>text below clearly shows that simulators / testers were valid assets</div>
<div>to obtain a SCId) … nor alternate solutions are offered (which we</div>
<div>should discuss further now).</div>
<div><br>
</div>
<div><br>
</div>
<div>You are correct in that the current, published, SCID document does not</div>
<div>discriminate against simulators nor testers. And yet we have this</div>
<div>problem that we must resolve in some way that does not halt the</div>
<div>ability of new spacecraft to be flown, by as many different users as</div>
<div>can be accommodated. In the immediate term the only way that I can</div>
<div>see to handle this is to only give out new (or re-cycled) SCIDs to the</div>
<div>real spacecraft. Your support for a set of registries sorted by</div>
<div>frequency, and inclusion of a "Frequency = none” category may be a</div>
<div>rapid way forward.</div>
<div><br>
</div>
<div>I think we can, through discussion, arrive at an agreed recommendation</div>
<div>to agencies re how to deal with the similator / tester issue. I hope</div>
<div>that this is the start of an active discussion where we try and arrive</div>
<div>at that agreement, because so far the discussion jhas ben of the</div>
<div>nature “We have a problem ….. What do we do?"</div>
<div><br>
</div>
<div>In CNES we also have several projects for which simulators have been</div>
<div>assigned a SCId, different from the one assigned to the SC.</div>
<div>Some more may come soon with similar requirements…</div>
<div><br>
</div>
<div><br>
</div>
<div>I hope that is sufficient motivation to have you and your staff, among</div>
<div>others from different agencies, get engaged in the discussion.</div>
<div><br>
</div>
<div>CCSDS should offer a workaround way to answer these requests and not</div>
<div>just reject the request because of the lack of Ids.</div>
<div><br>
</div>
<div>I agree we need a work-around. And I think we need to find one</div>
<div>quickly and document it.</div>
<div><br>
</div>
<div>Meanwhile, if we do not modulate requests for multiple SCIDs what is</div>
<div>to stop anyone from requesting several SCIDs for one spacecraft and</div>
<div>using up what little resource we have left?</div>
<div><br>
</div>
<div>Out of your list of activities below, Peter, I see Number 3 as quite</div>
<div>promising in terms of solving our SCId capacity issue, but I am not</div>
<div>100% sure if Number 4 could be another solution or not.</div>
<div><br>
</div>
<div>In more details:</div>
<div><br>
</div>
<div>Number 3: if SANA may allocate the same SCId to several missions,</div>
<div>based on the frequency discrimination, the issue of the testers /</div>
<div>simulators may be solved as they fall in the category “no</div>
<div>radiation” (meaning “no frequency”). Frequencies are already</div>
<div>part of the SCId request form and the information is already available</div>
<div>for a majority of missions (I hope).</div>
<div><br>
</div>
<div>You are correct, but we seem to have a bit of an issue. While the</div>
<div>transmitting frequencies (TM & TC) are on the form</div>
<div>(<a href="http://sanaregistry.org/cgi/spacecraftid">http://sanaregistry.org/cgi/spacecraftid</a>) they do not appear in the</div>
<div>available database in SANA</div>
<div>(<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html">http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>). We will</div>
<div>have to check with the SANA operator to see if this information is, in</div>
<div>fact, in the database but is just hidden in what is displayed.</div>
<div><br>
</div>
<div><SANA>Currently, as discussed a while ago when we took over the</div>
<div>spacecraftid registry, frequencies are kept internally in the database</div>
<div>but are not exposed.</div>
<div><br>
</div>
<div>However, one has to understand that, as we did a giant cleanup of the</div>
<div>registry, it is clear that the reliability of that data is unknown for</div>
<div>various reasons, such as: data was not entered properly by the </div>
<div>operator,</div>
<div>data was not provided by the requestor, frequencies were changed from</div>
<div>the time of the registration request to the time of the launch and the</div>
<div>requestor never sent the information back to the registry operator,</div>
<div>etc… Therefore, as we have seen for some IDs that were allocated</div>
<div>simultaneously to multiple missions, it took a long time to get the</div>
<div>space agencies involved to find the real frequencies used for those</div>
<div>missions. Therefore, the use of the frequency data for concurrent use </div>
<div>of</div>
<div>spacecraft ids are a challenge. Moreover, we also heard that</div>
<div>spacecraftids are also used within information systems to uniquely</div>
<div>identify the spacecraft, and that id does not include the frequencies.</div>
<div>Therefore, the collision may also happen in information systems.</div>
<div><br>
</div>
<div>One also has to remember that we have been accepting requests and</div>
<div>provided assignments of spacecraft ids that were requested to be </div>
<div>hidden</div>
<div>publicly (for various reasons such as military). Therefore, the public</div>
<div>version of the registry is not a full view of the database.</div>
<div></SANA></div>
<div><br>
</div>
<div>We will also have to accommodate spacecraft that use more than one</div>
<div>frequency, as in S / X or X / Ka. I do not know that the database in</div>
<div>its current form accommpodates that.</div>
<div><br>
</div>
<div><SANA>we can certainly make it happen</SANA></div>
<div><br>
</div>
<div><br>
</div>
<div>As you suggest, perhaps we can, for a while, adopt that “no</div>
<div>frequency” approach and still manage the simulator / tester</div>
<div>assignments within SANA. I think that is an interesting approach to</div>
<div>discuss.</div>
<div><br>
</div>
<div>Number 4: I saw a lot of emails on registries but could not spend</div>
<div>enough time with them to be sure of the meaning of “Object Id</div>
<div>(OId)” and how it may be used in practice to differentiate the</div>
<div>assets of a same satellite project and the assets of multiple projects</div>
<div>between them. It could be, assuming some verifications, that the OID</div>
<div>is another way to allow SANA to allocate several times the same SCId</div>
<div>to several missions, based on the OID discrimination this time.</div>
<div><br>
</div>
<div><br>
</div>
<div>The concept of the OID is an ISO construct that the Cross Support</div>
<div>Services area first started to use. It is a tree structured name</div>
<div>space where “CCSDS” (ISO OID = 1.3.112.4) forms the base of the</div>
<div>tree and we then get to determine which classes of objects we will</div>
<div>assign unique numbers to. A proposal for how to manage that namespace</div>
<div>is in the draft Registry Policy document and there is an information</div>
<div>model for it as well. Both are attached here. What has been proposed</div>
<div>is that there is a branch of the OID tree for spacecraft, and that</div>
<div>every spacecraft, simulator, or tester would have a unique SCID</div>
<div>assigned. That Spacecraft OID, as proposed, is just a number, of the</div>
<div>form 1.3.112.4.7.nnn. This OID is assigned when any registeration</div>
<div>request is made and it remains associated with that spacecraft</div>
<div>forever. In that way it can be used to unambiguously tag the</div>
<div>spacecraft data and allows the SCIDs to just be used on the</div>
<div>transmitted spacelink.</div>
<div><br>
</div>
<div>The rest of the Spacecraft information will be stored in the</div>
<div>Spacecraft database, as it is now, along with the SCID (during the</div>
<div>valid period) and the OID (which is permanent). The model of the</div>
<div>spacecraft database is also attached for reference. Most of these</div>
<div>fields are in the current database, but any shown in red are newly</div>
<div>added. It does occur to me now that we will probably need to add both</div>
<div>transmitting and receiving frequencies, and to add the ability to have</div>
<div>a spacecraft with multiple frequency bands.</div>
<div><br>
</div>
<div>So if we adopt some such approach I agree that we can re-allocate the</div>
<div>same SCID, using the Version Number (protocol type) and Frequency(s).</div>
<div>On the ground we can use just the OID as a unique identifier since it</div>
<div>is permanent. But unless there is a way to adopt the OID on the</div>
<div>spacelink I do not think that gives us any discrimination in radiated</div>
<div>space communication.</div>
<div><br>
</div>
<div>Those two options should be explored quickly, and I believe this is</div>
<div>the idea in the messages below, to confirm that the activity Number 2</div>
<div>may be cancelled and there is enough room then to continue the</div>
<div>allocation to simulators / testers.</div>
<div>Does it make sense ?</div>
<div><br>
</div>
<div><br>
</div>
<div>Based on this discussion, and if others agree with the use of</div>
<div>frequency band (including = none) , then I think that we could</div>
<div>continue to use the SANA to regsiter simulators and testers, as long</div>
<div>as we can use that distinction as well. For that matter, since these</div>
<div>simulators and testers will each belong to some single organization</div>
<div>that “owns” that asset you could even imagine a “Frequency =</div>
<div>None” namespace on a per agency / organization basis. There is no</div>
<div>fear then of collisions in communications and the OID can be used for</div>
<div>unambiguous identification of datasets. It is a little more</div>
<div>complicated than what we now do, but it is quite “future proof”</div>
<div>and avoids any risk of ambiguity.</div>
<div><br>
</div>
<div>In any case, one criteria to decide is how long it may take to put a</div>
<div>solution in place.</div>
<div>If too long, then we have a risk of overflow on the SCIds in the</div>
<div>meantime ; if doable in a reasonable time span, it would be a pity to</div>
<div>have rejected some requests for SCIds and have a solution for them a</div>
<div>few months later…</div>
<div><br>
</div>
<div>I agree, but contingent on getting rapid agreement on having a</div>
<div>“Frequency = none” SCID registry immediately set up, either on a</div>
<div>global basis or on an agency / organization basis. Does that sound</div>
<div>agreeable to you (and others)?</div>
<div><br>
</div>
<div>I think, for practicality, that we also need to reach agreement on a</div>
<div>set of SCID registries separated by frequency band (including None) so</div>
<div>that we can immediately re-gain some SCID breathing room/</div>
<div><br>
</div>
<div>Does that sound workable as well?</div>
<div><br>
</div>
<div><SANA>From the point of view of SANA, it would be good for our</div>
<div>operations point of view that we had clear and written and</div>
<div>agreed/approved recommendations on the way forward. Written so we can</div>
<div>refer the requestors to the document that describes the (new) policy. </div>
<div>It</div>
<div>does not need to be a full blown book, but some document that shows </div>
<div>the</div>
<div>new policy that we are using as our base assignment policy.</SANA></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>So my recommendation would be to work on activities 3 or 4, with the</div>
<div>objective not to apply number 2.</div>
<div>Of course activities number 1 and 5 should continue, with less</div>
<div>pressure on number1 if a solution is found … and no pressure on</div>
<div>number 5 which anyway is a long term and maybe not a global solution.</div>
<div><br>
</div>
<div>For further discussions I believe…</div>
<div><br>
</div>
<div><br>
</div>
<div>Yes. Indeed.</div>
<div><br>
</div>
<div>Best regards</div>
<div><br>
</div>
<div>Jean-Marc Soula</div>
<div>CNES - DCT/OP/C-STA</div>
<div>Advisor, GN Operations</div>
<div>18 Avenue Edouard Belin</div>
<div>31401 Toulouse Cedex 9 - France</div>
<div>Tel.: +33 (0)5 61 2 74647</div>
<div>Fax.: +33 (0)5 61 2 73135</div>
<div>Email: </div>
<div><a href="mailto:Jean-Marc.Soula@cnes.fr">Jean-Marc.Soula@cnes.fr</a><<a href="mailto:Jean-Marc.Soula@cnes.fr><mailto:Jean-Marc.Soula@cnes.fr">mailto:Jean-Marc.Soula@cnes.fr><mailto:Jean-Marc.Soula@cnes.fr</a>></div>
<div><br>
</div>
<div>Best regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>De :</div>
<div><a href="mailto:ssg-bounces@mailman.ccsds.org">ssg-bounces@mailman.ccsds.org</a><<a href="mailto:ssg-bounces@mailman.ccsds.org><mailto:ssg-bounces@mailman.ccsds.org">mailto:ssg-bounces@mailman.ccsds.org><mailto:ssg-bounces@mailman.ccsds.org</a>></div>
<div>[<a href="mailto:ssg-bounces@mailman.ccsds.org">mailto:ssg-bounces@mailman.ccsds.org</a>] De la part de Shames, Peter M</div>
<div>(312B)</div>
<div>Envoyé : mercredi 29 juillet 2015 18:18</div>
<div>À : </div>
<div><a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de">mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de</a>></div>
<div>Cc : CCSDS Engineering Steering Group - CESG Exec; SANA Steering Group</div>
<div>(SSG)</div>
<div>Objet : [SSG] Re: AW: [SANA #5270] AW: SCID assignments</div>
<div>Importance : Haute</div>
<div><br>
</div>
<div>Dear Osvaldo,</div>
<div><br>
</div>
<div>As I think you are aware, the CCSDS is in danger of running out of</div>
<div>available spacecraft ID (SCID) numbers. You could say that we are now</div>
<div>being hurt by our own success because there are so many spacecraft</div>
<div>using CCSDS data link and related standards that we no longer can</div>
<div>assign a SCID for the spacecraft, the simulator, and other possible</div>
<div>“flight-less birds”.</div>
<div><br>
</div>
<div>In the current SCID document, CCSDS 320.0-B-6C1, we have this</div>
<div>statement (emphasis added):</div>
<div><br>
</div>
<div>Section 2.1 Purpose of the CCSDS SCID</div>
<div><br>
</div>
<div>Because the SCID field is only eight or ten bits long, the SCID is not</div>
<div>intended to provide unique identification for all times.</div>
<div>It is inevitable that the SCIDs will have to be reused; however, at</div>
<div>any one time, the number of vehicles under simulation,</div>
<div>test, or active operational control is not anticipated to exceed the</div>
<div>available numbering domains.</div>
<div><br>
</div>
<div>Clearly this is no longer the case and the SSG, SLS and CESG have been</div>
<div>discussing this for at least the last three meetings. There are</div>
<div>several loosely coordinated activities which are now in process that</div>
<div>relate to this:</div>
<div><br>
</div>
<div>1) We have requested the Agency Representatives to relinquish all</div>
<div>assigned SCIDs for spacecraft that are no longer operational. This</div>
<div>has been somewhat successful, but we need to do it again.</div>
<div>2) We are in the process of revising the SCID assignment procedures to</div>
<div>no longer allow assignment of multiple SCID for a spacecraft</div>
<div>(simulators, testers, etc)</div>
<div>3) We are considering the use of frequency separation as well as the</div>
<div>current Version Number (VN) separation that is now in use. This could</div>
<div>relatively easily increase the number assignment space.</div>
<div>4) Under the new registry approach that is now in discussion we will</div>
<div>be assigning unique, permanent, object identifiers (OID) to all</div>
<div>spacecraft, similators, flightless birds, etc. These will persist</div>
<div>through time.</div>
<div>5) We are working on a new protocol, USLP, with a larger SCID number</div>
<div>space.</div>
<div><br>
</div>
<div>We have not yet discussed in any depth what recommendation we can make</div>
<div>to organizations who wish to have a separate, unique, SCID that they</div>
<div>can use internally to distinguish the spacecraft from any other</div>
<div>simulators or test gigs. Clearly this is a concern, but it is may be</div>
<div>treated as an internal issue that can be managed locally. It does not</div>
<div>have the same potential for cross agency impact because any such</div>
<div>signals will not be broadcast.</div>
<div><br>
</div>
<div>If you (or anyone else on this thread) has any other ideas or wishes</div>
<div>to contribute to the discussion please do so. I think that this is an</div>
<div>important enough issue for us to work quickly (as quickly as CCSDS can</div>
<div>move) to come up with a resolution.</div>
<div><br>
</div>
<div>Best regards, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>On 7/29/15, 7:43 AM,</div>
<div>"<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de></a>"</div>
<div><<a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de>">mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de></a>>
</div>
<div>wrote:</div>
<div><br>
</div>
<div>Dear Audric,</div>
<div>I know about the problem of SCIDs becoming rare.</div>
<div>You can process the satellite one, and discard the SIM one, BUT ....I</div>
<div>need to have for the project anyways and official answer from SANA.</div>
<div>It should be possible to inform the users about the situation and in</div>
<div>case of rejecting a request indicate a reference to a document and to</div>
<div>propose a solution, like "use the same ID as the Spacecraft or</div>
<div>something that you like, because your system is a closed one", as</div>
<div>example , can you do that?</div>
<div>I have another question:</div>
<div>I need to submit a request for another Satellite and it looks like the</div>
<div>link to do the request from the SANA page simply disappear, it is only</div>
<div>an E-mail.</div>
<div>It is that correct?</div>
<div>Thanks and best Regards</div>
<div>O. Peinado</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-----Ursprüngliche Nachricht-----</div>
<div>Von: SANA [<a href="mailto:info@sanaregistry.org">mailto:info@sanaregistry.org</a>]</div>
<div>Gesendet: Mittwoch, 29. Juli 2015 16:07</div>
<div>An: Peinado, Osvaldo Luis</div>
<div>Betreff: Re: [SANA #5270] AW: SCID assignments</div>
<div><br>
</div>
<div>Dear Mr. Peinado,</div>
<div><br>
</div>
<div>We were waiting for the SSG answer before getting back to you and see</div>
<div>if</div>
<div>you had any constraint on the two SCIDs being assigned at the same</div>
<div>time</div>
<div>or not.</div>
<div><br>
</div>
<div>If you tell us that we can go and process the non-sim request, we will</div>
<div>happily do that.</div>
<div><br>
</div>
<div>Thank you.</div>
<div><br>
</div>
<div>--</div>
<div>Best regards,</div>
<div>Audric Schiltknecht</div>
<div>Space Assigned Numbers Authority</div>
<div><br>
</div>
<div>Le 2015-07-29 09:47,</div>
<div><a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a><<a href="mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de">mailto:osvaldo.peinado@dlr.de><mailto:osvaldo.peinado@dlr.de</a>>
</div>
<div>a écrit :</div>
<div>Dear Audrich</div>
<div>Thank you for your answer.</div>
<div>I´m aware about the discussion about the SIM SCID and that till now</div>
<div>is nothing written down to deal with it, but what happened with the</div>
<div>SCID for the satellite?</div>
<div>I sent two separate request.</div>
<div>I do not see it also in the list of registry updates, why?</div>
<div>Best Regards</div>
<div>Osvaldo</div>
<div>-----------------------------------</div>
<div>Dr. Osvaldo Peinado</div>
<div>Ground Operations Manager</div>
<div>German Space Operations Center (GSOC)</div>
<div>Tel: +49 8153 28 3010</div>
<div>Fax: +49 8153 28 1456</div>
<div>Mobile: +491729410099</div>
<div>German Aerospace Center (DLR)</div>
<div>Oberpfaffenhofen</div>
<div>82234 Wessling</div>
<div>Germany</div>
<div>-----Ursprüngliche Nachricht-----</div>
<div>Von: Space Assigned Numbers Authority [<a href="mailto:info@sanaregistry.org">mailto:info@sanaregistry.org</a>]</div>
<div>Gesendet: Dienstag, 28. Juli 2015 22:35</div>
<div>An: Peinado, Osvaldo Luis</div>
<div>Cc: Space Assigned Numbers Authority</div>
<div>Betreff: SCID assignments</div>
<div>Dear Mr. Peinado,</div>
<div>SANA are currently discussing some issues regarding your recent SCID</div>
<div>requests with the SSG (Sana Steering Group).</div>
<div>When all is sorted out, we will inform you of the result.</div>
<div>Thank you for your understanding.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>[CCSDS OID Tree flat 10Jul15 v6.pdf]</div>
<div><br>
</div>
<div>[Spacecraft ID, name, & characteristics v1.pdf]</div>
<div><br>
</div>
<div>[CCSDS SCID Registry relationships v3.pdf]</div>
<div>_______________________________________________</div>
<div>SSG mailing list</div>
<div><a href="mailto:SSG@mailman.ccsds.org">SSG@mailman.ccsds.org</a><<a href="mailto:SSG@mailman.ccsds.org">mailto:SSG@mailman.ccsds.org</a>></div>
<div><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg</a></div>
<div><br>
</div>
<div><br>
</div>
<div>[Screen Shot 2015-07-30 at 10.49.17 AM.png]</div>
</blockquote>
<div><br>
</div>
</blockquote>
</body>
</html>