A Link Layer Protocol for Quantum Networks
Axel Dahlberg, Matthew Skrzypczyk, Tim Coopmans, Leon Wubben, Filip, Rozp\k{e}dek, Matteo Pompili, Arian Stolk, Przemys{\l}aw Pawe{\l}czak, Robert, Knegjens, Julio de Oliveira Filho, Ronald Hanson, Stephanie Wehner

TL;DR
This paper introduces the first link layer protocol for quantum networks, transforming experimental quantum entanglement setups into a scalable, robust, and platform-independent quantum internet system with validated simulations and performance analysis.
Contribution
It proposes a novel quantum network link layer protocol, validated through simulations and hardware data, enabling scalable and robust quantum internet infrastructure.
Findings
Protocol is robust against classical message losses
Validated physical and simulation models with NV hardware
Analyzed tradeoffs between throughput and entanglement quality
Abstract
Quantum communication brings radically new capabilities that are provably impossible to attain in any classical network. Here, we take the first step from a physics experiment to a fully fledged quantum internet system. We propose a functional allocation of a quantum network stack and construct the first physical and link layer protocols that turn ad-hoc physics experiments producing heralded entanglement between quantum processors into a well-defined and robust service. This lays the groundwork for designing and implementing scalable control and application protocols in platform-independent software. To design our protocol, we identify use cases, as well as fundamental and technological design considerations of quantum network hardware, illustrated by considering the state-of-the-art quantum processor platform available to us (Nitrogen-Vacancy (NV) centers in diamond). Using a purpose…
| T (1/s) | NL | CK | MD |
|---|---|---|---|
| (i) FCFS | 0.146 (0.003) | 0.144 (0.003) | 2.464 (0.056) |
| (i) WFQ | 0.154 (0.003) | 0.156 (0.003) | 2.130 (0.063) |
| (ii) FCFS | - | 0.086 (0.003) | 5.912 (0.033) |
| (ii) WFQ | - | 0.096 (0.003) | 5.829 (0.049) |
| Usage pattern | NL | CK | MD |
|---|---|---|---|
| Uniform | , | , | , |
| MoreNL | , | , | , |
| MoreCK | , | , | , |
| MoreMD | , | , | , |
| NoNLMoreCK | , | , | , |
| NoNLMoreMD | , | , | , |
| Scenario | Throughput_NL (1/s) | Throughput_CK (1/s) | Throughput_MD (1/s) |
|---|---|---|---|
| Lab_MoreCK_FCFS | 0.976 | 4.126 | 1.187 |
| Lab_MoreCK_HigherWFQ | 1.046 | 3.719 | 1.408 |
| Lab_MoreMD_FCFS | 1.025 | 0.905 | 4.771 |
| Lab_MoreMD_HigherWFQ | 0.981 | 1.058 | 4.659 |
| Lab_MoreNL_FCFS | 3.975 | 0.950 | 1.375 |
| Lab_MoreNL_HigherWFQ | 4.447 | 0.986 | 1.117 |
| Lab_NoNLMoreCK_FCFS | - | 4.696 | 1.366 |
| Lab_NoNLMoreCK_HigherWFQ | - | 5.101 | 0.916 |
| Lab_NoNLMoreMD_FCFS | - | 1.044 | 4.600 |
| Lab_NoNLMoreMD_HigherWFQ | - | 1.300 | 5.408 |
| Lab_Uniform_FCFS | 2.066 | 2.035 | 2.170 |
| Lab_Uniform_HigherWFQ | 2.210 | 2.186 | 1.908 |
| QL2020_MoreCK_FCFS | 0.064 | 0.302 | 1.398 |
| QL2020_MoreCK_HigherWFQ | 0.078 | 0.329 | 1.146 |
| QL2020_MoreMD_FCFS | 0.075 | 0.078 | 4.139 |
| QL2020_MoreMD_HigherWFQ | 0.066 | 0.073 | 4.793 |
| QL2020_MoreNL_FCFS | 0.312 | 0.066 | 1.667 |
| QL2020_MoreNL_HigherWFQ | 0.292 | 0.084 | 1.374 |
| QL2020_NoNLMoreCK_FCFS | - | 0.355 | 1.480 |
| QL2020_NoNLMoreCK_HigherWFQ | - | 0.374 | 1.180 |
| QL2020_NoNLMoreMD_FCFS | - | 0.084 | 6.756 |
| QL2020_NoNLMoreMD_HigherWFQ | - | 0.091 | 5.036 |
| QL2020_Uniform_FCFS | 0.175 | 0.143 | 2.538 |
| QL2020_Uniform_HigherWFQ | 0.154 | 0.166 | 2.483 |
| Scenario | SL_NL (s) | SL_CK (s) | SL_MD (s) | RL_NL (s) | RL_CK (s) | RL_MD (s) |
|---|---|---|---|---|---|---|
| Lab_MoreCK_FCFS | 40.18 (0.90) | 41.09 (0.42) | 19.64 (5.52) | 55.50 (0.30) | 55.58 (0.14) | 55.11 (2.83) |
| Lab_MoreCK_HigherWFQ | 0.30 (0.01) | 25.63 (0.61) | 24.95 (15.20) | 0.46 (0.02) | 33.88 (0.66) | 264.28 (35.75) |
| Lab_MoreMD_FCFS | 40.25 (1.15) | 41.70 (1.28) | 13.87 (2.91) | 55.63 (1.00) | 57.24 (1.00) | 62.55 (2.43) |
| Lab_MoreMD_HigherWFQ | 0.23 (0.01) | 2.09 (0.29) | 27.53 (6.00) | 0.36 (0.02) | 2.65 (0.35) | 129.30 (3.51) |
| Lab_MoreNL_FCFS | 45.59 (0.47) | 46.44 (0.95) | 14.70 (4.65) | 60.36 (0.21) | 60.59 (0.42) | 61.80 (2.76) |
| Lab_MoreNL_HigherWFQ | 0.69 (0.02) | 83.79 (2.64) | 98.34 (46.15) | 0.97 (0.02) | 114.89 (2.57) | 299.28 (37.25) |
| Lab_NoNLMoreCK_FCFS | - | 13.05 (0.27) | 3.55 (1.36) | - | 17.58 (0.30) | 23.04 (3.21) |
| Lab_NoNLMoreCK_HigherWFQ | - | 6.70 (0.16) | 26.14 (9.05) | - | 9.04 (0.19) | 76.02 (12.51) |
| Lab_NoNLMoreMD_FCFS | - | 23.45 (1.65) | 10.97 (2.51) | - | 30.86 (1.94) | 39.33 (4.09) |
| Lab_NoNLMoreMD_HigherWFQ | - | 2.26 (0.31) | 44.33 (11.92) | - | 3.34 (0.43) | 204.78 (9.54) |
| Lab_Uniform_FCFS | 11.41 (0.27) | 11.46 (0.27) | 12.38 (0.26) | 11.41 (0.27) | 11.46 (0.27) | 12.38 (0.26) |
| Lab_Uniform_HigherWFQ | 0.35 (0.01) | 0.73 (0.02) | 61.19 (0.97) | 0.35 (0.01) | 0.73 (0.02) | 61.19 (0.97) |
| QL2020_MoreCK_FCFS | 40.65 (4.43) | 37.46 (1.93) | 12.22 (3.82) | 52.20 (5.21) | 51.34 (2.33) | 43.41 (5.79) |
| QL2020_MoreCK_HigherWFQ | 4.11 (0.24) | 26.66 (0.95) | 76.29 (16.50) | 5.72 (0.34) | 35.91 (1.05) | 238.09 (21.00) |
| QL2020_MoreMD_FCFS | 25.45 (3.03) | 28.34 (3.01) | 9.30 (1.63) | 32.94 (3.43) | 38.90 (3.65) | 37.97 (2.67) |
| QL2020_MoreMD_HigherWFQ | 2.62 (0.42) | 3.04 (0.42) | 14.44 (1.92) | 3.79 (0.60) | 4.51 (0.62) | 47.64 (2.75) |
| QL2020_MoreNL_FCFS | 65.92 (1.93) | 64.05 (4.18) | 26.16 (5.84) | 89.83 (1.79) | 85.99 (3.70) | 85.98 (5.24) |
| QL2020_MoreNL_HigherWFQ | 7.04 (0.35) | 45.87 (3.73) | 50.55 (12.63) | 9.78 (0.41) | 59.92 (4.15) | 236.03 (21.62) |
| QL2020_NoNLMoreCK_FCFS | - | 15.98 (0.64) | 4.63 (0.87) | - | 21.90 (0.72) | 21.27 (1.63) |
| QL2020_NoNLMoreCK_HigherWFQ | - | 39.31 (1.64) | 70.64 (16.03) | - | 55.94 (1.93) | 277.08 (19.97) |
| QL2020_NoNLMoreMD_FCFS | - | 60.12 (6.95) | 22.28 (4.04) | - | 102.23 (4.17) | 104.88 (2.69) |
| QL2020_NoNLMoreMD_HigherWFQ | - | 3.01 (0.35) | 6.21 (1.58) | - | 5.18 (0.70) | 38.91 (4.89) |
| QL2020_Uniform_FCFS | 49.13 (1.29) | 50.85 (1.38) | 47.39 (0.33) | 49.13 (1.29) | 50.85 (1.38) | 47.39 (0.33) |
| QL2020_Uniform_HigherWFQ | 4.16 (0.26) | 8.22 (0.58) | 34.39 (0.61) | 4.16 (0.26) | 8.22 (0.58) | 34.39 (0.61) |
| Max Rel. Diff. Fid. | Max Rel. Diff. Throughp. | Max Rel. Diff. Laten. | Max Rel. Diff. Nr pairs | |
|---|---|---|---|---|
| 0.005 | 0.027 | 0.629 | 0.026 | |
| 0.004 | 0.012 | 0.469 | 0.008 | |
| 0.016 | 0.037 | 0.332 | 0.047 | |
| 0.040 | 0.026 | 0.576 | 0.020 | |
| 0.007 | 0.023 | 0.623 | 0.020 | |
| 0.004 | 0.026 | 0.338 | 0.021 | |
| 0.018 | 0.075 | 0.742 | 0.077 |
| (Unsquared) fidelity | Duration/time | Experimentally realized | |
| Electron | - | ms | h(Abobeih et al., 2018) |
| Electron | - | ms | s(Abobeih et al., 2018) |
| Carbon | - | m (C. E. Bradley, tion) | |
| Carbon | - | ms | ms (C. E. Bradley, tion) |
| Electron single-qubit gate | ns | (100 ns) (Kalb et al., 2017) | |
| E-C controlled--gate (E=control) | s | (500-1000 s) fig 2 in (Kalb et al., 2017) | |
| Carbon Rot--gate | s | (20 s) (Taminiau et al., 2014) | |
| Electron initialization in | s | (2 s) (Reiserer et al., 2016) | |
| Carbon initialization in | s | (300 s) (Cramer et al., 2016b) | |
| Electron readout | (), () | s | (), () (3-10 s) (Humphreys et al., 2018) |
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Code & Models
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
A Link Layer Protocol for Quantum Networks
Axel Dahlberg1,2, Matthew Skrzypczyk1,2, Tim Coopmans1,2, Leon Wubben1,2, Filip Rozpędek1,2, Matteo Pompili1,2, Arian Stolk1,2, Przemysław Pawełczak1, Robert Knegjens1, Julio de Oliveira Filho1, Ronald Hanson1,2, Stephanie Wehner1,2
1QuTech, Delft University of Technology and TNO2628 CJ
2Kavli Institute of Nanoscience, Delft University of Technology2600 CJ
Abstract.
Quantum communication brings radically new capabilities that are provably impossible to attain in any classical network. Here, we take the first step from a physics experiment to a fully fledged quantum internet system. We propose a functional allocation of a quantum network stack and construct the first physical and link layer protocols that turn ad-hoc physics experiments producing heralded entanglement between quantum processors into a well-defined and robust service. This lays the groundwork for designing and implementing scalable control and application protocols in platform-independent software. To design our protocol, we identify use cases, as well as fundamental and technological design considerations of quantum network hardware, illustrated by considering the state-of-the-art quantum processor platform available to us (Nitrogen-Vacancy (NV) centers in diamond). Using a purpose built discrete-event simulator for quantum networks, we examine the robustness and performance of our protocol using extensive simulations on a supercomputing cluster. We perform a full implementation of our protocol, where we successfully validate the physical simulation model against data gathered from the NV hardware. We first observe that our protocol is robust even in a regime of exaggerated losses of classical control messages with only little impact on the performance of the system.We proceed to study the performance of our protocols for 169 distinct simulation scenarios, including tradeoffs between traditional performance metrics such as throughput and the quality of entanglement. Finally, we initiate the study of quantum network scheduling strategies to optimize protocol performance for different use cases.
††copyright: none††doi: ††isbn: ††price:
1. Introduction
Quantum communication enables the transmission of quantum bits (qubits) in order to achieve novel capabilities that are provably impossible using classical communication. As with any radically new technology, it is hard to predict all uses of a future Quantum Internet (Wehner et al., 2018; Kimble, 2008), but several major applications have already been identified depending on
the stage of quantum network development (Wehner et al., 2018), ranging from cryptography (Bennett and Brassard, 1984; Ekert, 1991), sensing and metrology (Gottesman et al., 2012; Komar et al., 2014), distributed systems (Ben-Or and Hassidim, 2005; Denchev and Pandurangan, 2008), to secure quantum cloud computing (Broadbent et al., 2009; Fitzsimons and Kashefi, 2017).
Qubits are fundamentally different from classical bits, which brings significant challenges both to the physical implementation of quantum networks, as well as the design of quantum network architectures. Qubits cannot be copied, ruling out signal amplification or repetition to overcome transmission losses to bridge great distances. Two qubits can share a special relation known as entanglement, even if these two qubits are stored at distant network nodes. Such entanglement is central not only to enable novel applications, but also provides a means to realize a quantum repeater, which enables quantum communication over long-distances (Figure 1).
At present, short-lived entanglement has been produced probabilistically over short distances (km) on the ground by sending photons over standard telecom fiber (see e.g. (Dynes et al., 2009; Inagaki et al., 2013)), as well as from space over 1203km from a satellite (Yin et al., 2017). Such systems can allow the realization of applications in the prepare-and-measure stage (Wehner et al., 2018) of quantum networks on point-to-point links, but cannot by themselves be concatenated to allow the transmission of qubits over longer distances.
In order to enable long-distance quantum communication and the execution of complex quantum applications, we would like to produce long-lived entanglement between two quantum nodes that are capable of storing and manipulating qubits. To do so efficiently (Section 3.1), we need to confirm entanglement generation by performing heralded entanglement generation. This means that there is a heralding signal that tells us if we have been successful in an attempt to generate entanglement.
The current world distance record for producing such entanglement is 1.3km, which has been achieved using a solid state platform known as Nitrogen-Vacancy (NV) centres in diamond (Hensen et al., 2015). Intuitively, this platform is a few qubit (as of now maximum (C. E. Bradley, tion)) quantum computer capable of arbitrary quantum gates, with an optical interface for initialization, measurement and entanglement generation. Key capabilities of the NV platform have already been demonstrated, including qubit lifetimes of s (Abobeih et al., 2018), entanglement production faster than it is lost (Humphreys et al., 2018), and using entanglement to teleport qubits between separated NV centres (Pfaff et al., 2014). Other hardware platforms exist that are identical on an abstract level (quantum computer with an optical interface), and on which heralded long-lived entanglement generation has been demonstrated (e.g. Ion Traps (Moehring et al., 2007), and Neutral Atoms (Hofmann et al., 2012)). Theoretical proposals and early stage demonstrations of individual components also exists for other physical platforms (e.g. quantum dots (Delteil et al., 2016), rare earth ion-doped crystals (Valivarthi et al., 2016), atomic gases (Julsgaard et al., 2001; Chou et al., 2005), and superconducting qubits (Narla et al., 2016)), but their performance is not yet good enough to generate entanglement faster than it is lost.
Up to now, the generation of long-lived entanglement has been the domain of highly sophisticated, but arguably ad-hoc physics experiments. We are now on the verge of seeing early stage quantum networks becoming a reality, entering a new phase of development which will require a joint effort across physics, computer science and engineering to overcome the many challenges in scaling such networks. In this paper, we take the first step from a physics experiment to a fully-fledged quantum communication system.
Design considerations and use cases: We identify general design considerations for quantum networks based on fundamental properties of entanglement, and technological limitations of near-term quantum hardware, illustrated with the example of our NV platform. For the first time, we identify systematic use cases, and employ them to guide the design of our stack and protocols.
Functional allocation quantum network stack: We propose a functional allocation of a quantum network stack, and define the service desired from its link layer to satisfy use case requirements and design considerations. In analogy to classical networking, the link layer is responsible for producing entanglement between two nodes that share a direct physical connection (e.g. optical fiber).
First physical and link layer entanglement generation protocols: We proceed to construct the world’s first physical and link layer protocols that turn ad-hoc physics experiments producing heralded entanglement into a well defined service. This lays the groundwork for designing and implementing control and application protocols in platform independent software in order to build and scale quantum networks. At the physical layer, we focus primarily on the quantum hardware available to us (NV platform) but the same protocol could be realized directly using Ion Traps or Neutral Atoms, as well as —with small changes— other means of producing physical entanglement (Sangouard et al., 2011). Our link layer protocol takes into account the intricacies of the NV platform, but is in itself already platform independent.
Simulation validated against quantum hardware: Using a purpose built discrete-event simulator for quantum networks, we examine the robustness and performance of our protocol using more than 169 scenarios totaling 94244h wall time and 707h simulated time on a supercomputing cluster. To this end, we perform a complete implementation of our protocols and let them use simulated quantum hardware and communication links. To illustrate their performance, we consider two concrete short and long-distance scenarios based on the NV platform: (1) Lab where the nodes and are 2m apart. Since this setup has already been realized, we can use it to compare the performance of the entanglement generation implemented on real quantum hardware against the simulation to validate its physical model, and (2) a planned implementation of QL2020 where and are in two European cities separated by km over telecom fiber. Next, to investigate trade-offs between traditional performance metrics (e.g. throughput or latency) and genuinely quantum ones (fidelity, Section 4.2), we take a first step in examining different quantum network scheduling strategies to optimize performance for different use cases.
2. Related Work
At present there is no quantum network stack connected to quantum hardware, no link layer protocols have been defined to produce entanglement, and no quantum networks capable of end-to-end qubit transmission or entanglement production have been realized (see (Wehner et al., 2018) and references therein).
A functional allocation of a stack for quantum repeaters and protocols controlling entanglement distillation (a procedure to increase the quality of entanglement) has been outlined in (Meter and Touch, 2013; Meter, 2012; Van Meter et al., 2009; Aparicio et al., 2011), which is complementary to this work. This is very useful to ultimately realize entanglement distillation, even though no concrete control protocols or connection to a hardware system were yet given. We remark that here we do not draw layers from specific protocols like entanglement distillation, but focus on the service that these layers should provide (a layer protocol may of course choose distillation as a mean to realize requirements). An outline of a quantum network stack was also put forward in (Pirker and Dür, 2018), including an appealing high level quantum information theory protocol transforming multi-partite entanglement. However, this high level protocol does not yet consider failure modes, hardware imperfections, nor the requirements on entanglement generation protocols and the impact of classical control. Plans to realize the physical layer of a quantum network from a systems view were put forward in (Lloyd et al., 2004), however development has taken a different route.
In the domain of single-use point-to-point links for quantum key distribution (QKD), software has been developed for trusted repeater networks (Wehner et al., 2018) to make use of such key in e.g. VoIP (Liu et al., 2013). However, these do not allow end-to-end transmission of qubits or generation of entanglement, and rely on trust in the intermediary nodes who can eavesdrop on the communication. Control using software defined networks (SDN) to assist trusted repeater nodes has been proposed, e.g. (Yu et al., 2018; Rarity et al., 2017). These QKD-centric protocols however do not address control problems in true quantum networks aimed at end-to-end delivery of qubits, and the generation of long-lived entanglement.
In contrast, classical networking knows a vast literature on designing and analyzing network protocols. Some ideas can indeed be borrowed from classical networking such as scheduling methods, but fundamental properties of quantum entanglement (Section A.2), as well as technological considerations of quantum hardware capabilities (Section 4.5) call for new protocols and methods of network control and management. Naturally, there is a continuous flow of systems papers proposing new networking architectures, e.g. for SDN (Bremler-Barr et al., 2016), data center networks (Handley et al., 2017), content delivery networks (Chen et al., 2015) or cloud computing (Zheng et al., 2015), to name a few. Yet, we are unaware of any system-level papers proposing a quantum network stack including protocols for concrete hardware implementations.
3. Design Considerations for Quantum Network Architectures
We first discuss design considerations of quantum networks themselves, followed by considerations specific to the physical and link layer (Section 4). These can be roughly subdivided into three categories: (i) fundamental considerations due to quantum entanglement, (ii) technological limitations of near-term quantum hardware, and (iii) requirements of quantum protocols themselves.
3.1. Qubits and Entanglement
We focus on properties of entanglement as relevant for usage and control (see Appendix and (Nielsen and Chuang, 2010)). Teleportation (Bennett et al., 1993) allows entanglement to be used to send qubits (see Figure 1). We will hence also call two entangled qubits an entangled link or entangled pair. Teleportation consumes the entangled link, and requires two additional classical bits to be transmitted per qubit teleported. Already at the level of qubit transmission we hence observe the need for a close integration between a quantum and classical communications. Specifically, we will need to match quantum data stored in quantum devices, with classical control information that is sent over a separate physical medium, akin to optical control plane architectures for classical optical networks (Strand et al., 2001). To create long-distance entanglement, we can first attempt to produce short-distance entangled links, and then connect them to form longer distance ones (Briegel et al., 1998; Munro et al., 2015) via an operation known as entanglement swapping (see Figure 1). This procedure can be used iteratively to create entanglement along long chains, where we remark that the swapping operations can in principle be performed in parallel. From a resource perspective, we note that to store entanglement, both nodes need to store one qubit per entangled link. Proposals for enabling quantum communication by forward communication using quantum error correction also exist, which avoid entanglement swapping (Munro et al., 2012). However, these have arguably much more stringent requirements in terms of hardware, putting them in a technologically more distant future: they require the ability to create entangled states consisting of a large number of photons (only realized today (Gao et al., 2010)) and densely placed repeater stations performing near perfect operations (Muralidharan et al., 2014).
Producing heralded entanglement does however allow long-distance quantum communication without the need to create entanglement consisting of many qubits. Here, the heralding signal (see Figure 3) provides a confirmation that an entanglement generation attempt has succeeded. Such heralding allows long-distance quantum communication without exponential overheads (Briegel et al., 1998), and without the need for more complex resources (Barrett and Kok, 2005; Cabrillo et al., 1999). Creating long-distance links between two controllable nodes by means of entanglement swapping (Section 3.2), and executing complex applications requires both nodes to know the state of their entangled links (which qubits belong to which entangled link, and who holds the other qubit of the entangled pair). As illustrated in Figure 1, remote nodes ("" in the figure) can change the state of such entangled links ("" and "" in the figure). Entanglement is an inherently connected element at the lowest physical level, whereas classical communications deal with unidirectional forward communication that abstracts the notion of a connection between a sender and receiver. In order to make use of entanglement for a quantum network special devices capable of producing entanglement and manipulating local qubits are required.
3.2. Quantum Network Devices
We focus on a high level summary of devices in a quantum network without delving into detailed physics (for more details, see (Wehner et al., 2018; Awschalom et al., 2018; Sangouard et al., 2011) and Section 4.4). Qubits can be sent optically through standard optical fiber using a variety of possible encodings, such as polarization (Bennett and Brassard, 1984; Mattle et al., 1996), time-bin (Brendel et al., 1999), or absence and presence of a photon (Cabrillo et al., 1999). Such qubits can be emitted from the devices in quantum nodes (Bernien et al., 2013; Blinov et al., 2004; Ritter et al., 2012), but in principle also transferred (Nemoto et al., 2016; Ritter et al., 2012; Kalb et al., 2015) from optical fiber into the node’s local quantum memory. Present day quantum memories have very limited lifetimes, making it highly desirable to avoid the exchange of additional control information before the entanglement can be used.
We distinguish two classes of quantum nodes. One, which we will call a controllable quantum node, offers the possibility to perform controllable quantum operations as well as storing qubits. Specifically, these nodes enable decision making, e.g. which nodes to connect by entanglement swapping. Such nodes can act as quantum repeaters and decision making routers in the network (e.g. NV platform or other quantum memories combined with auxiliary optics), and — if they support the execution of gates and measurements — function as end nodes (Wehner et al., 2018) on which we run applications (e.g. NV centre in diamond or Ion Traps). Others, which we call automated quantum nodes, are typically only timing controlled, i.e. they perform the same preprogrammed action in each time step. Such nodes also support quantum operations and measurements, but only those necessary to perform their preprogrammed tasks. The latter is still very useful, for example, to establish entanglement along a chain of quantum repeaters performing the entanglement swapping operations (Briegel et al., 1998; Munro et al., 2015) (see again Figure 1). In Section 4.4 we give a concrete example of such a timing controlled node.
3.3. Use Cases
We distinguish four use cases of a quantum network: one related to producing long-distance entanglement, and three that come from application demands. Since no quantum network has been realized to date, we cannot gain insights from actual usage behavior. Instead we must resort to properties of application protocols known today. We desire flexibility to serve all use cases, including supporting multiple applications at the same time.
Measure Directly (MD) Use Case: The first application use case comes from application protocols that produce many () pairs of entangled qubits sequentially, where both qubits are immediately measured to produce classical correlations. As such, no quantum memory is needed to store the entanglement and it is not necessary to produce all entangled pairs at the same time. It follows that applications making use of this use case may tolerate fluctuating delays in entanglement generation. Additionally, it is not essential to deliver error free correlations obtained from entanglement to the application. Such applications will thus already anticipate error fluctuation across the many pairs. This contrasts with classical networking where errors are often corrected before the application layer. Examples of such applications are QKD (Ekert, 1991), secure identification (Damgård et al., 2007) and other two-party cryptographic protocols (Chailloux and Kerenidis, 2011; Aharonov et al., 2000; Damgård et al., 2008; Wehner et al., 2008; Ribeiro and Grosshans, 2015) at the prepare-and-measure network stage (Wehner et al., 2018), and device-independent protocols at the entanglement network stage (Wehner et al., 2018).
Create and Keep (CK) Use Case: The second application use case stems from protocols that require genuine entanglement, possibly even multiple entangled pairs to exist simultaneously. Here, we may wish to perform joint operations on multiple qubits, and perform quantum gates that depend on back and forth communication between two nodes while keeping the qubits in local quantum storage. While more applications can be realized with more qubits, this use case differs substantially in that we want to create relatively few (even just one) pairs, but want to store this entanglement. Since we typically want these pairs to be available at the same time, and memory lifetimes are short, we want to avoid delay between producing consecutive pairs, which is superficially similar to constraints in real time classical traffic. Also for CK, many applications can perform well with noisy entangled links and the amount of noise forms a performance metric (Section 4.2). Examples of such protocols lie in the domain of sensing (Gottesman et al., 2012), metrology (Komar et al., 2014), and distributed systems (Ben-Or and Hassidim, 2005; Denchev and Pandurangan, 2008) which lie in the quantum memory network stage and beyond (Wehner et al., 2018).
Send Qubit (SQ) Use Case: While many application protocols known to date consume entanglement itself, some — such as distributed quantum computing applications — ask for the transmission of (unknown) qubits. This can be realized using teleportation over any distance as long as entanglement is confirmed between the sender and the receiver. For the link layer, this does not differ from CK, where we want to produce one entangled pair per qubit to be sent.
*Network Layer (NL) Use Case: * In analogy to the classical notion of a link layer, we take the link layer to refer to producing entanglement between neighboring nodes (see Section 3.4). The network layer will be responsible for producing entanglement between more distant ones. While usage behavior of quantum networks is unknown, it is expected (due to technological limitations) that routing decisions, i.e. how to form long-distance links from pairwise links, will not be entirely dynamic. One potential approach would be to first determine a path, and reserve it for some amount of time such that pairwise entanglement can be produced. Producing pairwise entanglement concurrently enables simultaneous entanglement swapping along the entire path with minimal delay to combat limited memory lifetimes. For this, the network layer needs to be capable of prioritizing entanglement production between neighboring nodes.
3.4. Network Stack
Based on these considerations, we propose an initial functional allocation of a quantum network stack (see Figure 2). In analogy to classical networking, we refer to the lowest element of the stack as the physical layer. This layer is realized by the actual quantum hardware devices and physical connections such as fibers. We take the physical layer to contain no decision making elements (comparable to e.g. ISP path tunneling architectures (Peter et al., 2014)) and keep no state about the production of entanglement (or the transmissions of qubits). The hardware at the physical layer is responsible for timing synchronization and other synchronization, such as laser phase stabilization (Humphreys et al., 2018), required to make attempts to produce heralded entanglement (Section 4.4). A typical realization of the physical layer involves two controllable quantum nodes linked by a (chain of) automated quantum nodes that attempt entanglement production in well defined time slots.
The task of the link layer is then to turn the physical layer making entanglement attempts into a robust entanglement generation service, that can produce entanglement between controllable quantum nodes connected by a (chain of) automated quantum nodes. Requests can be made by higher layers to the link layer to produce entanglement, where robust means that the link layer endows the physical system with additional guarantees: a request for entanglement generation will (eventually) be fulfilled or result in a time-out. This can be achieved by instructing the physical layer to perform many attempts to produce entanglement until success.
Built on top of the link layer rests the network layer, which is responsible for producing long-distance entanglement between nodes that are not connected directly or by automated quantum nodes. This may be achieved by means of entanglement swapping, using the link layer to generate entanglement between neighboring controllable nodes. In addition, it contains an entanglement manager that keeps track of entanglement in the network, and which may choose to pre-generate entanglement to service later requests from higher layers. It is possible that the network layer and entanglement manager may eventually be separated.
A transport layer takes responsibility for transmitting qubits deterministically (e.g. using teleportation). One may question why this warrants a separate layer, rather than a library. Use of a dedicated layer allows two nodes to pre-share entanglement that is used as applications of the system demand it. Here, entanglement is not assigned to one specific application (purpose ID, Section 4.1.1). This potentially increases the throughput of qubit transmission via teleportation as teleportation requires no additional connection negotiation, but only forward communication from a sender to the receiver. Implementing such functionality in a library would incur delays in application behavior as entanglement would need to be generated on-demand rather than supplying it from pre-allocated resources.
4. Link Layer Design Considerations
4.1. Desired Service
The link layer offers a robust entanglement creation service between a pair of controllable quantum nodes and that are connected by a quantum link, which may include automated nodes along the way. This service allows higher layers to operate independently of the underlying hardware platform, depending only on high-level parameters capturing the hardware capabilities.
4.1.1. Requesting entanglement
Our use cases bring specific requirements for such a service. Entanglement creation can be initiated at either or by a CREATE request from the higher layer with parameters:
- (1)
Remote node with whom entanglement generation is desired if the node is connected directly to multiple others. 2. (2)
Type of request - create and keep (K), and create and measure (M). The first type of request (K) stores entanglement, addressing the use cases CK and NL (see Section 3.3. The second (M) leads to immediate measurement, supporting the use case MD. The reason for distinguishing these two scenarios is twofold: first, we will show later (Section 4.4 that a higher throughput can for some implementations be achieved for M than for K on the same system. Second, simple photonic quantum hardware without a quantum memory and sophisticated processing capabilities (Scarani et al., 2009) only supports the M mode of operation. 3. (3)
Number of entangled pairs to be created. Allowing the higher layer to request several pairs at once can increase throughput by avoiding additional processing delays due to increased inter-layer communication (comparing to classical networks (unpeng James Liu et al., 2014, Table 2)). It also helps the CK use case where an application actually needs several pairs concurrently. 4. (4)
Atomic is a flag that assists the requirement from the CK use case, by ensuring that the request must be fulfilled as one, and all pairs be made available at the same time. 5. (5)
Consecutive is a flag indicating an OK is returned for each pair made for a request (typical for NL use case). Otherwise, an OK is sent only when the entire request is completed (more common in application use cases). 6. (6)
Waiting time, can be used to indicate the maximum time that the higher layer is willing to wait for completion of the request. This allows a general timeout to be set, and enables the NL and CK use case to specify strict requirements since the requested pairs may no longer be desirable if they are delivered too late. 7. (7)
A purpose ID can be specified which allows the higher layer to tag the entanglement for a specific purpose. For an application use case, this purpose ID may be considered analagous to a port number found in the TCP/IP stack and including it in the CREATE request allows both nodes to immediately pass the entanglement to the right application to proceed with processing at both ends without incurring further communication delays. A purpose ID is also useful to identify entanglement created by the NL use case for a specific long-distance path. We envision that an entanglement manager who may decide to pre-generate entanglement would use a special tag to indicate “ownership“ of the requested pairs. For the NL use case for example, if the entanglement request does not correspond to a pre-agreed path, then the remote node may refuse to engage in entanglement generation. Finally, a purpose ID enables rejection of generation by the remote node based on scheduling or security policies, e.g. for NL when no path is agreed upon. 8. (8)
A priority that may be used by a scheduler. Here we use only three priorities (use cases NL, MD and CK). 9. (9)
Finally, we allow a specification of a purely quantum parameter (refer to Appendix A), the desired minimum fidelity, , of the entanglement (Nielsen and Chuang, 2010). Here, it is sufficient to note that the fidelity measures the quality of entanglement, where a higher value of means higher entanglement quality. The ideal target state has , while is often desirable (Horodecki and Horodecki, 1999).
The reason for allowing different instead of fixing one for each hardware platform is that the same platform can be used to produce higher or lower fidelity pairs, where a higher fidelity pair costs more time to prepare. Examples of this are the use of entanglement distillation (Dür and Briegel, 2007; Kalb et al., 2017) where two lower quality pairs are combined into one higher quality one, and the bright state population (see Appendix D) used to generate entanglement.
4.1.2. Response to entanglement requests
If entanglement has been produced successfully, an OK message should be returned. In addition, the use cases specified in Section 3.3 desire several other pieces of information, which may also be tracked at higher layer:
- (1)
An entanglement identifier unique in the network during the lifetime of the entanglement. This allows both nodes to immediately process the entanglement without requiring an additional round of communication degrading the entanglement due to limited memory lifetimes. 2. (2)
A qubit ID for -type (create and keep) requests which identifies where the local qubit is in the quantum memory device. 3. (3)
The “Goodness“ , which for requests is an estimate (Section B) of the fidelity — where should hold — and for an estimate of the quantum bit error rate (QBER, see again Appendix A). 4. (4)
The measurement outcome for type requests. 5. (5)
The time of entanglement creation. 6. (6)
The time the goodness parameter was established. The goodness may later be updated given fixed information about the underlying hardware platform.
Evidently, there are many possibilities of failure resulting in the return of error messages. This includes:
- •
Timeout when a request could not be fulfilled in a specific time frame (TIMEOUT).
- •
An immediate rejection of the request because the requested fidelity is not achievable in the given time frame (UNSUPP).
- •
The quantum storage is permanently (MEMEXCEEDED) or temporarily (OUTOFMEM) too small to simultaneously store all pairs of an atomic request.
- •
Refusal by the remote node to participate (DENIED).
Finally, we allow an EXPIRE message to be sent, indicating that the entanglement is no longer available. This in principle can be indicated by a quantum memory manager (see Appendix, Section 5.2.2) instead of the protocol, but we will that show that it allows for recovery from unlikely failures.
4.1.3. Fixed hardware parameters
Not included in these request or response messages are parameters that are fixed for the specific hardware platform, or change only very infrequently. As such, these may be obtained by high-level software by querying the low level system periodically, similarly to some classical network architectures (e.g. (Marinos et al., 2014)). Such parameters include:
- •
The number of available qubits.
- •
The qubit memory lifetimes.
- •
Possible quantum operations.
- •
Attainable fidelities and generation time.
- •
The class of states that are produced.
The latter refers to the fact that more information than just the fidelity allows optimization at layers above the link layer.
4.2. Performance Metrics
Before designing any protocols that adhere to these requirements for entanglement generation, we consider the performance metrics that such protocols may wish to optimize. Standard metrics from networking also apply here, such as throughput (entangled pairs/s), and the latency. We distinguish between:
- (1)
Latency per request (time between submission of a CREATE request and its successful completion at a requesting node). 2. (2)
Latency per pair (time between CREATE and OK at requesting node). 3. (3)
Latency per request per number of requested pairs (which we denote as the scaled latency).
Given requests may originate at both and , we also demand fairness, i.e., the metrics should be roughly independent of the origin of the request. Here, we also care about genuinely quantum quality metrics, specifically the fidelity (at least ).
The non-quantum reader may wonder about the significance of , and why we do not simply maximize throughput (e.g. (Singh et al., 2018; Bremler-Barr et al., 2016)) or minimize latency (e.g. (Dogar et al., 2014; Chen et al., 2015)). For instance, QKD (a MD use case as listed in Section 3.3), requires a minimum quantum bit error rate (QBER) between measurement outcomes at and (related to , see Appendix A). A lower results in a larger QBER, allowing less key to be produced per pair. We may thus achieve a higher throughput, but a lower number of key bits per second, or key generation may become impossible.
4.3. Error Detection
Link layer protocols for classical communication typically aim to correct or detect errors, e.g. using a CRC. In principle, there exists an exact analogy at the quantum level: We could use a checksum provided by a quantum error correcting code (QECC) (Nielsen and Chuang, 2010; Terhal, 2015) to detect errors. This is technologically challenging and experimental implementations of QECC are in very early stages (Cramer et al., 2016a; Riste et al., 2015; Córcoles et al., 2015). Yet, apart from technological limitations, future link layer protocols may not use quantum checksums due to different use case requirements: We typically only demand some minimum fidelity with high confidence that may also fluctuate slightly for pairs produced within a time window.
As we focus primarily on fidelity, we instead use a different mechanism: we intersperse test rounds during entanglement generation (for details, refer to Appendix B) to verify the quality of the link. Such test rounds are easy to produce without the need for complex gates or extra qubits. Evidently, there exists an exact analogy in the classical networking world, where we would transmit test bits to measure the current quality of transmission, e.g. a direct analogy to network profiling (Marinos et al., 2014, Section 4.3) to gain confidence that the non-test bits are also likely to be transmitted with roughly the same amount of error. Yet, there we typically care about correctness of a specific data item, rather than an enabling resources like entanglement.
4.4. Physical Entanglement Generation
Let us now explain how heralded entanglement generation is actually performed between two controllable nodes and (see Appendix D for details). As an example, we focus on the hardware platform available to us (NV in diamond, Figure 3), but analogous implementations have been performed using remote Ion Traps (Moehring et al., 2007) and Neutral Atoms (Hofmann et al., 2012).
Nodes and are few-qubit quantum processors, capable of storing and manipulating qubits. They are connected to an intermediate station called the heralding station over optical fibers. This station is a much simpler automated node, built only from linear optical elements. Each node can have two types of qubits: memory qubits as a local memory, and communication qubits with an optical interface. To produce entanglement, a time synchronized trigger is used at both and to create entanglement between each communication qubit, and a corresponding traveling qubit (photon). These photons are sent from and to over fiber. When both arrive at , performs an automatic entanglement swapping operation which succeeds with some probability. Since has no quantum memory, both photons must arrive at at the same time to succeed. Success or failure is then transmitted back from to the nodes and over a standard classical channel (e.g. 100Base-T). In the case of success, one of several entangled states may be produced, which can however be converted to one other using local quantum gates at and . After a generation attempt, the communication qubit may be moved to a memory qubit, in order to free the communication qubit to produce the next entangled pair. Many parameters influence the success and quality of this process, such as the quality of the qubits themselves, the probability of emission of a photon given a trigger signal, losses in fiber, and quality of the optical elements such as detectors used at (Figure 3).
For further information on this process see (Humphreys et al., 2018). For an overview on NV centres in diamond see (Childress and Hanson, 2013). Two different schemes for producing entanglement have been implemented, that differ in how the qubits are encoded into photons (time-bin (Barrett and Kok, 2005), or presence/absence of a photon (Cabrillo et al., 1999)). While physically different, both of these schemes fit into the framework of our physical and link layer protocols.
To evaluate the performance of the protocol (Section 6) and provide intuition of timings, we compare to data from the setup (Humphreys et al., 2018) which uses presence/absence of a photon as encoding. A microwave pulse prepares the communication qubit depending on a parameter , followed by a laser pulse to trigger photon emission (total duration ). A pair ( or ) is successfully produced with fidelity (ignoring memory lifetimes and other errors, see Appendix D) with probability , where is the probability of emitting a photon followed by heralding success. The parameter thus allows a trade-off between the rate of generation (), and the quality metric . For K type requests, we may store the pair in the communication qubit, or move to a memory qubit (duration of for the qubit considered). The quality of this qubit degrades as we wait for to reply. For M type requests, we may choose to measure immediately before receiving a reply (here readout ). Important is the time of an attempt (time preparing the communication qubit until receiving a reply from , and completion of any post-processing such as moving to memory), and the maximum attempt rate (maximum number of attempts that can be performed per second not including waiting for a reply from H or post-processing). The rate can be larger than : (1) for M the communication qubit is measured before receiving the reply from and thus allows for multiple attempts to overlap and (2) for K, if the reply from is failure, then no move to memory is done.
For performance evaluation we consider two physical setups as an example (see Appendix D) with additional parameters hereafter referred to as the Lab scenario and the QL2020 scenario. The Lab scenario already realized (Humphreys et al., 2018) with distance to the station from both and (communication delay to negligible), ( vs. , Figure 8). For requests, we act the same for Lab and QL2020 and always measure immediately before parsing the response from to ease comparison (thus s which includes electron readout 3.7 s, photon emission 5.5 s and a 10 % extra delay to avoid race conditions). For requests in Lab, s but s as memory qubits need to be periodically initialized (330 s every s). The QL2020 scenario has not been realized and is based on a targeted implementation connecting two European cities by the end of 2020 ( from to with a communication delay of in fiber, and from to with a delay). Frequency conversion of 637nm to 1588nm is performed on the photons emitted in our modeled NV centre while fiber losses at 1588nm are taken to be (values for deployed QL2020 are fibers 0.43-0.47 db/km). We model the use of optical cavities to enhance photon emission (Riedel et al., 2017a; Bogdanović et al., 2017) giving a probability of success . is worse due to increased communication times from (Figure 9). For QL2020 s for M (trigger, wait for reply from ) and s for K (trigger, wait for reply from , swap to carbon). Maximum attempt rates are s (M) and s (K).
4.5. Hardware Considerations
Quantum hardware imposes design considerations for any link layer protocol based on top of such experiments.
Trigger generation: Entanglement can only be produced if both photons arrive at the heralding station at the same time. This means that the low level system requires tight timing control; such control (ns scale) is also required to keep the local qubits stable. This imposes hard real time constraints at the lowest level, with dedicated timing control (AWG) and software running on a dedicated microcontroller (Adwin ProII). When considering a functional allocation between the physical and link layer, this motivates taking all timing synchronization to happen at the physical layer. At this layer, we may then also timestamp classical messages traveling to and from , to form an association between classical control information and entangled pairs.
Scheduling and flow control: Consequently, we make the link layer responsible for all higher level logic, including scheduling, while keeping the physical layer as simple as possible. An example of scheduling other than priorities, is flow control which controls the speed of generation, depending on the availability of memory on the remote node to store such entanglement.
Note that depending on the number of communication qubits, and parallelism of quantum operations that the platforms allows, a node also has a global scheduler for the entire system and not only the actions of the link layer.
*Noise due to generation: * One may wonder why one does not continuously trigger entanglement generation locally whenever the node wants a pair, or why one does not continuously produce pairs and then this entanglement is either discarded or otherwise made directly available. In the NV system, triggering entanglement generation causes the memory qubits to degrade faster (Reiserer et al., 2016; Kalb et al., 2018). As such we would like to achieve agreement between nodes to avoid triggering unless entanglement it is indeed desired.
This consideration also yields a security risk: if an attacker could trick a node into triggering entanglement generation, without a matching request on the other side, this would allow a rapid destruction of contents of the nodes’ local quantum memory. For this reason, we want classical communication to be authenticated which can be achieved using standard methods.
Memory allocation: Decisions on which qubits to use for what purpose lies in the domain of higher level logic, where more information is available. We let such decisions be taken by a global quantum memory manager (QMM), which can assist the link layer to make a decision on which qubits to employ. It can also translate logical qubit IDs into physical qubit IDs in case multiple qubits are used to redundantly form one logical storage qubit.
5. Protocols
We now present our protocols satisfying the requirements and considerations set forth in Sections 3 and 4. The entanglement generation protocol (EGP) at the link layer, uses the midpoint heralding protocol (MHP) at the physical layer. Classical communication is authenticated, and made reliable using standard methods (e.g. 802.1AE (IEEE 802.1 working group, 2015), authentication only).
5.1. Physical Layer MHP
Our MHP is a lightweight protocol built directly on top of physical implementations of the form of Section 4.4, supplementing them with some additional control information. With minor modifications this MHP can be adapted to other forms of heralded entanglement generation between controllable nodes, even using multiple automated middle nodes (Guha et al., 2015).
The MHP is meant to be implemented directly at the lowest level subject to tight timing constraints, which is why we let the MHP poll higher layer (Figure 4, the link layer EGP) at each timestep to determine whether entanglement generation is required, and keep no state. A batched operation is possible, should the delay incurred by the polling exceed the minimum time to make one entanglement generation attempt - the MHP cycle - and hence dominate the throughput. Upon polling, the higher layer may respond “no“ in which case no attempt will be made or with “yes“, additionally providing parameters to use in the attempt. These parameters include the type of request (M, measure) or (K, store) passed on from the higher layer, for which the MHP takes the following actions.
5.1.1. Protocol for Create and Keep (K)
The parameters given to the MHP with a “yes“ response contain the following:
- •
An ID for the attempt that is forwarded to
- •
Generation parameters (, Section 4.4)
- •
The device qubits for storing the entanglement
- •
A sequence of operations to perform on the device memory 111Less abstractly, by specifying microwave and laser pulse sequences controlling the chip (see Appendix)..
The higher layer may instruct the MHP to perform a gate on the communication qubit depending on the heralding signal from allowing the conversion from the state to the state. Entanglement generation is then triggered at the start of the next time interval, including generation parameter , and a GEN message is sent to which includes a timestamp, and the given ID. The motivation for including the ID is to protect against errors in the classical control, for example losses.
The station uses the timestamp to link the message to a detection window in which the accompanying photons arrived. Should messages from both nodes arrive, the midpoint verifies that the IDs transmitted with the GEN messages match, and checks the detection counts (Figure 3) from the corresponding detection window. The midpoint will then send a REPLY message indicating success or failure, and in the case of success which of the two states and was produced. The REPLY additionally contains a sequence number uniquely identifying the generated pair of entangled qubits chosen by , which later enables the EGP to assign unique entanglement identifiers. This REPLY and the ID is forwarded to the link layer for post-processing. Note that the REPLY may be received many MHP cycles later, allowing the potential for emission multiplexing (Section 5.2).
5.1.2. Protocol for Create and Measure (M)
Handling M type requests is very similar, differing only in two ways: Instead of performing a gate on the communication qubit, the “yes“ message requests the MHP to perform a measurement on the communication qubit in a specified basis once the photon has been emitted, even before receiving the response from . The outcome of the measurement and the REPLY are passed back to the EGP. In practice, the communication time from transmitting a GEN message to receiving a REPLY may currently exceed the duration of such a local measurement (3.7 vs. communication delay Lab 9.7 ns, and QL2020 145 s), and the MHP may choose to perform the measurement only after a successful response is received.
5.2. Link Layer EGP
Here we present an implementation of a link layer protocol, dubbed EGP, satisfying the service requirements put forth in Section 4 (see Appendix E for details and message formats). We build up this protocol from different components:
5.2.1. Distributed Queue
Both nodes that wish to establish entangled link(s) must trigger their MHP devices in a coordinated fashion (Section 4.4). To achieve such agreement, the EGP employs a distributed queue comprised of synchronized local queues at the controllable nodes. These local queues can be used to separate requests based on priority, where here we employ 3 for the different use cases (CK, NL, MD). Due to low errors in classical communication (estimated on QL2020, see Appendix D.6.1)), we let one node hold the master copy of the queue, and use a simple two-way handshake for enqueing items, and a windowing mechanism to ensure fairness. Queue items include a that specifies the earliest possible time a request is deemed ready for processing by both nodes (depending on their distance). Specifying prevents either node from beginning entanglement generation in different timesteps.
5.2.2. Quantum Memory Management (QMM)
The EGP uses the node’s QMM (Section 4.5) to determine which physical qubits to use for generating or storing entanglement.
5.2.3. Fidelity estimation unit (FEU)
In order to provide information about the quality of entanglement, the EGP employs a fidelity estimation unit. This unit is given a desired quality parameter , and returns generation parameters (such as ) along with an estimated minimal completion time. Such a fidelity estimate can be calculated based on known hardware capabilities such as the quality of the memory and operations. To further improve this base estimate the EGP intersperses test rounds.
5.2.4. Scheduler
The EGP scheduler decides which request in the queue should be served next. In principle, any scheduling strategy is suitable as long as it is deterministic, ensuring that both nodes select the same request locally. This limits two-way communication, which adversely affects entanglement quality due to limited memory lifetimes.
5.2.5. Protocol
Figure 5 presents an architecture diagram visualizing the operation. The protocol begins when a higher layer at a controllable node issues a CREATE operation to the EGP specifying a desired number of entangled pairs along with and . Upon receipt of a request the EGP will query the FEU to obtain hardware parameters (), and a minimum completion time. If this time is larger than , the EGP immediately rejects the request (UNSUPP). Should the request pass this evaluation, the local node will compute a fitting specifying the earliest MHP polling cycle the request may begin processing. The node then adds the request into the distributed queue shared by the nodes. This request may be rejected by the peer should the remote node have queue rules that do not accept the specified purpose ID. Then, the EGP locally rejects the request (DENIED).
The local scheduler selects the next request to be processed, given that there exists a ready one (as indicated by ). The QMM is then used to allocate qubits needed to fulfill the specified request type (create and keep K or create and measure M). The EGP will then again ask the FEU to obtain a current parameter due to possible fluctuations in hardware parameters during the time spent in the queue. The scheduler then constructs a “yes” response to the MHP containing from the FEU, along with an ID containing the unique queue ID of the request in the distributed queue, and number of pairs already produced for the request. This response is then forwarded to the local MHP upon its next poll to the EGP. If no request is ready for processing, a “no” response is returned to the MHP . At this point the MHP behaves as described in the previous section and an attempt at generating entanglement is made.
Whenever a REPLY and ID is received from the MHP, the EGP uses the ID to match the REPLY to an outstanding request, and evaluates the REPLY for correctness. Should the attempt be successful, the number of pairs remaining to be generated for the request is decremented and an OK message is propagated to higher layers containing the information specified in Section 4.1.2, where the Goodness is obtained from the FEU.
In the Appendix, we consider a number of examples to illustrate decisions and possible pitfalls in the EGP. An example is the possibility of emission multiplexing (van Dam et al., 2017): The EGP can be polled by the MHP before receiving a response from the MHP for the previous cycle. This allows the choice to attempt entanglement generation multiple times in succession before receiving a reply from the midpoint, e.g., in order to increase the throughput for the MD use case. Errors such as losses on the classical control link can lead to an inconsistency of state (of the distributed queue) at and from which we need to recover. Inconsistencies can also affect the higher layer. Since the probability of e.g. losses is extremely low, we choose not to perform additional two way discussion to further curb all inconsistencies at the link layer. Instead, the EGP can issue an EXPIRE message for an OK already issued if inconsistency is detected later, e.g. when the remote node never received an OK for this pair.
6. Evaluation
We investigate the performance of our link layer protocol using a purpose built discrete event simulator for quantum networks (NetSquid (net, 2018), Python/C++) based on DynAA (Filho et al., 2013) (see Appendix C for details and more simulation results). Both the MHP and EGP are implemented in full in Python running on simulated nodes that have simulated versions of the quantum hardware components, fiber connections, etc. All simulations were performed on the supercomputer Cartesius at SURFsara (sur, 2018), in a total of 2578 separate runs using a total of 94244 core hours, and 707 hours time in the simulation (250 billion MHP cycles).
We conduct the following simulation runs:
- •
Long runs: To study robustness of our protocol, we simulate the 169 scenarios described below for an extended period of time. Each scenario was simulated twice for 120 wall time hours, simulating seconds. We present and analyze the data from these runs in sections 6.1, 6.2 and C.2.
- •
Short runs: We perform the following simulations for a shorter period of time (24 wall time hours, reaching simulated seconds):
- –
Performance trade-offs: To study the trade-off between latency, throughput and fidelity we sweep the incoming request frequency and the requested minimum fidelity, see Figure 6.
- –
Metric fluctuations: To be able to study the impact of different scheduling strategies on the performance metrics, we run 4 scenarios, 102 times each. The outcomes of theses simulation runs are discussed in section 6.3.
To explore the performance at both short and long distances, the underlying hardware model is based on the Lab and QL2020 scenarios, where we validate the physical modeling of the simulation against data collected from the quantum hardware system of the Lab scenario already realized (Figure 8). For the quantum reader we note that while our simulations can also be used to predict behavior of physical implementations (such as QL2020), the focus here is on the performance and behavior of the link layer protocol.
We structure the evaluation along the three different use cases (NL, CK, MD), leading to a total of 169 different simulation scenarios. First, we use different kinds of requests: (1) NL (K type request, consecutive flag, priority 1 (highest), store qubit in memory qubit), (2) CK, an application asking for one or more long-lived pairs (K type request, immediate return flag, priority 2 (high), store qubit in memory qubit) and (3) (MD) measuring directly (M type request, consecutive flag, priority 3 (lowest)). For an application such as QKD, one would not set the immediate return flag in practice for efficiency, but we do so here to ease comparison to the other two scenarios. Measurements in MD are performed in randomly chosen bases , and (see Appendix A).
In each MHP cycle, we randomly issue a new CREATE request for a random number of pairs (max ), and random kind with probability , where is the probability of one attempt succeeding (Section 4.4), is a fraction determining the load in our system of kind , and is the expected number of MHP cycles to make one attempt ( for MD and for NL/CK in Lab due to memory re-initialization and post-processing). for NL/CK in QL2020 due to classical communication delays with ()). In the long runs, we first study single kinds of requests (only one of MD/CK/NL), with (Low), (High) or (Ultra). For the long runs, we fix one target fidelity to ease comparison. For each of the 3 kinds (MD/CK/NL), we examine (1) , (2) , and (3) only for MD, . For Ultra the number of outstanding requests intentionally grows until the queue is full (max 256), to study an overload of our system. To study fairness, we take 3 cases of CREATE origin for each single kind (MD/CK/NL) scenario: (1) all from (master of the distributed queue), (2) all from , (3) or are randomly chosen with equal probability. To examine scheduling, we additionally consider long runs with mixed kinds of requests (Appendix, e.g. Figure 7).
6.1. Robustness
To study robustness, we artificially increase the probability of losing classical control messages (100 Base T on QL2020 fiber , Appendix D.6.1), which can lead to an inconsistency of state of the EGP but also at higher layers (Section 5.2). We ramp up loss probabilities up to (Appendix D.6.1) and observe our recovery mechanisms work to ensure stable execution in all cases (35 runs, 281 - 3973 s simulated time), with only small impact to the performance parameters (maximum relative differences 222Relative difference between and is to the case of no losses, fidelity (0.005), throughput (0.027), latency (0.629), number of OKs (0.026) with no EXPIRE messages). We see a relatively large difference for latency, which may however be due to latency not reaching steady state in the course of this simulation ( core hours).
6.2. Performance Metrics
We first consider runs including only a single kind of request (MD/CK/NL). In addition to the long runs, we conduct specific short runs examining the trade-off between latency and throughput for fixed target fidelity (Figure 6(a)), and the trade-off between latency (throughput) and the target fidelity in Figure 6(b) (Figure 6(c)).
Below we present the metrics extracted from the long runs with single kinds of requests:
Fidelity: As a benchmark, we began by recording the average fidelity in all 169 scenarios with fixed minimum fidelity. We observe that is independent of the other metrics but does depend on the distance, and whether we store or measure: NL/CK Lab, NL/CK QL2020, MD Lab, MD QL2020 (Fidelity MD extracted from QBER measurements, Appendix A). This is to be expected since (1) we fix one and (2) we consider an NV platform with only 1 available memory qubit (Lab).
Throughput: All scenarios High and Ultra in Lab reach an average throughput (1/s) of NL/CK and for MD. It is expected that MD has higher throughput, since no memory qubit needs to be initialized. The time to move to memory () is less significant since many MHP cycles are needed to produce one pair, but we only move once. As expected for Low the throughput is slightly lower in all cases, NL/CK, and MD. For QL2020, the throughput for NL/CK is about 14 times lower, since we need to wait () for a reply from before MHP can make a new attempt.
Latency: The scaled latency highly depends on the incoming request frequency as the queue length causes higher latency. However, from running the same scenarios many (102) times for a shorter period (24 wall time hours), see section 6.3, we see that the average scaled latency fluctuates a lot, with a standard deviation of up to 6.6 s in some cases. For QL2020 with NL requests specifying 1-3 pairs from both nodes, we observe an average scaled latency of 10.97 s Low, 142.9 s High and 521.5 s Ultra. For MD requests, 0.544 s Low, 3.318 s High and 32.34 s Ultra. The longer scaled latency for NL is largely due to longer time to fulfill a request, and not that the queues are longer (average queue length for NL: 3.83 Low, 56.3 High, 214 Ultra), and for MD: 3.23 Low, 22.4 High and 219 Ultra).
Fairness: For 103 scenarios of the long runs (single kinds of requests (MD/CK/NL) randomly from and ), we see only slight differences in fidelity, throughput or latency between requests from and . Maximum relative differences do not exceed: fidelity 0.033, throughput 0.100, latency 0.073, number of OKs 0.100 (which occurs for Ultra).
6.3. Scheduling
We take a first step studying the effect of scheduling strategies on the performance when using mixed kinds of requests. Part of simulating the performance of a scheduling strategies can certainly be done without implementing all details of the physical entanglement generation. However, since we do simulate these details we can first confirm that different scheduling strategies below do not affect the average fidelity in these scenarios. Here, we examine two simple scheduling strategies: (1) first-come-first-serve (FCFS) and (2) a strategy where NL of priority 1 has a strict highest priority, and use a weighted fair queue (WFQ) for CK (priority 2) and MD (priority 3), where CK has 10 times the weight of MD. With these scheduling strategies, we simulate two different request patterns ((i) uniform and (ii) no NL more MD), 102 times over 24 wall time hours each and extract the performance metrics of throughput and scaled request latency, see table 1.
As expected we see a drastic decrease of the average scaled latency for NL when giving it strict priority: 10.3 s with FCFS and 3.5 s with WFQ. For CK there is similarly a decrease in average scaled latency, however smaller than for NL, 10.1 s and 6.5 s for FCFS and WFQ respectively. For MD the average scaled latency goes up in both cases when using WFQ instead of FCFS, by factors of (uniform) and (no NL more MD).
We observe that the throughput gets less affected by the scheduling strategy than the latency for these scenarios. The maximal difference between the throughput for FCFS and WFQ is by a factor of (for MD in the scenario of no NL and more MD). Furthermore, we see that the total throughput for all requests goes down from () 1/s for FCFS to () 1/s for WFQ in the case of uniform (no NL more MD).
7. Conclusion
Our top down inventory of design requirements, combined with a bottom up approach based on actual quantum hardware allowed us to take quantum networks a step further on the long path towards their large-scale realization. Our work readies QL2020, and paves the way towards the next step, a robust network layer control protocol. The link layer may now be used as a robust service without detailed knowledge of the physics of the devices. We expect that at the network layer, and when considering larger quantum memories, smart scheduling strategies will be important not only to combat memory lifetimes but also to coordinate actions of different nodes in time, calling for significant effort in computer science and engineering.
Acknowledgements
We thank Kenneth Goodenough for comments in earlier drafts. This work was supported by ERC Starting Grant (Stephanie Wehner), ERC Consolidator Grant (Ronald Hanson), EU Flagship on Quantum Technologies, Quantum Internet Alliance, NWO VIDI (Stephanie Wehner), Marie Skłodowska-Curie actions — Nanoscale solidstate spin systems and emerging quantum technologies — Spin-NANO, grant agreement number 676108.
Appendix
In this Appendix, we provide further background and details, as well as more in-depth simulation results.
- •
In Section A, we provide a very brief introduction to quantum information, including concepts like entanglement, fidelity, QBER and provide an intuition on how the fidelity is related to memory lifetimes.
- •
In Section B, we explain how to estimate the fidelity by interspersing test rounds.
- •
In Section C, we provide further simulation results to illustrate protocol performance and further validate our simulation against hardware.
- •
In Section D, we provide further details of the NV platform as relevant for the design considerations of the proposed protocol. Furthermore, we provide details the physical modeling as well as numerical methods used to conduct the simulation.
- •
In Section E, we provide a complete description of the proposed protocol.
Appendix A Quantum prelude
This section provides a very short introduction to quantum information and in particular quantum states, entanglement, fidelity and decoherence. For a deeper introduction to quantum information, see for example (Nielsen and Chuang, 2010).
A.1. Qubits and states
A quantum bit (qubit) is a two-level system, where the two levels are usually denoted and respectively (“ket”-notation) and called the basis states of the qubit. These levels can for example be two energy levels of an electron spin or - when considering transmitting qubits - vertical and horizontal polarization of a photon, presence or absence of a photon, or a time-bin of early and late. Compared to a “classical” bit or , a qubit can be in superpositions thereof. Mathematically, a state of a qubit is written as
[TABLE]
where and are arbitrary complex numbers with the constraint that , and
[TABLE]
Note that and form a basis for . Some common states are
[TABLE]
corresponding to a ’0’ or ’1’ in the three different bases labeled , , and . The label also refers to the standard basis. We also use to denote the conjugate transpose of .
Measuring a qubit in the standard () basis (, ), gives measurement outcomes ’0’ (i.e. ) or ’1’ (i.e. ). Measuring a qubit which is in the state as in equation 1 in the standard basis, yields the outcomes [math] or with the following probabilities
[TABLE]
which is why needs to be normalized. Measuring a qubit in the standard basis collapses it to or . Measuring a qubit in the - or -basis yields outcomes with probabilities
[TABLE]
where is the inner product.
A.2. Entangled states
If qubit is in a state and qubit is in the state , then their joint state (at possibly remote nodes) is given by the tensor product of the individual states and , i.e. as
[TABLE]
Importantly, for the discussion here is that not all joint states can be factorized into single qubit states and in this way. These are called entangled states. For example, consider the state
[TABLE]
which is a superposition of (1) both qubits being in the state and (2) both qubits being in the state . This is an entangled state, i.e., it cannot be factorized into two individual states, giving rise to genuinely quantum correlations between and that have no classical analogue. The state is one of the so called Bell states. These are entangled states, where the other three are given as
[TABLE]
Measurement outcomes of measuring the two qubits in any of the Bell-states in the bases , and are either perfectly correlated or perfectly anti-correlated. For example, for the measurement outcomes are perfectly correlated in the and bases but perfectly anti-correlated in the basis. On the other hand, for the measurement outcomes are perfectly anti-correlated in all three bases.
Relevant to understand the generation of entanglement is that all the Bell-states can be transformed to one another by only applying local quantum gates to one of the qubits. Two useful gates are the bit flip and phase flip . Applying them on qubit (at node only) allows one to transform:
[TABLE]
where we added the index to emphasize the gates are applied to qubit . We could also apply such gates to qubit to have the same effect.
In the heralded entanglement generation (Section 4.4), we can obtain either failure, or else success. In the case of success, an additional bit indicates whether we produced the state or . From equation (17), these two states can be transformed between each other by simply applying a -gate to one of the qubits.
A.3. Fidelity and QBER
In any real implementation of a quantum network, the generated entangled states will always differ from the perfect Bell states above due to noise in the system. When writing noisy states, it is convenient to express the state as a density matrix. For a perfectly prepared state , the density matrix is . This allows one to express noise. For example, the analogue of applying a classical bit flip error with some probability can be written as
[TABLE]
The fidelity measures how close a realized state is to an ideal target state . The fidelity of a state with the target state can be written as
[TABLE]
where if is identical to the target state. We have , where a larger value of means we are closer to the target state.
It is important to note that one cannot measure the fidelity of a single instance of a quantum state. However, if we produce the same state many times in succession, we can estimate its fidelity. One way to do this is to measure the qubit-error-rate (QBER). Consider above and recall that measurement outcomes in the , and bases are always perfectly anti-correlated in this case. I.e. we always get different measurement outcome for qubit and for qubit . In case the state is noisy, this is no longer the case. For a fixed basis (say ) the QBER (here QBERZ) is the probability of receiving equal333QBER for the other Bell states is defined in a similar manner, taking into account that measurement outcomes are always equal in some bases for the other ideal Bell states. measurement outcomes, when measuring qubit and qubit in the basis. Similarly, we can define QBERX and QBERY for measurements in the and bases. One can show that the fidelity and QBER of the Bell state state are related as
[TABLE]
A.4. Decoherence
Quantum memories are inherently noisy and the amount of noise a qubit experiences depends on how long it stays in the memory. How long a qubit state is preserved is usually captured by the two numbers T1 (energy/thermal relaxation time) and T2 (dephasing time) of the qubit (Nielsen and Chuang, 2010), as well as free-induction decay (see e.g. (Kalb et al., 2017)). Here, we focus on our performance metric (the fidelity) and illustrate in Figure 9(a) how it behaves as a function of time, where to highlight the actual effect of limited memory lifetimes we show the timescales in terms kms in fiber, where km/s is the speed of light in fiber. Figure 9 shows the fidelity of an entangled state stored in two electron states with a coherence time (T2) of 1.46 s as a function of the time it takes to communicate over a certain distance.
Appendix B Testing
We now explain the test used to gain confidence in transmission quality, specifically to estimate the quality parameter fidelity used in the FEU (Section 5.2.3). The following is a standard procedure in quantum information to estimate the fidelity of a state to the entangled target state . We emphasize that it is not possible to measure from a single copy of the state . The matrices are a mathematical description of an underlying quantum system, and not a matrix that one can read or access like classical information.
We first describe the standard procedure in the way that it is normally used. We then outline how this protocol can be extended to the case of interest here, and why we can draw conclusions even in real world scenarios in which we can experience arbitrary correlated errors.
Let us first assume a simpler scenario, in which identical noisy entangled states are produced in succession and we want to estimate . We remark that when using imperfect quantum devices it is evidently a highly idealized situation that all states are exactly identical. We can see from Eq. (20) that we can express in terms of the quantum bit error rates QBERX, QBERZ, and QBERY, which immediately suggests a protocol: specifically, we will estimate the QBERs in bases , and to obtain . We sketch such a protocol in a specific way to build intuition for the more general procedure below:
- •
Node randomly chooses an element string and sends it to Node .
- •
Nodes and now perform the following procedure for rounds:
- –
Node produces one entangled pair with Node .
- –
Nodes and both measures their respective qubits in the basis and record outcomes (Node ) and (Node ) respectively.
- •
Node () transmits the outcome string () to Node ().
- •
Both nodes estimate the error rates
[TABLE]
where is the number of indices satisfying the stated condition.
Using Eq. (20) then yields an estimate of .
Before we continue it may be instructive to compare the procedure above to the classical world. Evidently, classically, one way to gain confidence in a channels ability to transmit classical bits would be rather similar: Instead of preparing states , we choose random bits and send them. In the end, we estimate the error rate. Translated to the quantum setting, we would be preparing random bits and at node , and sending them to node which measures them in the bases to obtain an estimate of the bit error rate, similarly to . Such an estimate can give us confidence that also future bits are likely to be transmitted with roughly the same amount of errors as the test bits. This of course does not allow the same level of confidence as error detection in the quality of transmission. Specifically, a CRC is a check for a specific piece of data (e.g. one frame in 100 Base T), whereas such a test only yields a confidence in transmission quality.
Creating an analogous quantum CRC is theoretically possible by using a quantum error correcting code (Nielsen and Chuang, 2010), but technologically highly challenging and highly infeasible for many years to come. Yet, we remark that also in a future in which such methods would become feasible we may not want to employ them because the requirements of our use cases are different. Since many protocols for our use cases are probabilistic, or make many pairs (especially NL and MD use cases), we often do not require more confidence on the exact quality of a single pair. Indeed, we can pass errors all the way up to the application level (such as for example in QKD (Bennett and Brassard, 1984)), where errors are then corrected using classical instead of quantum error correction. In such cases, fluctuations in quality are indeed expected at the application level. Here, using fast and easy to produce test rounds may remain preferable over more time consuming quantum CRCs.
The protocol above is limited in two ways: (1) all states were assumed to be both identical and independent from each other. I.e., there are no memory effects in the noise. Such memory effects are non-trivial in the quantum regime since they may inadvertently create (some amount of) entanglement not only between and , but between subsequent pairs produced. (2) We measured all rounds, consuming all entangled pairs. Instead, we would like a protocol in which only test rounds are interspersed, and we can draw an inference about the pairs which we did not measure. Again, the possibility of quantum correlated noise between subsequent rounds makes this non-trivial.
To achieve this, we use a slight variant of the above as in (Pfister et al., 2018). Precise statistical statements are relatively straightforward - but very lengthy - to obtain using the techniques in (Tomamichel et al., 2012; Pfister et al., 2018) and are out of scope of this paper. Here, we focus on the practical protocol and intuition without the need for mathematical tools from quantum information, which is a direct extension of the one above:
- •
Nodes and agree on a sampling window .
- •
Nodes and randomly pick an bit string where for some parameter determining the frequency of using test rounds. and periodically refresh as needed.
- •
Nodes and randomly pick an element basis string . and periodically refresh as needed.
- •
The EGP uses to determine when to intersperse a test round. When producing the -th response to the MHP, the EGP checks whether . If so, it uses a standard test response instead to attempt to produce a test pair , and takes as the measurement basis the next available in the random basis string .
- •
and record their measurement outcomes.
- •
and estimate QBERX, QBERZ, QBERY over the past rounds of producing entanglement (tested and untested ’data’ rounds)
The key insight in the analysis of this procedure is that we can (with some amount of confidence depending on and ) use the QBER measured on the test rounds to determine the QBER on the untested - i.e. data - rounds (Tomamichel et al., 2012, Inequality 1.3). Using Eq. (20), then again allows one to draw conclusions about the average fidelity of the untested rounds to inform the FEU.
Appendix C Simulation and modeling
We here provide additional simulation results, and further verification against the quantum hardware.
For our simulations we make use of a purpose built discrete event simulator for quantum networks: NetSquid444NetSquid is an acronym for Network Simulator for Quantum Information using Discrete events.. By utilizing the discrete event paradigm NetSquid is capable of efficiently simulating the transmission and decay of quantum information in combination with the complex and stochastic nature of communication protocols. NetSquid can simulate both arbitrary quantum operations and Clifford-only gates, the former allowing for a precise simulation of small networks, while the latter allowing for networks containing thousands of nodes and qubits to be studied. Complete libraries of base classes enable users to simulate protocols and model physical devices at different levels of abstraction; for instance, (quantum) channels with modular noise, loss and delay models, or quantum processing devices with configurable gate topologies. NetSquid thus provides an ideal tool to validate network design choices and verify the performance of quantum network protocols in a physically-realistic setting.
The core simulation engine used by NetSquid is based on DynAA(Filho et al., 2013; van Leeuwen et al., 2014; Filho et al., 2016), a computer-aided analysis and design tool for the development of large, distributed, adaptive, and networked systems. It combines the best of network and system simulation technologies in a discrete-event modeling framework. DynAA provides a simple, yet powerful language able to describe large and complex system architectures, and innovative constructs to express adaptation mechanisms of the system, such as dynamic parameterization, and functional and architectural reconfiguration. A DynAA model can be simulated and/or analyzed to reveal system wide performance indicators, such as – but not limited to – throughput, power consumption, connectivity, reliability, and availability.
C.1. Validation of simulation
We compare our simulation model against further data gathered from the NV platform Labscenario. Node A rotates its qubit over the Z-axis of the Bloch sphere by a fixed angle, followed by measuring its communication qubit in a basis ( or ) that the nodes agreed upon beforehand. Node B only performs the measurement on its communication qubit, in the same pre-agreed basis. Regardless of the signal from the heralding station, both nodes initialize their qubit in before the start of the next round.
We compute the correlations of the measurement outcomes ()as shown in Figure 10 using
[TABLE]
where is the expectation value of the product of joint measurement outcomes with the measurement basis after rotation.
The fidelity with the target state (where denotes the heralding detector) can be expressed as a function of the correlations as
[TABLE]
Assuming independence between the different rounds, propagation of standard deviations can be computed using standard techniques.
C.2. Simulation data
In this section we present further results from the simulations of our proposed link layer protocol. Simulation data will be made available upon request. In total 1618 simulation runs were performed: long runs (120 h wall time each) with 169 scenarios and 1280 shorter runs (24 h wall time each) with varying request load and minimal requested fidelity. Out of the 169 scenarios used in the long runs, concerned scenarios where the entanglement generation requests where a mix of the priorities NL, CK and MD. For these mixed scenarios we considered (1) two physical setups, Lab and QL2020, (2) five usage patterns (described below) and (3) three different schedulers, FCFS, LowerWFQ and HigherWFQ.
We implement different usage patterns of the link layer by, in every MHP cycle, issuing a new CREATE request for a random number of pairs (max ) with probability , where is the probability of an attempt being successful, is a fraction determining load of our system and is the expected number of MHP cycles to make one attempt. For Lab(QL2020) () for M requests and () for K requests. We consider five different use patterns with and defined in table 2.
We make use of the following three scheduling strategies:
- •
FCFS: First-come-first-serve with a single queue.
- •
LowerWFQ: NL are always service first (strict priority) and a weighted fair queue (WFQ) is used between CK (weight 2) and MD (weight 1).
- •
HigherWFQ: NL are always service first (strict priority) and a weighted fair queue (WFQ) is used between CK (weight 10) and MD (weight 1).
Figures 11-16 show scaled latencies and request latencies as functions of simulated time for 20 of the first long simulations runs using the different scenarios of mixed request types. Furthermore, Figures 17-22 show the throughput as a function of simulated time for the same runs. We also ran a second batch with the same scenarios which produced similar plots. When using FCFS the request latency for the different requests are highly correlated, which is to be expected since all requests are in the same queue. On the other hand the scaled latency for the different request priorities, in particular MD, deviates from the others, which is due to the varying number of number of pairs in the requests. From Figures 17-22 one can observe that the type of scheduler, at least for these simulated scenarios, have a relative small affect on the throughput. In table 3 and 4 the average throughputs, scaled latency and request latencies are collected for the same 20 simulation runs.
Appendix D Under the hood
We now provide some more details on the simulation, numerical methods and the underlying NV platform. We remark that physical models for different parts of the NV platform are well established and validated (Bernien, 2014). The validation performed here is thus only about how the combined system performing entanglement generation matched with our simulation.
D.1. The simulated network
To understand our simulation we perform a full implementation of the MHP and EGP, running on simulated quantum hardware. To achieve this, we start by defining basic components in NetSquid, which, inspired by NS-3, is entirely modular and can be used to construct complex simulation scenarios by combining component elements. The components in the simulation are as follows, and our simulation could easily be configured to examine the performance of our protocol on other underlying hardware platforms such as Ion Traps.
- •
A QuantumProcessingDevice, which is a general component we defined in NetSquid. Abstractly, such a QuantumProcessingDevice is described by the following:
- (1)
A number of communication and memory qubits. Each such qubit is associated with a noise-model that describes how quantum information decoheres over time when kept in the memory itself. Concrete parameters for the NV platform are given in Section D.2. 2. (2)
Possible one or two-qubit quantum gates to be performed on each (pair of) qubit(s), the time required to execute the gate, as well as a noise-model associated with each such gate that may differ from qubit to qubit. For the NV platform we will only need to consider the gates given in Section D.2.2. 3. (3)
With each communication qubit we associate a trigger that allows the generation of entanglement between this communication qubit and a traveling qubit (a photon). Such an operation only succeeds with some probability of success, requires a certain amount of time, and can also be noisy. For the NV platform, we explain this in Section D.4. 4. (4)
Readout - i.e. measurement of a qubit. This takes a certain amount of time, and does again carry a noise-model. For NV, we explain this in Section D.3.4.
- •
A FiberConnection, which is a general NetSquid component that allows us to simulate optical fibers, including photon loss per km.
- •
A HeraldingStation, which automatically measures incoming photons in a certain time interval. This process is again subject to several possible errors explained in Section D.5.
- •
ClassicalConnection, which we use to transmit classical messages allowing us to simulate, for example, losses on the channel. Section D.6.1 explains the model considered here.
- •
Node, which includes a QuantumProcessingDevice, and enjoys fiber connections with the HeraldingStation or other nodes. Each Node can run programs in the same way that they could be run on e.g. a computer or microcontroller, allowing these Programs to make use of - for example - the QuantumProcessing Device. This allows us to perform a full implementation (here in Python) of the MHP and EGP including all subsystems in the same way as the program will later run on an actual microcontroller (however, in C).
We briefly review properties of the nitrogen-vacancy (NV) centre in diamond (Bernien, 2014) and how they affect the design and performance of our protocol. We will also highlight how this can be modeled in simulation. Important to the design and performance of our protocol is how long operations on qubits stored in the NV-center take. Additionally, the coherence time, i.e. how long a qubit can be stored, has an impact on our protocol. We summarize typical values for the noise-level and execution time of the allowed operations of a NV-center together with coherence times. These are the values we used in our simulation. Note however that these values can vary significantly between samples.
D.2. Qubits on the NV Platform
A NV centre is formed by replacing a carbon atom in a diamond lattice with a nitrogen atom and removing a neighboring carbon (vacancy). This structure traps electrons which together form a spin-1 system. Two of the levels of the collective spin-1 state can be used as a communication qubit in a quantum network. Around the NV centre there is also a natural abundance of carbon-13 atoms which interact with the communication qubit (electron spin). The surrounding carbon spins can be addressed using the communication qubit and can thus be used as memory qubits. We here consider a situation with only one communication qubit, and one memory qubit.
D.2.1. Noise model - Free evolution of the electronic and nuclear spins
Noise in experimental implementations is described in terms of , , times, where Section A.4 serves to provide intuition on how our quantity of interest - the fidelity to the maximally entangled target state - depends on their values. Table 6 lists values used in simulation (reflecting Lab), and state of the art for the communication qubit (Electron), and memory qubit (Carbon).
D.2.2. Quantum gates
Procedure and parallelism constraints
Quantum gates can be realized by applying microwave pulses. Of specific interest that affects the throughput is the duration of such operations given in Table 6. While not absolutely necessary for the understanding of the simulation, we briefly sketch how operations are performed also on the carbons to illustrate one feature of this system that is relevant for the performance of our protocols - namely the parallelism of the allowed gate operations. We remark that operations on the carbon spins are performed using the following pulse sequence
[TABLE]
where is a microwave--pulse on the electron spin, is the time between the pulses and is the total number of pulses. The target carbon spin can be chosen by picking such that it is precisely in resonance with the target carbon spin’s hyperfine interaction with the electron spin. If the electron spin is in the state () the target carbon spin will rotate around the -axis of the Bloch sphere in the positive (negative) direction, with an angle which depends on the total number of pulses . This means that one can perform quantum gates on the carbon that are controlled by the state of the electron spin. The effective unitary operation (E=control) on the electron and the target carbon spin is then given as
[TABLE]
where denotes a rotation around the -axis of an angle . Not only does the pulse sequence (25) manipulate the carbon spin, but it also decouples the electron from its environment, thereby prolonging its coherence time and is thus also called dynamical decoupling, allowing longer memory lifetimes (Figure 9(a)). We thus see a limit to the amount of parallelism when operating on the carbon and the electron spin.
Other quantum gates are however simpler: Since the carbon continuously precess around the axis of the Bloch sphere, rotations around (Carbon Rot-) are simply done by waiting a correct amount of time. Thus, also controlled rotations around other axes than can be performed by correctly interspersed waiting times during the pulse sequence above.
D.3. Gates and their noise
In this section we collect parameters for noise and delays of gates used in our simulation. Table 6 summarize the possible gates that can be performed on the electron and carbon spins in the NV system, together with decoherence times. Section D.4 describes how the noise occurring from entanglement generation attempts is modeled.
Here the E-C controlled- rotates the carbon spin around the -axis in the positive (negative) direction if the electron is in the () state. Furthermore, note that there is an asymmetry in reading out the -state and the -state of the electron.
D.3.1. Modeling noisy operations
Noise in gate operations is modeled by applying noise after a perfect gate (a standard method):
[TABLE]
where
[TABLE]
is the dephasing channel in and is the gate fidelity as given in table 6. States are initialized as , where
[TABLE]
denotes the depolarization channel by.
D.3.2. How the electron spin is initialized
Initialization of the electron spin means setting the state to (Reiserer et al., 2016). Initialization of the electron spin is done by performing optical pumping, in which light shines onto the electron, thereby bringing its quantum state in a higher energy level, given it was in , after which it falls back to either or with a given probability. If the electron falls down to the state is will stay there, thus after many repetitions of this process, the electron is with high confidence in the state . For our discussion here, it will be relevant to remark that this operation takes time (Table 6), and we will need to perform it repeatedly as the first step in producing entanglement.
D.3.3. Moving a qubit to memory
When moving a qubit from the communication qubit to the memory qubit, the memory qubit needs to already be initialized. Initialization of the carbon is done by effectively swapping the state from the electron to the carbon and cannot therefore be performed while having an entangled state in the electron. For this reason, initialization of the carbon ( s) needs to be performed before a photon is emitted from the electron during an entanglement generation attempt. However, it is not necessary to re-initialize the carbon before every entanglement generation attempt but simply periodically depending on the coherence time. In our simulation we assumed to be s and thus re-initialize the carbon every s (every 350th MHP cycle).
Swapping a state in the electron to the carbon can be done by 2 E-C controlled--gates and single qubit gates (total time s) (Kalb et al., 2017).
D.3.4. How a measurement (readout) is performed
Readout of the communication qubit
First, we are again interested in the time to perform this operation given in Table 6 which will be relevant in the MD use case. Evidently, also a readout can be noisy, where we here remark that the noise is asymmetric in that the probability of incorrectly obtaining measurement outcome [math] is much lower than incorrectly getting outcome .
Reading out a memory qubit
We again remark that next to timing constraints (Table 6), we have limited parallelism on the current NV platform, since we need the electron spin to readout the memory qubit. Reading out the nuclear spin is done by performing the following steps:
- (1)
initialize the electron spin, 2. (2)
apply an effective controlled NOT operation with the nuclear spin as control (consisting of one E-C controlled--gate and single-qubit gates), 3. (3)
measure (readout) the electron spin.
The reason why a controlled NOT is sufficient, rather than a full swap, is the following: If the nuclear spin is in state , then after the CNOT, the combined state is . The reduced state (Nielsen and Chuang, 2010) of the electron is then , so measuring in the standard basis yields the same statistics as measuring in the same basis.
Readout noise
Readout is modeled by performing a POVM measurement with the following Kraus operators (see (Nielsen and Chuang, 2010) for definition)
[TABLE]
where () is the readout fidelity of the -state () as given in table 6
D.4. Physical Entanglement Generation and Noise
We here consider the single-click scheme of Lab. To understand timing and quality, as well as parameter choices let us give a high-level overview of the single-click scheme: A microwave pulse is used to prepare the communication qubit in the state (max. for and ), where is also called the bright state, and the bright state population. A resonant laser pulse is then used to cause emission of a photon, if the state was in the bright state, preparing the joint state of the communication qubit () and an emitted photon () in the state , where () denotes the absence (presence) of a photon. This process succeeds with probability without Purcell enhancement using optical cavities. To ensure phase-stabilization only one laser may be used for both nodes, combined with local shutters to allow node control. We remark that local control at the node is still desirable at a distance due to aligning with other operations such as performing gates. to keep qubits stable. The heralding station interferes both incoming photons on a beam splitter, thereby performing a probabilistic entanglement swap. Intuitively, this can be understood as a measurement of the incoming qubits in the Bell basis, where we can only obtain outcomes , or “other”. Since “other” is more than one possible state, we declare failure in this case.
Depending on the clicks observed in the detectors, we have projected the state of the communication qubits at and in the state (only left detector clicks), (only right detector clicks), or we declare failure (either none or both of the detectors click). Success occurs with probability , where is the probability of detecting an emitted photon.
During entanglement generation, a variety of noise processes occur:
- (1)
Dephasing of the nuclear spins (memory qubits) due to resetting the electron during entanglement generation attempts. 2. (2)
Effective dephasing of the photon state due to uncertainty in the phase between the paths the photon travel to the beam-splitter. 3. (3)
Effective dephasing of the photons state due to non-zero probability of emitting two photons. 4. (4)
Effective amplitude damping of the photon state due to coherent emission, i.e. the photon is in a super-position of being emitted at different times. 5. (5)
Effective amplitude damping due to collection losses from non-unity probability of emitting the photon in the zero-phonon line and non-unity collection efficiency into the fiber. 6. (6)
Effective amplitude damping due to losses in fiber. 7. (7)
Non-perfect beam-splitter measurement at the heralding stations due to photons not being perfectly indistinguishable. 8. (8)
Errors in the classical outcome from the detectors due to non-unity detection efficiency and dark counts.
D.4.1. Dephasing mechanism on nuclear spins during entanglement attempts
Between every entanglement attempt, the electron spin (communication qubit) needs to be reset. The dominant source of noise on the nuclear spins (memory qubits) during the entanglement attempts is due to this re-initialization of the electron spin, as described in (Kalb et al., 2018). We model the noise on the nuclear spins as a fixed amount of dephasing noise
[TABLE]
for every entanglement attempt. The dephasing parameter depends on: the bright state population , the coupling strength and a decay constant as follows
[TABLE]
see equation (2) in (Kalb et al., 2018). If the length of the Bloch vector in the equatorial plane of the state in the nuclear spin is before the entanglement attempts , then after attempts the length will be
[TABLE]
The bright state population can be chosen per experiment but the coupling strength and decay constant are fixed but vary between different nuclear spins. The decay constant can also vary by performing different microwave control pulses of the electron spin. As an example of these parameters, for the nuclear spin and the standard microwave control pulses, the coupling strength is kHz and the decay constant is ns, see (Kalb et al., 2018). In the simulations we use these values for the coupling strength and decay constant.
D.4.2. Phase uncertainty for photon paths
There is uncertainty in the phase between the paths the photon travels from the nodes to the beam-splitter, due to for example uncontrolled stretching of the fiber. If this phase difference is then the state after a successful measurement at the heralding station (conditioned on there being only one photon) is
[TABLE]
where is the electron spin at node and is the electron spin at node .
We model this by performing dephasing noise to both qubits encoding the presence/absence of photon from and . As shown in (Rozpȩdek et al., 2018), if we chose the dephasing parameter to be
[TABLE]
then the standard deviation of the phase in the state between the electron (/) and the photon (/)
[TABLE]
is precisely . To efficiently compute quotients of modified Bessel functions we implemented the algorithm described in (Amos, 1974). Note that the variance of the phase in equation (31) is twice the variance of the phase in equation (33). In experiments the standard deviation of the phase for the state between the electrons, i.e. (31), has in (Humphreys et al., 2018) shown to be . Thus, we set the standard deviation in equation (33) to be .
D.4.3. Two-photon emission
There is a probability that two photons are emitted from the electron during the entanglement generation attempt at a node. For the physical setup we assume the probability of there being two photons emitted, given that at least one is emitted, to be approximately 4% (Humphreys et al., 2018). As argued in (Humphreys et al., 2018), the two-photon event can effectively be modeled as applying dephasing noise to the electron qubit which is part of the generated entanglement.
D.4.4. Coherent emission, superposition of time-modes
The emission of the photon is a coherent process and the photon is actually in a super-position of being emitted at different times. As shown in (Rozpȩdek et al., 2018), the effect of a finite detection window can be seen as effective amplitude damping noise to the qubit encoding the presence/absence of a photon. The amplitude damping parameter is then given by
[TABLE]
where is the detection time window and is the characteristic time of the NV emission (12 ns without cavity (Riedel et al., 2017b) and 6.48 ns with cavity (Rozpȩdek et al., 2018)).
D.4.5. Collection losses
We model non-unity collection efficiencies by effective amplitude damping noise on the qubit encoding the presence/absence of a photon. The amplitude damping parameter is given by
[TABLE]
where is the probability of emitting a photon in the zero phonon line (3% without cavity and 46% with cavity (Riedel et al., 2017b)) and is the probability of collection the photon into the fiber. From (Humphreys et al., 2018) we know that the total detection efficiency of the system is , which can be decomposed as
[TABLE]
where is the probability that the photon is not lost during transmission in the fiber and is the probability that the detector clicks, given that there was a photon. Using equation (36) we find that given the numbers in (Humphreys et al., 2018). Frequency conversion succeeds with probability 30% (Zaske et al., 2012), so in this case we use .
D.4.6. Transmission losses
Since the qubit sent from the node to the heralding station is encoded in the presence/absence of a photon, the losses during transmission over fiber are modeled as amplitude damping noise. We use an amplitude damping parameter given as
[TABLE]
where is the length of the fiber (in km) and is assumed to be without frequency conversion and with frequency conversion.
D.4.7. Distinguishable photons
Entanglement is generated between the electrons of the two nodes since the beam-splitter in the heralding station effectively deletes the information of which node a detected photon came from. This information is only perfectly detected if the photons emitted from the nodes are completely indistinguishable. In reality however, the photons properties (spectral, temporal etc.) can be slightly different and they are therefore not completely indistinguishable. In section D.4.7 we derive effective measurement operators of a beam-splitter measurement, taking photon indistinguishability into account, which we make use of in our simulation. For the physical setup we simulate, the overlap (visibility) of the photons coming from the nodes is approximately (Humphreys et al., 2018), i.e. where is defined in equation (70).
D.4.8. Detection losses and dark counts
Detection losses and dark counts are modeled by probabilistically changing the ideal classical outcome from the detectors at the heralding station. For each detector, if the ideal detector clicked the noisy detector also clicks with probability and otherwise not. In the simulations we use , as measured in (Hensen et al., 2015).
If the ideal detector did not click the noisy detector does click with probability . The parameter used for the dark count is the dark count rate per second (Humphreys et al., 2018). The dark counts follow a Poisson distribution and we have that
[TABLE]
where is the detection time window.
D.5. Heralding station
Let us now consider the measurement at the Heralding Station in more detail in order to understand its error models.
D.5.1. Distinguishable photons
We here describe how we model a beam-splitter measurement of two photons which are not perfectly indistinguishable. This is relevant for many heralding entanglement generation schemes, since if photons are distinguishable the beam-splitter will not erase the information of where the photons came from. Two perfectly indistinguishable photons incident on a beam-splitter will always go to the same output arm, as captured by the Hong-Ou-Mandel effect (Hong et al., 1987). However, if the photons are distinguishable they do not necessarily go to the same output arm, which can be detected in experiment. For a given setup, lets denote the probability that two incident photons on the beam-splitter go to different output arms as .
We will in this section derive the effective POVM and Kraus operators correspond to detecting photons at the ends of the output arms of the beam-splitter in terms of , under the assumptions described below and using ideas from the paper (Branczyk, 2017) where is computed.
D.5.2. Model
Assume that there is a 50:50 beam-splitter with input arms and and output arms and . At the end of the output arms there are photon detectors that can click. We will assume that the detectors have a flat frequency response and at first that the detectors can count photons, i.e. there are different measurement outcomes for there being one or two photons incident on a detector. However we will show below how one can easily consider detectors which cannot count photons from the analysis in this note.
Photons
In many simulations we model the presence or absence of a photon as a two-level system, i.e. a qubit , where means no photon and one photon. We would then describe the state before the beam-splitter as a state living in a 2-qubit Hilbert space spanned by the following four basis vectors:
[TABLE]
describing 0 photons, photon on the right, photon on the left and two photons. Here and corresponds to arm and of the beam-splitter, but we distinguish these since we will denote (and ) as the infinite dimensional Hilbert space describing the spectral property of the photon. Note that we assume that there are never more than one photon per arm.
Describing the presence and absence of a photon as a qubit masks the fact that a photon can have many other degrees of freedom, such as polarization, spectral and temporal properties. We will here focus on spectral and temporal properties and will therefore model a photon in arm with a spectral amplitude function as the state
[TABLE]
where is the creation operator of a photon in arm of frequency and is the vacuum and is normalized such that
[TABLE]
Furthermore, the state of arm will be described by a spectral amplitude function as
[TABLE]
Two photons arriving at the beam-splitter can have different spectral properties, captured by and being different. We will also include a possible temporal shift between the arrival times of the two photons. As described in equation (16) of (Branczyk, 2017), a temporal shift of a photon in arm induces the following action on the creation operators
[TABLE]
Beam-splitter
The 50:50 beam-splitter acts on the creation operators in the following way:
[TABLE]
Thus the state of a photon described as in equation (40), i.e. one photon in the input arm , will after the beam-splitter become
[TABLE]
Furthermore, the three other cases of no photon, one photon in the input arm and one photon in each input arm becomes after the beam-splitter:
[TABLE]
Where the states , , and should be thought of as the corresponding states to the states in equation (39). Below, we will in fact formally define an isometry between these two Hilbert spaces.
Detectors
As mentioned we assume that the detectors have a flat frequency response. The event that the detector in arm detected one photon can then be described by the projector
[TABLE]
Since we assume that there is maximally one photon arriving at each input arm of the beam-splitter the only other possible measurement outcomes are described by the following projectors:
[TABLE]
where corresponds to no photon, one photon in arm , one photon in each arm, two photons in arm and two photons in arm . Note that the factors of are needed for such that and similarly with .
Deriving effective POVM on presence/absence description
The goal of this note is to derive the effective POVM on the Hilbert space , spanned by vectors in equation (39), induced by the projective measurements in equations (50)-(55) on the infinite-dimensional Hilbert space . To do this we will first define an isometry from the Hilbert space to , using the states in equation (39) and equations (46)-(49). This isometry will have the following action on the basis states of :
[TABLE]
and will therefore be given as
[TABLE]
One can easily check that the states , , and are mutually orthogonal and that is therefore indeed an isometry, i.e.
[TABLE]
Lets assume that is a state in and we wish to compute the probability of receiving a measurement outcome corresponding to the projector for the state . Using Born’s rule we find that this probability is given as
[TABLE]
From the above equation we find that the effective POVM on is given as
[TABLE]
whose elements we will denote as , , , , and . In section D.5.2 we compute what these POVM-elements are and find a choice of Kraus operators in section D.5.3 for both the case then the detector can count photons and when it cannot.
Effective POVMs
Here we compute the POVM-elements in equation (63) one-by-one.
:
Let’s start with since this will allow us to relate these POVM-elements to , i.e. the probability that both detectors click, given that there were one photon in each input arm. The operator only has non-zero overlap with the term of and is therefore given as
[TABLE]
Lets evaluate the factor . Using equation (49) and equation (53) we find that the above expression evaluates to
[TABLE]
where we used the fact that and similarly for arm . Using that
[TABLE]
we find that equation (66) evaluates to
[TABLE]
Finally using equation (41) we find that evaluates to
[TABLE]
where
[TABLE]
From equation (69) we can relate to as
[TABLE]
:
The operator only has non-zero overlap with the term of and is therefore given as
[TABLE]
Lets evaluate the factor . Using equation (49) and equation (54) we find that the above expression evaluates to
[TABLE]
where we used the fact that . Then similarly to we find that equation (74) evaluates to
[TABLE]
and we thus find to be
[TABLE]
:
Similarly to we find that evaluates to
[TABLE]
:
The operator only has non-zero overlap with the terms and of and is therefore given as
[TABLE]
Lets evaluate the factors , , and one-by-one. First we have that:
[TABLE]
and similarly that
[TABLE]
Furthermore, we find that
[TABLE]
where is defined in equation (70). One easily then finds that
[TABLE]
Combining the above results, we find that is given as
[TABLE]
:
Similarly to one finds that evaluates to
[TABLE]
:
Its easy to see that
[TABLE]
POVM for photon-counter detectors
To summarize we found that the POVM-elements are given as
[TABLE]
where the rows and columns of the above matrices are ordered as and is given as
[TABLE]
and is related by to the probability that both detectors click, given that there were one photon in each input arm as
[TABLE]
POVM for non-photon-counter detectors
If the detectors used cannot distinguish between one and two photons we can simply add the POVM elements and to get a new POVM given as
[TABLE]
D.5.3. Effective Kraus operators
Given the POVMs in equation (86)-(91) and equation (94)-(97) one can choose corresponding Kraus operators for these measurements by taking the matrix square root of the corresponding POVM-elements. Assuming that is real one finds a set of Kraus operators of the POVM to be
[TABLE]
D.6. Classical communication
D.6.1. Optical Link Error Model
We claimed that we highly inflated losses in the simulation to stress test our protocol. We now consider more realistic values for such errors by considering a realistic packet-level error model for the non-quantum optical link. For this we have assumed that two quantum internet end nodes are connected by a legacy 1000BASE-ZX single-mode wavelength Gigabit Ethernet link. The reason for choosing 1000BASE-ZX interface is (i) its achievable long-distance transmission at least up to with no dependency on optical repeaters and (ii) decades of its successful deployment within magnitude of networks worldwide.
To be conservative, our optical Gigabit Ethernet model assumes a typical worst-case optical link budget ( attenuation555Fibers measured for QL2020 have been found to have this loss level., /connector loss, /splice/(joint) loss, and safety margin) (Cisco, 2005). We also assume a typical worst-case optical transmission power and receiver sensitivity of a 1000BASE-ZX small form-factor hot pluggable transceiver, see e.g. (KG, 2013). For a maximum realism of link error over an optical link we model a IEEE 802.3 frame errors, instead of modeling individual bit errors of every message sent across the network. The latter would require a software implementation of a complete modulation and coding layer of IEEE 802.3 which is beyond the scope of this work. Using measurement trace-driven packet-level Gigabit Ethernet frame error data from (James, 2005, Table 6.1) we have mapped the received SNR per transmitter/receiver distance to the respective frame error probability, which was then applied to every classical message sent over an optical link between quantum end nodes. SNR values that were not represented in the measurements of (James, 2005) have been linearly interpolated. We have not distinguished between the lengths of each classical message as the model of (James, 2005) has aggregated over all messages captured over a measured campus Ethernet link (cf. (James, 2005, Fig. 6.1)). We note that our modeling approach is equivalent to the frame error models applied in e.g. NS-3 (Consortium, 2019) for WiFi frame errors.
For two example long-distance Quantum Internet typologies (node-to-node distance of and , respectively) we have ended up in a perfect frame error probability, with the assumption that amount of splices is zero666Which is consistent with the measurements, e.g. in (Corndorf et al., 2004, Section 4). (we only start to observe frame errors only at transmitter/receiver distance exceeding 40 km for the above model variables, with a very narrow transition error between no frame error rate and disconnected interface, i.e. frame error rate of one). Even when we increase the number of splices to an exaggerated level, say 30 splices for a interface (with 0.3 dB loss/splice), we still observe a very low frame error probability of 410. Therefore, to test the effect of frame errors on the non-quantum optical link on the Quantum Internet protocol stack—in the cases of extreme frame loss—we have increased the value of frame error to 10 (and tested frame error rate to up to 10—an error rate level of a link with 21 splices—in steps of 10). If our protocol would work in such a high (but unrealistic) condition then it would also work on a realistic low-error optical link.
D.6.2. Optical Link CRC Error Model
Additionally, we have investigated a non-zero probability of CRC not being able to detect a frame error. Assuming the same optical link type (e.g. 1000BASE-ZX) we have used a model of (Fujiwara et al., 1989) to calculate the respective probability of not detecting a CRC frame error within a IEEE 802.3 frame. For this we have mapped the transmitter/receiver distance to the respective SNR (the same way as described in Section D.6.1). Then we mapped the SNR to the respective BER using (James, 2005, Table 6.3) (performing the same process of interpolating SNR between the points not measured by (James, 2005) as for the optical link error model, see again Section D.6.1) and then using (Fujiwara et al., 1989, Fig. 1) mapped this resulting SNR to the respective probability of undetected error. We have assumed a worst case scenario of the longest IEEE 802.3 frame (i.e. bits, that is a maximum MTU). Again, for any of the two Quantum Internet lengths mentioned above, we do not find any CRC errors. At the highly-spliced case, considered in Section D.6.1, we obtain an extremely low CRC error rate of 1.410. Therefore such errors were decided to be ignored in our implementation. Another reason for not considering these errors: it would require a full implementation of en- and decoding of classical frames which outside the scope of this work.
Appendix E Protocols
Here we give details of the implementation of the physical and link layer protocols in our simulations. Python implementation is available upon request.
E.1. Distributed Queue Protocol
In order to track the individual applications that the entangled qubits belong to, the EGP makes use of a distributed queue which shares request information between peers. Management of the distributed queue is performed by the Distributed Queue Protocol (DQP). In addition to storing the parameters supplied with a CREATE request generated by the layers above the link layer777Refer to Section 4 of the main paper for the details of the CREATE request., DQP will keep additional information about each entanglement request including its create_time, min_time at which the request may be executed and MHP timeout cycle by which the entanglement request will time out. We proceed with the introduction of the DQP by describing the structure of priority queues, followed by the queue establishment process, DQP message sequence diagram and DQP associated messages.
E.1.1. Priority Queues
Priorities are necessary to fulfill the use case requirements outlined in section 3. This is accomplished by adding requests to different types of queues , where is the total number of queues in the distributed queue. Each queue can contain a maximum of items simultaneously (in other words is the maximum size of each individual queue), where an item is an individual entanglement request with its associated metadata, e.g. create_time, min_time, MHP timeout cycle. Each CREATE request is assigned a queue number by the scheduler (see Section E.3.1 below), and receives an absolute queue ID which is a tuple where indicates the designated queue (or, more abstractly, the queue ID of the entanglement request) and is a unique ID within . Equivalently, for a finite number of queues we will denote as the absolute queue ID or , and use to indicate the ID of the request.
The queue ID must obey the following properties:
- •
Total order: Items on each queue follow a total order of items waiting in the queue determined by .
- •
Arrival time: ID of an entanglement (CREATE) request is a function of its arrival time. Let and denote the create_time of entanglement requests 1 and 2, respectively. Then, let and denote their respective queue ID’s. If both requests are added to the same queue , and , then . That is, if a CREATE request arrives earlier, it will also receive a lower queue ID.
We will now outline the distributed queue establishment within DQP. For simplicity of exposition, we now assume there is only one queue, i.e., .
E.1.2. DQP Queue Establishment
The core objective of DQP is to obtain shared queues at both nodes, i.e. the items and the order of the elements in the queues are agreed upon. That is, both controllable end nodes and hold local queues and respectively, which are synchronized using the DQP. CREATE request additions to the queue can be made by either or invoking the DQP by the function , where is the entanglement request by CREATE message. ADD returns a tuple where indicated success or failure. Failure can occur if
- •
no acknowledgments are received within a certain time frame, i.e. a timeout occurs,
- •
the remote node rejects addition to the queue, or
- •
the queue is full.
Success means that the request to create entanglement is placed into and such that the following properties are satisfied:
- •
Equal queue number: If a request is added by as , then it will (eventually) be added at with the same absolute queue ID (and vice versa);
- •
Uniqueness of queue ID: If a request is placed into the queue by either or , then it is assigned a unique queue number. That is, if and reference two distinct CREATE requests, then ;
- •
Consistency: If and then both absolute queue IDs refer to the same request888This is implied by the previous two conditions, but added for clarity.;
- •
Fairness: If (or ) is issuing requests continuously, then also the other node (or ) will get to add items to the queue after (or ) in a “fair manner“ as determined by the window size, denoted as (). More precisely, if are CREATE requests submitted at , and are CREATE requests submitted at with and —all assigned to the same queue but not yet added—then the final ordering of the requests on the queue obeys with and .
Recall that each request receives a minimum to be executed time—a time buffer before the request may begin processing which takes into account the processing time to add it into the queue (denoted by the min_time)—which we will choose to be the expected propagation delay between and . The purpose of this minimum time is to decrease the likelihood or wants to produce an entanglement before the other node is ready. If either or begins processing early, no penalty other than reduced performance due to increased decoherence of the quantum memory results. Refer to Section E.1.4 on how this minimum time is passed between nodes.
We recall that in the current implementation of quantum network we have two nodes only. This implies that the queue establishment can be realized by one node being the master controller of the queue marshaling access to the queue, and the other the slave controller. Extensions to multiple nodes are more complex, and a motivation to consider heralding station-centric protocols in the future versions of the protocol. Also, as we have two nodes only, there is no need for the introduction of leader election or a network discovery mechanism. We leave this as future work.
E.1.3. DQP Sequence Diagrams
Figure 23 shows a DQP sequence diagram of adding an item to the queue containing a request to the distributed queue. Specifically, an item is an entanglement create request with its associated properties that is passed inside an ADD message within its REQ field, refer to Figure 24 for details.
Upon receiving an ADD message from master , a slave may choose to acknowledge the item with an ACK message, should validation pass, or reject it with the REJ message for any of the previously mentioned reasons. In the case that master never receives an acknowledgment (ACK) or rejection (REJ) message after a timeout, the item will be removed from the queue and no processing will occur on the request. Loss of ADD, REJ, and ACK messages in the distributed queue protocol result in retransmissions of the original ADD to guarantee the receipt of rejection and acknowledgement messages.
When the slave wishes to add an item to the queue, a message containing the request information and desired queue is included within the messages. Because the master controller has the final say on the state of the queue, a sequence number within the specified queue will be transmitted in return to the slave such that absolute queue IDs are consistent between the nodes.
E.1.4. DQP Packet Formats
Figure 24 presents the packet format for messages exchanged in the DQP. Schedule Cycle and Timeout Cycle of 64 bits is governed by the maximum number of MHP cycles in the scheduler. Purpose ID of 16 bits enables pointing to different applications and the total number of uniquely addressed applications and follows from the number chosen for IPv4. Create ID defines the identifier of locally created request. Number of pairs enables to request up to 2 pairs. Priority field of 4 bits is used as we enable 16 local queues composing the distributed queue and each one represents a priority lane. Initial Virtual Finish is used for weighted fair queuing.
E.2. Midpoint Heralding Protocol
The purpose of MHP is to create entanglement using a midpoint heralding protocol. The operation of the MHP is defined by Protocol E.2.
[TABLE]
[TABLE]
E.2.1. MHP Sequence Diagrams
The MHP sequence diagram is defined by two cases: the successful —see Figure 25, and unsuccessful one—see Figure 26. Specifically, there are two failure scenarios that may occur in the MHP protocol: queue mismatch error (Figure 26(a))—where the message consistency check fails at the midpoint—and single-sided transmission error (Figure 26(b)).
E.2.2. MHP Packet Formats
MHP relies on the exchange of the packets listed in the MHP sequence diagrams, see Figure 25 and Figure 26: GEN and REPLY.
GEN packet (Figure 27) is used by the midpoint to determine whether the nodes are consistent in their local information regarding their knowledge of the attempt at entanglement.
REPLY packet (Figure 28) is sent by the midpoint in the case of no error. It will include the senders’ submitted absolute queue ID (i.e. QID and QSEQ) and additionally pass on the submitted queue ID of the peer node (i.e. QIDP and QSEQP). The sequence number, SEQ, denotes the number of successful heralded entanglement generations that have occurred at the midpoint heralding station and allows the end nodes to keep track of the number of entangled pairs that have been generated. OT encodes the heralding signal from the midpoint upon successful operation and encodes errors in case of failures.
E.3. Entanglement Generation Protocol
The role of the Entanglement Generation Protocol (EGP) is to produce the required entanglement between two end nodes or otherwise declare failure.
E.3.1. Entanglement Generation Scheduler
We now proceed with the description of the scheduler—refer to Protocol E.3.1 for details. The EGP scheduler fulfills the following arbitrage functions, where we remark that for CREATE requests that demand multiple EPR pairs, only one request is added to the queue, and hence NEXT (function to select the next request from the local set of queues, see below) will return multiple pairs to be produced for the same request when called successively.
- •
GET_QUEUE(creq): Once a request has been submitted, GET_QUEUE deterministically chooses which queue to assign the CREATE request creq to. This may depend on the details of the request, such as for example , or as well as the purpose ID and priority.
- •
NEXT: Selects the next request from the local set of queues to serve, if any. Specifically, NEXT will determine:
- –
Flag, set to true when a request is ready to be served;
- –
Absolute queue ID (and corresponding request details) of request to be served;
- –
Parameters to use in the MHP depending on the number of type of outstanding requests;
- –
Communication and storage qubits, determined in cooperation with QMM.
[TABLE]
[TABLE]
E.3.2. EGP Sequence Diagrams
We proceed with the introduction of all message passing sequence diagrams for the EGP.
Figure 29 presents a sequence diagram for the EGP operation when performing emission multiplexing. In some cases (such as the CM use case) it is not necessary to wait for the REPLY message from the midpoint before attempting entanglement generation again if one simply desires to generate correlated bit streams.
Figure 30 shows a sequence diagram detailing the message flow should station A obtain information that it is behind as well as a timeline of the message exchange when EGP processes at both nodes exchange available quantum memory information. Sharing this information allows both nodes to know whether there are available resources in order to proceed with satisfying an entanglement request. In the absence of resources of either peer there is no use in photon emission. Simply, both nodes must be able to emit photons for the protocol to operate properly.
Imperfect message transmission may cause any of the GEN, REPLY, EXPIRE, REQ(E), and ACK messages to become lost or corrupted in transit between nodes. Depending on which messages are lost in the protocol, different actions are taken to prevent deadlock. lost EXPIRE or corresponding ACK results in a retransmission of the EXPIRE to ensure that OK messages are properly revoked at the peer node. Loss of a REQ(E) message or its corresponding ACK results in a retransmission of the REQ(E) to make sure that both nodes have up-to-date information of available resources.
Losing a GEN message is handled by the midpoint heralding station when only one GEN message arrives from an end node. In this case the REPLY message containing NO_CLASSICAL_OTHER (see Protocol E.2) is issued to alert the nodes of the failure. In this case no attempt at entanglement is made and the sequence number at the midpoint remains the same.
Losing a REPLY message from the midpoint that contains an outcome of 0 has no impact on or as seq is only updated when a successful attempt at entanglement occurs. When a REPLY message containing an outcome of 1 or 2 (for successful entanglement) is lost, the end node(s) that lost the message will continue attempting entanglement generation in subsequent polls by the MHP as there are outstanding pairs to be generated for the request. Upon successful receipt of any message from the midpoint (REPLY), the included SEQ will be ahead of the receiving node(s) seq and the loss will be detected. The detecting node will then transmit an EXPIRE message to its peer containing the old seq that did not agree with the SEQ received from the midpoint along with its new seq, so that any OK messages containing the missing set of sequence numbers are revoked at the peer.
E.3.3. EGP Packet Formats
Finally, we present the definitions of all messages being used by the EGP. Figure 35 describes the information passed from the EGP to the MHP during each periodic cycle, while Figure 36 shows the packet format for replies from the physical layer MHP to the EGP. Figure 32 and Figure 33, define EXPIRE and ACK messages, respectively, exchanged in entanglement request expiration sequence diagram described in Figure 30. Figure 34 shows the REQ(E) and ACK(E) packet formats exchanged by memory advertisement requests made by the EGP sequence diagram described in Figure 30.Figure 37 and Figure 38 present the format of OK messages passed from the EGP to higher layers, in case of create and keep request and measure directly request, respectively.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1(1)
- 2net (2018) 2018. Net SQUID. https://netsquid.org/ . (2018).
- 3sur (2018) 2018. SUR Fsara. https://userinfo.surfsara.nl/systems/cartesius . (2018).
- 4Abobeih et al . (2018) M. H. Abobeih, J. Cramer, M. A. Bakker, N. Kalb, M. Markham, D. J. Twitchen, and T. H. Taminiau. 2018. One-second coherence for a single electron spin coupled to a multi-qubit nuclear-spin environment. Nature Communications 9, 1 (Dec. 2018), 2552. https://doi.org/10.1038/s 41467-018-04916-z ar Xiv:1801.01196 · doi ↗
- 5Aharonov et al . (2000) Dorit Aharonov, Amnon Ta-Shma, Umesh V Vazirani, and Andrew C Yao. 2000. Quantum bit escrow. In Proceedings of the thirty-second annual ACM symposium on Theory of computing . ACM, 705–714.
- 6Amos (1974) D. E. Amos. 1974. Computation of Modified Bessel Functions and Their Ratios. Math. Comp. 28, 125 (Jan. 1974), 239. https://doi.org/10.2307/2005830 · doi ↗
- 7Aparicio et al . (2011) L. Aparicio, R. Van Meter, and H. Esaki. 2011. Protocol design for quantum repeater networks. In Proc. Asian Conference on Internet Engineering . ACM, Pattaya, Thailand.
- 8Awschalom et al . (2018) David D Awschalom, Ronald Hanson, Jörg Wrachtrup, and Brian B Zhou. 2018. Quantum technologies with optically interfaced solid-state spins. Nature Photonics 12, 9 (2018), 516.
