A Modular Quantum Network Architecture for Integrating Network Scheduling with Local Program Execution

TL;DR

This work introduces a modular quantum network architecture that unifies network scheduling with end-node program execution by formalizing packets of entanglement and packet generation tasks. It provides a demand format and a central scheduler that jointly plans entanglement generation and local quantum program execution, accommodating both measure-directly and create-and-keep applications. The approach is demonstrated in a simulated 6-node star network, revealing that admission control and carefully chosen packet-generation parameters are critical to achieving minimal service for application sessions. The study highlights design considerations, discusses potential bottlenecks, and outlines future research directions in scheduling algorithms, adaptive-rate strategies, and end-to-end QoS guarantees for near-term quantum networks.

Abstract

We propose an architecture for scheduling network operations enabling the end-to-end generation of entanglement according to user demand. The main challenge solved by this architecture is to allow for the integration of a network schedule with the execution of quantum programs running on processing end nodes in order to realise quantum network applications. A key element of this architecture is the definition of an entanglement packet to meet application requirements on near-term quantum networks where the lifetimes of the qubits stored at the end nodes are limited. Our architecture is fully modular and hardware agnostic, and defines a framework for further research on specific components that can now be developed independently of each other. In order to evaluate our architecture, we realise a proof of concept implementation on a simulated 6-node network in a star topology. We show our architecture facilitates the execution of quantum network applications, and that robust admission control is required to maintain quality of service. Finally, we comment on potential bottlenecks in our architecture and provide suggestions for future improvements.

Figures (10)

• Figure 1: A general quantum network may be built from four kinds of devices: end nodes, metropolitan hubs, repeater chains, and junction nodes (see \ref{['subsubsec: DC - Network - Devices and Components']}). These devices may be connected in the manner illustrated. Circles $A$-$G$ represent user controlled end nodes, squares $M_i$ are metropolitan hubs and diamonds $J_i$ are junction nodes. Repeater chains are represented by zig-zag lines, while individual quantum repeater nodes are represented by triangles.
• Figure 2: Example of an entanglement generation protocol (heralded entanglement). Nodes $A$ and $B$ probabilistically send photons to a 'heralding station' located midway between them. This heralding station consists of (single) photon detectors and a beamsplitter. Depending on the pattern of photons detected, it is possible to determine if an elementary entangled link has been generated, and to subsequently inform the nodes. More details can be found in, e.g. theoryHeraldCCGZ.
• Figure 3: Flow of information through the stages of the architecture. The processes of 'Network Capability Update' and 'Capability Negotiation' allow the nodes to gather enough information to be able to submit a unified demand. These demands are then used to construct a central network schedule, which in turn is used when constructing the local node schedules.
• Figure 4: Example of the timings for computing, distributing and executing the $k$th network schedule (in colour and hatched). In grey and unhatched are the corresponding operations for preceding and subsequent network schedules. The process of registering received demands is continuous, however we indicate here the time during which if a demand is submitted, then it will be first considered for scheduler admission as part of computing the $k$th network schedule.
• Figure 5: Interaction Diagram for our proposed quantum network architecture. Elements in red are local software components. Single stroke arrows represent purely classical interactions and double-stroke arrows represent quantum interactions. The dotted arrows denote the corresponding interaction from the other end node. The QPS and CPS are the quantum processing system and classical processing system respectively. The application stack includes the application code, compiler and execution environment. The Network Capabilities Manager is an oracle which can be queried by end nodes to find out information about the network as part of the network capabilities update phase of the architecture (\ref{['ssec: Arch - NCU']}). The process of Scheduler Admission includes the demand queue. The Quantum Network Stack is that of dahlberg_link_2019. The ellipsis represents the quantum network. The labelled interactions are as follows: A: Network Capability Update; B: Capability Negotiation; C: Demand Registration; D: Session Initialisation; E: Network Schedule Distribution (note this goes to all components of the network); F: Input of network schedule into the local schedule; G: Execution of the schedule(s).

Theorems & Definitions (1)

• theorem 1