Protocols and Standards

Space link protocols are published as CCSDS Blue Books, which are Recommended Standards with an issue number and a date. A mission cites the specific issue it implements, because the frame formats change between issues.

The layers a Mars rover uses

Layer	Standard	Issue	Role
Application data unit	Space Packet Protocol, CCSDS 133.0-B-2	June 2020	The packet a science or engineering data product is broken into
Space data link, orbiter to Earth	AOS Space Data Link Protocol, CCSDS 732.0-B-4	October 2021	Transfer frames on the deep space link
Proximity link, surface to orbiter	Proximity-1 Space Link Protocol, Data Link Layer, CCSDS 211.0-B-6	July 2020	The UHF relay hop
File delivery	CCSDS File Delivery Protocol, CCSDS 727.0-B-5	July 2020	Reliable file transfer across one or more hops
Networking overlay	CCSDS Bundle Protocol, CCSDS 734.2-B-1	September 2015	Store-and-forward networking across scheduled contacts

Sources: the Blue Books themselves, [1] through [4].

Space Packet Protocol

A Space Packet is a 6 octet primary header plus a data field of 1 to 65,536 octets, so a packet is at least 7 and at most 65,542 octets, with individual projects free to set a lower maximum [1]. The primary header is four contiguous fields: packet version number, 3 bits; packet identification, 13 bits, of which 1 bit is packet type, 1 bit the secondary header flag and 11 bits the application process identifier; packet sequence control, 16 bits; and packet data length, 16 bits.

The application process identifier is the field that makes multiplexing work operationally. MER relay data arriving at Odyssey was divided into fixed length packets with a distinct identifier per rover, and the MER ground system queried the Odyssey ground system after each pass for the packets carrying its identifiers, stripped the headers and fed the result to frame synchronization, at which point the data looked as though it had arrived directly [7].

Proximity-1

Proximity-1 is the protocol on the UHF hop, and it is a session protocol rather than a framing convention. The Version-3 transfer frame carries a mandatory 5 octet header of ten fields: transfer frame version number, 2 bits; quality of service indicator, 1 bit; PDU type identifier, 1 bit; data field construction identifier, 2 bits; spacecraft identifier, 10 bits; port identifier, 3 bits; frame length, 11 bits; and frame sequence number, 8 bits, among others [2]. On the physical channel each frame is wrapped in an attached synchronization marker and an attached CRC-32.

Two services are defined: sequence controlled, which is reliable and retransmits from a sent frame queue against status reports, and expedited, which is not [2]. On Curiosity the sequence controlled link is the nominal protocol, with an unreliable bit stream mode that bypasses Proximity-1 available for off-nominal cases and for entry, descent and landing [6]. Of all MSL relay sessions flown to that point, 99.9 percent used the reliable mode, bitstream being reserved for a handful of demonstrations [10].

The session model is what enables adaptive data rates. Every link is opened by the orbiter hailing the surface vehicle, on MER always at 8 kbit/s, carrying the communications mode, data rates and coding to use [7]. Because rate is a negotiable session parameter, Proximity-1 can command a different return rate during a pass, which is how the Curiosity to MRO link tracks the changing geometry within a single overflight; only the return rate is adapted, and the forward rate stays at 32 kbit/s [6].

CCSDS File Delivery Protocol

CFDP moves files rather than packets, and it carries its own PDU header so it is independent of the underlying protocol [3]. It offers an unacknowledged mode and several acknowledged modes. In acknowledged mode the receiver informs the sender of undelivered file segments by negative acknowledgment, with sub-options ranging from immediate NAK release to deferred release in which NAKs are held until the assumed end of transmission. A transaction closure option lets unacknowledged mode still confirm delivery. Annex B specifies store and forward overlay operations, which is the multi-hop case a Mars relay chain represents.

The core Flight System ships CFDP as one of its standard applications; on the Global Precipitation Measurement observatory it was 8559 logical lines of code and 85,812 bytes of EEPROM, the largest single application in that build [9].

Delay tolerant networking, and where it has actually flown

The Bundle Protocol adds a store-and-forward overlay above the link layer, so a node can take custody of data and forward it when the next contact opens rather than requiring an end-to-end path to exist at any instant [4]. The CCSDS Blue Book is a profile of the Internet experimental RFC 5050.

