SOSA - Khan BMS Battlefield Management System
Working notes on SOSA (Sensor Open Systems Architecture): cca protocols context, design trade-offs, and where it fits in the Arban–Tumen hierarchy.
Sensor Open Systems Architecture is normally documented in benign-link conditions. The interesting questions begin where the documentation stops: under jamming, under spoofing, under partial denial. That is the regime SOSA actually has to perform in.
SOSA earns its full keep at the Tumen — ten thousand nodes under a single human Khan. Span of control stays at ten because the hierarchy is fractal; SOSA state aggregates upward through Minghan and Zuun before it ever reaches the Khan's console.
Definitions first. SOSA = Sensor Open Systems Architecture. Tri-service hardware-and-software open standard for sensor and EW payload modules. SOSA is a Tri-Service consortium standard hosted by The Open Group that defines hardware form factors (largely VPX/OpenVPX), backplane profiles, software interfaces, and module classes for radar, EO/IR, SIGINT, and EW payloads. A SOSA-aligned line-replaceable module from one vendor is intended to drop into any SOSA chassis with minimal integration. SOSA is a foundational MOSA enabler and is increasingly required for sensor payloads on CCA, rotary-wing, and ISR platforms.
Khan BMS treats SOSA as a property of the formation, not a feature of the radio. Every node in a cca protocols stack publishes its SOSA state to its parent tier as a signed envelope; every parent reasons about SOSA the same way it reasons about fuel, ammunition or sensor coverage.
SOSA is one of perhaps a dozen primitives that decide whether a modern force can fight through denial. Khan BMS is built on the premise that all of them deserve the same treatment.