Patent Application
20240428110
The embodiments relate to an operating system for a quantum network nodes and execution of quantum network applications using such operating system, and, in particular, though not exclusively, to methods and systems for executing one or more quantum network applications on one or more quantum network nodes forming a quantum network and a software program product using such methods.
Quantum network architectures are based on quantum devices, i.e. quantum network nodes, that are capable of connecting over large distances in order provide new applications that are impossible to achieve using a classical communication network or that are better (e.g. more secure, more efficient) than their purely classical implementation. Examples of such quantum network applications include security enhancing applications such as quantum key distribution (QKD), improved clock synchronization, support for distributed sensing and distributed systems, as well as secure quantum computing in the cloud. To run a general quantum network application on a quantum network of connected quantum network nodes, the quantum network nodes need to be capable of producing quantum entanglement between quantum end nodes, or in short end nodes. Entanglement is a special property of at least two quantum bits (qubits), one held by each end node. Such entanglement can be consumed by an application as is, or be used to transmit qubits from one end node to the other using teleportation.
Additionally, a quantum network node needs be capable of executing local quantum operations on the qubits held by a quantum network node. For simple quantum applications such as secure communication these operations can be just a single measurement. For more complex quantum network applications at a higher stage of quantum internet development, however, these operations can include the execution of quantum gates and indeed full quantum computation on a quantum processor. Next to such quantum actions, many quantum network applications known to date require significant local classical processing, as well as classical communication between the end nodes Wehner et al, Quantum internet: A vision for the road ahead. Science, 362(6412):eaam9288, October 2018. Different types of end node hardware has been realized by experimental physics ranging from simple photonic devices on which the only operation is a measurement, to fully fledged quantum processors with a network interface.
Quantum network applications should be distinguished from quantum computing applications Cross, et al. OpenQASM 3: A broader and deeper quantum assembly language. arXiv preprint arXiv:2104.14722, 2021 in which quantum operations are sequentially executed on a hybrid computing systems. Up to now, demonstrations of quantum networking beyond QKD focused on hardware realizations Pompili et al. Realization of a Multinode Quantum Network of Remote Solid-State Qubits. Science 372, no. 6539 (Apr. 16, 2021): 259-64. Up to three quantum processors have been connected into a network at the hardware level, and demonstrations of quantum network applications beyond QKD have been performed using several photonic devices. Central to all these experiments is that the software to control the hardware was programmed in an ad-hoc fashion specific to the experiment into low-level control devices.
In order to advance quantum networks from a physics experiment to a fully-fledged quantum network system, quantum network nodes and an operating system for controlling such quantum network nodes are desired that allow a programmer to realize quantum network applications based on high-level software, and control entanglement generation over long distances in a scalable way. The high-level parts of the software for realizing such quantum network applications need to be platform independent, in order to be able to interact with a variety of potential candidates for future quantum network hardware technology. When designing such quantum network nodes and associated operating system, many challenges and design considerations arise, which can be roughly classified into three areas. A first challenge relates to the fundamental differences between classical and quantum information. A good example of this, is the phenomenon of quantum entanglement, which already at the physical layer forms a “connection” between two qubits held by different nodes. A second challenge relates to the technological limitations of so-called near-term quantum devices impose stringent demands on the performance of such a system. One example of such a limitation are limited lifetimes of quantum memories (microseconds up to seconds for network capable devices), which impose scheduling constraints on the execution of quantum operations. A third challenge relate to the fact that unlike in the study of classical operating systems today which take advantage of the existence of advanced computer architectures defining a specific interaction of software and hardware, there exists no general low-level quantum processor architecture.
Hence, from the above it follows that there is a need in the art for methods and systems for enabling the realization of a programmable quantum network. In particular, there is a need in the art for quantum nodes for a programmable quantum network and an operating system for controlling and programming such quantum nodes.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Functions described in this disclosure may be implemented as an algorithm executed by a microprocessor of a computer. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java™, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, in particular a microprocessor or central processing unit (CPU), of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, other programmable data processing apparatus, or other devices create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. Additionally, the Instructions may be executed by any type of processors, including but not limited to one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), System-on-Chip (SoC) or other equivalent integrated or discrete logic circuitry.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In a first aspect, the invention may relate to a computer-implemented method for executing one or more quantum network applications comprising classical code blocks and quantum code blocks on one or more quantum network nodes. In an embodiment, a quantum network node may include a classical computer system and a quantum computing system, wherein the quantum computing system may comprise one or more communication qubits and, optionally, one or more storage qubits.
In an embodiment, the method may include receiving a quantum code block associated with a first quantum network application by an operating system of a first quantum network node, the quantum code block comprising quantum operations, the quantum operations including local quantum operations not related to entanglement generation and at least an entanglement generation operation for entanglement generation between the first quantum network node and a second quantum network node, the first and second quantum network nodes being part of a quantum network; and, executing at least part of the quantum operations on the quantum computing system via a first subsystem of the operating system, wherein if a quantum operation is relates to an entanglement generation operation, sending the entanglement generation operation to a second subsystem of the operating system for preparing execution of the entanglement generation operation.
In an embodiment, the second subsystem may be configured to prepare execution of the entanglement generation operation as a background process of the operating system, while the first subsystem continues executing local quantum operations.
In an embodiment, the method may further include blocking the execution of the local quantum operations associated with a first quantum network application by the first subsystem, if a first local quantum operation requires access to an entangled qubit associated with the entanglement generation operation.
In an embodiment, the method may include executing the entanglement generation operation by the second subsystem based on a timeslot in a network schedule provided to the first and second quantum network node.
In an embodiment, the entanglement generation operation may be executed as a kernel process of the operating system.
In an embodiment, the method may include unblocking execution of the quantum operations by the first subsystem if entanglement between the first and second quantum network node is established.
In a further embodiment, the method may include providing access to a communication qubit of the quantum computing system of the first quantum network node that is entanglement with a communication qubit of the quantum computing system of the second quantum network node.
Hence, the invention relates to executing a quantum network application by an operating system of a quantum network node which is configured to separately process local quantum operations using a first subsystem of the operating system and entanglement generation requests using a second subsystem of the operating system, wherein the entanglement generation requests are processed by the operating system based on a network schedule to coordinate entanglement generation between quantum network nodes.
In an embodiment, the local quantum operations may be part of a user process and the entanglement generation operation by the second subsystem part of a network process. The user process and network process associated with a quantum network application define logical entities that can be scheduled and processed by the operation system of the quantum network node. It provides the ability to implement scheduling policies which can be used to address the issue of scheduling user processes and network processes to optimize fidelity and throughput. The strict separation between local user processes and network processes enable execution of quantum network applications on multiple quantum network nodes of a quantum network through scheduling mechanisms and scheduling policies. Further, the user processes and the network processes can be scheduled such that they can generate entanglement between to quantum network nodes and consume that entanglement as fast as possible to ensure the highest fidelity.
In an embodiment, the preparation of the execution of the first entanglement generation operation may include: sending a request for entanglement over a classical communication link to the second quantum network node; or, receiving a request for entanglement over a classical communication link from the second quantum network node. Hence, a quantum network node may be a node requesting entanglement generation or a node receiving an entanglement generation request from another node.
In an embodiment, the first and second quantum network nodes may be connected to each other via an optical medium, preferably an optical fibre. In this embodiment, entanglement between communication bits of different nodes may be achieved via an optical interface such as an optical fibre.
In an embodiment, the network schedule may include one or more time slots for coordinating entanglement generation between the one or more quantum network nodes.
In an embodiment, the one or more time slots of the network schedule may signal the operating system at what time the second subsystem has access to the quantum hardware of the quantum network node.
In an embodiment, the network schedule may be a time division multiplexing schedule. In another embodiment, the network schedule may be a time-division multiple access TDMA schedule. In yet another embodiment, the network schedule may be statistical multiplexing schedule.
In an embodiment, the network schedule may be used by the operating system to schedule the user process and the network process based on a scheduling policy. In an embodiment, in a scheduling policy, a higher priority network process may take precedence over a lower-priority user process, if the user process and the network process become ready at the same time instance.
In an embodiment, the executing of the entanglement generation operation may include: allocating the ownership of the communication that is used in the entanglement generation to the network process. In another embodiment, the executing the entanglement generation operation may include: transferring ownership of the communication qubit to the user process if entanglement between the communication qubit and a communication qubit of the second quantum network node is established.
Ownership transfer of a qubit from a user process to a network process (or viz versa) may be implemented logically by updating the qubit owner and allocating a new virtual address in the new process' virtual address space rather than physically moving quantum data in the memory in order to minimize fidelity losses due to imperfect hardware operations and additional latency.
In an embodiment, a central network controller may provide the one or more quantum network nodes with a network schedule for coordinating entanglement between the quantum network nodes.
In an embodiment, the quantum network application may include classical code blocks and quantum code blocks wherein the classical code blocks include classical operations of a high-level computer language and wherein the quantum code blocks include quantum operations of a quantum assembly language.
In an embodiment, the quantum assembly language may include one or more operations for entanglement generation.
In an embodiment, the method may further include during the blocking of the execution of the local quantum operations associated with a first quantum network application, executing local quantum operations associated with a second quantum network application or sending a further entanglement generation request associated with a second quantum network application to the second subsystem.
Thus, in contrast to the executing of quantum applications that are executed on a conventional quantum computer which executes programs sequentially, the execution of quantum network applications according to this embodiment, allow multitasking as a quantum network application may have to wait for some classical message exchange to happen between the programs running on different end-nodes to proceed. Such idle time will leave spare capacity that can be potentially used to execute other applications. Such multitasking will lead to increased application throughput when compared to sequential execution without a significant impact on the quantum execution quality.
In an embodiment, executing the entanglement generation operation may include: after execution of the first code block sending a notification message to the quantum network application the end of execution, preferably the notification message comprising results of the execution, the results of the execution including at least one of: a measurement of an entangled communication qubit and/or information on one or more stored entangled communication qubits.
In a further aspect, the invention may relate to a computer-implemented method for executing a quantum network application comprising classical code blocks and quantum code blocks wherein the method may comprise: executing a first classical code block, the execution including registering the quantum network application with an operating system of a first quantum network node, the registration including registration information for resource requirements for the quantum network application, preferably registration information including resource requirements such as a bandwidth for entanglement generation, a socket identifying a second quantum network node and a fidelity associated with the execution of the quantum network application; sending a first quantum code block to the first quantum network node, the first quantum code block comprising quantum operations including local quantum operations not related to entanglement generation and one or more entanglement generation requests for entanglement generation between the first quantum network node and the second quantum network node; receiving a notification from the first quantum network node, that the execution of the first quantum code block has ended, the notification including one or more execution results of the execution of the code block, the one or more execution results including information about one or more measured communication qubits and/or information about one or more stored entangled qubits; executing a second classical code block of the quantum network based on the execution results.
In an embodiment, the classical code blocks may include classical operations of a high-level computer language and wherein the quantum code blocks include quantum operations of a quantum assembly language, preferably quantum assembly language comprising instructions for entanglement generation.
In a further aspect, the invention may relate to a quantum network node system for executing one or more quantum network applications comprising classical code blocks and quantum code blocks, the quantum network node system may comprise a classical computer system and a quantum computing system comprising one or more communication qubits and, optionally, one or more storage qubits system.
In an embodiment, the classical computer system comprising a memory device including computer-executable instructions and a processor connected to the memory device, wherein the processor is configured to perform executable operations.
In an embodiment the executable operations may include: receiving a quantum code block associated with a first quantum network application by an operating system of a first quantum network node, the quantum code block comprising quantum operations, the quantum operations including local quantum operations not related to entanglement generation and at least an entanglement generation operation for entanglement generation between the first quantum network node and a second quantum network node.
In an embodiment, the executable operations may include: executing at least part of the quantum operations on the quantum computing system via a first subsystem of the operating system, wherein if a quantum operation is relates to an entanglement generation operation, sending the entanglement generation operation to a second subsystem of the operating system, the second subsystem preparing execution of the entanglement generation operation as a background process of the operating system, while the first subsystem continues executing local quantum operations;
In an embodiment, the executable operations may include blocking the execution of the local quantum operations associated with a first quantum network application by the first subsystem, if a first local quantum operation requires access to an entanglement associated with the entanglement generation operation.
In further embodiment, the executable operations may include executing the entanglement generation operation by the second subsystem based on a timeslot in a network schedule provided to the first and second quantum network node, preferably the entanglement generation operation being executed as a kernel process of the operating system.
In yet a further embodiment, the executable operations may include unblocking execution of the quantum operations by the first subsystem if entanglement between the first and second quantum network node is established.
The executable operations may also include providing the local quantum operation access to a communication qubit of the quantum computing system of the first quantum network node that is entanglement with a communication qubit of the quantum computing system of the second quantum network node.
In an embodiment, the executable operations may further comprise any of the methods steps as described above.
In a further aspect, the invention may relate to a computer-implemented method for executing a quantum network application comprising classical code blocks and quantum code blocks comprising: executing a first classical code block, the execution including registering the quantum network application with an operating system of a first quantum network node, the registration including registration information for resource requirements for the quantum network application, preferably registration information including a context, a bandwidth for entanglement generation, a socket identifying a second quantum network node and a fidelity associated with the execution of the quantum network application; sending a first quantum code block to the first quantum network node, the first quantum code block comprising quantum operations including local quantum operations not related to entanglement generation and one or more entanglement generation requests for entanglement generation between the first quantum network node and the second quantum network node; receiving a notification from the first quantum network node, that the execution of the first quantum code block has ended, the notification including one or more execution results of the execution of the code block, the one or more execution results including information about one or more measured communication qubits and/or information about one or more stored entangled qubits; and, executing a second classical code.
In an embodiment, the method may further include sending a second quantum code block to the first quantum network node, wherein the second quantum code block comprises quantum operations for measuring one or more stored entangled qubits that were stored during the execution of the first quantum code block.
In an embodiment, the classical code blocks may be executed by a host system and the quantum code blocks may be executed by the operating system of a quantum network node.
The execution results may include measurements of one or more qubits or information about a communication qubit that is not measured and stored in the quantum memory. In an embodiment, the execution results may include qubit metadata. For example, in an embodiment, the qubit metadata may include at least part of the qubit metadata that is managed by a quantum memory management unit (QMMU) of the operating system of the quantum network node, such as ownership of a qubit and/or transfer of ownership of a qubit.
In an embodiment, the classical code blocks may include classical operations of a high-level computer language and the quantum code blocks may include quantum operations of a quantum assembly language, preferably quantum assembly language comprising instructions for entanglement generation.
The invention relates to an architecture for a quantum networked operating system that is executed on quantum nodes forming a quantum network. The quantum networked operating system includes methods and systems for quantum memory management, scheduling different types of quantum operations, as well as an interface to different drivers addressing several possible quantum hardware architectures. The quantum networked operation system may be implementation of quantum nodes that use quantum hardware based on Nitrogen-Vacancy Centers in Diamond.
Quantum network applications should be distinguished from quantum computing applications in that a programmer may ask for an arbitrary interleaving of such quantum and classical actions at different quantum network nodes that may depend on each other. Moreover, in order to implement such applications, independent programs may be written for each quantum network node, which only interact with each other by passing classical or quantum messages using e.g. entanglement of qubits. This way, security sensitive network applications may be realized just as in the classical domain, but prohibits a global orchestration of the quantum execution.
As a consequence of the need to for continuous interaction between the classical parts (the classical code blocks) and quantum parts (the quantum code blocks) of a quantum network application, both the classical and quantum state needs to be kept alive, i.e. stored in a quantum memory, such that for example quantum instructions can be executed depending on messages from a remote quantum network node. This is in sharp contrast to conventional quantum computing applications, wherein the quantum part of a program is compiled and sent to the quantum processor to be executed in one batch, concluding in a measurement terminating the quantum execution.
Further, quantum network nodes may be configured as end-nodes or as intermediary nodes, e.g. quantum repeater nodes, in order to generate entanglement between end nodes separated by long distances. Such repeater nodes can be simple automated nodes, or controllable nodes capable of—for example—on demand entanglement generation or higher-level decision making. In the latter case, quantum repeater nodes are capable of executing similar actions as end nodes—without the need to realize universal quantum computation. A typical quantum repeater protocol may include actions such as: producing entanglement with neighbouring repeater nodes, executing a restricted class of local quantum operations, and basic classical communication and computation in order to control entanglement generation. From a hardware perspective, possible realizations of quantum repeaters have been suggested using the same type of quantum processors that are also used for end nodes, or simpler devices not capable of universal quantum computation.
Hence, in that case the invention may relate to a computer-implemented method for executing a quantum repeater application comprising quantum code blocks on one or more quantum network nodes, each quantum network node including classical computer system and a quantum computing system comprising one or more communication qubits and one or more storage qubits, the method comprising:
The invention may also relate to a computer program product comprising software code portions configured for, when run in the memory of a computer, executing the method steps according to any of process steps described above.
The invention will be further illustrated with reference to the attached drawings, which schematically will show embodiments according to the invention. It will be understood that the invention is not in any way restricted to these specific embodiments.
The embodiments in this disclosure relate to an operating system for a programmable quantum network node. Such operating system will be referred to as a quantum node operating system or in short QNodeOS. Whilst operating systems for quantum computers already exist, introducing quantum communications between quantum network nodes require new challenges in memory and process management for the quantum network nodes. In particular, a quantum node operating system needs to be able to run quantum network applications, while maintaining the quality of the quantum execution in terms of its fidelity. As will be described hereunder in more detail, this problem can be solved through close cooperation between networking, process management and memory management. Although a quantum network protocol stack including a link layer and network layer is known from Dahlberg et al, A link layer protocol for quantum networks, in ACM SIGCOMM 2019 Conference, SIGCOMM '19, page 15, New York, NY, USA, 2019. ACM and Kozlowski, et al, 2020, Designing a quantum network protocol. In Proceedings of the 16th International Conference on emerging Networking Experiments and Technologies (CoNEXT '20). Association for Computing Machinery, New York, NY, USA, 1-16. These schemes assume coexistence within a more advanced software system however do not describe how the protocol stack is integrated with a local resource management nor do they consider any application execution model. Hence, substantial challenges for quantum hardware resource management both on a fundamental and technical level still exist in the prior art.
A first challenge relates to memory management, which is necessarily more complicated on a quantum network node in a quantum network as compared to a single quantum computing node executing only local applications. For example, a quantum network node needs the quantum memory to persist between separate quantum code blocks. In a quantum computer that is not connected to a network, the most optimal quantum memory management strategy is to execute blocks of code in batches such that no quantum memory needs to persist between them. Such strategy is possible in a non-networked scenario as one can include all classical logic within such a block a priori, but not for distributed quantum network applications. Quantum network applications, in general, need to wait, with a live quantum state being held in memory, for classical input from the other node. Even in the simple case of teleportation Bennett, et al. Teleporting an unknown quantum state via dual classical and Einstein-Podolsky-Rosen channels, Physical review letters 70.13 (1993): 1895, the receiver needs to hold its qubit waiting for the two bits of information that will indicate the required Pauli correction. It is not, in general, possible to include all such input a priori. Therefore, a quantum node operating system requires a quantum memory manager that allows for a quantum memory to persist between quantum code blocks of the same application.
A second challenge relates to resource scheduling. Quantum networks will require a lot of coordination between the quantum network nodes. Nodes have finite resources so carefully allocation is desired to execute users' applications. The resource management strategy needs to be coordinated so that end-nodes have access to the right resources at the right time to execute the application successfully and efficiently. Furthermore, classical communication between quantum network nodes is needed to synchronize and schedule resources. This will remain a challenge even in the long-term wherever resources are limited, but it is particularly challenging in the near-term where the resource constraints are significant.
For example, current networked hardware is limited to very few qubits (for example fewer than ten qubits) and only a few (e.g. only one qubit on currently employed NV platforms) of the qubits can actually be used for computation or communication (the rest is for storage only). The communication qubit limitation is particularly challenging as it is shared between local computation and network demands. In that case, only one of these activities can execute at any time per communication qubit and if a platform only has one such qubit, computation and networking are mutually exclusive activities. This may be further complicated by the fact that the network schedule requires accurate synchronization with other nodes of the network. This means that networking cannot be arbitrarily scheduled and if a node misses its allocated networking time, the other nodes will have wasted their resources.
Furthermore, the lifetime of the quantum memories is currently very short (e.g. around 300 ms). This means that distributed resources must be allocated carefully as it is easy to starve an application if its remote peer allocates its resources elsewhere in that small window of time. This is even more likely to happen when running multiple independent applications on each node. Additionally, the network itself will be significantly resource constrained and will require its own careful and time-sensitive resource management. This means that in the near-term, resource scheduling must be carefully coordinated between all end-nodes involved as well as the network itself.
A third challenge relates to the decoherence, i.e. the process that limits the lifetime of quantum memories. Decoherence is the gradual process of losing information due to uncontrolled environmental interactions. A lifetime is often stated as an upper bound, but it is important to note that the quality, i.e. fidelity, is not constant throughout this time. The number usually cited as a lifetime is the time after which the quantum state can no longer be considered quantum at all, but the fidelity degrades steadily the entire time. This means, that for practical applications, qubits, in particular when they are entangled, must be consumed very quickly. Depending on the quality of execution required by the application, this time may be longer or shorter. Therefore, not only is the memory lifetime finite and short, the practically usable timescales are even shorter if the user requires very good quantum fidelity.
The invention aims to provide a quantum node operating system for quantum network nodes in a quantum network that provide solutions to the above-mentioned technical challenges.
In particular, the embodiments described in this application relates to a quantum node operating system that provides the user with the useful resource abstractions and manages the hardware resources for efficient application execution by a quantum network node that is part of a quantum network. In addition to standard classical performance metrics such as latency and throughput, the performance of a quantum application is also determined by the quality of quantum execution. This quantum quality is generally measured by the fidelity 0≤F≤1, where a higher value corresponds to higher quality. For a quantum state, F measures the quality with respect to an ideal state. For a quantum gate or measurement, it measures the quality of execution, averaged over all possible states that it could be applied to. For a specific application, F can be translated into its performance (e.g. how much key could be produced in QKD, or the success probability of the application). Thus, efficient execution of a quantum network application means that a quantum network node operating system is capable of delivering a fidelity (minimize decoherence) that satisfies the application's requirements whilst optimizing for the conventional metrics like latency and throughput across multiple applications from multiple independent users.
The embodiments in this disclosure aim to provide a quantum network node operating system which enables a quantum network application to achieve sufficient fidelity of quantum execution and decoherence can be minimized. To that end, the embodiments provide schemes for co-scheduling of local operations with network operations such that decoherence can be minimized. Additionally, the embodiments provide an execution model for a quantum network wherein the quantum network application includes classical code blocks and quantum code blocks. Even though perfect quantum fidelity is not required, poor fidelity will lead to poor performance or even cause the application to abort. However, if that was the only requirement all resources at all the nodes in the network could be reserved for a single application at a time and execute them sequentially just like one would execute applications on a quantum computer. Therefore, the secondary goal of the quantum node operating system is to optimize application latency and throughput across multiple applications from multiple independent users. This will require careful resource management mechanisms and policies, both local and distributed, to address the challenges outlined above.
Further, the quantum node operating system is configured to abstract the underlying quantum hardware resources from the user's applications. Preferably, these abstractions are useful for a programmer. Firstly, this means that they are independent from the quantum hardware platform they are running on. However, just like in classical devices, it may sometimes be useful to expose platform specific details if this enables platform-specific optimizations that would be otherwise unavailable (similar to the march option available in classical compilers). Secondly, in light of the challenges, in particular the significantly constrained resources and short timescales, useful also means that the quantum node operating system provides options to the programmer to help optimize resource usage whilst maintaining platform independence. For example, different applications may have different fidelity thresholds for operation and quantum network protocols on some platforms can achieve higher entanglement generation rates at lower fidelities and thus the operation system may be configured to expose this protocol stack option directly to the application.
Each end-node may be configured to execute single-node application 1121,2, which may include classical information processing and quantum information processing. This way, during execution of a single-node application by a first end-node, a quantum connection between the first-end node and another second end-node may be established so that at least part of the quantum information processing may be performed by the second end-node. To establish quantum connections between nodes in the network, the classical communication channels between end nodes may be used to exchange signalling information 114 for setting up and tear down quantum connections between the nodes. This way, applications executed on different end-nodes of the quantum network may communicate with each based on exchanging classical messages over the classical connections and quantum (entanglement) messages over the quantum connections. The transmission and processing of quantum messages between nodes in the network are managed by a quantum node operating system 1041,2 also referred to in short as QNodeOS.
The qubits may be controlled using a variety of signals depending on the physical platform used. For example, for nitrogen vacancies NV in diamond, qubits may be controlled using microwave pulses and laser pulses. The chip-level control of the qubits obeys hard real time constraints and timing precision (nanosecond precision with sub-nanosecond jitter), and may be implemented using waveform generators driving the microwave sources and lasers to interact with the qubits. In turn, custom electronics assisted by a dedicated microcontroller, for example FPGA-based controllers, may be used to control the waveform generators and lasers.
The quantum network node further comprises a quantum node operating system 212 running on the classical processing unit, which provides an interface between the quantum network applications and the low-level quantum hardware of the quantum processing unit. Further, the one or more applications, the quantum network protocol stack of the quantum network node operating system, and the classical control hardware of the quantum hardware are connected to their peers over classical channels (CC). The quantum hardware is connected to its peers over quantum channels (QC).
In this application, a quantum network application may comprise several programs, each running at a different quantum network node as shown in
Results of this processing are used as input to the quantum code blocks which are handled by the quantum node operating system and executed on the quantum hardware. Quantum code blocks include low-level operations associated with local quantum computations, quantum measurements or quantum entanglement generation with remote quantum nodes, executed by the quantum hardware. The output of the quantum code blocks (e.g. measurement outcomes or entanglement information) may be returned to the application to be used in further classical processing, which, in turn may provide new input to the next quantum block.
For example, a first classical code block 3021 may represent classical operations including: setting up application parameters, agree on application and entanglement parameters with remote end-node by exchanging classical messages, execute any time-intensive classical logic that precedes the quantum code blocks and prepare inputs for the quantum code block (which may depend on information received from a remote end-node). A first quantum code block 3041 may include quantum operations including: initialized qubits, generate entanglement, execute local quantum operations on qubit in memory (quantum gates, measurements); return measurement outcomes (if qubits were measured) or entanglement information (if qubits are to be stored in quantum memory). A second classical code block 3022 may represent classical operations including: process output from quantum code block (which may be time-intensive if there are no live quantum states in the quantum memory) and exchange classical message with remote end-node to prepare input for next code block (which may be measurement parameters, e.g. basis, for a quantum state currently stored in the quantum memory). A second quantum code block 3042 may include quantum operations including: execute local operations based on input from classical code block on qubits that were stored in memory from the previous quantum code block and generate more entangled qubits if required. The processing of the classical and quantum code blocks associated with a quantum network application may continue until the application has finished.
Hence, the example of
Thus, during the execution of a quantum network application, quantum node operating system 212 controls the execution of the quantum code blocks. To that end, the quantum node operating system may include a local processing stack 214 (a local subsystem) for managing local quantum operations and classical operations and a quantum network stack 216 (a network subsystem) for managing quantum communication (entanglement) between nodes.
Given that generating an EPR pair on a link, i.e. a pair of entangled qubits that are in a Bell state, requires that both quantum network nodes start an entanglement attempt simultaneously, the network schedule may be configured such that the quantum network node operation system assigns a higher priority to a quantum network process than any other process. For example, as shown in
The central controller may transmit network schedules to quantum network nodes 4041,2 so that pairs of nodes are able to establish an entangled quantum communication link in a synchronized way. To that end, a network schedule may be provided to the quantum network stack 4061,2 of the quantum node operating system that runs on the quantum network node. The quantum network stack may subsequently manage entanglement generation between different quantum nodes based on the network schedule.
Resource coordination for entanglement generation between two quantum network nodes in a network of quantum network nodes requires time synchronization of processes between quantum network nodes at different levels. To schedule and coordinate resources for quantum communication to different quantum network nodes, the network scheduling protocol, may be used to achieve the required synchronization of processes on the application level and link level. The scheduling protocol requires clocks of the quantum network nodes that are being used to be synchronized, wherein the accuracy of the synchronization will depend on the application and network protocol requirements.
Additionally, the physical layer entanglement generation protocols require timing synchronization between neighbouring quantum nodes that engage in a qubit entanglement generation process. These physical layer protocols require synchronisation with much higher precision, e.g. of the order of nanoseconds with sub-nanosecond jitter, so that a further synchronization process will take place during the process of establishing an entanglement. Synchronization schemes for achieving accurate synchronization at the physical layer of the quantum network node are known. For example, the white rabbit synchronization protocol https://white-rabbit.web.cern.ch/ may be used.
As already briefly described with reference to
In an embodiment, a network quantum assembly language comprising instructions for entanglement generations may be used as an interface language which the host layer applications may use to interact with quantum network node operating system. In another embodiment, executable machine code may be used to by the host layer application to interact with the quantum network operating system. The quantum assembly language may include an instruction set including operations for local quantum computing and operations for quantum networking. Further, the quantum assembly language may provide a useful set of OS abstractions for a networked quantum OS. The quantum assembly language may be platform-independent with the option to use a flavour for hardware platform specific optimizations. Furthermore, the quantum assembly language may expose several options for the programmer to help optimize resource usage. In addition to exposing the option to choose the fidelity of network entanglement, the quantum assembly language may also allow the programmer to combine classical control logic with quantum instructions to minimize back-and-forth communication when no external input is required. This feature is particularly valuable when a program is waiting for entanglement to be generated. The quantum assembly language instruction set and its execution by the quantum network node operating system is described hereunder in greater detail with reference to
To run quantum code blocks of a quantum network application on the quantum network node operating system, the host layer may first register a quantum network application 5081,2 with the operating system. Upon registration, the operating system may create a user process and a context which will be used to store state (e.g. metadata) for that process and returns a new application ID, which may be used by the host layer to identify instructions belonging to the quantum network application. Once registered, the application network application may execute the fully classical code blocks locally on the host layer CPU(s) and may transform the quantum real-time code blocks in a format suitable for processing by the quantum network node operating system. In an embodiment, the quantum real-time code blocks may be transformed into instructions of a quantum assembly language routine 510, which are forwarded to the quantum network node operating system running on the QNPU. In another embodiment, the quantum real-time code blocks may be transformed into operations of executable machine code. A first subsystem, a local subsystem, of the quantum network node operating system may execute the instructions, wherein instructions related to entanglement generation are forwarded to quantum network stack 522, a second subsystem of quantum network node operating system. Local quantum operations, such as quantum gate operations, associated with the user process and entanglement generation operations, associated with a network process and handled by a quantum network stack, are then issued to the quantum hardware 506 via a suitable quantum hardware driver 526 for that particular quantum hardware platform, wherein the scheduling of the user and network processes are based on a network schedule that is provided to the quantum network node.
The quantum network node operating system provides an OS abstraction layer for the QNPU that is capable of communicating to the quantum hardware 506. It may be implemented entirely in software running on a classical CPU, or parts of its functionality may be implemented in classical hardware. An interface 528 may be used to connect the processor 516 to a low-level electronic control system that controls the qubits. In another embodiment, the processor may be integrated with the quantum hardware, so that the processor can directly operate on the quantum hardware.
The quantum real-time code blocks 510 may be offloaded by the host to the operating system via host communication handler 512, which links the routine to the application's user process, which is created when the host layer first registered the application. The user process may be associated with context information, such as the process ID, parent application ID, scheduling state and priority, program counter, and pointers to the process data structures and instructions. The user process is then handed over to a scheduler 514 of the operating system. The scheduler's responsibility is to schedule processes based on scheduling information, e.g. a network schedule, which may be provided by a central controller of the quantum network to which the quantum network node belongs to. In addition to user processes, the operating system also has a persistent kernel network process. Once the user process is selected by the scheduler, it is handed over to the processor 516 which executes the instructions of the user process, wherein the processor may step through the instructions and perform one of the following actions:
The user process does not execute any networked instructions itself. Instead, when the processor is running the kernel network process, it will fetch instructions from the quantum network stack, issue them to the quantum hardware, and return the results back to the stack as will be explained hereunder in more detail with reference to
The quantum network node operating system also has a quantum memory management unit 626 (QMMU) for persistent memory management. The QMMU may implements basic memory management functionality, including identification of virtual address spaces for different processes, allocation of qubits to these processes, and ownership transfer of a physical qubit from one processes to another process. The virtual quantum memory address space may isolate the qubit address spaces of different operating system processes, e.g. different user processes and different network processes. Ownership transfer is an inter-process communication (IPC) mechanism for passing qubits between different processes, for example between a user process and a network process. Since quantum states cannot be copied due to the no-cloning theorem, this is the only valid IPC for passing quantum data between address spaces. Ownership transfer of a qubit from a user process to a network process (or viz versa) may be implemented logically by updating the qubit owner and allocating a new virtual address in the new process' virtual address space rather than physically moving quantum data in the memory in order to minimize fidelity losses due to imperfect hardware operations and additional latency.
Thereafter, the host system may execute the quantum network application by executing a first classical code block at the host system and by providing a first quantum code block to the quantum network node (step 556). Here, the classical code blocks may represent software routines which may be written in a high-level programming language which may be executed on a classical computer of the host system. The quantum code blocks may include quantum operations and time-critical classical operations. Quantum code operations may include local quantum operations not related to entanglement generation and/or at least an entanglement generation operation for entanglement generation between the quantum network node and a further quantum network node. Here, the quantum network nodes may be part of a network of quantum network nodes, which may be provided with a network schedule that can be used for coordinating entanglement generation between quantum network nodes. In an embodiment, the quantum code block may include instructions of a quantum assembly language that include operations for generating entanglement, which can be processed by a processor of the quantum network node. In an embodiment, the processor may be part of a quantum network node operating system as described with reference to the embodiments in this application. In another embodiment, the quantum code block may be executable code, e.g machine code, which can be executed by a processor of the quantum network node.
When receiving the quantum code block, the quantum network node may execute quantum operations on the quantum hardware which may include communication qubits for entanglement generation and storage qubits, on which quantum gates can be applied. The qubits can be measured and the resulting outcome may be stored in a classical memory by the processor. When entangled, a communication qubit of the quantum network node may be connected through a quantum channel (a quantum communication link) to a further quantum network node. The quantum channel may also include classical communication which is needed for synchronization, phase stabilization or other mechanisms.
When the execution of the quantum operations of the first quantum code block is finished, the quantum network node may send a notification message back to the quantum network application (step 560). The notification message may include first execution results, e.g. information on the outcome of the execution of the first quantum code block. These first execution results may be used when executing a second classical code block. The first execution results may include measurements of one or more qubits or information about a communication qubit that is not measured and stored in the quantum memory. In an embodiment, the execution results may include qubit metadata. For example, in an embodiment, the qubit metadata may include at least part of the qubit metadata that is managed by a quantum memory management unit (QMMU), such as ownership of a qubit and/or transfer of ownership of a qubit. These metadata are described in greater detail with reference to
The second classical code block may be executed and a second quantum code block may be sent by the application to the quantum network node (step 562), which may start executing the quantum operations of the second quantum code block (step 564). These operations may include local operations on communication qubits that are stored during the execution of the first quantum code block. In some embodiments, a memory update message may be sent to the quantum network application (step 566) to signal for example, that a particular stored communication qubit has been measured and to provide the measured value to the application. This message may be sent to the application during the execution of the second quantum code block. Thereafter, when the execution of the quantum operations of the second quantum code block is finished, the quantum network node may send second execution results back to the quantum network application (step 568),
As can be seen from
Hence, the ability to control the scheduling of resources between user processes and network processes is achieved by assigning a kernel process exclusively to network processes and by limiting user processes to local quantum instructions only. Thus, if an application needs entanglement from the network, the user process executed by processor 512 will submit an entanglement request 518 to the quantum network stack 522. In some embodiments, this request may be included in the instruction set of a quantum assembly language, which assumes a quantum network stack that handles all entanglement generation requests asynchronously with respect to other local quantum operations of the user process. The network process will then coordinate the requested entanglement generation, with the rest of the network and eventually return an entangled qubit to the user process. Examples of such coordinated entanglement generation will be described hereunder with reference to
Hence, the quantum network node operating system defines user processes including local quantum operations and associated context and network operations which are scheduled by the scheduler and processed by the processor. If during the processing of a user process, a request for entanglement generation is requested, the request is forwarded to the quantum network stack which handles the entanglement generation request independently from the processing of the user process. The handling of the entanglement generation request by the quantum network stack may be referred to as a quantum network process or in short a network process. This network process may be executed by the scheduler based on information in the network schedule that is provide to the different quantum network nodes. The network schedule signals the scheduler at what time instance the processor may optimally execute the network process as described with reference to
Thus, a user process can continue executing local instructions even after a entanglement generation request has been forwarded to the quantum network stack. The entanglement generation request does not block execution of the user process, which increases instruction throughput during times when the network process cannot proceed. At the same time, network processes may be executed by the quantum network stack based on the network schedule. This is important because entanglement generation requires careful synchronization with a neighbouring node (and possibly the rest of the network) and thus requires execution at precise moments in time which are not controlled or even known by the user process. By separating the quantum network process from the user process, synchronization may be centrally controlled by the network stack for all of the entanglement requests that are pending at that particular node. Further, the process status of the entanglement generation rests allows the scheduler 514 to schedule it based on the network schedule while accounting for the local scheduling requirements of the other applications running on that quantum network node. Additionally, it gives the option to use scheduling policies to change its behaviour.
If an entangled qubit pair is generated by the network process, the entangled qubit may be handed over to the blocked user process. Entanglement requires metadata (entanglement metadata), which is generated by the quantum network stack to account for the non-local nature of entanglement. For example, an entanglement identifier allows an application to identify which qubits at two separate nodes are entangled with each other. Various other entanglement parameters such as the goodness, i.e. the estimated fidelity, may be used as well. This information may be provided by the network protocol stack.
Thus, to hand an entangled qubit over to a user process, two steps are executed:
Once all the entangled pairs that the user process was waiting for have been delivered, the scheduler will wake the user process and allow it to execute up to completion or until the next entangled qubit is required.
The quantum network nodes in the quantum network may be provided with a network schedule for coordinating entanglement generation between quantum network nodes in the quantum network. Further, a quantum network node may include a quantum network node operating system comprising a local subsystem for executing local quantum operations which are not related to entanglement generation and a quantum network subsystem for executing operations relating to entanglement generation.
A quantum network application may be executed on by an application layer running on a host computer, which may send quantum routines represented by quantum code blocks to the operating system of a quantum network node, which may executed the quantum code blocks based on user processes executed by a local subsystem and network processes executed by a quantum network subsystem (the quantum network stack).
The quantum network subsystem, which has a persistent kernel process associated with it, may start preparing the requested entanglement generation as a background task in order to coordinate the entanglement generation with the other quantum nodes before the network process is scheduled to run, i.e. execute the entanglement generation. This processing may include generating entanglement metadata and sending a request for entanglement over a classical communication link to a quantum network node to notify the quantum network node that entanglement is desired. During the preparation of the entanglement generation by the quantum network subsystem, the local subsystem of the operating system may continue processing local operations associated with the user process until an operation requires the entanglement, e.g. a measurement of an entangled qubit pair. At that moment, the user process may be blocked (step 806) and the processor may wait for the scheduler to signal that the network process can be started. The scheduler may then use a time slot as defined in the network schedule to start the network process (step 808) so that the entanglement between both quantum network nodes can be realized.
The processor may then start executing the quantum network operations of the network process based on the entanglement metadata to establish entanglement with the other quantum network node (step 810). When starting the network process, the QMMU may transfer ownership of a communication qubit that is going to be used in the entanglement generation to the network process (step 812). From that moment on, only the network process has access to the quantum hardware (in particular the communication qubit that is going to be used in the entablement generation) so that execution of the network process does not collide with the execution of the user process.
The network process for establishing entanglement may require multiple attempts. Hence, the network process will repeat the process in a loop until entanglement is generated (step 814) within a predetermined time as signalled by the network schedule to the scheduler of the operating system. If entanglement generation does not succeed in the allocated time, the network process has to wait for the next time slot (step 816). In that case, the communication qubit is released from the ownership by the network process.
If entanglement generation succeeds, the entangled communication qubit may be transferred by the QMMU to the user process (step 818). This unblocks the user process (step 820), which may consume the qubit (step 822), e.g. measure the qubit or apply another operation to the qubit. After consumption of the qubit, the ownership of the qubit by the user process is released. Thereafter, the user process may continue until the end of the quantum code block and return a result to the quantum network application.
The quantum network subsystem, which has a persistent kernel process associated with it, may start processing the receive entanglement operation as a background task in order to prepare entanglement generation with the other quantum nodes before the network process is scheduled to run the entanglement generation. This processing may include sending a response over a classical communication link to the requesting quantum network node to notify the requesting quantum network node that the request for entanglement has been received. The processing may further include receiving entanglement metadata from the requesting quantum network node.
During the preparation of the entanglement generation by the quantum network subsystem, the local subsystem of the operating system may continue processing the user process until access to the entanglement is required, e.g. a measurement of an entangled qubit pair. At that moment, the user process may be blocked (step 906) and the processor may wait for the scheduler to signal that the network process can be started. The scheduler may then use a time slot as defined in a network schedule to start the network process (step 908) so that the generation of the entanglement between both quantum network nodes is coordinated.
The processor may start executing the entanglement generation by the network process based on the entanglement metadata to establish entanglement with the other quantum network node (step 910) in a similar way as described with reference to
The processor may start executing the quantum network operations of the network process based on entanglement metadata to establish a quantum communication link with the other quantum network node based on entanglement (step 1004). When starting the network process, the QMMU will transfer ownership of a communication qubit that is going to be used in the entanglement generation to the network process (step 1006) so that only the network process has access to the quantum hardware. The network process will repeat the process in a loop until entanglement is generated (step 1010) within a predetermined time as allocated by the network schedule. If entanglement generation fails in the allocated time allocated, the network process will release the ownership of the communication qubit (step 1008). If entanglement succeeds, the communication qubit is stored and the quantum network process keeps the ownership of the qubit (step 1012).
Then, at a certain moment, the local subsystem of the quantum network node may start executing operations of a user process (step 1014), wherein the processor may forward a receive entanglement operation to a quantum network subsystem (a quantum network stack) of the quantum network node operating system (step 1016), which may determine the entanglement identified by the receive entanglement operation is stored. The execution of the user process may continue until a quantum operation requires access to the entanglement. In that case, the scheduler may block the user process and start execution of the network process (step 1018). As the entanglement is already generated and stored, the network process will only transfer ownership of a communication qubit that participates in the entanglement (step 1020). Thereafter, the scheduler may unblock the user process (step 1022) and continue its execution wherein a quantum operation that requires access to the entangled qubit may consume the qubit. After consumption of the qubit, the ownership of the communication qubit by the user process may be released (step 1024). When the execution of the user process is finished, the results may be returned to the quantum network application to which the quantum code block belongs.
The strict separation between local user processes and network processes as explained with reference to
In an embodiment, a cooperative scheduling policy may be selected that determines how the user process and the network processes are executed by the operating system. That is, once a first quantum routine represented by a first quantum code block is scheduled by the scheduler of the quantum network node operating system, the processor of the operating system may run it until either instructions are completed, or it is blocked because it has to wait for entanglement of the quantum network node with another quantum network node. The routine may finish while the process still holds a live quantum state in memory which can be processed in a subsequent second quantum routine represented by a second quantum code block (e.g. after the host exchanges some classical information with its peer). During the processing of the quantum bode blocks, the QMMU will keep track of the ownership of the qubit by either a user process or a network process.
A cooperative scheduler may be used if it is not allowed to the move live quantum states into storage to free up the communication qubit for an incoming process. This may be the case if the quantum state would suffer from significant fidelity degradation due to hardware quality and/or additional sources of decoherence (nuclear dephasing noise). This may be the case for current NISQ type quantum platforms like NV centers. Furthermore, due to the limited number of qubits (just one or two or several) there is little room for more complex strategies. Therefore, once a quantum network application acquires the communication qubit, it is allowed to proceed uninterrupted until it is freed. If the process is currently waiting for a further routine, other processes are free to execute classical instructions such as issuing entanglement requests to the network stack, but otherwise require waiting for the communication qubit to become available. In case memory size and/or lifetimes of the qubits increase, this strategy may be adapted to full optimize the use of the increased capabilities.
The quantum network node operating system uses the concept of user processes and kernel processes, including the quantum network stack (kernel) process. User processes are released (i.e., they become ready) asynchronously, i.e. when a process routine is loaded, or when they leave the waiting state, while the quantum network stack process may be released periodically or repeatedly, at the start of each time slot of the network schedule. Given that entanglement generation on a link requires that both nodes attempt entanglement simultaneously, the operating system assigns the quantum network stack process a priority higher than any user process. This ensures that, at the start of each time slot of the network schedule, the priority-based scheduler can assign the quantum network node process as soon as the processor is available, and thus a node can start attempting entanglement with its neighbour as soon as possible and minimize wasted attempts on the neighbouring node.
Thus, in an embodiment, a scheduling policy as depicted in
While waiting for moment that the entanglement generation can be started, the scheduler may start the local subsystem to start execution of local quantum operations (step 1208), i.e. operations not related to an entanglement generated, of a second user process, until the second user process has ended (step 1210). When the scheduler determines that the further quantum network node is ready for the entanglement generation, then the scheduler may schedule execution of a network process (not shown) by the quantum network subsystem based on a timeslot of the network schedule in a similar way as described with reference to
While waiting for the first entanglement, the scheduler may start the local subsystem to start execution operations (step 1308) of a second user process of a second quantum code block associated with a second quantum network application, which may include sending a request for a second entanglement with a further third quantum network node to the quantum network subsystem of the operating system (step 1310), which will start preparing the second entanglement generation as a background process.
When the scheduler determines that the further second quantum network node is ready for the entanglement generation, then the scheduler may start a first network process (not shown) based on a first timeslot of the network schedule in a similar way as described with reference to
After release of the communication qubit, the scheduler may determine that the further third quantum network node is ready for the entanglement generation. In that case, the scheduler may start a second network process (not shown) based on a second timeslot of the network schedule and after establishment of the second entanglement (step 1316), the scheduler gives the processor back to the second user process, which may consume the second entanglement, e.g. measure the communication bit, and release of the communication qubit (step 1318).
The execution of the quantum network applications as described with reference to
Further, it is noted that for multitasking to be useful, the quantum network nodes do not need to have much quantum memory available. For example, a “client” quantum network node may want to execute a computation on a remote “server” quantum network node for which it needs entanglement. However, if the “server” quantum network node is busy, the “client” quantum network node will have to wait for its turn. Meantime, other quantum network applications which may use the communication qubit to execute some local computation. Once it is time for entanglement to be generated with the server, the operating system may stop scheduling the local computations and schedules the network process. Such multitasking will lead to increased application throughput when compared to sequential execution without a significant impact on the quantum execution quality.
Within a quantum network, two types of node may be distinguished: end nodes, that run quantum networking user applications, and intermediate nodes, that perform those routines necessary to connect two or more end nodes. Both types of nodes are capable of executing quantum physical operations, as well as classical computing and networking tasks. The quantum network node operating system described with reference to the embodiments in this application may be used on both types of nodes. On intermediate nodes, its main responsibility is to multiplex the various quantum network requests, also called entanglement generation requests, originating from its neighbors into its underlying quantum physical hardware. End nodes may be configured to both manage the quantum hardware and to interface to the users of the node.
In an embodiment, a host system may be used to provide an interface to the user of the node. Typically, a host system may include a conventional computer including a conventional operating system for executing quantum network applications in a high-level programming language, e.g. Python or the like. Hence, the host system is only present on end nodes and represent an user environment where quantum networking applications are developed and compiled, and where application results are stored. The quantum network node operating system receives programs from the host system and entanglement generation requests from peer nodes, and arbitrates access to the quantum hardware, i.e. the physical quantum device, to multiplex quantum network applications and entanglement generation requests.
The system may further include quantum network node operating system 1404, which may be configured to communicate with the host system through a host communication handler 1416 wherein the communication may include receiving quantum routines 1418, in the form of a plurality of quantum code blocks. The quantum code blocks may be executed by the core 1418 which may include a quantum network subsystem 1424 (a quantum network stack) and a local subsystem 1426 (a local processor), The quantum network system is configured to prepare and execute entanglement generation requests, which also requires classical communication 1422 with other quantum network nodes. The operating system may be configured arbitrate access to the quantum physical device and to multiplex host applications and entanglement generation requests.
Further, the system may include a quantum device 1406, the quantum device may include a processor configured to execute a quantum device processing stack 1430 for controlling the qubits which may include communication qubits and storage qubits and for controlling the interface to the qubits, such as a classical channel interface 1432 and quantum channel interface 1434.
In an embodiment, the host system and the quantum network node operating system—while both being capable of performing non-quantum operations—may be separate components, wherein the quantum network node operating system is expected to meet real-time requirements and perform its arbitration tasks within set deadlines, whereas the host system does not need to provide such strict requirements. In an embodiment, the host system, quantum node operating system and quantum device may be implemented as physically different systems. Alternatively, some of these elements may be implemented or integrated on the same chip or board. In an embodiment, the host system may run one a general-purpose computer, while the quantum network node operation system may be implemented on a system on a chip SoC and a multitude of digital and analog controllers for the quantum device.
As shown in
A quantum networking user application, or program, may be written and programmed by programmer in a high-level language on the host, through the use of some SDK. Quantum network applications may include quantum routines—with real-time execution constraints—and possibly non-real-time pre- and postprocessing routines. A compiler may be used to split a user application into these two kinds of routines. The real-time quantum routines may form a quantum code block for execution by the quantum network node operating system, while other routines may be part of the host application.
The quantum code blocks may be expressed in a lower-level network quantum assembly language which the quantum network node operating system understands, wherein the instruction set of the quantum assembly language may include both computational and networking quantum instructions, as well as simple classical arithmetic and branching instructions which can be used for real-time processing by the operating system. It is the task of the compiler to transform high-level routines into quantum code blocks which can be executed by the quantum network node operating system. A quantum code block may be loaded onto quantum network node operating system through a host interface 1413. On the other hand, classical routines belonging to the host application may be executed locally on the host. To that end, coordination between the quantum network node and the host of the user application may be required as well as (some) post-processing of the results.
Upon receiving quantum code block, the quantum network node operating system may create a user process to store application data and execution state. A process of the operating system is defined by the application routines—as produced by the compiler—and other run-time data analogous to what a typical process control block contains, useful for the execution of the application. Further, as depicted in
The quantum operations may be sent to the quantum device through the quantum device driver 1428, which provides an abstraction of the quantum device interface 1423. The classical logic may be processed locally on the quantum network node operating system, and potentially results in the update of a process's data. Entanglement generation requests may be forwarded to the quantum network stack 1424, which in turn forwards them to the next hops, e.g. neighbouring quantum network nodes, on the path, and which stores them together with other requests coming from network peers.
Quantum physical operations may be executed on the quantum device 1406 which is configured as a quantum processing and networking unit. The implementation of the quantum device processing stack 1430 may depend on the underlying physical platform—for instance, nitrogen-vacancy (NV) centres, ion traps (IT), atomic ensembles (AE). Such platforms should be able to process both local quantum operations and entanglement generation requests. The quantum device may include (at least) two communication channels with its neighbours: a classical channel 1432, used for low-level synchronization of the entanglement generation procedure and other configuration routines, and a quantum channel 1434, where qubits—encoded in a physical medium like an electromagnetic wave-travel.
The Host communication handler 1504 translates protocol-specific messages from the Host into API calls, which are subsequently processed by the AIP handler 1506 of the quantum network node operating system. The API handler is responsible for listening to system calls made to the operating system and to relay these calls to the appropriate component inside of the core of the operating system, which is a central engine that multiplexes user processes and network processes and manages the hardware resources of the quantum device. The API may be configured to execute the following steps:
The EPR socket may define the endpoint of an entanglement generation request, and is used by the quantum network stack to set up network tables and to establish connections with its peers.
The host communication handler may communicate with the host system based on a communication protocol and is configured to translate protocol-specific messages into API calls for the operating system. Similarly, the quantum device driver layer provides an abstraction of the quantum device, and its implementation depends on the nature of the quantum device and on the physical communication interface between the operating system and the quantum device.
Further, a vertical platform layer may provide SoC-specific abstractions for the operating system to access the physical resources of the platform it is implemented on, including I/O peripherals, interrupts controllers and timers. Additionally, if the quantum network node operating system is implemented on top of a lower-level operating system, this layer may give access to system calls to the underlying OS. The Platform layer is vertical in the sense that it can be accessed by all other layers of the.
As mentioned previously, the operating system receives and processes quantum network applications, wherein each quantum network application corresponds a user process, which is associated with an execution context, which may comprise quantum assembly language routines and other context information—the process control block—including process ID, ownership of qubits, process state, scheduling priority, program counter, and pointers to process data structures. Here, process state and scheduling priority determine how processes are scheduled the operating system.
A kernel process is similar to a user process, but is created by the operating system statically, and its routines are generated at the operating system level as well. The network process associated with the quantum network stack is a kernel process that issues quantum instructions to satisfy entanglement requests coming from the network and from user applications.
Communication between the user process and the network includes the signalling of qubit ownership transfer, which is used when a process produces a qubit state which is to be consumed by another process. Typically, the network process transfers ownership of the entangled qubits that it produces to the user process which requested the EPR pairs.
Most of the process handling of the operating system happens inside of the core layer of the operating system.
As shown in the figure, the core layer 1602 may include:
The process manager marshals accesses to all user processes and kernel processes. The scheduler assigns ready processes to the processor, which runs quantum instructions through the underlying quantum device, processes (time critical) classical instructions locally, and registers entanglement generation requests with the entanglement management unit. The EMU maintains a list of EPR sockets and entanglement generation requests, forwards the entanglement generation requests to the quantum network stack, which, in turn, registers available entangled qubits with the EMU. The quantum memory management unit keeps track of used qubits, and transfers qubit ownership across processes when requested.
The process manager owns processes and marshals accesses to those. Creating a process, adding a routine to it and accessing the process's data must be done through the process manager. Additionally, the process manager is used by other components to notify events that occur inside the operating system, upon which the state of one of more processes is updated. Process state updates result in a notification to the scheduler. The process manager may include interfaces for the following services:
The scheduler registers processes that are ready to be scheduled, and assigns them to the processor when the latter is available. Ready processes are stored in a prioritized ready queue, and processes of the same priority may be scheduled with a first-come-first-served policy. The scheduler has one interface (interface 4 in
The processor handles the execution of user and network processes, by running classical instructions locally and issuing quantum instructions to the quantum device driver. While executing a process, the processor reads its routines and accesses (reads and writes) its classical memory. The processor implements a specific instruction set architecture dictated by a quantum assembly language of choice. The processor exposes one interface for processor assignment (interface 5 in
The entanglement management unit (EMU) contains a list of open EPR sockets and a list of entanglement generation requests, and keeps track of the available entangled qubits produced by the quantum network stack. Received entanglement generation requests may be considered valid only if an EPR socket associated to such requests exists. Valid requests are forwarded to the quantum network stack. Entangled qubit generations are notified as events to the process manager. The EMU has interfaces for the following services:
A data link layer and network layer protocols may be part of the quantum network stack. The physical layer may be implemented on the quantum device and the application layer may be part of the host. The quantum network stack has an associated kernel process, created statically on the operating system. However, this process's routine is dynamic: the instructions to be executed on the processor may depend on the outstanding entanglement generation requests received from EMU and network peers. The quantum network stack has interfaces for the following services:
The quantum memory management unit (QMMU) may receive requests for qubit allocations from processes such as user processes and network processes, and manages the subsequent usage of those. It may also translates virtual qubit addresses into physical addresses for the quantum device, and keeps track of which process is using which qubit at a given time. A QMMU may take into account that the topology of a quantum memory determines what operations can be performed on which qubits, and thus allow processes to allocate qubits of a specific type upon request. A more advance QMMU may also include algorithms to move qubits in the background—that is, without an explicit instruction from a process's routine—to accommodate an application's topology requirements while not trashing the qubits being used by other processes. Such a feature could prove crucial to increase the number of processes that can be using the quantum memory at the same time, and to enhance multitasking performances. The QMMU may include the following interfaces:
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2029673 | Nov 2021 | NL | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/NL2022/050625 | 11/4/2022 | WO |
