Design and demonstration of an operating system for executing applications on quantum network nodes

TL;DR

This work introduces QNodeOS, the first hardware-independent operating system designed to execute quantum network applications on quantum processors by separating classical and quantum processing into CNPU and QNPU with a hardware-abstracted QDevice interface. The architecture enables platform-agnostic programming (via NetQASM) and supports multitasking across multiple quantum and classical programs, including a network-schedule-informed entanglement workflow. Demonstrations on two NV-node pairs validate delegated quantum computation with fidelities surpassing the classical bound, and multitasking experiments show improved device utilization without compromising quantum performance; an NV-based setup achieves a memory coherence time of $T_{ ext{coh}}=13(2)$ ms, with entangled-state fidelity around $F_{ ext{ent}}=0.72(2)$ and end-to-end latencies near $4.8$ ms on average. The outlook highlights integrating CNPU and QNPU on a single board to reduce latency and identifies future directions in real-time scheduling, compilation, and entanglement-aware programming languages to broaden practical quantum network deployment.

Abstract

The goal of future quantum networks is to enable new internet applications that are impossible to achieve using solely classical communication. Up to now, demonstrations of quantum network applications and functionalities on quantum processors have been performed in ad-hoc software that was specific to the experimental setup, programmed to perform one single task (the application experiment) directly into low-level control devices using expertise in experimental physics. Here, we report on the design and implementation of the first architecture capable of executing quantum network applications on quantum processors in platform-independent high-level software. We demonstrate the architecture's capability to execute applications in high-level software, by implementing it as a quantum network operating system -- QNodeOS -- and executing test programs including a delegated computation from a client to a server on two quantum network nodes based on nitrogen-vacancy (NV) centers in diamond. We show how our architecture allows us to maximize the use of quantum network hardware, by multitasking different applications on a quantum network for the first time. Our architecture can be used to execute programs on any quantum processor platform corresponding to our system model, which we illustrate by demonstrating an additional driver for QNodeOS for a trapped-ion quantum network node based on a single $^{40}\text{Ca}^+$ atom. Our architecture lays the groundwork for computer science research in the domain of quantum network programming, and paves the way for the development of software that can bring quantum network technology to society.

Figures (29)

