Quantum Network Operations Centers — Operating Quantum Computers

A quantum network operations center, or QNOC, is not just a classical NOC with different equipment names. Entanglement networks add resources such as shared quantum states, probabilistic entanglement generation, and quantum-memory decoherence. They also impose new constraints on concerns already present in classical optical networks, including synchronization, photon loss, detector behavior, routing, and monitoring.

DOE's quantum internet blueprint frames long-distance entanglement and national-scale quantum networking as a strategic research direction, and NIST's quantum networking work covers characterization and validation of quantum communications technologies. These sources are research-facing, but they point toward an operating model: quantum networks will need continuous monitoring, routing, synchronization, link management, and incident response. [R157] [R158]

Diagram loads as you read

Quantum Network Operations Centers · Figure 1

View diagram source

flowchart LR
    NodeA[Quantum node A] --> LinkAB[Entanglement link]
    LinkAB --> NodeB[Quantum node B]
    NodeB --> LinkBC[Entanglement link]
    LinkBC --> NodeC[Quantum node C]
    QNOC[QNOC] --> NodeA
    QNOC --> NodeB
    QNOC --> NodeC

QNOC responsibilities

Diagram loads as you read

QNOC responsibilities · Figure 2

View diagram source

mindmap
  root((QNOC))
    Link health
      loss
      fidelity
      detector state
    Timing
      synchronization
      clock drift
    Routing
      entanglement paths
      swapping plans
    Operations
      incidents
      maintenance
      change windows
    Evidence
      link logs
      calibration
      experiment packages

The QNOC should not only ask, “Is the link up?” It should ask, “Can this link support the requested entanglement service at the required fidelity and time?”

Entanglement as an operational resource

Diagram loads as you read

Entanglement as an operational resource · Figure 3

View diagram source

flowchart TB
    Request[Entanglement request] --> Route[Choose route]
    Route --> Generate[Generate local entanglement]
    Generate --> Swap[Entanglement swapping]
    Swap --> Verify[Check estimated quality and heralding]
    Tests[Sampled test rounds and link model] --> Verify
    Verify --> Deliver[Deliver unmeasured resource pairs]
    Verify --> Retry[Retry or reroute]

Unknown quantum states cannot be freely copied, and stored entanglement has a finite usable lifetime. Generate and, where supported, store or swap entanglement, then consume or discard it. Estimate link quality from sampled test pairs and a validated model; the sampled pairs are consumed by measurement. Heralding signals a protocol event, not an exact fidelity certificate for each unmeasured pair.

Link SLOs

SLO	Meaning
entanglement generation rate	usable pairs per unit time
fidelity distribution	quality of generated entanglement
heralding success rate	probability of successful event notification
memory lifetime	usable storage interval
synchronization error	timing mismatch across nodes
detector availability	ability to observe required events

Diagram loads as you read

Link SLOs · Figure 4

View diagram source

xychart-beta
    title "Example entanglement generation rate"
    x-axis [00, 04, 08, 12, 16, 20]
    y-axis "pairs/min" 0 --> 100
    line [62, 65, 41, 38, 70, 68]

A rate drop may be caused by optical alignment, weather for free-space links, detector drift, clock synchronization, firmware, or classical control-plane issues.

Routing constraints

Diagram loads as you read

Routing constraints · Figure 5

View diagram source

flowchart LR
    A[A] --> B[B]
    B --> C[C]
    A --> D[D]
    D --> C
    B --> E[E]
    E --> C

A route is not merely shortest path. It must consider:

link fidelity;
generation probability;
memory availability;
swapping success probability;
synchronization;
node policy;
experiment priority;
maintenance windows.

Diagram loads as you read

Routing constraints · Figure 6

View diagram source

flowchart TB
    CandidateRoutes[Candidate routes] --> Score[Score routes]
    Score --> Fidelity[Fidelity]
    Score --> Rate[Rate]
    Score --> Memory[Memory time]
    Score --> Policy[Policy]
    Score --> Cost[Cost and opportunity]
    Score --> Select[Select route]

