Scheduling Module

Two-level scheduler

Network level

The Controller has a global scheduler to handle network-wide (global) non-real-time functions such as quantum network topology discovery, quantum network monitoring, and quantum link calibration etc. The controller also handles user requests on an event-driven basis. When serving a user request, the controller performs alternating cycles between calibration and operational mode.

Node level

Each Agent implements a node with dedicated real-time control system. Each node has a local scheduler to handle node-wide (local) real-time functions that have tight time constraints, such as qubit control and quantum protocol implementation etc.

User request handling

Figure 1. User request handling in two-level scheduler

When a user requests an QN request, controller orchestrate the request handling in following order.

1. The controller performs a request analysis. The request is admitted only if its requirement can be fulfilled.

2. If the request is admitted, the controller proceeds to call a routingroutine to select a path to establish entanglement.

3. The controller matches and assigns functions required for remote entanglement generation for each node along the path. We assume a singlefunction is required at each node, which are func_ion_photon_entanglement at Q-node A, func_BSM at BSM-node, and func_ion_photon_entanglement at Q-node B, respectively. The control framework has full knowledge of these functions, which are well-characterized and pre-configured.

4. The controller reaches out to Q-node A, BSM-node, and Q-node B for the time-slot allocation status of their local schedulers.

5. Q-node A, BSM-node, and Q-node B all reply with their local schedules.

6. The controller proceeds to call the network-wide scheduler to allocate common free time-slots for func_ion_photon_entanglement at Q-node A, func_BSM at BSM-node, and func_ion_photon_entanglement at Q-node B, such that these functions can be scheduled simultaneously at time T1. Afterwards, the controller updates Q-node A, BSM-node, and Q-node B with the newly assigned time-slots.

7. Q-node A, BSM-node, and Q-node B accept and confirm the newly assigned time-slots.

8. At time T1, the local schedulers run func_ion_photon_entanglement at Q-node A, func_BSM at BSM-node, and func_ion_photon_entanglement at Q-node B, respectively.

Calibration handling

Figure 2. Dependency handling using a DAG

When an Agent starts, its node-level scheduler manages local calibration tasks as defined in the agent’s configuration file. This ensures that real-time devices remain calibrated and ready for incoming tasks. To manage these calibration tasks, the agent reads the task section of its configuration file:

Example:

[tasks]
[[light_calibration]]
path=dummy_lsrc_calibration.py

[[light_calibration2]]
path=dummy_lsrc_calibration.py

[[cavity_calibration]]
path=dummy_cavity_calibration.py

With the task definitions, it performs the following steps:

1. Each constructs a Directed Acyclic Graph (DAG) with an empty root node, based on the local calibration definitions from the configuration file. This DAG is used to track task dependencies. Each non-root node represents a calibration task, while the edges between nodes represent dependencies. Tasks with no dependencies are connected directly to the root node via an edge.

2. The DAG is traversed using a Breadth-First Search (BFS) algorithm, and tasks are scheduled in the agent’s local schedule in the order they are encountered.

3. Initially, the state of all nodes is set to OUT_OF_SPEC. The DAG is periodically traversed using BFS to check the state of each node. If a calibration task is valid (i.e., it was performed correctly within the specified interval), the node’s state is updated to IN_SPEC. If a calibration task becomes invalid, the task and all its predecessors are set to OUT_OF_SPEC.

4. If the root node’s state changes between IN_SPEC and OUT_OF_SPEC, the agent sends a monitoring message to the controller to report the status change.

Controller-side request dispatch

The controller distinguishes between experiment and calibration requests, routing each through a dedicated execution path with its own protocol and schema. Parameters are structured and typed before being forwarded to agents, ensuring consistent handling regardless of request type. Errors during allocation or result retrieval are reported with the identity of the specific agent involved.