• Figure 1: Application Paradigm. A quantum networking application consists of multiple programs, each running on one of the end nodes dahlberg_2022_netqasm The distinct programs can only interact via (1) quantum communication (e.g. entanglement generation) and (2) classical communication. This allows a programmer to realize security-sensitive applications, but prohibits a global orchestration of the quantum execution, like one might do in (distributed) quantum computing caleffi_distributed_2022 in which a single quantum program is executed on multiple nodes. Programs are written in high-level quantum hardware independent software, and executed on a quantum hardware independent system (our architecture) that controls a hardware dependent system (QDevice, \ref{['fig:fig2']}) such as a nitrogen-vacancy (NV) center node with a diamond chip (photo taken by authors, left images) or a trapped-ion quantum node teller2023integrating (right images). These platforms constitute physically very different QDevice systems, but can both be programmed by our architecture.
• Figure 2: QNodeOS architecture.(a) QNodeOS consists of a Classical Network Processing Unit (CNPU) and a Quantum Network Processing Unit (QNPU, classical system). QNodeOS controls a QDevice (quantum hardware and low-level classical control). (b) Schematic of our implementation of QNodeOS on a two-node setup where both QDevices control a single qubit in a diamond nitrogen-vacancy (NV) center. The CNPU is implemented on a general-purpose PC, and the QNPU on an embedded system, connected via Gigabit Ethernet (blue). The QNPU connects to its QDevice via a serial peripheral interface (SPI, pink). The two QNPUs (brown), and the two CNPUS (green) connect to each other via Gigabit Ethernet. The setup is based on pompili_2022_experimental with two QDevices (including arbitrary waveform generators (AWG) and microcontroller units (MCU); QDevices communicating over a classical DIO interface) and a heralding station composed by a balanced 50:50 beam-splitter (whose output ports are connected to superconducting nanowire single-photon detectors (SNSPD) via optical fibers (red)), a TimeTagger (TT), and a CPLD that heralds the entanglement generation between QDevices and sends a classical message to the MCU.
• Figure 3: Delegated computation between two NV center nodes using QNodeOS.(a) Delegated Quantum Computation (DQC) circuit (effective computation: single-qubit rotation $R_Z (\alpha)$, \ref{['sec:methods']}). The DQC application consists of $k$ repetitions of this circuit (varying measurement bases for tomography on $\ket{\psi}$) realized by two programs: the DQC-client program (client node, repeating the sequence "quantum block (C1, orange) – classical block (computing $\delta$)" $k$ times), and the DQC-server program (server node, repeating "quantum block (S1, blue) - classical block (receiving $\delta$) – quantum block (S2, purple)" $k$ times). Client and server produce an entangled pair $\ket{\Phi^+} = (\ket{00} + \ket{11}) / \sqrt{2}$ (S1 and first part of C1). The client performs local gates and a measurement ("destroying" qubit), resulting in outcome bit $m_c$ (rest of C1). Client computes $\delta$ as function of $m_c$ and DQC parameters $\alpha \in [0,2\pi)$ and $\theta \in [0, 2\pi)$, and sends $\delta$ to server (classical message). Meanwhile the server keeps its qubit coherent (alive). Upon receiving $\delta$, the server applies gates depending on $\delta$, resulting in single-qubit state $\ket{\psi}$ (S2) depending only on $\alpha$ and $\theta$. (b) Experimental results of executing DQC for 6 different sets of $(\alpha, \theta)$ parameters ($k=1200$, i.e. 7200 executions of the circuit of \ref{['fig:fig3']}a). The fidelity of the resulting server state to the target state $\ket{\psi}$ is estimated using single-qubit tomography (1200 measurement results per data point), and corrected for known tomography errors (SSRO, blue), and post-selected for Charge-Resonance (CR) check validation (purple), and post-selected for latencies (orange) (\ref{['sec:methods']}). (c) Sequence diagram including the interaction CNPU-QNPU-QDevice for one execution of the DQC circuit of \ref{['fig:fig3']}a on QNodeOS (repeated $k=1200$ times in each experiment) (time flows to the right; not to scale). CNPUs prepare NetQASM subroutines (C1, S1, S2), and send them to their respective QNPUs. CNPUs also do classical computation (computing $\delta$) and communication (message containing $\delta$). QNPUs execute subroutines, sending physical instructions to their QDevices. Entanglement is generated by QDevices doing a batch of attempts, resulting in the heralding of a two-qubit entangled state (Bell pair) rotated to $\ket{\Phi^+}$ by the server. (d) Processing times and latencies while server qubit is live (time frame red line 3c, averaged over all 7200 circuit executions except executions with latency spikes, see \ref{['sec:methods']}), including CNPU-QNPU communication latencies, CNPU processing on both nodes and client-server communication latency (CC) (average total of $\sim 4.8 (\pm 0.8)$ ms, error bars for the sum of individual segments (variance per segment in \ref{['sec:processing_time_latencies']}).
• Figure 4: Multitasking experiment on two NV centers with QNodeOS. (a) Local Gate Tomography (LGT) Circuit. A single NetQASM subroutine (L1) executes the following 6 times for different bases $B \in \{\pm X, \pm Y, \pm Z\}$: initialize qubit to $\ket{0}$, rotate around fixed axis $D \in \{X,Y\}$ by angle $\ket{\phi}$, measure in $B$. The LGT application consists of a single LGT program, which submits subroutine L1 for execution to the QNPU (fixed $D$ and $\phi$) $k$ times in succession. (b) Example sequence diagram illustrating concurrent execution (multitasking) of the DQC application (\ref{['fig:fig3']}) and the LGT program on the client: time slice in which two DQC circuit repetitions (\ref{['fig:fig3']}a) are realized (2 subroutines on the client (orange), 4 on the server (blue and purple)), and three LGT circuit repetitions (3 subroutines, green). The client QNPU receives subroutines for both the DQC program and the LGT program, which the QNPU scheduler can interleave: While the server executes S2 (purple), the client cannot yet execute the next S1 (orange) since it involves joint entanglement generation. In this idle time, the client can execute a number of LGT subroutines (number can vary). (c) Results of multitasking LGT (client) and DQC (on both server and client). For each input pair $(D, \phi) \in \{ (X,0), (X,\pi), (Y,pi/2), (Y,-\pi/2), (X,-\pi/2), (X,\pi/2) \}$ (6 cardinal states $\{\pm X, \pm Y, \pm Z\}$), the following experiment was performed: simultaneously (1) a single LGT program was initiated on the client ($k=1000$), (2) a single DQC-client program was initiated on the client ($k=200$ successive subroutines), and (3) a single DQC-server program was initiated at the server ($k=200$, i.e. 400 successive subroutines). This resulted in a total of 6000 LGT subroutine executions and 36000 LGT measurement results, yielding plotted fidelity estimates for the LGT quantum state before measurement. Results are the same as running LGT on its own (no multitasking with DQC), as expected (\ref{['sec:multitasking-tomography']}). (d) Scaling number of programs on the client. For $N \in \{1,2,3,4,5\}$, we initiate at the same time: (1) $N$ LGT programs (each using $k=100$) on the client, (2) N DQC-client programs on the client (each using $k=60$), and (3) $N$ DQC-server programs on the server (each using $k=60$). This results in $2N$ programs active at the same time on the client, each continuously submitting subroutines from the CNPU to the QNPU, where the QNPU scheduler chooses which process to execute when. Each experiment was repeated but with multitasking disabled on the client. Plot shows the utilization factor of the QDevice (fraction of time spent executing instructions), corrected for variable entanglement generation duration (\ref{['sec:methods']}), with (blue) and without (orange) multitasking, showing that multitasking can increase device utilization.
• Figure 5: Trapped-ion QDevice implementation. Schematic of our implementation of QNodeOS on a single-node setup in which the QDevice contains a single trapped-ion qubit. The QNPU QDriver is implemented on a field-programmable gate array (FPGA) that connects to its QDevice via a serial peripheral interface (SPI) (\ref{['sec:methods']}). The setup consists of an emulator that translates between SPI messages and TTL signals, experimental control hardware that includes an FPGA and direct digital synthesis (DDS) modules, a trapped-ion qubit teller2023integrating under ultra-high vacuum (\ref{['fig:fig1']}), and a photomultiplier tube (PMT) that registers atomic fluorescence.