QNOC telemetry model

Diagram loads as you read

QNOC telemetry model · Figure 7

View diagram source

erDiagram
    NETWORK_NODE ||--o{ LINK : terminates
    LINK ||--o{ LINK_HEALTH : emits
    LINK ||--o{ ENTANGLEMENT_ATTEMPT : records
    ENTANGLEMENT_ATTEMPT ||--o{ HERALD_EVENT : has
    NETWORK_NODE ||--o{ CLOCK_STATE : reports
    ROUTE ||--o{ ROUTE_SEGMENT : contains

Minimum telemetry:

node identity and role;
link identity;
detector state;
photon source state;
optical path status;
clock source;
synchronization error;
attempt rate;
heralding events;
fidelity estimates;
classical control latency;
environmental data.

Incident response

Diagram loads as you read

Incident response · Figure 8

View diagram source

stateDiagram-v2
    [*] --> Normal
    Normal --> DegradedLink
    DegradedLink --> Reroute
    Reroute --> Normal
    DegradedLink --> Maintenance
    Maintenance --> Requalify
    Requalify --> Normal
    Normal --> Partitioned
    Partitioned --> RestoreClassical
    RestoreClassical --> Requalify

Incident classes:

Incident	Likely action
link fidelity regression	reroute, recalibrate, inspect optics
detector outage	drain link, switch standby, open hardware case
clock sync error	stop timing-sensitive service, requalify sync
classical control outage	pause service, preserve local logs
memory decoherence regression	restrict route lengths
policy violation	isolate project, preserve audit logs

Change windows

Quantum network changes can invalidate active experiments.

Diagram loads as you read

Change windows · Figure 9

View diagram source

sequenceDiagram
    participant QNOC
    participant Users
    participant Policy
    participant LinkActor as Link
    QNOC->>Users: announce maintenance window
    QNOC->>Policy: block new sensitive requests
    QNOC->>LinkActor: apply change
    LinkActor-->>QNOC: telemetry and validation
    QNOC->>Policy: reopen with updated profile
    QNOC->>Users: publish evidence note

The QNOC must maintain link profiles just as a quantum computing platform maintains target profiles.

Service classes

Diagram loads as you read

Service classes · Figure 10

View diagram source

flowchart TB
    Service[Quantum network service] --> Research[Research experiment]
    Service --> Key[Key distribution support]
    Service --> DistributedCompute[Distributed compute experiment]
    Service --> Sensor[Distributed sensing]
    Service --> Calibration[Link characterization]

Different service classes have different requirements. A characterization run may tolerate many failures. A distributed-sensing run may require strict timing. A key-distribution support workflow may emphasize security evidence.

QNOC dashboard

Diagram loads as you read

QNOC dashboard · Figure 11

View diagram source

flowchart LR
    Links[Link map] --> Dashboard[QNOC dashboard]
    Fidelity[Fidelity trends] --> Dashboard
    Timing[Timing state] --> Dashboard
    Incidents[Incidents] --> Dashboard
    Reservations[Reservations] --> Dashboard
    Dashboard --> Decisions[Route, drain, maintain, requalify]

Dashboards should separate:

physical-layer health;
quantum-service health;
classical control health;
policy and tenant health;
evidence completeness.

Validation after repair

Diagram loads as you read

Validation after repair · Figure 12

View diagram source

flowchart LR
    Repair[Repair] --> LinkTest[Link characterization]
    LinkTest --> EntTest[Entanglement test]
    EntTest --> RouteTest[Route test]
    RouteTest --> ServiceTest[Service-class probe]
    ServiceTest --> Reopen[Reopen service]

A repaired link should not automatically rejoin production routes. It must requalify.

The QNOC is the operating bridge between physics and network service. It must be staffed, tooled, and governed accordingly.

Additional technical sources: [R268].