DTN’s deep space flight validation is DINET, run on the Deep Impact spacecraft under the EPOXI project in October and November 2008 [5]. About 300 images were sent from JPL ground nodes to the spacecraft and automatically forwarded back over 27 days across eight transmission opportunities, exercising bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer and automatic retransmission. All transmitted bundles were received without corruption.

Four validation metrics were defined in advance [5]:

Metric	Criterion	Result
Path utilization rate, configuration a	greater than 90 percent	76.2 percent raw, 97.4 percent excluding underutilized passes and non-DTN overhead
Path utilization rate, configuration b, higher loss	greater than 90 percent	72.4 percent raw, 92.5 percent on the same basis
Delivery acceleration ratio, configuration a	greater than 1.05	1.10
Delivery acceleration ratio, configuration b	greater than 1.1	1.12
Node storage utilization	zero custody refusals for depleted storage, and stabilizing utilization	satisfied, except node 10 changed by 156,816 bytes between passes 6 and 7
Multipath advantage	greater than 20 percent	35 percent

About 20 percent of the available uplink capacity was consumed by link service overhead, mainly telecommand coding, which is why the raw and corrected utilization figures differ so much [5]. Errors in the dynamic routing implementation meant the measured multipath advantage did not translate into improved delivery acceleration.

ION’s design constraints are stated explicitly and are the reason the protocol looks as it does: interplanetary downlink on the order of 256 kbit/s to 6 Mbit/s, uplink on the order of 1 to 2 kbit/s, and flight processors that are invariably slower than ground equivalents because radiation hardening lags commercial process nodes, so the cost per processing cycle is high and processors are heavily subscribed [5]. The Interplanetary Overlay Network implementation runs on VxWorks 5.4 among other targets, avoids unrestrained dynamic allocation, and uses a shared memory model rather than protected memory to keep the cost of passing data between tasks down.

The operational DTN deployment with published throughput is the International Space Station, where bundle storage covers 4.4 hours at 60 Mbit/s and measured throughput was about 15 Mbit/s down and 4 Mbit/s up [8]. No Mars surface vehicle has flown DTN operationally.

References

CCSDS. (2020). Space Packet Protocol . Consultative Committee for Space Data Systems, CCSDS 133.0-B-2, Blue Book. Source

BibTeX

