Why Static Routing Fails in QKD Networks
The standard network routing model assumes that if a link is available, it can carry traffic. Capacity may vary, latency may vary, but the fundamental link state is binary: up or down. QKD key delivery does not work this way. A satellite QKD link can be geometrically available, with the satellite above the horizon and the ground station pointed correctly, and still deliver zero key bits because of atmospheric conditions. A key buffer at a relay node may be full, making additional generation wasteful. The rate at which a given ground station pair can generate keys varies continuously with link quality, not in discrete steps.
Static routing rules, of the form "route key requests for destination X through node Y," fail in this environment for a straightforward reason: they cannot account for the current state of the system. A routing decision made at the time of key request needs to reflect which source currently has key material available at the required security level, what the delivery latency will be through each path, and whether the key buffer at the destination endpoint will be replenished by the time the current reserve is exhausted.
This is not an architectural choice we made because adaptive systems are theoretically appealing. It is a conclusion we reached after our first months of running a real multi-node pilot, where static scheduling resulted in uneven buffer depletion across nodes and predictable delivery failures during periods when the most heavily loaded satellite pass windows were degraded by monsoon cloud cover.
What the Routing Layer Needs to Know
An adaptive routing layer for a QKD network needs real-time state from several information sources that do not exist in classical network monitoring systems.
Orbital geometry is the first. A satellite is above the horizon and can serve a given ground station only during specific windows, typically 8 to 18 minutes for LEO depending on altitude and orbital inclination. The geometry is deterministic and calculable from TLE (two-line element) orbit data. The routing layer needs to maintain a running schedule of upcoming pass windows for each satellite-ground station pair, enabling it to pre-position key generation work and buffer key material in advance of predicted demand spikes.
Atmospheric conditions are the second. Free-space optical QKD link quality correlates with several atmospheric parameters: low-altitude aerosol loading (dust, urban haze), cloud cover fraction in the line of sight to the satellite, and precipitation intensity. We use numerical weather prediction data from public meteorological sources combined with real-time measurements of received photon count rate at the ground station to estimate current and near-term link quality for each ground station. When a pass window is predicted to have high cloud cover, the routing layer shifts key generation workload toward stations with cleaner skies and adjusts delivery planning accordingly.
Buffer state is the third. Each node in the network maintains a key buffer with a current fill level and a consumption rate driven by application demand. The routing layer monitors buffer levels across all nodes and triggers generation work on the appropriate satellite-ground station pairs to replenish the buffers most at risk of exhaustion. This is the QKD equivalent of dynamic capacity planning, operating on timescales of minutes to hours.
The Algorithm Design: Predictive Scheduling Under Uncertainty
The routing algorithm we run is not a neural network making black-box decisions. It is a predictive scheduling system with an explicit uncertainty model, which is the right architecture when the system must explain its decisions to network operations teams and when errors have operational consequences.
At each scheduling cycle, the system constructs a probability distribution over key delivery outcomes for each possible routing decision over the next 4 to 8 hours. The inputs are deterministic orbital geometry, probabilistic atmospheric forecasts, and the current buffer states. The scheduling problem is then framed as selecting the allocation of satellite pass capacity to maximize the probability that all nodes maintain buffer levels above their safety thresholds throughout the planning horizon.
This formulation handles uncertainty gracefully: a pass with high atmospheric uncertainty is weighted by its expected yield, not its theoretical maximum yield. If the forecast for a particular station is uncertain, the scheduler naturally distributes generation work across multiple stations rather than relying on the high-uncertainty pass.
We are not claiming this is a solved problem or that our implementation is mature. We have tested it against 14 months of pilot data and it outperforms static round-robin scheduling on every metric we measure: key delivery uptime, buffer exhaustion frequency, and capacity utilization efficiency. But the operational experience needed to tune the atmospheric model and validate the demand forecast inputs takes time to accumulate, and we are still learning from each month of production-like operation.
Integration with the Key Management Layer
The routing layer is not the key management layer. Key management, which handles key storage, access control, key lifecycle, and delivery to application endpoints, is a separate function. The routing layer tells the key management layer where and when to generate keys and how to distribute them across nodes. The key management layer handles the delivery to applications.
This separation matters for security review and certification. The routing layer manipulates scheduling metadata: orbital parameters, atmospheric data, buffer fill levels. It does not touch key material directly. This means its threat model is different from the key management layer. A compromise of the routing layer could cause suboptimal scheduling, denial-of-service through deliberate exhaustion of buffers, or routing manipulation that could facilitate traffic analysis. It cannot directly expose key material. Keeping these layers cleanly separated, with a defined API between them, is an architectural decision we enforce in our system design.
Where Classical Network Intelligence Ends
Classical network monitoring and management tools are built around assumptions that do not hold for QKD infrastructure. SNMP polling assumes link state is the primary variable. Capacity planning assumes predictable traffic patterns. SLA definitions assume that with sufficient bandwidth, delivery guarantees can be met.
QKD key delivery has a fundamentally different resource model. The key generation capacity is physically bounded by quantum optical constraints, not by bandwidth provisioning. The capacity varies continuously with atmospheric and geometric conditions rather than being a configurable parameter. Buffer management is central rather than incidental. An operator using standard network management tooling for a QKD deployment will have poor visibility into actual key delivery capacity and limited ability to diagnose or prevent buffer exhaustion events.
We built the routing and visibility layer we needed because no available tool addressed the QKD-specific operational variables. This is not an unusual situation for early infrastructure in a new technology category: the operations tooling trails the initial deployment capability by several years. It is worth flagging because organizations evaluating QKD deployments should plan for the operational tooling gap, not assume it is covered by existing network management infrastructure.
