The Future of QKD Networks

TL;DR

Addresses the challenge of scaling QKD networks across federated infrastructures like EuroQCI by proposing QKD Virtual Networks (QVNets). The core mechanism introduces QVLinks as logical sub-ports of physical QKD links with $r_c = f(c) \times r$ and $f: C \to [0,1]$, enabling multiple concurrent key streams on a single physical path. QVNets are modeled as subgraphs with per-ID policy layers and a multi-layer stack (Physical, QVNet, KMS, Application), allowing behaviors such as balanced, broadcast, and high-throughput via a QVNet Update Module. The approach supports cross-border, black-box networks and satellite-ground links within EuroQCI, addressing cost and rate constraints while pursuing standardization and automatic configuration toward a global quantum internet.

Abstract

With the recent advancements in quantum technologies, the QKD market exploded. World players are scrambling to win the race towards global QKD networks, even before the rules and policies required by such large endeavors were even discussed. Several vendors are on the market, each with specific parameters and advantages (in terms of key rate, link range, KMS software, etc.), hence considerable effort is now made towards standardization. While quantum communications is expected to reach a market size of up to \$36B by 2040, the largest QKD initiative to date is EuroQCI, which, due to its sheer scale, is forcing the market to mature. Although building a QKD network is believed to be trivial today, inter-connecting federated networks on a global scale is a heavy challenge. We propose QKD virtual networks not only as a useful infrastructure abstraction for increased flexibility and granular security, but as an inevitable solution for several problems that future QKD networks will encounter on the way towards widespread adoption.

Figures (5)

• Figure 1: A representation of a physical network (top-left), with the resulting key rate in three different scenarios: balanced key distribution (top-right), broadcast key distribution (bottom-left), high-throughput (bottom-right) - see balancedqkd.
• Figure 2: A representation of a trunk logical link split into 4 QVLinks (red, blue, violet, black). QVLinks may be assigned different fractions of the total key rate available on the link (e.g. 1/2 for red, 1/4 for blue, 1/8 for violet, 1/8 for black). Each QVLink attends to a specific use-case, user, or sub-network. The number of QVLinks per logical link is unlimited, and their key rate quota can be dynamically adjusted based on the network conditions and key demand. Each QVLink may serve applications on the premises of Alice and Bob only, or may extend (perhaps through multi-hop physical links) towards other locations (as is the case for Charlie and David).
• Figure 3: A representation of QVNets over a physical QKD network. At the KMS level, different configurations may be imposed for each QVNet. For example, the KMS behaviours in terms of key forwarding for each QVNet may be balanced (forwading maximizes the minimum key rate between all pairs of nodes within that QVNet), broadcast (forwarding maximizes the minimum key rate between one fixed node and all others within that QVNet), and high-throughput (forwarding maximizes the key rate between two fixed nodes within that QVNet).
• Figure 4: Simple QKD architecture for QVNets
• Figure 5: Visualization of QVNet use-cases over a blackbox network. QKD networks A and B wish to exchange keys along the red path, but the path between them passes through the black-box network in the middle. Depending on the (potentially unknown) inner architecture of the black box, several situations may arise. Red: path between A and B requires terrestrial connection through the black-box network, which needs to co-exist with other networks within the black box. Blue: path between A and B requires satellite connection which is available via the black-box network on specific terms. The QVNets allow granular access for A and B through the black-box network. Not only this, but consider that you don't even know what the black box actually contains: the point of QVNets is that you don't need to.