<html>
<body>
<blockquote type=cite class=cite cite=""><font color="#800080">At 12:17
PM 9/7/2005, Krupiarz, Christopher wrote:<br>
... Could you elaborate a bit on how you would see commanding done in an
emergency situation without using an IP packet? I probably got lost
along the way, but I made the assumption that in this architecture all
packets that a spacecraft received would be an IP packet. The
hardware decode command (I think equivalent to our critical commands
here) would just be a bit string, but it would still be in an IP
packet</font>.</blockquote>===================<br>
<font color="#0000FF">At 08:32 AM 9/7/2005, Matthew Cosby wrote:<br>
<blockquote type=cite class=cite cite="">In Europe we get around this
problem with a Command Pulse Distribution Unit (CPDU) installed in the
Packet Telecommand Decoder (PTD - "hunk of hardware that
doesn't rely on the correct operation of the flight computer" ).
This hardware commanding utilises the Multiplexed Access Point (MAP)
identifiers in the segmentation layer of the Telecommand Stack. <br><br>
I have attached a data sheet of PTD for you read - Section 4.5. The
upshot of it is you can send a command to the PTD (within the
communications system) that can toggle up to 256 lines, for resetting the
flight computer, switching antenna, etc without needing to worry about
the high level stuff on
top.</font></blockquote>===================<br><br>
<font size=2>As Matt notes, there is extensive and well-tested standard
infrastructure built around the concept of direct Link-layer
"hardware" commanding. If you read section 4.3 of the PTD data
sheet you will also see that command authentication is covered and if I
remember correctly, bog standard CCSDS Link layer data protection has
already been quite widely implemented in Europe for
"asset"-class missions:<br><br>
-- Perhaps we can hear more about these capabilities from Matt and
Dai? <br>
-- Howie; what's your take on the strength of the security that is
provided by the PTD?<br><br>
I'm not sure that the CSI architecture should assume (as Chris suggests)
that *all* traffic is IP-based. Given where we are today, wouldn't it be
reasonable to expect an evolutionary progression, with a mix of some
services that are built directly on the Link layer and other services
that are Network based? <br><br>
Perhaps the CSI group should revisit the AOS architecture that is
expressed in Figure 2-2 (page 2-5) of
<a href="http://public.ccsds.org/publications/archive/701x0b3.pdf" eudora="autourl">
http://public.ccsds.org/publications/archive/701x0b3.pdf</a> to see what
possibilities exist? It should be noted that the AOS architecture is now
~15 years old and that we are still waiting for any significant customers
of space networking to emerge. Rather than starting over, one would hope
that the CSI group would build on the internationally-agreed AOS
framework and at the end of the day the group would be able to recommend
a comprehensive update to the AOS service model (as defined in section 2
of the specification) and to the corresponding protocol specs. In
particular, someone might want to at least propose a Pink Sheet to change
the selection of the protocol that is currently recommended to implement
the Internet service... :-\<br><br>
</font>///adrian<br>
</body>
<br>
</html>