Abstract

The CCSDS Telemetry (TM), Telecommand (TC), and AOS (Advanced Orbiting Systems) data link protocols were all developed to support data transfer to/from a single spacecraft with a hands off approach of “security by obscurity”. Each of these protocols was developed at a different point in time and each came into existence based upon slightly different requirements. These differences resulted in a mixed usage of both the Transfer Frame Secondary Header (FSH) and Insert Zone fields. Moreover this mixed usage makes it difficult for users to understand and apply these fields today. Emerging work within CCSDS in the areas of space internetworking and data link layer security is providing a forum for further standardization that could utilize these fields. The primary driver is to provide common services across all the CCSDS Link Layer Protocols for improved dynamic flexibility for virtual channel operations including the flexible addition of security. We envision the coming era containing trunk lines utilizing switching nodes in a network that provide both link layer frame switching and network layer packet routing. In the link layer case, a node is simply taking multiple physical channels and multiplexing them together to form an aggregate physical channel. Here the switching node does not build frames but rather it simply multiplexes them into a single stream or demultiplex them from a single stream and channels them to separate channels based on their Master Channel address. The current design of the AOS protocol allows one to assign a different Master Channel ID or Virtual Channel to the frames produced by different entities within an enterprise; an example would be different agency’s Instrument/Lab on a space platform (ISS) would control the content of the Virtual Channel that they produce and then provide it to the switching node to multiplex the data into the return trunk line channel. When the AOS protocol was established the vision was to use AOS primarily for high rate links but designed in a feature to support low latency data for low rate operations. This low rate support was allocated to the Physical Channel and not the Master or Virtual Channel because having multiple Master Channels on a single Physical Channel was not envisioned at that time. The current view of how the AOS protocol will provide support for mission enlarges the role for supporting low latency data at low data rates and spreading the functionality across the Master Channels and Virtual Channels. For this reason we recommend the use of the Insert Zone for Master Channels and incorporate a self identifying and self delimiting Virtual Channel Secondary Header to provide this capability within a Virtual Channel. Thus we have changed the association of the Insert Zone from the Physical channel to the Master channel. This approach when applied to the TM protocol allows us to redefine the MC-FSH service to be an Insert Zone thus eliminating the duality of the FSH signaling flag and provide for both the Master Channel Insert Zone and Virtual Channel Secondary Header services when desired. Since we are developing approaches for the future then the merging of frames received from different channels may well be a model for a relay node where each mission builds its frames, encrypts/decrypts them and the relay node simply routes the frames onto/off other physical links.

Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.