Quantum Networking and Entanglement Operations

Quantum networking is not classical packet switching with a different payload. The core resource is distributed quantum correlation. That resource is probabilistic, fragile, and consumed by use.

The IRTF Quantum Internet Research Group's architectural RFC frames the quantum internet as a network whose stack must be designed around entanglement and quantum-state constraints, not around copying classical payloads [R65]. For operators, the immediate lesson is practical: links, heralding, memory lifetime, synchronization, and trust boundaries become first-class production objects.

36.1 What a quantum link provides

flowchart LR
    NodeA[Quantum node A] --> Source[Entanglement source]
    Source --> Channel[Optical or microwave channel]
    Channel --> NodeB[Quantum node B]
    Source --> Herald[Heralding detector]
    Herald --> Control[Classical control plane]
    Control --> NodeA
    Control --> NodeB

A useful quantum link does not simply move data. It attempts to create shared states between endpoints and provides classical metadata about whether the attempt succeeded.

36.2 Entanglement is expiring inventory

Entangled pairs are not durable inventory. They are created probabilistically, degrade over time, and are consumed by use. Treating them as ordinary queue entries hides the core operating constraint.

stateDiagram-v2
    [*] --> Requested
    Requested --> Attempting
    Attempting --> Available: herald success
    Attempting --> Failed: herald failure
    Available --> Allocated: scheduler reserves pair
    Available --> Expired: memory timeout
    Allocated --> Consumed: operation uses pair
    Failed --> [*]
    Expired --> [*]
    Consumed --> [*]

Inventory metrics:

36.3 The scheduler must coordinate two planes

A quantum network scheduler has to coordinate the quantum plane and the classical coordination plane. The classical messages do not carry the quantum state, but they determine whether the quantum state is usable.

flowchart TB
    Workload[Distributed workload] --> Need[Entanglement requirement]
    Need --> QuantumPlane[Quantum plane schedule]
    Need --> ClassicalPlane[Classical control schedule]
    QuantumPlane --> Attempts[Generation attempts]
    ClassicalPlane --> Heralds[Heralding and acknowledgments]
    Attempts --> Inventory[Entanglement inventory]
    Heralds --> Inventory
    Inventory --> Run[Run distributed operation]

Admission should consider pair fidelity, memory age, route availability, classical latency, and whether the workload can tolerate retry behavior.

36.4 Repeaters and swapping create operational depth

Extending entanglement through a chain of quantum repeaters uses intermediate operations such as entanglement swapping. Each repeater hop introduces physical failure modes and timing constraints. Direct fiber or free-space distribution is also possible; its useful range depends on loss and the chosen architecture. [R65]

flowchart LR
    A[Node A] --> R1[Repeater 1]
    R1 --> R2[Repeater 2]
    R2 --> B[Node B]
    A -. classical coordination .-> B
    R1 -. heralding .-> Control[Network controller]
    R2 -. heralding .-> Control

Route record:

entanglement_route:
  route_id: string
  endpoints: [node_a, node_b]
  repeaters: [node_r1, node_r2]
  target_fidelity: float
  max_pair_age_ms: float
  expected_attempts: int
  classical_coordination_budget_ms: float
  fallback_route: string | null

The route is an experiment artifact. Without route provenance, a distributed quantum result cannot be reproduced or interpreted.

36.5 QKD is not a general quantum network

Quantum key distribution is an important quantum-communications use case, but it should not be confused with a general-purpose quantum internet. ETSI's QKD work focuses on interoperability, interfaces, implementation safety, and integration of QKD systems into communication networks [R67]. That is a narrower service than distributing arbitrary entanglement for computation.

flowchart TB
    QuantumComms[Quantum communications] --> QKD[QKD key service]
    QuantumComms --> EntNet[Entanglement network]
    QuantumComms --> Clock[Clock and timing transfer]
    QKD --> Keys[Symmetric key material]
    EntNet --> DistributedCompute[Distributed quantum operations]

Operator distinction:

36.6 Application scenarios shape the network

The QIRG application-scenarios RFC distinguishes use cases such as secure communications, clock synchronization, distributed quantum computation, and sensor networks [R66]. These use cases do not need the same network.

flowchart LR
    UseCase[Application scenario] --> Service[Network service contract]
    Service --> Metrics[Relevant metrics]
    Metrics --> Architecture[Architecture choice]
    Architecture --> Ops[Operational model]

Example mapping:

36.7 Failure modes

flowchart TB
    Failure[Network failure] --> Loss[Photon or transduction loss]
    Failure --> Drift[Timing drift]
    Failure --> Herald[False or missed herald]
    Failure --> Memory[Memory decoherence]
    Failure --> Route[Route exhaustion]
    Failure --> Trust[Trust boundary violation]

Default responses:

36.8 Operational checklist

A production quantum-network claim should include:

• route topology,
• link attempt rates,
• heralding statistics,
• pair fidelity distribution,
• memory lifetime distribution,
• synchronization error,
• classical coordination latency,
• endpoint trust model,
• key or entanglement inventory policy,
• failure and reroute runbooks.

flowchart LR
    Link[Link metrics] --> Evidence[Network evidence package]
    Route[Route provenance] --> Evidence
    Trust[Trust model] --> Evidence
    Runbook[Failure runbooks] --> Evidence
    Evidence --> Service[Quantum-network service]