A vendor-neutral protocol for safer space operations
Space is getting crowded. Over 10,000 active satellites orbit Earth today, with tens of thousands more planned. Every conjunction—a close approach between two objects—requires operators to assess collision risk and potentially maneuver to avoid disaster.
The problem: Today's space traffic coordination is fragmented.
- Operators rely on different data sources with varying quality
- No standard protocol for sharing collision warnings
- Manual processes slow down critical decisions
- Proprietary systems create vendor lock-in
- International coordination lacks technical infrastructure
When Iridium-33 and Cosmos-2251 collided in 2009, it created over 2,000 trackable debris pieces. Each piece is a new collision risk. The Kessler syndrome—a cascade of collisions making orbits unusable—is not science fiction. It's a growing operational concern.
SpaceComms is a neutral, open protocol for space traffic coordination.
Think of it like BGP (Border Gateway Protocol) for the internet—the technology that lets different networks share routing information without a central authority. SpaceComms does the same for space:
Instead of routing internet traffic, SpaceComms routes collision warnings and satellite positions between operators, providers, and regulators.
Day 1: Operators connect their systems to SpaceComms
↓
Each operator becomes a "node" in the network
↓
Day 2: A conjunction is detected between Satellite A and Debris B
↓
The detecting system announces it via SpaceComms
↓
All connected nodes automatically receive the warning
↓
Operator of Satellite A sees the alert immediately
↓
Operator plans a maneuver and shares intent via SpaceComms
↓
Other operators know to expect the new trajectory
- Automated propagation of conjunction warnings
- Seconds instead of hours to reach all stakeholders
- No manual email chains or phone trees
- Open specification anyone can implement
- No single company controls the protocol
- Interoperates with existing infrastructure
- Built on CCSDS CDM format (the international standard)
- Compatible with TraCSS recommendations
- Ready for future ISO/UN standardization
- One integration instead of many point-to-point connections
- Clear message formats reduce interpretation errors
- Audit trails built into the protocol
- Handles thousands of objects and operators
- Designed for mega-constellation era
- Extensible for new message types
Situation: A company operates 500 satellites and needs to monitor conjunction risks and coordinate with other operators.
With SpaceComms:
- Connect operations center to SpaceComms network
- Automatically receive CDMs for owned satellites
- Share maneuver intent before execution
- Receive acknowledgments from affected parties
Situation: An STM provider (like SDA, TraCSS, or commercial) wants to distribute collision warnings to customers.
With SpaceComms:
- Integrate CDM generation pipeline with SpaceComms
- Announce CDMs to all peered operators
- Receive maneuver intents for improved predictions
- Offer premium routing policies to subscribers
Situation: A national space agency needs visibility into conjunction activity and operator responses.
With SpaceComms:
- Peer with major operators and providers
- Receive all CDMs in standard format
- Monitor maneuver coordination
- Generate compliance reports
Situation: ESA, NASA, JAXA, and other agencies need to share data about high-risk events without complex bilateral agreements.
With SpaceComms:
- Each agency runs a SpaceComms node
- Technical protocol handles interoperability
- Policy decisions remain with each agency
- No central authority required
┌──────────────────────────────────────────────────────────────────┐
│ SpaceComms Network │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ CDM_ANNOUNCE ┌─────────────┐ │
│ │ SDA/STM │ ────────────────────────────►│ Operator A │ │
│ │ Provider │◄────── MANEUVER_INTENT ──────│ (Starlink) │ │
│ └─────────────┘ └─────────────┘ │
│ │ │ │
│ │ CDM_ANNOUNCE │ │
│ ▼ │ │
│ ┌─────────────┐ │ │
│ │ Operator B │◄──────── CDM_ANNOUNCE ─────────────┘ │
│ │ (OneWeb) │ │
│ └─────────────┘ │
│ │ │
│ │ MANEUVER_STATUS │
│ ▼ │
│ ┌─────────────┐ │
│ │ Regulator │ (observes all traffic) │
│ │ (FAA) │ │
│ └─────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘
No. SpaceComms complements existing services. It provides the "plumbing" for sharing data between systems. Providers like 18th Space Defense Squadron, SDA, and commercial providers can use SpaceComms as a distribution mechanism.
No single entity. Like the internet, SpaceComms is a protocol, not a service. Anyone can run a node and peer with others. Governance could evolve through standards bodies (ISO, CCSDS) or industry consortia.
SpaceComms is designed for unclassified, shareable data. Operators determine what they share. The protocol includes security hooks for authentication and encryption, but does not dictate data classification policies.
SpaceComms uses CCSDS CDM format as its core data structure. It aligns with TraCSS recommendations for transparency fields. It could become an input to future ISO TC20/SC14 standardization.
This reference implementation demonstrates protocol viability. Production deployment would require:
- Pilot programs with willing operators (6-12 months)
- Security hardening and certification (12-18 months)
- Industry adoption and standardization (18-36 months)
| Operators | Review Architecture, evaluate integration path | | Regulators | Review Regulatory Compliance | | Developers | Try the Demo, explore Interop Guide | | Executives | Share with technical teams for feasibility assessment |
SpaceComms is an open-source initiative with transparent governance.
- Implement Your Own: We provide a full Interop Guide for building compatible nodes in any language.
- Influence Standards: Join the Governance Process to propose protocol changes.
For questions about SpaceComms adoption or partnership opportunities, contact the project maintainers through the repository issue tracker.