Distributed Quantum Systems
Design distributed quantum systems around entanglement lifecycles, repeaters, memory deadlines, routing, heralding, classical control, and realistic evidence.
What is a distributed quantum system?
A distributed quantum system connects quantum nodes with channels that can exchange qubits or establish entanglement, while ordinary computers coordinate the work. Its defining service is not a faster classical packet. It is a short-lived quantum resource, often an entangled pair, that an application can consume for teleportation, distributed operations, sensing, or cryptographic protocols.
In plain language, two kinds of machinery cooperate:
- Classical systems decide and coordinate. They discover topology, authenticate nodes, reserve memories, schedule attempts, carry heralding and measurement results, and report failure.
- Quantum hardware creates and consumes correlated states. Photons, stationary qubits, memories, detectors, local gates, and Bell-state measurements generate link pairs and extend them across a path.
A group of cloud-accessible quantum processors connected only by APIs is distributed orchestration around quantum hardware. It becomes a quantum network only when nodes can exchange qubits or distribute entangled states through a quantum channel.
Core invariant
An unknown quantum state cannot be copied for store-and-forward routing. A usable design must generate, identify, protect, extend, consume, and recreate entanglement before noise and time make it unusable. Every success is conditional on classical evidence.
Start with four resources, not a seven-layer analogy
Quantum networking is still an active research field. A beginner needs the physical constraints and lifecycle before a speculative protocol stack.
Consumable resource
Bell pair
Two qubits share an entangled state. The network delivers identifiers for the two halves so the endpoints know which local memories belong to the same pair. Using or measuring the pair consumes that resource.
Quality estimate
Fidelity
Fidelity compares the prepared state with a target state. A value near one is better, but it is not a generic success probability and cannot replace an application-specific quality contract.
Classical evidence
Heralding
A detector outcome and classical message announce that a generation attempt probably produced a usable pair. No herald means the nodes retry or abandon the reservation.
Expiring storage
Quantum memory
A node stores its half of a pair while other links finish. Environmental noise causes decoherence, so each stored state needs an age, quality estimate, and disposal deadline.
Why a repeater is not an amplifier
A classical repeater can detect, regenerate, and forward a copied signal. A quantum repeater cannot perfectly copy an unknown state. Instead it coordinates three operations:
- Elementary-link generation creates entanglement between neighboring nodes, often after many probabilistic attempts.
- Entanglement swapping performs a Bell-state measurement at an intermediate node. It consumes two adjacent pairs and can leave the outer nodes entangled.
- Purification or distillation consumes multiple lower-fidelity pairs to probabilistically produce fewer higher-fidelity pairs. The quality gain costs rate, memory, local operations, and classical round trips.
NIST's quantum memory and repeater overview emphasizes that no-cloning and measurement prevent a quantum repeater from using the same physical method as a classical repeater.
Separate global control from the pair lifecycle
The split is logical, not a claim that quantum operations happen without classical messages. The IRTF architecture distinguishes a largely classical control plane from a quantum data plane that also includes pair-granularity classical control information such as heralds.
Two cooperating planes
The classical controller establishes intent and resources. The entanglement plane executes a stateful, probabilistic lifecycle and returns evidence.
Classical control plane
Route and admit
Select a path using available memories, expected Bell-pair rate, fidelity, deadline, and administrative policy. Reject a request that the network cannot credibly satisfy.
Classical control plane
Reserve and signal
Bind a request ID to memories, communication qubits, time slots, controller identity, sequence numbers, and expiry. Send generation and swap commands.
Quantum entanglement plane
Generate and extend
Attempt elementary links, store successful halves, validate heralds, and consume adjacent pairs in swaps. Retry because loss and local operations are probabilistic.
Joint contract
Deliver or discard
Return pair IDs and quality evidence to the application, or expire and release every resource. A timeout is a normal outcome, not an impossible exception.
The pair lifecycle
1 Application contract
Request
Name endpoints, pair count, minimum fidelity, deadline, priority, and any synchronization requirement.
2 Elementary links
Generate and herald
Nodes repeat a physical protocol until detector evidence identifies a successful neighboring pair or the reservation expires.
3 Repeaters
Store, purify, and swap
Memories hold successful pairs while local operations improve quality or extend entanglement. Each operation consumes pairs and can fail.
4 Application boundary
Consume or dispose
The application uses the delivered pair once. Expired, misbound, low-fidelity, or unneeded pairs are explicitly discarded and their resources released.
The IRTF's RFC 9340 is an informational research-group architecture, not an Internet Standard. It is useful because it makes the entanglement lifecycle, classical signalling, control/data separation, memory limits, and routing constraints explicit without claiming that a production quantum internet already exists.
Lab 1: budget one end-to-end Bell pair
Change the link profile, number of elementary links, generation schedule, fidelity target, and purification choice. Watch the route trade pair yield against memory age and delivered quality.
Budget a Bell pair before the memory forgets it
Choose an illustrative link profile, repeater count, generation schedule, and purification policy. The model exposes how probability, fidelity, classical delay, and memory lifetime constrain one another.
Loading entanglement budget...
Read the model in the right order:
- Link generation is probabilistic. Requiring every link to succeed in one round multiplies their probabilities.
- Buffering changes the bottleneck. Keeping early successes raises yield, but the oldest pair waits while other links retry.
- Swapping extends distance by consuming pairs. Every intermediate operation adds a success and fidelity constraint.
- Decoherence turns time into quality loss. Memory lifetime is part of the route, not only a hardware detail.
- Purification trades quantity for quality. One modeled BBPSSW-style round consumes two candidate pairs and can discard both.
What this model does not prove
The lab uses independent identical links, Werner-state fidelity, exponential memory decay, and a simplified concurrent schedule. It exposes relationships; it does not predict a device. Hardware-specific conclusions require calibrated noise, detector, gate, memory, multiplexing, and classical-delay models.
Route for fidelity, rate, time, and current availability
A classical shortest-path metric is insufficient. A route with fewer hops may have low generation probability or too little memory. A longer route may have better elementary links and multiplexing, yet accumulate more swaps and cross more administrative boundaries.
A request should carry an explicit service contract
- endpoint identities and the intended application
- number and topology of entangled states required
- minimum delivered fidelity and how it will be estimated
- minimum Bell-pair rate or a completion deadline
- maximum acceptable jitter or a simultaneous-delivery window
- reservation priority, preemption rules, and cancellation behavior
- trust-domain, controller, and measurement-evidence requirements
The scheduler needs live resource state
- communication-qubit and memory occupancy at every candidate node
- elementary-link attempt rate, herald success, and detector health
- pair age, fidelity estimate, and expiry for each stored memory
- swap and purification success rates for the selected hardware
- classical round-trip latency and controller availability
- active reservations, contention, and fair-share or preemption policy
A link-state database that reports only physical connectivity can select an unusable path. The scarce resources are memories, communication qubits, time slots, and already-created pairs.
Lab 2: inject an orchestration failure
Select an application contract and route, then change the scheduling policy, failure, and classical control security. The lab shows why a physically possible path may still fail admission.
Admit the request only when the whole lifecycle is credible
Choose an application contract, route, scheduler, failure, and control-channel policy. The trace keeps classical orchestration separate from the quantum operations it coordinates.
Loading orchestration model...
Try these cases:
- Give a distributed gate burst the direct route. One link avoids swapping, but one pair slot cannot satisfy simultaneous demand.
- Inject memory pressure on the multiplexed detour. More capacity does not help when the oldest pair expires.
- Replay a stale herald with sender authentication but no freshness check. A valid signature does not bind old evidence to the current reservation.
- Forge a swap command with unsigned control messages. No-cloning remains true, but the attacker can misbind, consume, starve, or reorder scarce resources.
- Enable authenticated, freshness-bound control. The forged or stale command is rejected, which preserves integrity but still causes an availability failure that must be retried.
Treat security and observability as one lifecycle contract
Entanglement does not automatically secure the surrounding system. Quantum protocols may provide special security properties under explicit assumptions, but node identity, classical messages, software, detectors, timing, key management, and operations still need conventional controls.
Protect the classical control path
- authenticate controllers, repeaters, endpoints, and administrative domains
- authorize route, reservation, generation, swap, measurement, and disposal operations
- bind every command and herald to a request, reservation, pair, attempt, sequence, and expiry
- encrypt sensitive control metadata where traffic analysis or topology disclosure matters
- reject replays and stale evidence; do not treat an old signed message as current truth
- rate-limit reservation churn and generation commands to contain denial of service
Observe the quantum resource without pretending to inspect its full state
- count attempts, herald successes, timeouts, swaps, purification rounds, and explicit discards
- record pair age, memory occupancy, calibration version, and fidelity estimate with uncertainty
- correlate the application request through route admission, reservation, pair IDs, and terminal outcome
- alert on impossible state transitions, duplicate delivery, events after expiry, and controller-identity changes
- separate photon loss, detector faults, memory expiry, fidelity rejection, control-plane faults, and application cancellation
Tomography and benchmarking consume samples and cannot continuously reveal an arbitrary unknown state without disturbance. Production-style observability therefore combines classical lifecycle evidence, calibration, sampled experiments, and protocol-specific statistical tests.
Implement admission and evidence, not imaginary hardware APIs
The first example rejects requests that exceed current route capacity, fidelity, deadline, memory, or controller-integrity bounds. A real controller would use a protocol-specific scheduler and signed state distribution; the example only makes the contract visible.
The second example audits classical lifecycle events. It does not simulate or measure qubits. It detects cross-reservation mixing, duplicate delivery, expired-memory use, missing controller identity, and events after terminal disposal.
Keep protocol code behind hardware abstractions:
- physical models own photon loss, detector behavior, gates, memory noise, and timing
- link protocols own attempts, heralds, pair identifiers, and local quality evidence
- entanglement management owns swapping, purification, storage, and expiry
- resource management owns reservation and memory allocation
- network management owns route computation and signalling
- applications request a service contract and consume the delivered state
Use simulation to narrow experiments, not replace them
Explain one relationship
Analytical teaching model
Small equations reveal how independent success probabilities multiply or how waiting competes with memory lifetime. They intentionally omit hardware interactions and scheduling detail.
Compare protocols
Discrete-event simulation
Tools such as NetSquid and SeQUeNCe model events, memories, noise, classical delay, resource management, and application demand. Results are only as credible as their calibrated inputs and assumptions.
Validate the system
Hardware experiment
Testbeds expose coupling efficiency, phase stability, detector behavior, control latency, crosstalk, calibration drift, and integration failures that an abstract model can miss.
The peer-reviewed NetSquid paper and SeQUeNCe paper describe discrete-event approaches spanning hardware models, entanglement management, resource management, network management, and applications. Use more than one model when a result is sensitive to simulator assumptions.
Set expectations from demonstrated systems
The field has demonstrated important primitives, but they are not a general-purpose, interoperable, fault-tolerant quantum internet:
- A three-node solid-state network demonstrated remote entanglement, a memory qubit, local processing, and real-time classical feed-forward.
- A later three-node experiment used entanglement swapping and memory protection to teleport a qubit between non-neighboring nodes.
- An experimental link-layer stack abstracted physical attempts into an entanglement-delivery service for two remote solid-state nodes.
- A 2026 two-node experiment demonstrated an unconditionally teleported gate between remote solid-state registers over a short optical connection. Here, "unconditional" describes protocol execution after an input is supplied; it is not a security claim. The result is a testbed capability, not an Internet-scale service.
- QKD networks and remote access to standalone quantum computers are real engineering categories, but neither alone proves repeater-based end-to-end entanglement among general quantum processors.
A realistic readiness ladder
- Today: model assumptions, reproduce a published primitive, and build classical orchestration around a small testbed or simulator.
- Near-term research: improve interfaces, multiplexing, memories, link generation, repeaters, calibration, benchmarking, and multi-node scheduling.
- Not yet a safe production assumption: arbitrary long-distance entanglement on demand, heterogeneous interoperable routers, fault-tolerant distributed computation, or mature Internet-scale operations.
The architecture should make progress measurable without turning a laboratory milestone into a deployment promise.
Primary and peer-reviewed references
- IRTF RFC 9340: Architectural Principles for a Quantum Internet
- NIST: Quantum Memory and Repeaters
- Wehner, Elkouss, and Hanson: Quantum internet roadmap
- Pompili et al.: Realization of a multinode quantum network
- Hermans et al.: Teleportation between non-neighboring nodes
- Dahlberg et al.: Experimental entanglement delivery using a network stack
- Coopmans et al.: NetSquid discrete-event simulation
- Wu et al.: SeQUeNCe quantum-network simulator
- Iuliano et al.: Teleported gates between remote solid-state registers
Read experimental rates, fidelity, and distance together with hardware platform, confidence intervals, memory behavior, and protocol conditions. Values from one testbed should not be copied into an unrelated architecture estimate.