@techreport{ccsds2020space,
  title = {Space Packet Protocol},
  author = {{CCSDS}},
  number = {CCSDS 133.0-B-2, Blue Book},
  institution = {Consultative Committee for Space Data Systems},
  year = {2020},
  url = {https://ccsds.org/Pubs/133x0b2e2.pdf}
}

CCSDS. (2020). Proximity-1 Space Link Protocol: Data Link Layer . Consultative Committee for Space Data Systems, CCSDS 211.0-B-6, Blue Book. Source

BibTeX

@techreport{ccsds2020proximity,
  title = {Proximity-1 Space Link Protocol: Data Link Layer},
  author = {{CCSDS}},
  number = {CCSDS 211.0-B-6, Blue Book},
  institution = {Consultative Committee for Space Data Systems},
  year = {2020},
  url = {https://ccsds.org/Pubs/211x0b6e1.pdf}
}

CCSDS. (2020). CCSDS File Delivery Protocol (CFDP) . Consultative Committee for Space Data Systems, CCSDS 727.0-B-5, Blue Book. Source

BibTeX

@techreport{ccsds2020cfdp,
  title = {CCSDS File Delivery Protocol (CFDP)},
  author = {{CCSDS}},
  number = {CCSDS 727.0-B-5, Blue Book},
  institution = {Consultative Committee for Space Data Systems},
  year = {2020},
  url = {https://ccsds.org/Pubs/727x0b5e1.pdf}
}

CCSDS. (2015). CCSDS Bundle Protocol Specification . Consultative Committee for Space Data Systems, CCSDS 734.2-B-1, Blue Book. Source

BibTeX

@techreport{ccsds2015bundle,
  title = {CCSDS Bundle Protocol Specification},
  author = {{CCSDS}},
  number = {CCSDS 734.2-B-1, Blue Book},
  institution = {Consultative Committee for Space Data Systems},
  year = {2015},
  url = {https://ccsds.org/Pubs/734x2b1.pdf}
}

Wyatt, J., Burleigh, S., Jones, R., Torgerson, L. and Wissler, S. (2009). Disruption Tolerant Networking Flight Validation Experiment on NASA's EPOXI Mission . International Conference on Advances in Satellite and Space Communications. Source

BibTeX

@inproceedings{wyatt2009disruption,
  title = {Disruption Tolerant Networking Flight Validation Experiment on NASA's EPOXI Mission},
  author = {Wyatt, Jay and Burleigh, Scott and Jones, Ross and Torgerson, Leigh and Wissler, Steve},
  booktitle = {International Conference on Advances in Satellite and Space Communications},
  pages = {187-196},
  year = {2009},
  doi = {10.1109/spacomm.2009.39},
  abstract = {In October and November of 2008, the Jet Propulsion Laboratory installed and tested essential elements of Delay/Disruption Tolerant Networking (DTN) technology on the Deep Impact spacecraft. This experiment, called Deep Impact Network Experiment (DINET), was performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. During DINET some 300 images were transmitted from the JPL nodes to the spacecraft. Then they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. All transmitted bundles were successfully received, without corruption. The DINET experiment demonstrated DTN readiness for operational use in space missions. This activity was part of a larger NASA space DTN development program to mature DTN to flight readiness for a wide variety of mission types by the end of 2011. This paper describes the DTN protocols, the flight demo implementation, validation metrics which were created for the experiment, and validation results.}
}

Makovsky, A., Ilott, P. and Taylor, J. (2009). Mars Science Laboratory Telecommunications System Design . Jet Propulsion Laboratory, California Institute of Technology, Article 14. Source

BibTeX

@techreport{makovsky2009mars,
  title = {Mars Science Laboratory Telecommunications System Design},
  author = {Makovsky, Andre and Ilott, Peter and Taylor, Jim},
  series = {DESCANSO Design and Performance Summary Series},
  number = {Article 14},
  institution = {Jet Propulsion Laboratory, California Institute of Technology},
  year = {2009},
  url = {https://descanso.jpl.nasa.gov/DPSummary/Descanso14_MSL_Telecom.pdf}
}

Taylor, J., Makovsky, A., Barbieri, A., Tung, R., Estabrook, P. and Thomas, A. G. (2014). Mars Exploration Rover Telecommunications . Deep Space Communications. Source

BibTeX

@incollection{taylor2014mars,
  title = {Mars Exploration Rover Telecommunications},
  author = {Taylor, Jim and Makovsky, Andre and Barbieri, Andrea and Tung, Ramona and Estabrook, Polly and Thomas, A. Gail},
  booktitle = {Deep Space Communications},
  series = {DESCANSO Design and Performance Summary Series},
  publisher = {Jet Propulsion Laboratory, California Institute of Technology},
  chapter = {7},
  year = {2014},
  url = {https://descanso.jpl.nasa.gov/monograph/series13/DeepCommo_Chapter7--141030.pdf}
}

Schlesinger, A., Willman, B. M., Pitts, L., Davidson, S. R. and Pohlchuck, W. A. (2016). Delay/Disruption Tolerant Networking for the International Space Station (ISS) . SpaceOps. Source

BibTeX

@inproceedings{schlesinger2016delay,
  title = {Delay/Disruption Tolerant Networking for the International Space Station (ISS)},
  author = {Schlesinger, Adam and Willman, Brett M. and Pitts, Lee and Davidson, Suzanne R. and Pohlchuck, William A.},
  booktitle = {SpaceOps},
  pages = {1-14},
  year = {2016},
  doi = {10.1109/aero.2017.7943857},
  abstract = {Disruption Tolerant Networking (DTN) is an emerging data networking technology designed to abstract the hardware communication layer from the spacecraft/payload computing resources. DTN is specifically designed to operate in environments where link delays and disruptions are common (e.g., space-based networks). The National Aeronautics and Space Administration (NASA) has demonstrated DTN on several missions, such as the Deep Impact Networking (DINET) experiment, the Earth Observing Mission 1 (EO-1) and the Lunar Laser Communication Demonstration (LLCD). To further the maturation of DTN, NASA is implementing DTN protocols on the International Space Station (ISS). This paper explains the architecture of the ISS DTN network, the operational support for the system, the results from integrated ground testing, and the future work for DTN expansion.}
}

McComas, D., Wilmot, J. and Cudmore, A. (2016). The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft . Annual AIAA/USU Conference on Small Satellites. Source

BibTeX

@inproceedings{mccomas2016core,
  title = {The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft},
  author = {McComas, David and Wilmot, Jonathan and Cudmore, Alan},
  booktitle = {Annual AIAA/USU Conference on Small Satellites},
  year = {2016},
  url = {https://ntrs.nasa.gov/citations/20160010300},
  abstract = {In February 2015 the NASA Goddard Space Flight Center (GSFC) completed the open source release of the entire Core Flight Software (cFS) suite. After the open source release a multi-NASA center Configuration Control Board (CCB) was established that has managed multiple cFS product releases. The cFS was developed and is being maintained in compliance with the NASA Class B software development process requirements and the open source release includes all Class B artifacts. The cFS is currently running on three operational science spacecraft and is being used on multiple spacecraft and instrument development efforts. While the cFS itself is a viable flight software (FSW) solution, we have discovered that the cFS community is a continuous source of innovation and growth that provides products and tools that serve the entire FSW lifecycle and future mission needs. This paper summarizes the current state of the cFS community, the key FSW technologies being pursued, the development/verification tools and opportunities for the small satellite community to become engaged. The cFS is a proven high quality and cost-effective solution for small satellites with constrained budgets.}
}

Girerd, A. R., Kuhn, S., Roth, B., Gaines, D., Scandore, S., Cummings, D., Mendoza, R., Lefland, M., Bareh, M., Siegfriedt, R., Lenda, M., Reich, K., Shah, B. and Bohannon, E. (2022). Cross-Cutting Flight Infrastructure Improvements on M2020 . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{girerd2022cross,
  title = {Cross-Cutting Flight Infrastructure Improvements on M2020},
  author = {Girerd, Andre R and Kuhn, Stephen and Roth, Brian and Gaines, Dan and Scandore, Steve and Cummings, David and Mendoza, Ricardo and Lefland, Mallory and Bareh, Magdy and Siegfriedt, Rebekah and Lenda, Matthew and Reich, Kevin and Shah, Biren and Bohannon, Emily},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-15},
  publisher = {IEEE},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843523},
  abstract = {Mars2020 (M2020) was formulated as a mission that leveraged as much Mars Science Laboratory (MSL) heritage as possible, while focusing major new development efforts on the original and unique elements needed to accomplish the different mission objectives. Well publicized examples of high profile new developments include precision landing, the sampling and caching system, the specific instrument suite, improved mobility via Autonomous Navigation, and later the addition of the Ingenuity helicopter. Less well known are the refinements to the core flight infrastructure, primarily in the cross-cutting functions of Telecom, Avionics, Data Management, Communications Behaviors, and Parameter Management. These enhancements are introduced predominately via flight software, and represent increases in capability that justified their inclusion in an otherwise heritage-focused project environment. Perseverance's cross-cutting flight infrastructure improvements fall into and across the following five categories. First is a trimming of the software footprint of infrastructure modules, in order to make room for memory demands elsewhere in the system. Second is the minimization of data volume to be downlinked, through various methods such as the incorporation of new compression options. Third is the maximization of the available downlink bandwidth for data, by curtailing content-less data (fill) and introducing an improved UHF proximity link protocol. Fourth is a reduction in vulnerabilities, through increased file system redundancy, robustness, and software process monitoring. Fifth is an increase in operations efficiency by lowering file system mount times, improving parallelism between simultaneous events, minimizing the time to recover from file system errors, streamlining the purging of obsolete data, and reducing the number of commands to service parameters by a factor of 100. Individually, none of the cross-cutting infrastructure improvements are likely to garner headlines, but collectively they appreciably improve the safety and operability of Perseverance over its predecessor. This paper will describe the improvements, their promise, and where applicable, their actual impact in operations.}
}