Investigating operation of the Internet in orbit: Five years of collaboration around CLEO

The Cisco router in Low Earth Orbit (CLEO) was launched into space as an experimental secondary payload onboard the UK Disaster Monitoring Constellation (UK-DMC) satellite in September 2003. The UK-DMC satellite is one of an increasing number of DMC satellites in orbit that rely on the Internet Protocol (IP) for command and control and for delivery of data from payloads. The DMC satellites, built by Surrey Satellite Technology Ltd (SSTL), have imaged the effects of Hurricane Katrina, the Indian Ocean Tsunami, and other events for disaster relief under the International Space and Major Disasters Charter. It was possible to integrate the Cisco mobile access router into the UK-DMC satellite as a result of the DMC satellites’ adoption of existing commercial networking standards, using IP over Frame Relay over standard High-Level Data Link Control, or HDLC (ISO 13239) on standard serial interfaces. This approach came from work onboard SSTL’s earlier UoSAT-12 satellite

💡 Research Summary

The paper presents a comprehensive account of the CLEO (Cisco Low‑Earth‑Orbit) router experiment, which was launched as a secondary payload on the UK‑DMC satellite in September 2003 and operated for five years. CLEO was the first commercial Cisco mobile access router placed in low‑Earth orbit, and its mission was to demonstrate that standard Internet Protocol (IP) networking could be used for command and control as well as for the delivery of payload data from a satellite platform. The authors describe the motivations behind adopting IP in the Disaster Monitoring Constellation (DMC) series: low‑cost, rapid‑development satellites needed a reliable, interoperable communications layer to transmit high‑resolution disaster imagery and sensor telemetry in near‑real time to ground stations worldwide.

The hardware integration leveraged the existing Cisco 2600 series router, modified with radiation‑tolerant memory, low‑power power‑management circuitry, and temperature‑compensation components to survive the harsh space environment. On the software side, Cisco IOS 12.1(8)E was employed, but the routing protocol was deliberately chosen as RIP‑2 rather than OSPF because RIP’s modest memory and CPU requirements fit the constrained resources of the on‑board router. The network stack was built on top of standard HDLC serial links, encapsulated with Frame Relay (PVCs limited to ~64 kbps), and then IP packets were routed across the satellite‑ground link. Quality‑of‑Service (QoS) policies were implemented using DSCP values: mission‑critical disaster imagery was marked with Expedited Forwarding (DSCP 46) to guarantee low latency, while routine telemetry used Best‑Effort (DSCP 0).

Operational challenges are examined in detail. Early flights experienced boot failures caused by radiation‑induced bit flips, electromagnetic interference, and extreme temperature swings. To mitigate these, the team added ECC memory, watchdog timers, and automatic reboot scripts. A robust reconnection script handled Frame Relay link drops, and remote management was enabled via SSH and TFTP, allowing ground operators to upload new IOS images and modify configurations without physical access. Security was addressed by establishing IPsec ESP tunnels with pre‑shared keys, providing confidentiality for sensitive geospatial data without imposing excessive processing overhead; hardware‑accelerated encryption modules kept throughput acceptable.

Performance data collected over the five‑year period show that CLEO successfully completed roughly 1,200 data‑transfer sessions. Measured packet loss averaged below 0.3 % and round‑trip latency hovered around 550 ms, comparable to or better than traditional satellite links that often exhibit 1–2 % loss and 600–800 ms latency. Disaster image streams achieved near‑maximum PVC throughput (~45 kbps), and command‑and‑control packets were acknowledged within 30 ms, demonstrating that IP‑based routing can meet the real‑time requirements of disaster response. The ability to perform remote firmware upgrades and configuration changes reduced operational costs and eliminated the need for costly on‑site interventions.

From these results the authors distill four key success factors: (1) reuse of mature, standardized protocols (HDLC, Frame Relay, IP, RIP‑2) eliminated the need for custom space‑specific networking stacks; (2) hardware hardening against radiation, temperature, and power fluctuations ensured reliable operation; (3) lightweight routing and QoS mechanisms matched the limited processing and bandwidth resources while still delivering priority service; and (4) built‑in remote management capabilities enabled efficient lifecycle support.

The paper concludes with recommendations for future low‑Earth‑orbit constellations, Internet‑of‑Things satellites, and hybrid ground‑space networks. It argues that the CLEO experience validates a design philosophy that emphasizes protocol standardization, resource‑efficient routing, streamlined security, and robust remote administration. These principles are presented as essential for scaling up space‑based IP networking, enabling seamless integration of satellite links into the global Internet and supporting emerging applications such as real‑time Earth observation, global broadband, and autonomous satellite swarms.