Protocols and Standards
A surface robot’s communications protocols have to move commands and data across links that are slow, asymmetric, intermittent and, to Earth, delayed by minutes. A Mars rover reaches Earth mostly through orbiters that pass overhead for a few minutes at a time, so the protocols must share a scarce contact between several landers and instruments, recover from loss without a live round trip, and fit on flight processors that are slower than their ground equivalents. In early delayed-teleoperation experiments, operators given a delay stopped moving continuously and fell back on move, wait one round trip, and move again, so completion time grew linearly with delay [21].
The flown answer has converged on the 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 convergence was argued for before it happened: a 1998 proposal for all Mars in-situ links based the lander, rover and orbiter link layer on the CCSDS Telecommand Recommendation, with orbiter-initiated acquisition and routing by link-layer address [17], and a 1997 vision paper expected Internet-like and CCSDS standards to make spacecraft network nodes [19]. The result in practice is Proximity-1 on the relay hop, with Space Packets above it and CFDP for files. Delay tolerant networking is the one layer in this stack that has been demonstrated but not adopted operationally on a planetary surface.
The layers a Mars rover uses
Section titled “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 |
| Data compression | Lossless Data Compression, CCSDS 121.0-B-3 | August 2020 | Rice-based coder applied to instrument data before packetization |
| Networking overlay | CCSDS Bundle Protocol, CCSDS 734.2-B-1 | September 2015 | Store-and-forward networking across scheduled contacts |
Space Packet Protocol
Section titled “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]. The standard itself gives no packet-sizing guidance for a bandwidth-constrained relay link [1].
Link layers: AOS and Proximity-1
Section titled “Link layers: AOS and Proximity-1”The orbiter-to-Earth link carries fixed-length AOS transfer frames. A frame has a mandatory 6 or 8 octet primary header, an optional insert zone, the data field, an optional 4 octet operational control field and an optional 2 octet frame error control field, so a design that selects every option pays 14 octets of framing per frame; virtual channels, each with a 3 octet frame counter, let one downlink carry several prioritized streams [11].
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. The 11-bit length field caps a frame at 2048 octets, so a full frame carries 12 octets of framing, about 0.59 percent [2].
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].
Proximity-1 is also the basis of international relay. The framework for Mars UHF relay covers the protocol, the service agreements and interface control documents between agencies, and the Mars Relay Operations Service, and it was extended to ExoMars TGO and its lander to join the NASA orbiters [14]. It tabulates forward and return data rates, transceiver types and adaptive data rate capability for every NASA and ESA Mars lander, rover and orbiter from MGS onward [14]. Those values are as-specified transceiver capabilities, not measured link performance. The Mars Relay Network then in service used manually scheduled overflights and had no cross-links [13].
What the relay standards delivered, and the planned successors
Section titled “What the relay standards delivered, and the planned successors”An orbiter relay analysis predicted the return volume that a UHF relay could give a surface element, before any rover used one. For a Mars Global Surveyor relay at 8 kbit/s with a zero degree elevation mask and 15 percent overhead, it predicted 2.5 Mbyte per sol at the equator and 9.0 Mbyte per sol at 70 degrees south, with an average equatorial visibility of 48.4 minutes per sol, all from orbit simulation [26].
MER then supplied the flight record: through May 13, 2004, the two rovers had returned more than 40 Gbit, of which 78 percent came through Odyssey, 14 percent through Mars Global Surveyor and 8 percent direct to Earth [22]. Direct X-band ran at 10 to 20 kbit/s to a 70 m antenna and cost more than 1 Wh per Mbit, while routine UHF ran at 128 kbit/s, up to 256 kbit/s on the Odyssey link, and returned more than 10 Mbit per Wh; per-rover daily return was well over 150 Mbit per sol against 30 Mbit per sol for Mars Pathfinder, which had direct-to-Earth only [22]. The paper covers the prime mission only and several of its values are unfilled placeholders in print.
The lunar far side shows the same dependency with a single relay spacecraft. Queqiao, 448.7 kg in a halo orbit about Earth-Moon L2, carries a 4.2 m relay antenna; the forward link to the lander and rover is 125 bit/s, and the return is 285 kbit/s for the rover and 555 kbit/s for the lander with a directional surface antenna, falling to 700 and 1400 bit/s with an omnidirectional one [24]. These are link-budget values with margin, not measured on-orbit results [24].
The planned successor is a notional network of three relay orbiters at about 6000 km [23]. A 2021 JPL briefing states targets of 200 Gb per sol for a Curiosity-class lander against about 1 Gb per sol on the current network, and more than 1 Tb per day for a science orbiter against 30 Gb per day through MRO. The slide gives no link budget, contact model or cost, so the figures are targets, not capability [23].
On the flight software side, a prototype integrating ION into the F Prime framework needed a thread inside a nominally passive downlink component because ION’s segment API blocks, and pre-allocated shared memory sized from the ION configuration [25]. It has not been deployed or tested on flight hardware, and the paper reports no memory, CPU or throughput figures [25].
CCSDS File Delivery Protocol
Section titled “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 standard leaves timers and retry limits as parameters an implementer configures and gives no recommended value for any of them [3].
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]. Mars 2020 carried forward Mars Science Laboratory flight infrastructure and refined its telecom, data management and communications behaviors rather than replacing them [10].
Data compression
Section titled “Data compression”Compression sits above the transport, so the data volume a pass must carry is set before any of the protocols above act on it. The CCSDS lossless standard fixes the coder’s interoperable bit format: blocks of 8, 16, 32 or 64 samples, sample resolution up to 32 bits and a reference sample interval of up to 4096 blocks [12]. It states that a single channel bit error can corrupt an entire compressed sample sequence and provides no sync marker to resynchronize on, so recovery falls to the transport layer and to the choice of reference interval [12]. No compression ratio on any instrument data appears in the standard.
Relay in operation: Electra, open-loop recording and pass planning
Section titled “Relay in operation: Electra, open-loop recording and pass planning”The protocol stack has a flight-radio side that the Blue Books do not cover. The Electra UHF transceiver supports coded rates up to 2048 kbit/s against 256 kbit/s for the CE-505 on Odyssey and 128 kbit/s for Melacom on Mars Express, and a pre-landing JPL analysis predicted 303 Mbit per sol for the MSL to MRO link at a 2 sigma margin with adaptive data rate on, against 180 Mbit per sol for Odyssey, whose radio is limited to fixed rates of 8, 32, 128 and 256 kbit/s [27]. Those are predictions made before MSL arrived, not flight returns. The same paper records that EMI from two MRO science instruments degraded Electra threshold performance, with 4 dB allocated for MSL surface relay [27].
Entry, descent and landing is the case where session-based Proximity-1 is not used. For MSL the descent stage X-band link carried 8 bits per 10 s symbol, just under 1 bit/s, and MRO recorded the UHF signal open loop at 8 bits per sample so that a loss of lock could not destroy the record [27]. The ExoMars Schiaparelli lander, which was lost during entry in 2016, showed the value of that choice: open-loop recording on Trace Gas Orbiter reconstructed the 8 kbit/s telemetry on the ground, while Mars Express and a 12-antenna Giant Metrewave Radio Telescope sub-array detected only the carrier, and the signal ended 72 s before predicted touchdown [28]. The planned surface relay campaign of 46 passes over 14 sols produced no lander data [28].
Operations adds a scheduling constraint to the protocol choice. MSL relay planning had to be rebuilt when InSight landed 600 km away and the non sun synchronous MAVEN and TGO joined the network, because their overflights drift against the 38 day Earth to Mars phasing instead of arriving at consistent local times as MRO and Odyssey do [29]. Adaptive data rate on the Curiosity link reaches 2048 kbit/s, while InSight cannot use it because its CE-505 radio is sequenced in advance at fixed rates up to 256 kbit/s [29]. The paper is forward looking and gives no efficiency figure for the new cadence.
Simulation and proposals for relay networking
Section titled “Simulation and proposals for relay networking”Most of the work on networking beyond Proximity-1 and CFDP is simulation, and none of it is flight evidence. A simulation of Bundle Protocol over Licklider Transmission Protocol across a one-week Mars relay scenario with two landers, two orbiters and three ground stations argued that custody transfer frees onboard storage and permits dynamic prioritization; it omitted bit errors, finite buffers and multiple priorities, and it states that quantified cost savings were premature [15]. JPL’s MACHETE simulator was used for three cases: CFDP latency and buffer sizing for a Mars relay, quality-of-service prioritization for a lunar relay day, and retransmission latency under LTP compared with CFDP; the numbers in that paper are quoted from earlier work and their assumptions are not given [16]. The same tool evaluated IEEE 802.11g, 802.16 and a hybrid for a lunar surface scenario with two astronaut teams, a rover and a base. 802.16 lost less but added delay, and 802.11g with ARQ was the only case that met terrestrial voice targets [18]. That study modeled neither terrain RF loss nor relay and Earth links, and the simulation had no field measurement behind it [18].
The 2016 architecture for the Mars human era expects a network on CCSDS DTN with cross-links and optical bulk data, and states its own timelines (optical in 5 to 10 years, DTN connectivity in 15 to 25 years) as expectations rather than demonstrated capability [13]. A survey of distributed planetary surface instruments reaches the same dependency from the science side: networked sensors need radios, clocks and time synchronization whose maturity it tabulates, and no such instrument network has flown to a planetary surface [20].
Two smaller items sit between simulation and flight. A prototype of Proximity-1 Interleaved Time Synchronization folds time distribution into the Proximity-1 link layer and was exercised over UDP sockets between a simulated server and client; the brief reports no offset or delay figures [32]. The METERON OPSCOM-2 design for ISS-to-ground rover control used CCSDS MO services with Bundle Protocol transport over ION, at planned rates of 880 kbit/s up and 440 kbit/s down, and the paper predates the experiment so it reports no measured latency or throughput [30]. A publish-subscribe networking architecture for an Earth-Mars link was tested only in simulation, with assumed rates of 10 and 1 Mbit/s and a 750 s latency [31].
Delay tolerant networking, and where it has actually flown
Section titled “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. It requires a reliable storage service, makes the Extended Class of Service block mandatory, and maps reliable bundles to LTP red-part data and unreliable bundles to green-part data [4]. The ECOS block gives 256 ordinal priority levels within expedited service, with 255 reserved for custody signals, plus critical, streaming and reliable flags [4]. It provides no in-order or complete-sequence delivery, and the Blue Book contains no throughput, latency or storage figure.
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.
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 [5].
ION’s stated design constraints are 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 [33].
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.
What is not established
Section titled “What is not established”Every CCSDS Blue Book cited here is a specification: none reports link budgets, achieved throughput or protocol efficiency in operation, and the physical layer, coding and modulation sit in companion Blue Books [2][3][4]. Proximity-1 implementations diverge in practice, and no held source measures the interoperability cost [2]. DTN has one deep space validation, DINET, and one operational deployment on the ISS; nothing held shows it on a planetary surface, and the Mars-relay and lunar-surface evidence is simulation or proposal [5][8][15][16][18]. The Bundle Protocol profile covers RFC 5050 and not the later BPv7 work, and it does not address how routing tables are populated, which is where the engineering difficulty of a delay tolerant network sits [4]. The delayed-teleoperation result is a single degree of freedom task with a handful of subjects [21].
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.} } - CCSDS. (2021). AOS Space Data Link Protocol
. Consultative Committee for Space Data Systems, CCSDS 732.0-B-4, Blue Book. Source
BibTeX
@techreport{ccsds2021aos, title = {AOS Space Data Link Protocol}, author = {{CCSDS}}, number = {CCSDS 732.0-B-4, Blue Book}, institution = {Consultative Committee for Space Data Systems}, year = {2021}, url = {https://ccsds.org/Pubs/732x0b4.pdf} } - CCSDS. (2020). Lossless Data Compression
. Consultative Committee for Space Data Systems, CCSDS 121.0-B-3, Blue Book. Source
BibTeX
@techreport{ccsds2020lossless, title = {Lossless Data Compression}, author = {{CCSDS}}, number = {CCSDS 121.0-B-3, Blue Book}, institution = {Consultative Committee for Space Data Systems}, year = {2020}, url = {https://ccsds.org/Pubs/121x0b3.pdf} } - Kazz, G. J., Burleigh, S., Cheung, K.-M. and Shah, B. (2016). Evolution of the Mars Relay Network end-to-end information system in the Mars Human Era (2030-2040)
. SpaceOps Conference. Source
BibTeX
@inproceedings{kazznodateevolution, title = {Evolution of the Mars Relay Network end-to-end information system in the Mars Human Era (2030-2040)}, author = {Kazz, Greg J. and Burleigh, Scott and Cheung, Kar-ming and Shah, Biren}, booktitle = {SpaceOps Conference}, year = {2016}, doi = {10.2514/6.2016-2420}, abstract = {In order to help the reader understand this evolution from the current to the future MRN state in the Mars human era, we will provide a description of the current communication infrastructure supporting Mars mission users, and how we envision it to change in order to meet the needs and challenges of supporting both human and robotic communication by 2030-2040. This includes the introduction of new data types like audio and video, and new in-situ relay services for communications and navigation services.} } - Wenkert, D., Gladden, R. E., Edwards, C. D., Schmitz, P., Denis, M. and Winton, A. J. (2016). Enabling International Data Relay at Mars
. SpaceOps Conference. Source
BibTeX
@inproceedings{wenkert2016enabling, title = {Enabling International Data Relay at Mars}, author = {Wenkert, Daniel and Gladden, Roy. E. and Edwards, Charles D. and Schmitz, Peter and Denis, Michel and Winton, Alistair J.}, booktitle = {SpaceOps Conference}, publisher = {American Institute of Aeronautics and Astronautics}, year = {2016}, doi = {10.2514/6.2016-2355} } - Krupiarz, C. J., Jennings, E. H., Seguí, J. S., Pang, J. N., Schoolcraft, J. B. and Torgerson, J. L. (2006). Spacecraft data and relay management using delay tolerant networking
. SpaceOps Conference. Source
BibTeX
@inproceedings{krupiarz2006spacecraft, title = {Spacecraft data and relay management using delay tolerant networking}, author = {Krupiarz, Christopher J. and Jennings, Esther H. and Seguí, John S and Pang, Jackson N and Schoolcraft, Joshua B. and Torgerson, J. Leigh}, booktitle = {SpaceOps Conference}, year = {2006}, doi = {10.2514/6.2006-5754}, abstract = {NASA's demonstration of the successful transmission of relay data through the orbiting Mars Odyssey, Mars Global Surveyor, and Mars Express by the Mars Exploration Rovers has shown not only the benefit of using a relay satellite for multiple landed assets in a deep space environment but also the benefit of international standards for such architecture. As NASA begins the quest defined in the Vision for Exploration with robotic and manned missions to the Moon, continues its study of Mars, and is joined in these endeavors by countries world-wide, landed assets transmitting data through relay satellites will be crucial for completing mission objectives. However, this method of delivery of data will result in increased complexity in routing and prioritization of data transmission as the number of missions increases. Also, there is currently no standard method among organizations conducting such missions to return these data sets to Earth given a complex environment. One possibility for establishing such a standard is for mission designers to deploy protocols which fall under the umbrella of Delay Tolerant Networking (DTN). These developing standards include the Bundle Protocol (BP) which provides a standard, secure, store and forward mechanism designed for high latency and asymmetric communication links and the Licklider Transmission Protocol (LTP) which is used to provide a reliable deep space link transmission service.} } - Segui, J. S. and Jennings, E. H. (2008). Simulating autonomous telecommunication networks for space exploration
. SpaceOps Conference. Source
BibTeX
@inproceedings{segui2008simulating, title = {Simulating autonomous telecommunication networks for space exploration}, author = {Segui, John S. and Jennings, Esther H.}, booktitle = {SpaceOps Conference}, publisher = {American Institute of Aeronautics and Astronautics}, year = {2008}, doi = {10.2514/6.2008-3416} } - Kazz, G., Greenberg, E. and MacMedan, M. (1998). Application of an Externded CCSDS Telecommand Standard for All Mars In-Situ Telecommunication Links
. ESA, Tracking, Telemetry & Command System Workshop. Source
BibTeX
@inproceedings{kazz1998application, title = {Application of an Externded CCSDS Telecommand Standard for All Mars In-Situ Telecommunication Links}, author = {Kazz, G. and Greenberg, E. and MacMedan, M.}, booktitle = {ESA, Tracking, Telemetry & Command System Workshop}, year = {1998}, url = {https://ntrs.nasa.gov/citations/20060041323}, abstract = {The purpose of this paper is to propose a link layer standard for bi-directional telecommunication for in-situ links for data transfer between landers, rovers, and orbiters based upon the CCSDS Telecommand Recommendation.} } - Segui, J., Jennings, E. and Vyas, H. (2009). Evaluation of IEEE 802.11g and 802.16 for lunar surface exploration missions using MACHETE simulations
. AIAA Modeling and Simulation Technologies Conference. Source
BibTeX
@inproceedings{seguinodateevaluation, title = {Evaluation of IEEE 802.11g and 802.16 for lunar surface exploration missions using MACHETE simulations}, author = {Segui, John and Jennings, Esther and Vyas, Hemali}, booktitle = {AIAA Modeling and Simulation Technologies Conference}, year = {2009}, doi = {10.2514/6.2009-6035}, abstract = {In this paper, we investigated the suitability of terrestrial wireless networking technologies for lunar surface exploration missions. Specifically, the scenario we considered consisted of two teams of collaborating astronauts, one base station and one rover, where the base station and the rover have the capability of acting as relays. We focused on the evaluation of IEEE 802.11g and IEEE 802.16 protocols, simulating homogeneous 802.11g network, homogeneous 802.16 network, and heterogeneous network using both 802.11g and 802.16. A mix of traffic flows were simulated, including telemetry, caution and warning, voice, command and file transfer. Each traffic type had its own distribution profile, data volume, and priority. We analyzed the loss and delay trade-offs of these wireless protocols with various link-layer options. We observed that 802.16 network managed the channel better than an 802.11g network due to controlled infrastructure and centralized scheduling. However, due to the centralized scheduling, 802.16 also had a longer delay. The heterogeneous (hybrid) of 802.11/802.16 achieved a better balance of performance in terms of data loss and delay compared to using 802.11 or 802.16 alone.} } - Hooke, A. J. and Welch, D. C. (1997). Using New Technologies in Support of Future Space Missions. dataverse.jpl.nasa.gov/dataset.xhtml
BibTeX
@misc{hooke1997using, title = {Using New Technologies in Support of Future Space Missions}, author = {Hooke, Adrian J. and Welch, David C.}, year = {1997}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/22327} } - Rossi, F. (2025). Distributed Instruments for Planetary Surface Science: Scientific Opportunities and Technology Feasibility. arxiv.org/pdf/2407.01757
BibTeX
@misc{rossi2025distributed, title = {Distributed Instruments for Planetary Surface Science: Scientific Opportunities and Technology Feasibility}, author = {Rossi, Federico}, year = {2025}, url = {https://arxiv.org/pdf/2407.01757} } - Ferrell, W. R. (1964). Remote Manipulation with Transmission Delay
. IEEE Transactions on Human Factors in Electronics. Source
BibTeX
@article{ferrell1964remote, title = {Remote Manipulation with Transmission Delay}, author = {Ferrell, William R.}, journal = {IEEE Transactions on Human Factors in Electronics}, volume = {HFE-6}, pages = {24-32}, publisher = {Institute of Electrical and Electronics Engineers (IEEE)}, school = {Massachusetts Institute of Technology, Department of Mechanical Engineering}, type = {Ph.D. thesis}, year = {1964}, doi = {10.1109/thfe.1965.6591253}, abstract = {The effect on the performance of both simple and complex tasks of inserting transmission delay between the master and slave elements of a remote manipulator was studied. Most operators spontaneously adopted an effective “move-and-wait” strategy to cope with delay. A modification of a method proposed earlier enabled task-completion time to be accurately predicted from data taken when there was no delay. With the move-and-wait strategy, completion time depends on the length of sequences of open-loop movements. The number of such moves for positioning in one dimension as a function of task difficulty was found to agree with that predicted by a simple statistical model.} } - Statman, J. I. and Edwards, C. D. (2004). Coding, modulation, and relays for deep space communication Mars Rovers Case Study
. IEEE Convention of Electrical Engineers in Israel. Source
BibTeX
@inproceedings{statman2004coding, title = {Coding, modulation, and relays for deep space communication Mars Rovers Case Study}, author = {Statman, Joseph I. and Edwards, Charles D.}, booktitle = {IEEE Convention of Electrical Engineers in Israel}, year = {2004}, url = {https://ntrs.nasa.gov/citations/20060043953}, abstract = {This paper presents the communications challenges for the MER mission, the use of DSN and MER tools to maximize the science return, and the application of standards-based relays to the problem. To date, more than 90% of the data returned from MER has been returned via relays, not direct-to-Earath (DTE).} } - Edwards, C., Gladden, R. and Lee, C. (2021). Next-Generation Relay Capabilities for Future Robotic and Human Mars Exploration. ntrs.nasa.gov/citations/20220003436
BibTeX
@misc{edwards2021next, title = {Next-Generation Relay Capabilities for Future Robotic and Human Mars Exploration}, author = {Edwards, C. and Gladden, R. and Lee, C.}, year = {2021}, url = {https://ntrs.nasa.gov/citations/20220003436}, abstract = {No abstract provided} } - Wu, W., Wang, Q., Tang, Y., Yu, D., Wang, C., Liu, J., Zheng, L., Zhang, L. and Wang, F. (2021). Development and Prospect of Chinese Lunar Relay Communication Satellite
. Space: Science & Technology. Source
BibTeX
@article{wu2021development, title = {Development and Prospect of Chinese Lunar Relay Communication Satellite}, author = {Wu, Weiren and Wang, Qiong and Tang, Yuhua and Yu, Dengyun and Wang, Chi and Liu, Jizhong and Zheng, Lei and Zhang, Lihua and Wang, Feng}, journal = {Space: Science & Technology}, volume = {2021}, pages = {3471608}, year = {2021}, doi = {10.34133/2021/3471608}, abstract = {Relay communication satellites play a very important role on the lunar far side and pole areas exploration missions. Queqiao relay communication satellite was developed to provide relay communication support for the lander and the rover of Chang’e-4 mission landing on the far side of the Moon. From entering into the halo mission orbit around Earth-Moon libration point 2 on June 14, 2018, it has operated on the orbit more than thirty months. It worked very well and provided reliable, continuous relay communication support for the lander and the rover to accomplish the goals of Chang’e-4 lunar far side soft landing and patrol exploration mission. Exploration of the lunar south polar regions is of high scientific interest. A new relay communication satellite for Chinese south pole exploration mission is also under study. The system design and on-orbit operation status of Queqiao relay communication satellite were summarized in this paper. The system concept of the relay communication satellite for lunar south pole exploration missions is proposed. Finally, the future development and prospect of the lunar relay communication satellite system are given.} } - Rosemurgy, P., Gao, J., DeBaun, S., Starch, M., Levison, J. and Castano, R. (2024). Enabling DTN in Spaceflight Systems: Integration of ION with the F Prime Flight Software Framework
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{rosemurgy2024enabling, title = {Enabling DTN in Spaceflight Systems: Integration of ION with the F Prime Flight Software Framework}, author = {Rosemurgy, Paul and Gao, Jay and DeBaun, Sky and Starch, Michael and Levison, Jeffrey and Castano, Rebecca}, booktitle = {IEEE Aerospace Conference}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.idifr0} } - Horne, W. D., Hastrup, R. and Cesarone, R. (1997). Telecommunications for Mars Rovers and Robotic Missions
. AIAA ASCEND. Source
BibTeX
@inproceedings{horne1997telecommunicationsa, title = {Telecommunications for Mars Rovers and Robotic Missions}, author = {Horne, W. D. and Hastrup, Rolf and Cesarone, R.}, booktitle = {AIAA ASCEND}, publisher = {JPL Open Repository}, year = {1997}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/21726} } - Edwards, C. D. J., Arnold, B. W., Bell, D. J., Bruvold, K. N., Gladden, R. E., Ilott, P. A. and Lee, C. H. (2012). Relay support for the Mars Science Laboratory and the coming decade of Mars relay network evolution
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{edwards2012relay, title = {Relay support for the Mars Science Laboratory and the coming decade of Mars relay network evolution}, author = {Edwards, Charles D. Jr. and Arnold, Bradford W. and Bell, David J. and Bruvold, Kristoffer N. and Gladden, Roy E. and Ilott, Peter A. and Lee, Charles H.}, booktitle = {IEEE Aerospace Conference}, pages = {1-11}, publisher = {IEEE}, year = {2012}, doi = {10.1109/aero.2012.6187113}, abstract = {In the past decade, an evolving network of Mars relay orbiters has provided telecommunication relay services to the Mars Exploration Rovers, Spirit and Opportunity, and to the Mars Phoenix Lander, enabling high-bandwidth, energy-efficient data transfer and greatly increasing the volume of science data that can be returned from the Martian surface, compared to conventional direct-to-Earth links. The current relay network, consisting of NASA's Odyssey and Mars Reconnaissance Orbiter and augmented by ESA's Mars Express Orbiter, stands ready to support the Mars Science Laboratory, scheduled to arrive at Mars on Aug 6, 2012, with new capabilities enabled by the Electra and Electra-Lite transceivers carried by MRO and MSL, respectively. The MAVEN orbiter, planned for launch in 2013, and the ExoMars/Trace Gas Orbiter, planned for launch in 2016, will replenish the on-orbit relay network as the current orbiter approach their end of life. Currently planned support scenarios for this future relay network include an ESA EDL Demonstrator Module deployed by the 2016 ExoMars/TGO orbiter, and the 2018 NASA/ESA Joint Rover, representing the first step in a multimission Mars Sample Return campaign.} } - Edwards Jr., C. D., Asmar, S., Esterhuizen, S., Bruvold, K. N., Chamberlain, N. F., Gladden, R. E., Johnston, M. D., Kuperman, I., Mendoza, R., Potts, C. L., Wenkert, D., Denis, M., Schmitz, P., Wood, S., Bayle, O., Winton, A. and Montagna, M. (2017). NASA Relay Support to the ESA Schiaparelli Lander
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{edwardsjr2017nasa, title = {NASA Relay Support to the ESA Schiaparelli Lander}, author = {Edwards Jr., Charles D. and Asmar, Sami and Esterhuizen, Stephan and Bruvold, Kristoffer N. and Chamberlain, Neil F. and Gladden, Roy E. and Johnston, Martin D. and Kuperman, Igor and Mendoza, Ricardo and Potts, Christopher L. and Wenkert, Daniel and Denis, Michel and Schmitz, Peter and Wood, Simon and Bayle, Olivier and Winton, Alistair and Montagna, Mario}, booktitle = {IEEE Aerospace Conference}, publisher = {JPL Open Repository}, year = {2017}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/46397} } - Collins, R., Pashai, P., Young, E., Bennett, C., Laubach, S. and Thomas, S. (2019). MSL relay coordination and tactical planning in the era of InSight, MAVEN, and TGO
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{collins2019msl, title = {MSL relay coordination and tactical planning in the era of InSight, MAVEN, and TGO}, author = {Collins, Rachael and Pashai, Pegah and Young, Emma and Bennett, Chris and Laubach, Sharon and Thomas, Steven}, booktitle = {IEEE Aerospace Conference}, pages = {1-12}, publisher = {IEEE}, year = {2019}, doi = {10.1109/aero.2019.8741564} } - Sarkarati, M., Spada, M., Merri, M., Raymaekers, J. and Nergaard, K. (2014). METERON CCSDS MO Compliant Telerobotic Services Talk DTN
. SpaceOps Conference. Source
BibTeX
@inproceedings{sarkarati2014meteron, title = {METERON CCSDS MO Compliant Telerobotic Services Talk DTN}, author = {Sarkarati, Mehran and Spada, Mariella and Merri, Mario and Raymaekers, Jens and Nergaard, Kim}, booktitle = {SpaceOps Conference}, volume = {0}, year = {2014}, doi = {10.2514/6.2014-1871}, abstract = {Robotic systems are very diverse in their capabilities and characteristics. The software used for their monitoring and control is often custom developed and proprietary. When participating in a space exploration mission, the robotic system constitutes one important element of the overall mission infrastructure. Its operations become accordingly part of the overall mission operations and must be closely coordinated with other elements, such as ground communication networks, ground stations, relay satellites, orbiting spacecraft and in future scenarios manned orbiting stations around the target body. The monitoring and control (M&C) and planning systems of such complex space missions, expose often very different characteristics than the dedicated software systems used during the development, testing and validation of involved robotic elements on the ground. Collaborative mission operation scenarios, in which robotic agents of different space agencies must operate in close coordination, add more complexions to the design of M&C of such missions. The objective of the Multipurpose End-To-End Robotics Operations Network, in short METERON, project is to prepare for future robotic exploration missions by evaluating and demonstrating relevant concepts and technologies in the areas of Communications, Operations and Robotics. The task of integrating robotic elements, participating in METERON experiments, in the overall METERON operations and communications infrastructure can be optimised considerably, if the common robotic capabilities, relevant to mission operations, can be provided through standardised telerobotic service interfaces. The objective of the CCSDS Telerobotic working group, which has started its work in 2013, is to specify such standardised services, which shall abstract from the proprietary interfaces of each robotic system and from the adopted communication protocol. By the same token an initial set of harmonised Robotic Services have been specified for the METERON Operational Environment (MOE), which shall be used for the first time in the upcoming METERON OPSCOM-2 experiment in 2014. The design of the METERON Robotic Services has been based on the service oriented design principles of the CCSDS Mission Operations (MO) framework. METERON Robotic Services support multiple communication protocols including the DTN Bundle Protocol, since evaluation and demonstration of communication aspects related to Delay/Disruption Tolerant Network (DTN) are among main objectives of some of METERON experiments. METERON Robotic Services will be in the context of the OPSCOM-2 experiment the first in-orbit demonstration of the corresponding CCSDS MO monitoring and control services and can serve as proof of concept for the envisaged CCSDS Telerobotic services.} } - Gu, L., Yu, L., Li, W. and Zhao, K. (2020). A publish-subscribe networking architecture for future manned deep space exploration
. China Communications. Source
BibTeX
@article{gu2020publish, title = {A publish-subscribe networking architecture for future manned deep space exploration}, author = {Gu, Liuting and Yu, Lai and Li, Wenfeng and Zhao, Kanglian}, journal = {China Communications}, volume = {17}, pages = {38-51}, year = {2020}, doi = {10.23919/j.cc.2020.07.004}, abstract = {With the further development of the Deep Space Networking (DSN), more and more satellites and space probes will be put into space which makes the DSN more diverse and complex. We argued that Information Centric Networking (ICN) may be a suitable architecture for the DSN. In this paper, a publish-subscribe networking architecture based on ICN is proposed for future manned deep space exploration network. It adopts the publish-subscribe mechanism and decouples the control plane and data plane logically. In the proposed architecture, the improvement of routing is made to tolerant the long propagation delay and frequent link disruptions of deep space. And the multi-source transmission is considered to deal with the large amount of data in the future manned deep space exploration network. We evaluated the feasibility of the architecture and the performance of the protocol stack, the improved routing mechanism and the multi-source transmission. The results indicate that Publish-Subscribe Networking (PSN) can cope with the harsh transmission conditions, and the multi-source transmission can reduce the delivery time of data. It enables the network to allocate and share resources more efficiently and keeps the network well managed.} } - Woo, S. S., Veregge, J. R., Gao, J. L. and Clare, L. P. (2012). Software Modules for the Proximity-1 Space Link Interleaved Time Synchronization (PITS) Protocol
. NASA Jet Propulsion Laboratory, 20130009402. Source
BibTeX
@techreport{woo2012software, title = {Software Modules for the {Proximity-1} Space Link Interleaved Time Synchronization ({PITS}) Protocol}, author = {Woo, Simon S. and Veregge, John R. and Gao, Jay L. and Clare, Loren P.}, number = {20130009402}, institution = {NASA Jet Propulsion Laboratory}, type = {NASA Tech Briefs software item}, year = {2012}, url = {https://ntrs.nasa.gov/citations/20130009402}, abstract = {The Proximity-1 Space Link Interleaved Time Synchronization (PITS) protocol provides time distribution and synchronization services for space systems. A software prototype implementation of the PITS algorithm has been developed that also provides the test harness to evaluate the key functionalities of PITS with simulated data source and sink. PITS integrates time synchronization functionality into the link layer of the CCSDS Proximity-1 Space Link Protocol. The software prototype implements the network packet format, data structures, and transmit- and receive-timestamp function for a time server and a client. The software also simulates the transmit and receive-time stamp exchanges via UDP (User Datagram Protocol) socket between a time server and a time client, and produces relative time offsets and delay estimates.} } - Burleigh, S. C. (2011). Interplanetary Overlay Network Bundle Protocol Implementation
. NASA Jet Propulsion Laboratory, 20120000489. Source
BibTeX
@techreport{burleigh2011interplanetary, title = {{Interplanetary Overlay Network} Bundle Protocol Implementation}, author = {Burleigh, Scott C.}, number = {20120000489}, institution = {NASA Jet Propulsion Laboratory}, type = {NASA Tech Briefs software item}, year = {2011}, url = {https://ntrs.nasa.gov/citations/20120000489}, abstract = {The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.} }