Methods, systems, and apparatus, including computer programs, for enabling and managing quantum networks

Abstract

Centralized quantum capability management can be provided. The quantum network architecture can include a centralized quantum network manager. Quantum policy management can be controlled by the quantum network manager. Quantum capability registration, requesting, subscribing, and discovery can be provided. Centralized quantum connection creation and management can be provided. Efficient quantum link layer services can be provided.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of Provisional U.S. Patent Application No. 62 / 876,403, filed July 19, 2019, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0003] Leveraging quantum computing characteristics such as superposition and entanglement, quantum communication and computation can enable more secure web applications and other types of internet communication. For example, quantum key distribution (QKD) allows secure keys to be securely distributed between Hypertext Transfer Protocol (HTTP) clients and HTTP servers. Using such QKD-enabled secure keys, the HTTP client and the HTTP server can establish more secure HTTP connections. Summary of the Invention

[0004] This paper describes methods, apparatuses, and systems for addressing quantum capability management, quantum connectivity management, and quantum link layer services. While these problems may seem unrelated, they can serve as building blocks for realizing QKD and other quantum applications. As described herein, these methods, apparatuses, and systems can provide QKD and other quantum applications.

[0005] A device for managing one or more quantum nodes within a quantum network can be provided. The device may include a memory and a processor. The processor may be configured to perform multiple actions. The device may be a quantum network manager (QNM). A request to create a quantum connection between a source quantum network endpoint (QNT) and a destination QNT can be received. A quantum path between the source QNT and the destination QNT can be determined, wherein the quantum path may include a quantum network router (QNR). A first message may be sent to the QNR on the quantum path to create a first entangled qubit pair for a first hop of the quantum path and a second entangled qubit pair for a second hop of the quantum path. The first message may also include an indication of when the quantum connection can be created. A second message may be sent to the QNR instructing the QNR to perform an entanglement exchange using the first and second entangled qubit pairs to provide the quantum path for the quantum connection. An acknowledgment message indicating that the quantum connection has been created can be received.

[0006] A device for managing one or more quantum nodes within a quantum network can be provided. The device may be a quantum network manager (QNM). The device may include a memory and a processor. A request to create a quantum connection between a source quantum network endpoint (QNT) and a destination QNT can be received. A quantum path between the source QNT and the destination QNT can be determined. The quantum path may include a quantum network router (QNR). An entanglement sequence for creating the quantum connection can be determined. The entanglement sequence may include a first entanglement operation and a second entanglement operation. A first message may be sent to the source QNT to execute the first entanglement operation after a certain time. A second message may be sent to the QNR to execute the second entanglement operation after the time. An acknowledgment message indicating that the quantum connection has been created can be received.

[0007] An apparatus for creating a quantum connection can be provided. The apparatus is a quantum network client (QNC). The apparatus may include a memory and a processor. A first message may be sent to a quantum network manager (QNM). The first message may include a request for the quantum connection and parameters for the quantum connection. These parameters may include one or more of the following: a source QNT address, a destination QNT address, path information for the quantum path, a time at which the quantum connection can be created, a quantum connection creation mode, a minimum fidelity for entangled pairs, an indication of how entanglement swapping can be performed, an indication of a protocol that can be used for entanglement swapping, a maximum number of hops that can be used for the quantum path, an indication of an application that will use the quantum connection, and an indication of the lifetime of the quantum connection. Attached Figure Description

[0008] Furthermore, the same reference numerals in the figures denote the same elements, wherein:

[0009] Figure 1A This is a system diagram illustrating an example communication system that can implement one or more embodiments of the disclosure;

[0010] Figure 1B This illustrates a method according to one embodiment. Figure 1A The diagram shows an example wireless transmit / receive unit (WTRU) used internally in a communication system.

[0011] Figure 1C This illustrates a method according to one embodiment. Figure 1A The diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system.

[0012] Figure 1D This illustrates a method according to one embodiment. Figure 1AThe system diagram shown illustrates another example of a RAN and another example of a CN used internally in the communication system.

[0013] Figure 2 An example quantum internet is shown.

[0014] Figure 3 An example quantum network protocol stack is shown.

[0015] Figure 4 An example quantum network architecture with a centralized manager is shown.

[0016] Figure 5 An example of an end-to-end quantum path is shown.

[0017] Figure 6 An example of the Quantum Network Manager (QNM) functionality is shown.

[0018] Figure 7 An example flowchart of the quantum resource library in QNM is shown.

[0019] Figure 8 An example flowchart for quantum policy management is shown.

[0020] Figure 9 An example flowchart for quantum capability registration and operation is shown, such as updating, retrieving, deleting, solicitation, subscribing, and / or discovering.

[0021] Figure 10 An example of a quantum ability request and subscription is shown.

[0022] Figure 11 An example flowchart for discovering quantum network nodes and their capabilities is shown.

[0023] Figure 12 An example embodiment of quantum connectivity management in a fifth-generation (5G) mobile cellular communication system is shown.

[0024] Figure 13 An example embodiment of quantum connectivity management in a satellite-assisted vehicle network is shown.

[0025] Figure 14 An embodiment of quantum connectivity management in a future mobile cellular communication network is illustrated.

[0026] Figure 15 An example of quantum connectivity management in a fiber-to-the-home (FTTH) system is shown.

[0027] Figure 16 An example embodiment of QCM-controlled entangled qubit generation is shown.

[0028] Figure 17 The establishment of quantum connections controlled by a QCM is shown, which can buffer quantum connection reservations at the QCM.

[0029] Figure 18 The centralized quantum connection establishment controlled by QCM is shown, which can buffer quantum connection reservations at QNT and / or QNR.

[0030] Figure 19 An example flowchart for the joint creation of quantum connections and classical connections is shown.

[0031] Figure 20 An example embodiment for providing quantum connectivity as a service is shown.

[0032] Figure 21 An example implementation of the quantum link layer service is shown.

[0033] Figure 22 An example embodiment of information maintained at the quantum link layer is shown.

[0034] Figure 23 An example embodiment of the enhanced quantum link layer service for entanglement creation is shown.

[0035] Figure 24 An example embodiment of a quantum link layer service for creating periodic entanglement is shown.

[0036] Figure 25 This diagram illustrates a sample flowchart of a quantum link layer service used to update pending entanglement creation requests.

[0037] Figure 26 This diagram illustrates a sample flowchart of a quantum link layer service for canceling pending entanglement creation requests.

[0038] Figure 27 This diagram illustrates a sample flowchart of the quantum link layer service used to query existing entanglement creation requests.

[0039] Figure 28 An example flowchart for a quantum link layer service used to trigger qubit measurements is shown.

[0040] Figure 29 A sample flowchart for configuring / querying quantum statistics is shown.

[0041] Figure 30 An example flowchart is shown for a quantum link layer service used to trigger entanglement distribution.

[0042] Figure 31 An example flowchart for a quantum link layer service used for entanglement distribution is shown.

[0043] Figure 32 An example flowchart for a quantum link layer service used to trigger entanglement swaps is shown.

[0044] Figure 33 An example flowchart is shown for a quantum link layer service used to trigger entanglement distillation.

[0045] Figure 34 An example flowchart for a quantum link layer service for policy-based automated entanglement swapping / distillation is shown.

[0046] Example network for implementation of the embodiments

[0047] A device for managing one or more quantum nodes within a quantum network can be provided. The device may include a memory and a processor. The processor may be configured to perform multiple actions. The device may be a quantum network manager (QNM). A request to create a quantum connection between a source quantum network endpoint (QNT) and a destination QNT can be received. A quantum path between the source QNT and the destination QNT can be determined, wherein the quantum path may include a quantum network router (QNR). A first message may be sent to the QNR on the quantum path to create a first entangled qubit pair for a first hop of the quantum path and a second entangled qubit pair for a second hop of the quantum path. The first message may also include an indication of when the quantum connection can be created. A second message may be sent to the QNR instructing the QNR to perform an entanglement exchange using the first and second entangled qubit pairs to provide the quantum path for the quantum connection. An acknowledgment message indicating that the quantum connection has been created can be received.

[0048] A response message can be received from the QNR. The response message indicates that the QNR has performed the entanglement swap.

[0049] A quantum connection identifier associated with the quantum path and the quantum connection can be generated. A third message can be sent. The third message may include a quantum connection identifier (QNC) for one or more of the source QNT, the destination QNT, and the quantum network client. The third message can be sent to one or more of the source QNT, the destination QNT, and the quantum network client (QNC). The third message may indicate that the quantum path for the quantum connection may have been established.

[0050] The request to create the quantum connection between the source QNT and the destination QNT may include a strategy specifying when the quantum connection can be created. The request to create the quantum connection may be a first request. A second request to create the quantum connection between the source QNT and the destination QNT may be received. An aggregated quantum connection request may be generated by combining the first request and the second request.

[0051] A device for managing one or more quantum nodes within a quantum network can be provided. The device may be a quantum network manager (QNM). The device may include a memory and a processor. A request to create a quantum connection between a source quantum network endpoint (QNT) and a destination QNT can be received. A quantum path between the source QNT and the destination QNT can be determined. The quantum path may include a quantum network router (QNR). An entanglement sequence for creating the quantum connection can be determined. The entanglement sequence may include a first entanglement operation and a second entanglement operation. A first message may be sent to the source QNT to execute the first entanglement operation after a certain time. A second message may be sent to the QNR to execute the second entanglement operation after the time. An acknowledgment message indicating that the quantum connection has been created can be received.

[0052] The entanglement sequence may include a third entanglement operation. The entanglement sequence can be used to create the quantum connection, and the entanglement sequence can indicate that the entanglement swapping operation can be performed after the entanglement creation operation.

[0053] A third message may be sent to the destination QNT to perform the third entanglement operation after the said time. At least one of the first entanglement operation, the second entanglement operation, and the third entanglement operation may include an operation for creating entangled qubit pairs or an operation for entanglement swapping.

[0054] The quantum path includes a first hop and a second hop, wherein the first entanglement operation is associated with the first hop and the second entanglement operation is associated with the second hop.

[0055] A device for creating a quantum connection can be provided. This device is a quantum network client (QNC). The device may include memory and a processor. A first message can be sent to a quantum network manager (QNM). The first message may include a request for the quantum connection and parameters for the quantum connection. These parameters may include one or more of the following: a source QNT address, a destination QNT address, path information for the quantum path, the time at which the quantum connection should be created, a quantum connection creation mode, a minimum fidelity for entangled pairs, instructions on how entanglement swapping should be performed, instructions on protocols that can be used for entanglement swapping, a maximum number of hops that can be used for the quantum path, instructions on applications that will use the quantum connection, and instructions on the lifetime of the quantum connection.

[0056] A second message from the QNM can be received. This second message may include an indication that the QNM has calculated a quantum path between the source quantum network terminal (QNT) and the destination QNT for the quantum connection. The second message may also include an indication that the QNM has buffered the request for the quantum connection. A third message from the QNM can be received. This third message may include a connection identifier for the quantum connection and indicating that the quantum connection has been created.

[0057] Figure 1A This is an illustration of an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing voice, data, video, messaging, broadcasting, and other content to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 can use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtering OFDM, and / or Filter Bank Multicarrier (FBMC), etc.

[0058] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any WTRU 102a, 102b, 102c, or 102d may be referred to as a “station” and / or “STA”, and may be configured to transmit and / or receive wireless signals. It may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, and / or devices operating on commercial and / or industrial wireless networks, etc. Any of WTRU 102a, 102b, 102c, or 102d may be interchangeably referred to as a UE.

[0059] The communication system 100 may also include base stations 114a and / or 114b. Each base station 114a and / or base station 114b may be any type of device configured to enable its access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, 102d. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, e-node B, home node B, home e-node B, gNB, NR node B, site controller, access point (AP), and / or wireless routers, etc. Although each base station 114a and 114b is described as a single component, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network components.

[0060] Base station 114a may be part of RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies called cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., each transceiver corresponds to one sector of the cell. In one embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals can be transmitted and / or received in a desired spatial direction.

[0061] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, wherein the air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0062] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and / or SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c can implement a certain radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), wherein the technology can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0063] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may use some kind of radio technology, such as evolved UMTS terrestrial radio access (E-UTRA), wherein the technology may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTA Pro (LTE-A Pro) to establish air interface 116.

[0064] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a certain radio technology, such as NR radio access, wherein the radio technology can establish an air interface 116 using a novel radio (NR).

[0065] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access (e.g., using the dual connectivity (DC) principle). Thus, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0066] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and / or GSM EDGE (GERAN), etc. In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement technologies using electromagnetic spectrum technologies, such as infrared (e.g., near-infrared, mid-infrared, far-infrared, etc.), visible light, near-ultraviolet, ultraviolet, and / or similar technologies. For example, base station 114a and WTRUs 102a, 102b, 102c can use the terahertz band (e.g., the infrared band). As another example, base station 114a and WTRUs 102a, 102b, 102c can use optical technologies, such as optical fibers and / or lasers, to transmit one or more qubits.

[0067] Figure 1ABase station 114b can be a wireless router, home node B, home e node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), and / or road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not need to access the Internet 110 via CN106 / 115.

[0068] In another embodiment, base station 114b and WTRUs 102c, 102d can implement technologies using electromagnetic spectrum techniques, such as infrared (e.g., near-infrared, mid-infrared, far-infrared, etc.), visible light, near-ultraviolet, and / or ultraviolet light. For example, base station 114b and WTRUs 102c, 102d can use the terahertz band (e.g., infrared). As another example, base station 114b and WTRUs 102c, 102d can use optical technologies, such as optical fibers and / or lasers, to transmit one or more qubits.

[0069] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. This data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and / or mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or can perform advanced security functions such as user authentication. Although in Figure 1AWhile not shown, it should be understood that RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT or a different RAT as RAN 104 / 113. For example, in addition to connecting to RAN 104 / 113 which uses NR radio technology, CN 106 / 115 can also communicate with other RANs (not shown) that use GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technologies.

[0070] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a global network of interconnected computer equipment systems using common communication protocols (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite). Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, wherein the one or more RANs may use the same RAT or a different RAT as RAN 104 / 113.

[0071] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links). For example... Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a using cellular-based radio technology, and with base station 114b using IEEE 802 radio technology.

[0072] Figure 1B This is a system diagram illustrating an example of WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive unit 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with the embodiments, WTRU 102 may also include any sub-combination of the foregoing components.

[0073] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and / or state machine, etc. Processor 118 can perform signal decoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving unit 122. Although Figure 1B While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 can also be integrated into a single electronic component or chip.

[0074] Transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmit / receive component 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0075] Although Figure 1B While the transmit / receive component 122 is described as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive radio signals via the air interface 116.

[0076] Transceiver 120 can be configured to modulate signals to be transmitted by transmitter / receiver 122 and demodulate signals received by transmitter / receiver 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate using various RATs (e.g., NR and IEEE 802.11).

[0077] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a numeric keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from these components. The processor 118 can also output user data to the speaker / microphone 124, the numeric keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 can access and store information from any suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and / or a secure digital card (SD) memory card, etc. In other embodiments, processor 118 may access information from and store data in memories that are not actually located in WTRU 102, such as those memories located in a server or home computer (not shown).

[0078] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, and / or fuel cells, etc.

[0079] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable positioning method.

[0080] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and / or activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0081] WTRU 102 may include a full-duplex wireless device, wherein the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the wireless device. The full-duplex wireless device may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., choke coils) or by means of a processor (e.g., a separate processor (not shown) or by means of processor 118) for signal processing. In one embodiment, WTRU 102 may include a half-duplex wireless device that transmits or receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0082] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c using E-UTRA radio technology on air interface 116. RAN 104 can also communicate with CN 106.

[0083] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while maintaining conformity to the embodiments. Each eNodeB 160a, 160b, and 160c may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 140a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0084] Each eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and / or user scheduling in UL and / or DL, etc. For example... Figure 1C As shown, nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0085] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing components is described as part of the CN 106, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0086] MME 162 can connect to each eNodeB 162a, 162b, 162c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processes, and / or selecting a specific serving gateway during the initial attach process of WTRUs 102a, 102b, 102c, etc. MME 162 can also provide control plane functionality for handover between RAN 104 and other RANs (not shown) using other radio technologies (e.g., GSM and / or WCDMA).

[0087] The SGW 164 can connect to each eNodeB 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Furthermore, the SGW 164 can perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging processes when DL data is available to WTRUs 102a, 102b, and 102c, and / or managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0088] SGW 164 can be connected to PGW 166, which can provide packet-switched network (e.g., Internet 110) access for WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0089] CN 106 can facilitate communication with other networks. For example, CN 106 can provide circuit-switched network (e.g., PSTN 108) access for WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may act as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0090] Although Figure 1A-1D The WTRU is described as a wireless terminal; however, it should be understood that in some representative embodiments, such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

[0091] In a representative embodiment, the other network 112 may be a WLAN.

[0092] A WLAN employing an Infrastructure Basic Services Set (BSS) model may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or interface with a distributed system (DS) or other types of wired / wireless networks that send traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between the source and destination STAs (e.g., directly therebetween) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). For example, a WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP) and can communicate directly with each other either within the IBSS or with the STAs using the IBSS (e.g., all STAs). Here, the IBSS communication mode is sometimes referred to as a "self-organizing" communication mode.

[0093] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, carrier-sensing multiple access with collision avoidance (CSMA / CA) can be implemented (e.g., in an 802.11 system). For CSMA / CA, STAs, including the AP (e.g., each STA), can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. In a given BSS, at any given time, there is only one STA (e.g., only one station) transmitting.

[0094] High-throughput (HT) STAs can communicate using channels with a width of 40 MHz (e.g., by combining a 20 MHz main channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz channel).

[0095] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is transmitted and passed through a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed individually on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the STA performing the transmission. On the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0096] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to 802.11n and 802.11ac, the channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument-type control / machine-type communication (e.g., MTC devices in macro coverage areas). MTCs may have certain capabilities, such as limited capabilities including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include a battery with a battery life exceeding a threshold (e.g., for maintaining a very long battery life).

[0097] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by one or more (e.g., all) STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a particular STA, which originates from one or more (e.g., all) STAs operating in the BSS supporting the minimum bandwidth operating mode. In the example of 802.11ah, even if the APs and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the width of the primary channel can be 1MHz for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Assignment Vector (NAV) settings can depend on the state of the primary channel. If the main channel is busy (e.g., because the STA (which only supports 1MHz operating mode) transmits to the AP), then the entire available band can be considered busy even if most of the band is free and available.

[0098] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0099] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c using NR radio technology on air interface 116. RAN 113 can also communicate with CN 115.

[0100] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while maintaining conformity with the embodiments. Each gNB 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit and / or receive signals to and / or from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be in unlicensed spectrum, while the remaining component carriers may be in licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0101] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter configurations. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0102] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-standalone configuration, WTRUs 102a, 102b, and 102c communicate / connect with gNBs 180a, 180b, and 180c simultaneously with other RANs (e.g., eNodeBs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNodeBs 160a, 160b, and 160c, by implementing DC principles. In a non-standalone configuration, eNodeBs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRUs 102a, 102b, and 102c.

[0103] Each gNB 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, implement dual connectivity, implement interoperability processing between NR and E-UTRA, route user plane data to User Plane Functions (UPF) 184a and 184b, and / or route control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. For example... Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0104] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data network (DN) 185a, 185b. While each of the foregoing components is described as part of CN 115, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0105] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol PDU sessions with different needs), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, and / or mobility management, etc. AMF 182a and 1823b can use network slicing to customize the CN support provided to WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. As an example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and / or services for Machine Type Communication (MTC) access, etc. AMF 182a can provide control plane functionality for switching between RAN 113 and other RANs (not shown) using other radio technologies (e.g., LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0106] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and can configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications, etc. PDU session types can be IP-based, non-IP-based, and Ethernet-based, etc.

[0107] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface, thus providing packet-switched network (e.g., Internet 110) access for WTRU 102a, 102b, and 102c to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and / or providing mobility anchoring processing, etc.

[0108] CN 115 can facilitate communication with other networks. For example, CN 115 may include or can communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and CN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via the N3 interface connected to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0109] In view of Figure 1A-1D And about Figure 1A-1D The corresponding descriptions herein refer to one or more of the following functions, which can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other devices described herein. These emulation devices can be one or more devices configured to emulate one or more of the functions described herein. For example, these emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0110] The simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, the one or more simulation devices can perform one or more functions while being implemented and / or deployed, wholly or partially, as part of a wired and / or wireless communication network, to test other devices within the communication network. The one or more simulation devices can perform one or more functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform tests, and / or can use over-the-air wireless communication to perform tests.

[0111] One or more simulation devices can perform one or more functions, including all functionalities, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices can be used in test environments, such as test labs and / or test scenarios where wired and / or wireless communication networks are not deployed (e.g., under test), to perform tests on one or more components. The one or more simulation devices can be test equipment. The simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (which, as an example, may include one or more antennas). Detailed Implementation

[0112] Centralized quantum capability management can be provided. The quantum network architecture can include a centralized quantum network manager. Quantum policy management can be controlled by the quantum network manager. Quantum capability registration, updating, retrieval, deletion, requesting, subscription, and discovery can be provided.

[0113] It can provide centralized quantum connection management. It can provide centralized entangled qubit generation. It can provide centralized quantum connection creation. It can provide joint quantum and classical connection creation. It can provide quantum connections as a service.

[0114] It can provide advanced quantum link layer services. It can provide advanced quantum link layer services for entanglement creation. It can provide periodic entanglement creation. It can provide updates to pending entanglement creation requests. It can provide cancellation of pending entanglement creation requests. It can provide querying of existing entanglement creation requests. It can provide triggered qubit measurements. It can provide configuration / querying of quantum statistics. It can provide entanglement distribution. It can provide triggered entanglement swapping. It can provide triggered entanglement distillation. It can provide automatic entanglement swapping and distillation.

[0115] The following abbreviations are used in this article:

[0116] 5G (Fifth Generation)

[0117] BAR Broadband Access Router

[0118] BR backhaul router

[0119] CPE Customer Site Equipment

[0120] FTTH (Fiber to the Home)

[0121] gNB Next Generation Node B

[0122] DTLS (Data Transport Layer Security)

[0123] HTTP (Hypertext Transfer Protocol)

[0124] QKD quantum key distribution

[0125] QN quantum network

[0126] QNC Quantum Network Client

[0127] QNN quantum network nodes

[0128] QMM Quantum Network Manager

[0129] QNR Quantum Network Router

[0130] QNT Quantum Network Terminal

[0131] RSVP Resource Reservation Protocol

[0132] TLS transport layer security

[0133] UAV (Unmanned Aerial Vehicle)

[0134] UE User Equipment

[0135] A qubit can be analogous to a bit (e.g., a classical bit). The state of a qubit (e.g., a qubit) can be either "1" or "0" after it can be measured, and can be represented in quantum computing as quantum states |1> and |0>, respectively. Unlike a bit (e.g., a classical bit), a qubit can be in any state between "1" and "0" before it is measured. For example, a qubit can represent any state between "1" and "0" before it is measured. Photons or electrons can be used to realize qubits.

[0136] Quantum logic gates can be analogous to logic gates (e.g., classical logic gates) that can operate on bits (e.g., classical bits). Quantum logic gates can operate on qubits. A quantum logic gate can be a quantum computing circuit that can take one or more qubits as input, perform certain operations on them, and output a qubit (e.g., a new qubit).

[0137] Quantum superposition can be a principle of quantum mechanics (e.g., a fundamental principle). Using quantum superposition, any two or more quantum states can be added together (e.g., superimposed), and the result can be another valid quantum state. Conversely, a quantum state (e.g., each quantum state) can be represented as the sum of two or more other distinct states. For example, the quantum state of a qubit can be written as:

[0138] |φ>=α|0〉+β|1>,

[0139] Where |φ> can be a quantum state of the qubit, |0> (e.g., similar to the "0" state of a classical bit) and |1> (e.g., similar to the "1" state of a classical bit) can be two fundamental quantum states of the qubit, and α and β can be constrained by |α| 2 +|β| 2 Any complex number equal to 1. Even though a quantum bit can have any state |φ>, it may be corrupted to |0> or |1> when or after it is measured.

[0140] Quantum entanglement can be a property of quantum mechanics (e.g., a fundamental property). With quantum entanglement, the quantum states of two entangled qubits A and B can be completely correlated, even if the two entangled qubits are separated by a great distance. For example, if the quantum state of qubit A is measured, the state of qubit B can be automatically known.

[0141] Entangled qubits can be a pair of qubits A and B that are entangled and correlated with each other. For example, if the state of qubit A is measured, the state of qubit B can be known automatically. The joint state of two entangled qubits can be called an entangled state.

[0142] For example, It can be an entangled state, which means that whenever qubit A is measured as |0> (or |1>), the state of qubit B can change to |0> (or |1>). |Φ + > Can be one of the four Bell states (e.g., all states can be entangled states); the other three Bell states can include:

[0143]

[0144] as well as

[0145]

[0146] Entanglement fidelity can be a measure of value between 0 and 1, indicating how closely the generated entangled state approximates a Bell state (e.g., a perfect Bell state). This is because the entangled state generated in a quantum network implementation (e.g., a practical implementation) may differ from these four Bell states (e.g., a perfect Bell state). A higher fidelity indicates a closer approximation of the Bell state (e.g., a perfect Bell state). When fidelity equals 1, the entangled state can be identical to a Bell state.

[0147] Entanglement swapping can be a process of measuring one qubit from each of two pairs of entangled qubits to generate a new pair (e.g., a new pair) of entangled qubits. Entanglement swapping can be used to extend the entanglement distance. For example, two qubits A and B can be entangled together and can be held at two physically separate nodes N1 and N2, respectively. Another pair of entangled qubits C and D can be held at two physically separate nodes N2 and N3, respectively. N2 can be physically located between N1 and N2. N1 can have qubit A, N2 can have qubits B and C, and N3 can have qubit D. N2 can perform entanglement swapping (e.g., some measurement on qubits B and C, and feedback can be sent to N1 and N3 via a classical channel) and can eventually entangle qubits A and D with each other, which can essentially extend the entanglement between N1 and N2 to between N1 and N3.

[0148] Entanglement distillation can be a process performed on multiple pairs of entangled qubits to generate a new pair of entangled qubits with higher fidelity. For example, entanglement distillation can be used to improve the fidelity of existing entangled qubits.

[0149] Quantum teleportation can be a quantum application or process that can be based on quantum entanglement and can essentially be achieved by sending two bits (e.g., two classical bits) from a transmitter to a receiver and utilizing the shared entanglement between the transmitter and the receiver to transfer qubits from one location to another without physically transferring any qubits.

[0150] Quantum hyperdense coding can be a quantum application or process that is based on quantum entanglement and can essentially transfer two bits (e.g., two classical bits) from one location to another without physically transferring any bits (e.g., classical bits) by sending a qubit from a transmitter to a receiver and utilizing the shared entanglement between the transmitter and the receiver. Hyperdense coding can be the opposite of instantaneous transmission.

[0151] A quantum network can be a communication network composed of multiple quantum nodes, each capable of preparing, transmitting, receiving, manipulating, and / or measuring qubits. Two adjacent quantum nodes can be connected via quantum channels (e.g., optical fibers, free-space optics, etc.) and optionally via classical channels. A quantum internet can be a large-scale quantum network.

[0152] A quantum repeater is a quantum node that can achieve long-distance transmission of qubits using long-distance entanglement via entanglement swapping. A quantum repeater can typically be located between a source quantum node and a destination quantum node.

[0153] A quantum channel can be a communication channel connecting two quantum nodes in a quantum network, used to send / receive qubits between them. Optical fibers can be used as an implementation of a quantum channel to transmit qubits (e.g., via photons). Time slots on a wavelength in an optical fiber can also be quantum channels.

[0154] A classical channel can be a communication channel used to send / receive classical bits. A quantum connection can refer to a pair of entangled qubits existing between two quantum nodes. If two quantum nodes maintain an entangled pair (e.g., each node holds one qubit in the entangled pair), then a quantum connection can be said to have been established between the two quantum nodes. Since the use of the entangled pair may lead to the exchange of bits (e.g., classical bits) between the two quantum nodes, a classical channel may also exist between the two quantum nodes when they have a quantum connection.

[0155] Figure 2 An example quantum internet is shown. The Internet Research Task Force (IRTF) has developed the Quantum Internet Research Group (QIRG), in which the quantum internet is envisioned to bring new communication and remote computing capabilities, as well as improve the accuracy of physical sensor systems (e.g., interferometry for long-baseline telescopes). The quantum internet can be realized using quantum theory, computer science, and information theory. Future quantum internet can be built upon the internet (e.g., the current classical internet) with quantum computing infrastructure (e.g., quantum computers) and quantum communication systems (e.g., quantum channels, quantum repeaters, etc.), such as... Figure 2 As shown. Figure 2 An example quantum internet is shown.

[0156] Figure 3An example quantum network protocol stack is illustrated. This stack can realize a quantum internet. It may include a quantum physics layer, a quantum link layer, a quantum network layer, a quantum transport layer, and / or a quantum application layer. The quantum physics layer can be used to generate entanglement. The quantum link layer can be used to achieve robust entanglement generation. The quantum network layer can achieve multi-hop, long-distance entanglement. The quantum transport layer can be used for end-to-end qubit transmission. The quantum application layer can be used to support quantum applications such as quantum key distribution (QKD), quantum teleportation, and / or quantum hyperdense coding. The quantum application layer can support improved applications based on quantum applications such as QKD (e.g., classical applications).

[0157] Several different aspects of the quantum Internet can be addressed, such as design principles, entanglement capability announcement, quantum connection establishment, and / or quantum link layer services. The architectural principles of the quantum Internet can emphasize a well-managed solution with sufficient monitoring capabilities. One approach could be to utilize Internet link-state routing protocols (e.g., conventional Internet link-state routing protocols) to transmit / carry the entanglement capabilities of quantum nodes in the quantum network. This approach can be similar to distributed or peer-to-peer solutions.

[0158] A quantum connection establishment architecture can be proposed based on a reservation mechanism similar to RSVP, where the quantum capabilities of quantum nodes along the path (e.g., each quantum node) can be connected in the forward direction from the connection initiator to the connection responder, while rules (e.g., conditional action tuples) can be configured in the backward direction from the responder to the initiator. Quantum link layer services can allow the quantum network layer to request the link layer to create entangled qubits.

[0159] Leveraging quantum properties such as superposition and entanglement, quantum communication and computation can enable more secure web applications. For example, QKD can allow secure keys to be securely distributed between HTTP clients and HTTP servers. Using such QKD-enabled secure keys, HTTP clients and servers can establish more secure HTTP connections. Meanwhile, many recent QKD protocols rely on entanglement, which can be used for quantum teleportation and quantum ultra-dense coding.

[0160] Quantum network management is desirable. For example, quantum network management can involve efficiently creating qubits, creating entangled qubits, distributing and maintaining entanglement over long distances, and / or similar operations. However, existing standardization work on quantum network management has several drawbacks. For instance, existing methods for distributed entanglement capability announcement can lead to high overhead in classical internet and long delays in obtaining consistent knowledge of the entanglement capabilities of quantum nodes (e.g., all quantum nodes). As another example, existing methods for establishing quantum connections using RSVP-like mechanisms may not be robust and can be time-consuming. Furthermore, RSVP-like quantum connection establishment can incur significant overhead, such as when intermediate quantum nodes may frequently change their quantum capabilities. Existing methods for link-layer services are immature and may be limited to creating entangled qubits. Moreover, existing standardization work lacks functionality for managing entangled qubits.

[0161] This paper describes methods, apparatuses, and systems for addressing quantum capability management, quantum connectivity management, and quantum link layer services. While these problems may seem unrelated, they can serve as building blocks for realizing QKD and other quantum applications. As described herein, these methods, apparatuses, and systems can provide QKD and other quantum applications.

[0162] Quantum capability management can be provided. Quantum capabilities can refer to quantum resources (e.g., quantum memories, quantum channels, etc.) and quantum manipulation capabilities (e.g., entanglement creation, entanglement swapping, entanglement distillation, etc.) at quantum nodes, such as quantum repeaters. To realize a quantum network, it can be helpful to effectively manage the quantum capabilities of one or more quantum nodes (e.g., all quantum nodes) within that network. A quantum network can consist of one or more quantum nodes (e.g., many quantum nodes) connected by channels (e.g., quantum channels and classical channels). Furthermore, quantum capabilities can be relatively static and / or dynamically changing. This can pose challenges to the effective management of quantum capabilities in a quantum network.

[0163] Quantum connectivity management can be provided. The use of quantum networks can involve establishing two (or more) entangled qubits between two (or more) quantum nodes, allowing such entangled qubits to be consumed for quantum applications such as quantum key distribution (QKD), quantum teleportation, quantum hyperdense coding, and / or distributed quantum applications. The existence of entangled qubits that can be distributed and maintained among multiple quantum nodes can be termed a quantum connectivity. Thus, quantum connectivity can be established by distributing entangled qubits to two or more quantum nodes. However, current quantum physics and devices impose limitations on the entanglement generation rate (e.g., low) and entanglement coherence time (e.g., short). This can make establishing quantum connectivity efficiently challenging. As a result, quantum connectivity management can be difficult, even if it can be used to realize distributed quantum applications (e.g., novel distributed quantum applications).

[0164] Quantum link layer services can be provided. The quantum link layer can offer flexible and complete services to higher layers. Quantum link layer services can be designed so that higher-level quantum applications can easily access and manage the quantum link layer in an efficient manner, taking into account the properties and constraints of qubits, quantum channels, entanglement, and / or similar factors. For example, the higher layer might need to cancel a pending request for creating entangled qubits.

[0165] As described herein, methods, apparatus, and systems can be used to provide centralized quantum capability management with a quantum capability library. A quantum network architecture (e.g., a novel quantum network architecture) can be provided, which may include a quantum network manager (QNM), a quantum network router (QNR), a quantum network terminal (QNT), a quantum network client (QNC), and / or the like. The QNM may be a centralized entity that manages one or more (e.g., all) QNRs / QNTs / QNCs and the quantum capabilities of one or more (e.g., all) QNRs and QNTs. Quantum policy management may be a location where the QNM hosts quantum policies and configures / installs selected quantum policies to one or more (e.g., each) QNR / QNT. Quantum capability registration, updating, retrieval, deletion, solicitation, subscription, and discovery can be provided, wherein quantum capabilities of one or more (e.g., each) QNR / QNTs can be registered to the QNM, solicited by the QNM, subscribed to by other QNRs / QNTs / QNCs from the QNM, and / or discovered by other QNRs / QNTs / QNCs from the QNM.

[0166] As described herein, methods, apparatus, and systems can be used to provide centralized quantum connectivity management, which buffers quantum connectivity reservation requests at a quantum connectivity manager (QCM) or at quantum network nodes (QNNs). Based on some strategies, the QCM can send a request to the QNN to create entangled qubits at the QNN. The QNN can also optionally distribute the entangled qubits to its neighboring QNNs.

[0167] The QCM can receive quantum connection reservation requests from the QNC for establishing a quantum connection between the source QNT and the destination QNT. It can buffer these requests locally or at the QNN. The buffered reservation requests can be triggered at a later time, and the QCM or QNN can initiate entanglement swapping at one or more (e.g., each) QNRs along the path from the source QNT to the destination QNT.

[0168] The QNC can send a request to the QCM to jointly create a connection between the source QNT and the destination QNT, such as a quantum connection and a classical connection. The QCM can send instructions to create a quantum connection, and then instruct the source QNT to establish a connection with the destination QNT (e.g., a classical connection).

[0169] A QCM can proactively establish quantum connections between different QNTs and provide them as a service to a QNC. For example, a QNC can request existing quantum connections from a QCM, the QCM can allocate quantum connections to a QNC, the allocated quantum connections can be used and consumed to support quantum applications such as QKD, and the QNC or source (or destination) QNT with the allocated quantum connection can send notifications to the QCM.

[0170] As described herein, methods, apparatus, and systems can be used to provide a set of quantum link layer services. A set of quantum link layer services, such as periodic entanglement creation (e.g., a new quantum link layer service), can be used for quantum network nodes. Advanced entanglement creation can be provided. Higher layers can request the quantum link layer to create entangled qubits with one or more requirements, such as the lifetime of the entangled qubits, the need to distribute one entangled qubit to another quantum network node, and / or similar requirements.

[0171] Periodic entanglement creation can be provided. Higher layers can request the quantum link layer to periodically create entangled qubits. This periodic entanglement creation enables periodic QKD and allows for periodic changes in the secure key.

[0172] Updating pending entanglement creation requests can be provided. Higher layers can request the quantum link layer to update some parameters associated with pending entanglement creation requests. As a result, the quantum link layer can use the values ​​of these parameters (e.g., new values) to process the pending requests to create entangled qubits (e.g., new entangled qubits).

[0173] It is possible to cancel pending entanglement creation requests. Higher layers can request the quantum link layer to remove pending entanglement creation requests.

[0174] It allows querying existing entanglement creation requests. Higher layers can query the status and related parameters of existing entanglement creation requests that may have been received at the quantum link layer.

[0175] A trigger for qubit measurement can be provided. Higher layers can request the quantum link layer to measure some qubits. The quantum link layer can store the measurement results or return them to higher layers.

[0176] Quantum statistics can be configured / queried. Higher layers can configure quantum link layers to compute and collect quantum statistics, which can then be retrieved / queried by higher layers.

[0177] Entanglement distribution can be provided. Higher layers can trigger the quantum link layer to distribute one or more entangled qubits to other quantum network nodes (one or more).

[0178] Entanglement swaps can be triggered. Higher layers can trigger quantum link layers to perform entanglement swaps on two or more sets of entangled qubits to generate a new set of entangled qubits.

[0179] Entanglement distillation can be triggered. Higher layers can trigger quantum link layers to perform entanglement distillation on two or more sets of entangled qubits to improve the fidelity of a set of entangled qubits.

[0180] Automatic entanglement swapping and distillation can be provided. Higher layers can configure some entanglement swapping / distillation strategies to the quantum link layer, so that the quantum link layer can trigger (e.g., automatically trigger) and perform entanglement swapping and distillation based on the configured strategies.

[0181] As described herein, methods, apparatus, and systems can be used to provide a quantum network entity, which may be a quantum network manager. A quantum capability registration request, containing quantum capability information about the first quantum network node, can be received from a first quantum network node. The registration request can be verified to determine if it is authorized. A first quantum capability record can be created, which may include quantum capability information about the first quantum network node. A first response message indicating whether the registration request was successful can be generated. The first response message, indicating the identifier of the first quantum capability record, can be sent to the first quantum network node. A quantum capability operation request can be received from a second quantum network node, which may indicate a first quantum operation, such as updating, retrieving, and / or deleting a second quantum capability record. Whether the first quantum operation on the second quantum capability record is permitted can be verified. The first quantum operation can be executed and can generate a first result. A second response message including the first result can be generated. The second response message can be sent to the second quantum network node. A quantum capability solicitation request can be sent to a third quantum network node to solicit one or more quantum capabilities of the third quantum network node. A third response message indicating a solicited quantum ability can be received from a third quantum network node. A third quantum ability record, which may include the solicited quantum ability, can be created. A quantum ability discovery request can be received from a fourth quantum network node containing discovery criteria. The permission of the quantum ability discovery request can be verified. A list of quantum ability records and / or a list of quantum network nodes matching the discovery criteria can be identified. A fourth response message including the list of quantum ability records and / or the list of quantum network nodes matching the discovery criteria can be generated. This fourth response message can be sent to the fourth quantum network node. A quantum ability subscription request can be sent to a fifth quantum network node to subscribe to changes in one or more quantum abilities of that fifth quantum network node. A quantum ability notification message indicating changes in one or more subscribed quantum abilities can be received from the fifth quantum network node. A fourth quantum ability record containing changes in one or more subscribed quantum abilities can be created. A fifth response message containing an identifier of the fourth quantum ability record can be generated. This fifth response message can be sent to the fifth quantum network node.

[0182] The quantum network manager can be a network function of 5G and above core networks (e.g., new network functions), a service in a broadband access system (e.g., new services), a service in a satellite network (e.g., new services), and / or a service in a vehicle network (e.g., new services), etc.

[0183] Centralized quantum capability management can be provided. For example, each quantum network node can possess several quantum capabilities, including quantum resources such as quantum memories, the ability to perform entanglement swaps, the ability to perform entanglement distillation, the ability to support quantum applications such as quantum key distribution (QKD), and / or similar capabilities. To effectively manage the quantum capabilities of quantum network nodes in a quantum network, a centralized approach to quantum capability management can be used. A quantum network architecture (e.g., a novel quantum network architecture) can include a quantum network manager (QNM), a quantum network router (QNR), a quantum network terminal (QNT), a quantum network client (QNC), and / or the like. The QNM can be a centralized entity that manages the quantum capabilities of one or more (e.g., all) QNRs / QNTs / QNCs and one or more (e.g., all) QNRs and QNTs. Quantum policy management can be provided, where the QNM holds quantum policies and configures / installs selected quantum policies into one or more (e.g., each) QNR / QNTs. Quantum capabilities can be registered, updated, retrieved, deleted, solicited, subscribed to, and discovered, wherein one or more (e.g., each) of the quantum capabilities of a QNR / QNT can be registered to the QNM, solicited by the QNM, subscribed to by other QNR / QNT / QNCs from the QNM, and discovered by other QNR / QNT / QNCs from the QNM.

[0184] Figure 4 An example quantum network architecture with a centralized manager is shown. For example, Figure 4 The proposed quantum network architecture with a centralized quantum network manager (QNM) is illustrated. Three types of entities can be included in this architecture: quantum network routers (QNRs), quantum network terminals (QNTs), and quantum network clients (QNCs). For ease of explanation, QNTs and QNRs can be referred to as quantum network nodes (QNNs).

[0185] Multiple QNM functions can be provided. A QNM can be responsible for monitoring, controlling, and managing a quantum network comprising one or more (e.g., all) QNRs, QNTs, and QNCs. A QNC can request the QNM to instruct when / how / what to monitor / control / manage the quantum network. For example, a QNM can request one or more (e.g., all) QNRs / QNTs to report their quantum capabilities and states (e.g., quantum storage, quantum entanglement, etc.) periodically and / or similarly, once or multiple times. A QNM can also instruct a QNR to generate entangled qubits at a time, instruct a QNR to distribute entangled qubits to two other quantum nodes (e.g., QNTs or QNRs), select an effective path between two QNTs (e.g., whether a pair of entangled qubits exists or can be created at each hop), and / or instruct a QNR to perform entanglement operations such as entanglement swapping. A QNM can pre-install some instructions onto the QNRs / QNTs so that they are ready to generate and manage qubits, as quantum coherence time can be relatively short and generating entangled qubits can also take time. QNM can compute quantum statistics (such as short-term and long-term quantum fidelity) for example, to perform predictive analytics for QNR / QNT using machine learning (ML) and artificial intelligence (AI) on reported data from QNR / QNT. This quantum statistics can equip QNM with the intelligence to select the optimal path for one or more (e.g., two) QNTs.

[0186] QNR functionality can be provided. The QNR can be a quantum repeater (Type I) or a router with quantum repeater functionality and other routing-related functions (e.g., a mature router) (Type II). A quantum connection can be established between two QNRs, or between one QNR and one QNT. For example, Figure 5 The two QNRs on path 1 are type II QNRs, while type I QNRs can be on paths 2 and 3. Figure 5 An example of an end-to-end quantum path is shown.

[0187] QNT functionality can be provided. A QNT may be able to generate and store qubits. A QNT may be able to prepare entangled qubits. A QNT may not have quantum repeater functionality (e.g., entanglement swapping, entanglement distillation, etc.) or routing-related functionality. A QNT can provide an interface for QNCs to use quantum networks. Quantum connections (e.g., a pair of entangled qubits distributed across two QNNs) can be established between two QNTs, which may be located over long distances but connected via multiple end-to-end quantum paths, with some QNRs located in between. For example, Figure 5 An example is shown where there are three end-to-end quantum paths between QNT1 and QNT2.

[0188] QNC functionality can be provided. The QNC can be a quantum user and / or quantum application using a quantum network. The QNC can interact with the QNT via channels (e.g., classical channels) to leverage the quantum network, such as a quantum connection between two QNTs. The QNC can also function as a management client, directly interfacing with the QNM via one or more channels (e.g., classical channels), such as... Figure 4 QNC3 on.

[0189] Figure 4 The classical and quantum channels shown can be logical channels, which can be supported on two different physical channels or on a single physical channel. For example, wavelengths on an optical fiber can be time-slotted to allocate some time slots to the classical channel and others to the quantum channel.

[0190] Figure 6 An example QNM function is shown. For example, Figure 6 The modular functionality of QNM is illustrated, which can include an AI-based controller, quantum user management, a quantum policy library, a quantum resource library, quantum qubit management, and / or quantum connection management. These modular functions can be logical functions and can be deployed on one or more physical nodes. These modular functions can be coordinated by an AI-based controller, or they can interact directly with each other.

[0191] It can provide quantum client management capabilities. This capability can manage one or more QNCs, including client authentication and authorization, client access control, and / or client history management. An AI-based controller can be leveraged by this capability to efficiently and automatically analyze QNC history to obtain QNC behavior and other useful information.

[0192] A quantum policy library function can be provided. This function can be responsible for policy management, which may include storing quantum policies and distributing selected quantum policies to one or more QNRs and / or QNTs. Through this function, the QNC can also retrieve and update quantum policies based on its access permissions.

[0193] A quantum resource repository function can be provided. This function can store static information (e.g., relatively static information) about the quantum capabilities (e.g., supported entanglement swapping protocols, quantum memory size, quantum fidelity, and / or quantum channels, etc.) at one or more (e.g., each) QNR / QNT. The topology information of the quantum network can also be stored in this quantum resource repository. For example, a QNT or QNR can actively register itself (including its quantum capabilities) to the quantum resource repository and can even update them at a later time. The QNM can send requests to the QNT / QNR to solicit its quantum capabilities. An AI-based controller can utilize the stored quantum capability information to find one or more quantum paths (e.g., the optimal quantum path) between two QNTs.

[0194] Quantum qubit management functionality can be provided. This functionality can monitor and manage qubits at one or more (e.g., each) QNT / QNRs. For example, the QNT / QNR can periodically report information about the qubits it generates to this functionality. The functionality can also instruct the QNT / QNR to prepare qubits, generate a pair of entangled qubits, measure qubits, send a qubit to another QNR / QNT, and / or manipulate existing qubits (one or more) with quantum logic gates, etc. An AI-based controller can be used to analyze the history of qubit generation and usage to estimate and predict quantum fidelity at the QNT / QNR. This functionality can actively pull qubit-related information from a QNT / QNR or wait for that QNT / QNR to push in qubit-related information.

[0195] Quantum connection management functionality can be provided. This functionality manages entanglement-related information and operations. A QNC (or QNT) can request this functionality to create a quantum connection between two QNTs. This functionality can use an AI-based controller or quantum resource library to find one or more (e.g., optimal) quantum paths between the two QNTs. This functionality can request that one or more (e.g., each) hops of the selected quantum path create one or more entangled qubits between two quantum nodes. This functionality can instruct one or more (e.g., each) QNRs on the path to perform entanglement swaps (e.g., which can be performed in conjunction with entanglement distillation) to create two entangled qubits: one in the source QNT and the other in the destination QNT. This functionality can check a quantum policy library to implement appropriate policies. The AI-based controller can also be used to analyze the connection establishment history and predict future connection requests.

[0196] It can provide AI-based controller functionality. This functionality can provide intelligent services to one or more of the functions disclosed herein.

[0197] Figure 7 An example flowchart of the quantum resource library in QNM is shown. For example, Figure 7 A flowchart is shown for managing quantum capabilities as part of a quantum resource library, where multiple actions can exist depending on the type of trigger QNM received at 700. Figure 7 708 can periodically trigger QNM to solicit quantum abilities from QNT / QNR. To do this, at 701, it can send a solicitation request to QNT / QNR. This solicitation request 701 can indicate the type of quantum ability to be solicited.

[0198] exist Figure 7 In section 710, the QNM can receive report messages from the QNT / QNR. These report messages can be registration messages, through which the QNT / QNR registers its quantum capabilities with the QNM. The report messages can also be update messages, through which the QNT / QNR updates its quantum capabilities stored in the QNM. These report messages can be related to, for example, […]. Figure 7 At 701, the QNM sends a response message to the QNT / QNR regarding a solicitation request, which may contain the value of the solicited quantum ability. At 702, the QNM processes the quantum ability report received from the QNT / QNR. At 703, the QNM checks quantum policy management to apply certain policies, which may be associated with the received report message and the reported quantum ability of the QNT / QNR. At 704, the QNM may store the quantum ability of the QNT / QNR.

[0199] exist Figure 7 At 712, the QNM can receive a retrieval request from the QNC / QNT / QNR. At 705, the QNM can process the received retrieval request. At 706, the QNM can check the quantum user management function to verify whether the QNC / QNT / QNR has the authority to retrieve quantum capability information from the QNM. If it does have the retrieval authority, the QNM can send a response to the QNC / QNT / QNR that may include the retrieved quantum capability information at 707.

[0200] As described in this article, quantum networks can coexist with 5G and above cellular networks, satellite-assisted cellular networks, and / or fiber-to-the-home broadband access networks, and can be implemented as part of them. Thus, QMN, QNR, QNT, and QNC can be mapped to different entities in these network systems as described in Table 1:

[0201] Table 1: Examples of Quantum Networks

[0202]

[0203] In one embodiment, QNM can be a network function (e.g., a new network function) in a 5G or higher core network, a service (e.g., a new service) in a broadband access system, a service (e.g., a new service) in a satellite network, a service (e.g., a new service) in a vehicular network, etc.

[0204] In one embodiment, the QNR can be a base station in a cellular network, a satellite, a vehicle with a quantum channel (e.g., a satellite link or free-space optics) to other network nodes, a backhaul router in a cellular network, and / or a broadband access router, etc.

[0205] In one embodiment, the QNT can be a vehicle with a quantum channel (e.g., a satellite link or free-space optics) to other network nodes, a customer premises equipment (CPE) with optical fiber as a quantum channel, a satellite, a satellite ground station, a user equipment (UE) in a cellular network with a quantum channel to other UEs or to their base stations, and / or a base station in a cellular network, etc. In one embodiment, the QNC can be a user equipment (UE) in a cellular network, and / or a home device connected to a CPE, etc.

[0206] It can provide quantum strategy management. Figure 8 An example flowchart for quantum policy management is shown. The QNC can configure several quantum policies for the QNM. The QNM maintains the quantum policies. The QNM can also distribute and install selected quantum policies to the QNN. The QNN can inspect and access quantum policies from the QNM. The QNC can also configure quantum policies directly on the QNN, if it is authorized to do so.

[0207] exist Figure 8At 801, the QNC can send a request to the QNM to configure a quantum policy (e.g., a new quantum policy) and / or update some existing sub-policies. The QNC can also indicate which quantum policies can be distributed to certain specific QNNs. At 802, the QNM can verify and store the received quantum policies. At 803, the QNM can send a response to the QNC to indicate whether the requested quantum policy configuration / update was successful. At 804, the QNM can distribute one or more quantum policies to a QNN, which can be indicated by the QNC at point 1 or selected by the QNM. At 805, the QNN can receive one or more quantum policies (e.g., a new quantum policy) and can, for example, install them locally. The QNN can replace existing sub-policies that it can maintain locally with a quantum policy (e.g., a new quantum policy) that can be associated with the request at 804. At 806, the QNN can send a response to the QNM to indicate whether the request at 804 was successfully executed. At 807, the QNN can send a request to the QNM to retrieve any quantum policies that satisfy one or more criteria. In 808, the QNM can send a response to the QNN, which can contain the content of the quantum policy being retrieved.

[0208] like Figure 8 As shown, there is no correlation between option 1 and option 2. For example, either option can be selected in any order.

[0209] A QNM can manage the quantum capabilities at one or more (e.g., each) quantum network node (QNN) in a quantum network. A QNM can support several functions: A QNM can support one or more (e.g., each) QNN (which can be a QNR or QNT) registering or reporting their quantum capabilities to the QNM. A QNM can subscribe to a QNN to receive notifications about its selected quantum capabilities. A QNM can maintain the quantum capabilities of one or more (e.g., all) QNNs. A QNM can support one or more (e.g., each) QNN updating its quantum capabilities as stored in the QNM. A QNM can support one or more (e.g., each) QNN deleting its quantum capabilities as stored in the QNM. A QNM can proactively query quantum masses from target QNNs. A QNM can support QNNs discovering and retrieving the quantum capabilities of other QNNs from the QNM. A QNM can support QNNs discovering other QNNs from the QNM. A QNM can support QNNs subscribing to changes in the quantum capabilities of other QNNs. A QNM can send notifications to a QNN that, as a subscriber, may have already subscribed to changes in the quantum capabilities of other QNNs. QNM can support one or more (e.g., each) QNNs reporting their network neighbors (e.g., classic network neighbors) and topology information to QNM. If the network neighbors (e.g., classic network neighbors) and topology information of one or more (e.g., all) QNNs can be maintained at a third-party network entity such as a Path Computation Element (PCE), then QNM can interface with and interact with that third-party network entity to obtain the network neighbors (e.g., classic network neighbors) and topology information of one or more (e.g., all) QNNs.

[0210] Figure 9 An example flowchart for quantum ability registration and operation is shown, including quantum ability registration and operation such as solicitation, updating, retrieval, deletion, subscription, and / or discovery. For example, Figure 9 The process for quantum ability registration and manipulation can be illustrated. Quantum ability registration allows a QNN to register itself and its quantum abilities with a QNM. Quantum ability manipulation enables a QNN to update / delete / retrieve quantum ability records and / or subscribe to changes in the quantum abilities of other QNNs.

[0211] exist Figure 9 In step 901, the QNN can send a quantum capability registration request to the QNM. This message may include one or more (e.g., all) of the QNN's identifier and its current quantum capabilities (e.g., the size of the quantum memory, and / or the ability to perform entanglement swapping and distillation).

[0212] exist Figure 9At point 902, the QNM can create quantum ability records for one or more (e.g., each) registered quantum abilities. The QNM can use different methods to store one or more (e.g., all) of the records created by the QNN. For example, the QNM can assign different directories to one or more (e.g., each) QNNs to store one or more (e.g., all) of their quantum ability records.

[0213] For example, each quantum ability record can be in the form of a quadruple with four attributes (e.g., recordID, qcName, qcValue, qcLifetime). The recordID attribute can be the identifier of the record. The qcName attribute can be the type or name of the quantum ability. The qcValue attribute can be the value of the quantum ability. The qcLifeTime attribute can indicate the effective time of the record. For example, a record could be (recordID1, quantumMemory, 40, infinite), which could represent that the quantum memory can store 40 qubits at any time.

[0214] exist Figure 9 At point 903, the QNM can send a response to the QNN. In the response message, the QNM can indicate an identifier for the quantum ability record created. The QNM can also select one or more quantum protocols (e.g., entanglement swapping protocols) for the QNN and can include them in the response message. The QNM can include triggers in the message to instruct the QNN to initiate one or more quantum operations at a future time. For example, a trigger is a request from the QNN to report its quantum ability after a certain period of time.

[0215] exist Figure 9 At position 904, the QNN can send a quantum ability operation request to the QNM. This request can indicate the type of quantum ability operation, which can be one of the following:

[0216] One scenario could be updating an existing sub-capability record. In this case, the request could also include an identifier for the existing sub-capability record and one or more values ​​(e.g., new values) of other attributes to be updated.

[0217] One scenario could be the deletion of existing quantum capability records. In this case, the request could also include an identifier of the existing quantum capability record to be deleted.

[0218] One scenario could be retrieving an existing sub-capability record. In this case, the request could also include an identifier for the existing sub-capability record to be retrieved. The QNM can then return the contents of that record (e.g., the values ​​of one or more of the record's attributes) to the QNN in step 906.

[0219] One scenario could be a change in an existing quantum capability record being subscribed to, and / or a change in the quantum capability of another QNN. In this case, the request could also include the identifier of the existing quantum capability record being subscribed to and / or the identifier of the other QNN.

[0220] exist Figure 9 According to 905, QNM can perform quantum capability operations that may have been requested in 904. For the scenarios mentioned in 904, QNM can perform one or more of the following actions:

[0221] • Locate the specified quantum ability record and update it using the record attributes contained at address 904.

[0222] • Locate the specified quantum ability record and simply delete it.

[0223] • Locate the specified quantum ability record and include its contents in the response message to be sent back to the QNN in 906.

[0224] • Store the subscription information and prepare to generate a notification to the QNN once expected changes occur (such as those indicated at 904).

[0225] exist Figure 9 At position 906, the QNM can send a response to the QNN. The content of this response message can depend on one or more scenarios at position 904. For example, one or more of the following can be performed:

[0226] The response message can indicate whether the update operation was successful.

[0227] The response message can indicate whether the deletion operation was successful.

[0228] The response message may contain the contents of the quantum ability record being retrieved.

[0229] The response message can indicate whether the subscription was successful.

[0230] refer to Figure 9 The actions performed at 902 and 904 can be issued from different QNNs. A QNN can use 902 to register its quantum abilities, while another QNN can use 904 to manipulate its own quantum ability record that can be stored at the QNM, or manipulate quantum ability records that can be registered by other QNNs.

[0231] Figure 10 An example of quantum ability solicitation and subscription is shown. For example, Figure 10This illustrates the process by which a QNM actively solicits quantum capabilities from a QNN or subscribes to a QNN for any desired changes to its quantum capabilities. At 1000, the QNN may or may not have registered its quantum capabilities with the QNM. At 1001, the QNM may send a quantum capability solicitation request to the QNN. This request may include the type / name / identifier of the quantum capability to be solicited. At 1002, the QNN may check its current quantum capabilities and may send them to the QNM in a response. At 1003, the QNM may send a quantum capability subscription request to the QNN, such that in the future, whenever the QNN's quantum capabilities may change and meet certain specified criteria, the QNN may send (e.g., automatically) a notification to the QNM. At 1004, the QNN may send a response to the QNM indicating whether the subscription was successful. At 1005, the QNN's quantum capabilities change, and it can be determined that the change satisfies the notification criteria at 1003. At 1006, the QNN may send a notification to the QNM, which may include the changed quantum capabilities (e.g., newly changed quantum capabilities). At 1007, QNM can send a response to QNN as an acknowledgment of the notification received at 1006.

[0232] Figure 11 An example flowchart for discovering quantum network nodes and their capabilities is shown. For example, Figure 11 The process by which a QNC (or QNN) discovers other QNNs and their quantum abilities from a QNM is illustrated. At 1101, the QNC may send a quantum network node discovery request to the QNM, which may include one or more node discovery criteria to discover one or more QNNs. At 1102, the QNM may use the discovery criteria at 1101 as input to search its maintained quantum ability records to find quantum network nodes whose quantum abilities match the criteria. At 1103, the QNM may send a response to the QNC, which may contain a list of quantum network nodes whose quantum abilities match the criteria. At 1104, the QNC may send a quantum ability discovery request to the QNM, which may contain ability discovery criteria (e.g., one or more quantum network node identifiers) to discover their abilities. At 1105, the QNM may search its maintained quantum ability records against the criteria from 4, and at 1106, the QNM may send a response to the QNC, which may include a list of quantum ability records for those quantum network nodes as specified in 1104.

[0233] exist Figure 11In this context, a QNC can simultaneously or nearly simultaneously discover one or more (e.g., two) quantum network nodes and their capabilities. For example, a QNC can execute 1101 and 1104 almost simultaneously. A QNC might decide to execute 1101-1103 without further discovering one or more QNNs with quantum capabilities that meet the criteria. A QNC might decide to execute 1104-1106 without executing 1101-1103 to discover the quantum capabilities of one or more QNNs.

[0234] Centralized quantum connection management can be provided. Quantum network nodes (QNNs) in a quantum network can include quantum network terminals (QNTs) and quantum network routers (QNTs). QNRs can support entanglement operations (e.g., advanced entanglement operations), such as entanglement swapping and entanglement distillation. QNTs may not have this capability. A quantum connection can be established between two QNTs, and if it spans multiple hops, the quantum connection can use one or more QNRs along the quantum path to perform entanglement swapping to create an end-to-end quantum connection. A quantum connection between two QNNs (e.g., QNN-1 and QNN-2) can be a pair of entangled qubits (e.g., Qubit-A and Qubit-B), which may have already been created and distributed to both QNNs. For example, QNN-1 may hold Qubit-A, while QNN-2 may hold Qubit-B. Quantum connections may be affected (e.g., severely affected) and limited by entanglement generation, entanglement swapping, and / or other factors.

[0235] Current quantum physics and devices can lead to low entanglement generation rates and short entanglement coherence times. For example, it may take time to create a quantum connection, and one or more (e.g., each) quantum connections created may disappear rapidly.

[0236] As described in this paper, these constraints can be addressed using centralized quantum connection management, where a quantum connection manager (QCM) can be proposed as a logical function or service. The QCM can be responsible for generating entangled qubits at one or two adjacent QNNs, receiving quantum connection requests from quantum network clients (QNCs), establishing quantum connections between source QNTs and destination QNTs, and / or jointly establishing quantum connections and classical transport connections, etc.

[0237] Based on certain strategies, a QCM can send a request to a QNN to create entangled qubits at the QNN. The QNN can also distribute the entangled qubits to its neighboring QNNs.

[0238] The QCM can receive one or more quantum connection reservation requests from the QNC to establish a quantum connection between the source QNT and the destination QNT. The QCM can buffer the requests locally or at the QNN. The buffered reservation requests can be triggered at a later time, and the QCM or QNN can trigger entanglement swapping at one or more (e.g., each) QNRs along the path from the source QNT to the destination QNT.

[0239] The QNC can send a request to the QCM to jointly create a connection between the source QNT and the destination QNT, such as a quantum connection and a classical connection. For example, the QCM can instruct the creation of a quantum connection and then command the source QNT to establish a classical connection with the destination QNT.

[0240] A quantum communication mechanism (QCM) can proactively establish quantum connections between different quantum nuclei (QNTs) and offer them as a service to quantum communication control centers (QNCs). For example, a QNC can request an existing quantum connection from the QCM. The QCM can then assign the quantum connection to a QNC. The assigned quantum connection can be used and consumed to support quantum applications such as quantum key distribution (QKD). The assigned quantum connection's QNT or QNC (e.g., source QNT and / or destination QNT) can send notifications to the QCM.

[0241] While the embodiments described herein can describe entanglement involving two qubits, the embodiments can also be applied to and extended to scenarios or situations in which entanglement also involves more than two qubits.

[0242] Figure 12 An example embodiment of quantum connectivity management in a 5G system is shown. Figure 12 As shown, the embodiments described herein can be implemented in a 5G wireless network. In such a system, there may be no quantum channel between the User Equipment (UE) and the Next Generation Base Station (gNB). A quantum channel, such as free-space optics, can exist between two adjacent gNBs. One or more aggregation nodes or backhaul routers (BRs) can exist, connecting the gNBs to the 5G core network based on optical fibers, free-space optics, and / or satellite links, which can be used as quantum channels between the gNBs and the BRs, and between the BRs and the 5G core network. The BR can be a satellite, which can provide satellite links as quantum channels to the gNBs and to the 5G core network.

[0243] QCM can be implemented as a network function (e.g., a new network function) to be deployed in the 5G core network and / or its edge network. QNC can be a software module in the UE. A UE can hold one or more QNCs. QNT can be implemented as part of the gNB. The gNB can hold one or more QNTs. A QNT can serve multiple QNCs, similar to how a gNB can support many UEs within its coverage area. The source QNT can be gNB-1, and the destination QNT can be gNB-2. QNR can be implemented as part of a backhaul router, which can have fiber optic connections (or even free-space optics) to the gNB, other backhaul routers, and the 5G core network.

[0244] UE-1 can request more secure communication with UE-2. UE-1 can be overridden by gNB-1, and UE-2 can be overridden by gNB-2. UE-1 (e.g., QNC) or gNB-1 can send a request to a network function (e.g., a new network function) QCM to request the establishment of a quantum connection between gNB-1 (e.g., the source QNT) and gNB-2 (e.g., the destination QNT). The QCM can contact gNB-1, gNB-2, and / or other in-transit backhaul routers to complete the creation of the quantum connection between gNB-1 and gNB-2. gNB-1 and gNB-2 can establish a security key using the QKP protocol (which can be specified by the QCM or requested by UE-1 / gNB-1), which can be known only to gNB-1 and gNB-2. This security key can be used to encrypt communication segments between gNB-1 and gNB-2 for packets (e.g., any packets) between UE-1 and UE-2 (which can request some changes to the existing 5G data plane).

[0245] If a secure method exists, gNB1 can distribute the security key to UE-1. gNB-2 can perform a similar operation on UE-2. UE-1 and UE-2 can directly use this security key to encrypt any content exchanged between UE-1 and UE-2.

[0246] UE-1 can request more secure communication with the 5G core network. UE-1 can be overridden by gNB-1. UE-1 (which can be a QNC) or gNB-1 can send a request to a network function (e.g., a new network function) QCM to request the establishment of a quantum connection between gNB-1 (e.g., the source QNT) and a backhaul router BR-1 (e.g., the destination QNT) in the 5G core network. The QCM can contact gNB-1, BR-1, and / or other intermediate backhaul routers to complete the creation of the quantum connection between gNB-1 and BR-1. gNB-1 and BR-1 can use the QKP protocol (which can be specified by the QCM or requested by UE-1 / gNB-1) to establish a security key that can only be known by gNB-1 and BR-1.

[0247] This security key can be used to encrypt communication segments between gNB-1 and BR-1 for packets (e.g., any packets) between UE-1 and the 5G core network, which can request some changes to the existing 5G data plane.

[0248] Figure 13 An example embodiment of quantum connectivity management in a satellite-assisted vehicle network is shown. For example, Figure 13 The embodiments described herein can be illustrated as to how they can be implemented in a satellite-assisted vehicle network. A vehicle (e.g., each vehicle) may have a satellite link as a quantum channel, and this link may act as a QNT (or even a QNR if the vehicle may have quantum channels to other vehicles, such as visible light communication or free-space optics). A vehicle (e.g., each vehicle) may connect to other vehicles and the Internet (e.g., the conventional Internet) via one or more channels (e.g., classical channels), such as short-range (e.g., IEEE 802.11) and / or long-range (e.g., 4G / 5G cellular) wireless technologies. Satellites may connect to a mesh network via quantum channels such as free-space optics, and each satellite (e.g., each satellite) may be a QNR. In embodiments, once a vehicle has a satellite link as a quantum channel and a wired / wireless communication channel (e.g., a classical channel) to the Internet, the vehicle may be the satellite itself, a drone, an airplane, a train, other types of unmanned aerial vehicles (UAVs), and / or even any type of device.

[0249] QCM can be implemented as a service that can be deployed on the Internet (e.g., a new service), as part of a telecommunications operator's network, as part of a satellite system, as part of a vehicle network such as a roadside unit, and / or as part of a cloud service, etc. QNC can be a software module that can be inside a vehicle or UE (e.g., a telephone inside a vehicle).

[0250] A QNT can be implemented as part of a vehicle. A vehicle can hold one or more QNTs. A QNT can serve one or more (e.g., multiple) QNCs. The source QNT can be vehicle-1, and the destination QNT can be vehicle-2. A QNR can be implemented as part of a satellite, part of a vehicle (if the vehicle has quantum channels to one or more other vehicles), and / or other similar entities.

[0251] Vehicle-1 may request more secure communication with Vehicle-2, and Vehicle-1 and Vehicle-2 may be covered by the same or different satellites. Vehicle-1 (which may be a QNT) or a QNC connected to Vehicle-1 may send a request to a service (e.g., a new service) QCM to request the establishment of a quantum connection between Vehicle-1 (e.g., the source QNT) and Vehicle-2 (e.g., the destination QNT). The QCM may contact Vehicle-1, Vehicle-2, and / or other en route vehicles / satellites (e.g., QNRs) to complete the establishment of the quantum connection between Vehicle-1 and Vehicle-2. Vehicle-1 and Vehicle-2 may employ the QKP protocol (which may be specified by the QCM or requested by Vehicle-1) to establish a secure key known only to Vehicle-1 and Vehicle-2. This secure key can be used to encrypt content to be exchanged between Vehicle-1 and Vehicle-2 (e.g., any content).

[0252] Figure 14 An embodiment of quantum connectivity management in future cellular networks is illustrated. For example, Figure 14 The embodiments described herein are shown to be implementable in a future mobile cellular network (referred to as XG). A UE (e.g., each UE) may have a quantum channel to an XG base station (xgNB), such as millimeter-wave (mmWave) radio. For example, mmWave can be used to transmit qubits between the UE and the xgNB. A quantum channel, such as free-space optics, may exist between two adjacent xgNBs. One or more aggregation nodes or backhaul routers (BRs) may exist, connecting the xgNBs to the XG core network based on optical fibers, free-space optics, satellite links, and / or the like (which can serve as quantum channels between the xgNBs and BRs and between the BRs and the XG core network). The BR may be a satellite, which can provide satellite links as quantum channels to the xgNBs and to the XG core network.

[0253] QCM can be implemented as a network function (e.g., a new network function) to be deployed in the XG core network and / or its edge network. QNC can be a software module within the UE. The UE can hold one or more QNCs. QNT can be implemented as part of the UE. QNR can be implemented as part of the xgNB. QNR can also be implemented as part of the BR, which can have quantum channels (e.g., fiber optics, free-space optics, and / or satellite links) to the xgNB, other BRs, and the XG core network.

[0254] UE-1 can request more secure communication with UE-2. UE-1 can be overridden by xgNB-1, and UE-2 can be overridden by xgNB-2. UE-1 (which can be a QNC and / or QNT) can send a request to a network function (e.g., a new network function) QCM to request the establishment of a quantum connection between UE-1 (e.g., the source QNT) and UE-2 (e.g., the destination QNT). The QCM can contact UE-1, UE-2, and / or other en route QNRs (e.g., xgNB-1, one or more BRs, and xgNB-2) to complete the creation of the quantum connection between UE-1 and UE-2. UE-1 and UE-2 can use the QKP protocol (which can be specified by the QCM or requested by UE-1) to establish a security key that can only be known by UE-1 and UE-2. This security key can be used to encrypt content (e.g., any content) to be exchanged between UE-1 and UE-2.

[0255] Figure 15 An example of quantum connectivity management in a fiber-to-the-home (FTTH) system is illustrated. For example, Figure 15 The embodiments described herein are illustrated in how they can be implemented in a fiber-to-the-home (FTTH) broadband access system. For example, each Customer Premises Equipment (CPE) can be connected to a Broadband Access Router (BAR) via optical fiber as a quantum channel. One or more BARs can be interconnected via optical fiber as a quantum channel.

[0256] A QCM can be implemented as part of a service to be deployed on the Internet (e.g., a new service) or an FTTH broadband access system. A QNC can be implemented as part of a home appliance (e.g., any home appliance). A QNT can be implemented as part of a CPE. A CPE can hold one or more QNTs. A QNT can serve one or more QNCs. The source QNT can be CPE-1, and the destination QNT can be CPE-2. A QNR can be implemented as part of a BAR.

[0257] CPE-1 can request more secure communication with CPE-2 to enable more secure communication between a device connected to CPE-1 and another device connected to CPE-2. CPE-1 and CPE-2 can be overridden by the same or different BARs. A device connected to CPE-1 (which may be a QNT) or as a QNC can send a request to a service (e.g., a new service) QCM to request the establishment of a quantum connection between CPE-1 (e.g., the source QNT) and CPE-2 (e.g., the destination QNT). The QCM can contact CPE-1, CPE-2, and / or one or more other BARs (which may be QNRs) to complete the creation of the quantum connection between CPE-1 and CPE-2. CPE-1 and CPE-2 can use the QKP protocol (which can be specified by the QCM or requested by CPE-1) to establish a security key, which can only be known by CPE-1 and CPE-2. This security key can be used to encrypt content (e.g., any content) to be exchanged between CPE-1 and CPE-2. CPE-1 and / or CPE-2 can distribute this security to their home devices. A device connected to CPE-1 and another device connected to CPE-2 can use this security key for direct secure communication between them.

[0258] It can provide QCM-controlled generation of entangled qubits. Figure 16 An example embodiment of QCM-controlled entangled qubit generation is shown. For example, Figure 16 The process of quantum qubit management for QCM control is illustrated. A pair of entangled qubits can be generated at QNN2 based on one or more pre-configured strategies and / or under the control of the QCM. If a quantum channel exists between QNN1 and QNN2, QNN2 can optionally send one entangled qubit to QNN1.

[0259] exist Figure 16At points 1601a-1601b, the strategy for generating entangled qubits may have already been configured at QNN2 and / or QCM. At 1602, triggered by the quantum strategy in 1a, QCM may send a request to QNN2 to generate entangled qubits. In this request, QCM may instruct QNN2 to generate entangled qubits and distribute them to other QNNs. This request may include the address of QNN1. At 1603, QNN2 may generate multiple pairs of entangled qubits (e.g., a pair of qubits A and B), as triggered by 1601B or requested by 1602. At 1604, QNN2 may send a request to QNN1 to notify it that the entangled pair of qubits can be sent to QNN1 at a later time (such as at 1606). At 1605, QNN1 may send a response to QNN2. In this response, QNN1 may offer QNN2 a time for execution at 1606. QNN1 can prepare the quantum channel to receive the qubits transmitted in 1606. In 1606, QNN2 can send one qubit (e.g., qubit A) of an entangled pair to QNN1 via the quantum channel. QNN2 can maintain the other qubit (e.g., qubit B) in the entangled pair. In 1607, QNN1 can send a response to QNN2 to indicate whether it has successfully received the qubit. If QNN1 has not successfully received the qubit, QNN2 may destroy the other qubit (e.g., qubit B). In 1608, QNN2 can send a response to QCM to indicate whether a pair of entangled qubits has been successfully created by QNN2 and whether one qubit in the entangled pair has been successfully sent to QNN1. QCM can analyze one or more (e.g., all) responses received from QNN to obtain statistics on the generation of entangled qubits.

[0260] exist Figure 16 In this process, QNN2 can transfer qubit A to QNN1 and qubit B to QNN3. If QCM has the ability to generate entangled qubits, it can generate only one pair of entangled qubits (e.g., qubit A and qubit B), and it can transfer qubit A to QNN2 and qubit B to QNN1.

[0261] It can provide QCM-controlled quantum connection creation. Figure 17 This demonstrates the establishment of a QCM-controlled quantum connection that can be buffered at the QCM to reserve quantum connection space. Figure 18A centralized quantum connection establishment controlled by a QCM is illustrated, which can buffer quantum connection reservations at QNTs and / or QNRs. A QNC can request the QCM to establish a quantum connection between a source QNT (e.g., QNT-S) and a destination QNT (e.g., QNT-D). One or more QNRs can be located on the path from QNT-S to QNT-D. To establish a quantum connection between QNT-S and QNT-D, a pair of entangled qubits can be established between them (e.g., one entangled qubit at QNT-S and the other at QNT-D). This can be achieved by creating a pair of entangled qubits on one or more hops (e.g., each hop) of the path (e.g., using...). Figure 16 This is achieved by performing entanglement swaps on one or more QNRs (e.g., each QNR), as described in the embodiments above. Since entangled pairs may not be able to be maintained for a long time without sacrificing the desired fidelity, the QNC can reserve space for the creation of quantum connections in advance (e.g., before the quantum connection is usable). The quantum connection can be created at a later time, which can be referred to as qConnCreationTime. The QCM can have two modes for establishing or creating quantum connections.

[0262] Quantum connection creation mode A (buffered reservation at the QCM) can be provided. The QCM can continue to receive quantum connection reservation requests from the same or different QNCs. The QCM can wait and can trigger entanglement creation and exchange at the QNC at the indicated qConnCreationTime on one hop (e.g., each hop) of the path from QNT-S to QNT-D. For example, the QNC can pre-send one or more reservation requests to the QCM. The QCM can receive and buffer those reservation requests. The QCM can process those reservation requests at qConnCreationTime, e.g., batch processing.

[0263] Quantum connection creation mode B (buffer reservation at QNR / QNT) can be provided: upon receiving a reservation request (e.g., each reservation request), the QCM can identify a path (e.g., the optimal path) and one or more QNRs (e.g., the best QNR) between QNT-S and QNT-D. The QCM can divide the quantum connection creation task into several subtasks at QNT-S (e.g., entanglement creation), QNT-D (e.g., entanglement creation), and QNR (e.g., entanglement creation and entanglement swapping). It can assign these subtasks to QNT-S, QNT-D, and QNR, and can instruct them to perform these tasks at qConnCreationTime.

[0264] exist Figure 17 Multiple processes can be executed within it. Figure 17In step 1701, the QNC can send a quantum connectivity reservation request to the QCM. This request can indicate one or more of the following:

[0265] ·qntSourceAddr: The address of the source QNT.

[0266] ·qntDestinationAddr: The address of the destination QNT.

[0267] • qPathInfo: QNC can optionally specify the quantum path from QNT-S to QNT-D (e.g., to indicate the address of one or more (e.g., all) QNRs between QNT-S and QNT-D).

[0268] ·qConnCreationTime: Indicates when a quantum connection can be created. It can be an absolute time or a relative time. If it is a relative time, this parameter indicates the delay between when the QCM receives the reservation request and when the QCM begins creating the requested quantum connection.

[0269] ·qConnCreationMode: Indicates the mode in which the QCM creates the requested quantum connection. The quantum connection creation mode can be: Mode A: Buffer reservation request under QCM ( Figure 17 (Middle), or Mode B: Buffer retention request at QNR / QNT ( Figure 18 middle).

[0270] • minFidelity: The fidelity of the entangled pairs generated between QNT-S and QNT-D (minimum fidelity).

[0271] • entanglementSwappingModel: Indicates how to perform entanglement swaps at one or more (e.g., all) hops, which can be performed sequentially from QNT-S to QNT-D (or from QNT-D to QNT-S) or in parallel between different hops.

[0272] • entanglementSwappingProtocol: Indicates the protocol used for (e.g., each) entanglement swapping operation.

[0273] ·maxNumOfQuantumHops: Indicates the number of QNRs (e.g., the maximum number) on the path from QNT-S to QNT-D.

[0274] • targetAppID: Indicates the target application that can use the quantum connection between the created QNT-S and QNT-D.

[0275] ·qConnLifetime: Indicates the lifetime of a quantum connection that is active and valid after it can be created.

[0276] exist Figure 17 In section 1702, the QCM can receive reservation request messages. If qPathInfo might not be included in 1701, it can compute and select an appropriate quantum path for a given QNT-S and QNT-D. The selected quantum path can have fewer hops than, for example, the maxNumOfQuantumHops indicated in 1701. During section 1702, the QCM can also estimate and determine whether (e.g., for each) QNR on the selected quantum path has sufficient quantum resources / capacity in the vicinity of qConnCreationTime. If there might not be enough quantum resources, the reservation request in 1701 may fail.

[0277] exist Figure 17 At 1703, the QCM can send a response to the QNC to indicate whether the reservation was successful. If the reservation is successful, the QCM can create a reservation sequence number (e.g., qReservationID) and include it in the response message. The QCM can also include information about the selected path (e.g., the address of the QNT-S, the address of the QNT-D, and the address of each QNR on the path) in the response at 1702. The QCM can buffer the reservation request and can start a creation timer set to qConnCreationTime.

[0278] exist Figure 17 At point 1704, the creation timer associated with (for example, each) a buffered reservation request can become expired. There may be one or more reservation requests whose timers expire at approximately the same time. QCM can aggregate those reservation requests into a single reservation request and expire them at roughly the same time.

[0279] exist Figure 17 At positions 1705-1707, the reservation request may become expired. The QCM can use positions 1705-1707 to contact one or more (e.g., all) QNRs, QNT-S, and QNT-Ds to create entangled pairs on one or more (e.g., each) hops of a selected quantum path between QNT-S and QNT-D. Positions 1705-1707 can be used with... Figure 16 The steps shown are similar.

[0280] exist Figure 17At points 1708-1710, the QCM can instruct one or more (e.g., each) QNRs to perform an appropriate entanglement swap, as specified by the entanglementSwappingMode and entanglementSwappingProtocol indicated at point 1701. This can, for example, create entangled pairs (e.g., quantum connections) between QNT-S and QNT-D. At 1708, the QCM can send an entanglement operation request to the QNR. This message can contain identifiers for two unrelated qubits on which an entanglement swap can be performed. The message can also indicate some parameters received at 1701, such as the entanglementSwappingProtocol. At 1709, the QNR can perform the entanglement operation requested in 1708 (e.g., entanglement swap and optional entanglement distillation) on the specified qubit. At 1710, the QNR can send an entanglement operation response to the QCM to indicate whether the entanglement operation in 1709 was successful.

[0281] In step 1711, if steps 1708-1710 may have been successfully executed on one or more (e.g., all) QNRs, a quantum connection may have been successfully established between QNT-S and QNT-D. The QCM can generate a quantum connection identifier (e.g., qConnID) for this connection. The QCM can send a quantum connection creation acknowledgment to QNT-D, QNT-S, and QNC. In this acknowledgment message, the QCM may include qConnID and other parameters received in step 1701, such as TargetAppID and connLifetime. After step 7011, whenever a quantum connection may become unavailable (e.g., due to reduced entanglement fidelity) and / or be consumed, QNT-S (or QNT-D) can send a notification to the QCM. The QCM can mark the state of the consumed quantum connection as "consumed" and / or "unavailable." The QCM can remove this unavailable or consumed quantum connection from its database.

[0282] At 1701, the QNT-S or QNT-D can also send a quantum connection reservation request to the QCM, which can be triggered by some pre-configured policy at the QNT-S or QNT-D. For example, a sample policy could be set to create a quantum connection (e.g., a new quantum connection) when the current quantum connection might be consumed or become unavailable (e.g., due to low fidelity). This allows the action at 1711c to be skipped.

[0283] Before step 1705, the QNC (or QNT-S / QNT-D if QNT-S / QNT-D can request quantum connection reservations) can send a quantum connection reservation cancellation request to the QCM by indicating one or more qReservationIDs. The QCM can remove the corresponding pending reservation request, and steps 1705-1711 can be skipped.

[0284] Prior to execution of 1705, the QCM itself can cancel one or more quantum connection reservations and can send a quantum connection reservation cancellation notification to the QNC. The QCM can remove the corresponding pending reservation request, and 1705-1711 can be skipped.

[0285] Before 1705 is executed, the QCM itself can send a quantum connection reservation cancellation request to the QNC to cancel one or more quantum connection reservations. After receiving approval from the QNC, the QCM can remove the corresponding pending reservation request, and 1705-1711 can be skipped.

[0286] exist Figure 18 Multiple processes can be executed in [the context of the process]. Figure 18 At points 1801-1803, the code can be executed in accordance with the instructions here. Figure 17 The actions described are similar to those of 1801-1803. (See again...) Figure 18 At 1804, if multiple reservation requests can be received from different QNCs and can be received simultaneously, the QCM may optionally aggregate these quantum connection reservations together as a single reservation, but the QCM may not buffer these requests locally.

[0287] exist Figure 18 In steps 1805-1807, since the QCM may not buffer (e.g., any) reservation requests, it can configure one or more entanglement operations (e.g., entanglement creation and entanglement swap) at QNT-S, QNT-D, and QNR to satisfy a reservation request received at 1801 or an aggregation request at 1804. At 1805, the QCM can send a request to configure one or more entanglement operations at QNT-S, QNT-D, and one or more (e.g., each) QNR. This request may include a list of entanglement operations and one or more parameters received at 1801, such as qConnCreationTime, entanglementSwappingMode, entanglementSwappingProtocol, and / or targetAppID, etc.

[0288] exist Figure 18In step 1806, QNT-S, QNT-D, and QNR can be stored in a list of entangled operations received in step 1805. (E.g., each) The listed entangled operations can be executed sequentially and begin after qConnCreationTime. For example, an entanglement exchange can be performed after entanglement is created. In step 1807, QNT-S, QNT-D, and QNR can send a response to the QCM to indicate whether the entanglement operation configuration in step 1806 may have been successful. In step 1808, after a period of time (e.g., qConnCreationTime), QNT-S, QNT-D, and QNR can execute one or more of the entanglement operations configured in step 1806. During step 1808, one or more message exchanges can occur between QNT-S, QNT-D, and QNR. As a result of executing the configured entanglement operations, one or more message exchanges can occur between one or more QNRs. For example, after QNR-X may have completed performing an entanglement swap, it can send a notification to another QNR, such as QNR-Y, indicating that the entanglement swap is complete, to trigger QNR-Y to perform another entanglement swap, entanglement distillation, and / or other entanglement operations.

[0289] exist Figure 18 In 1809, QNT-S, QNT-D, and QCM can each report the execution results of one or more (e.g., each) entanglement operations to QCM. If one or more of them (e.g., all) successfully execute these operations, one or more entangled connections can now be established between QNT-S and QNT-D. Figure 18 In 1810, events could occur related to... Figure 17 The action described in 1811 is similar to that described in 1810. After 1810, whenever a quantum connection becomes unavailable (e.g., due to reduced entanglement fidelity) and / or is consumed, the QNT-S (or QNT-D) can send a notification to the QCM. The QCM can then mark the state of the consumed quantum connection as "consumed" and / or "unavailable." The QCM can then remove this unavailable or consumed quantum connection from its database.

[0290] exist Figure 18 In step 1801, QNT-S or QNT-D can also send a quantum connection reservation request to the QCM, which can be triggered by some pre-configured policy at QNT-S or QNT-D. For example, a sample policy could be set to create a quantum connection and not perform the action at step 1810c if the current quantum connection might be consumed or become unavailable due to low fidelity.

[0291] Prior to execution at 1808, the QNC can send a quantum connection reservation cancellation request to the QCM by indicating one or more qReservationIDs. The QCM can then contact the QNT-S / QNT-D and QNR to remove one or more (e.g., all) configured but pending entanglement operations. Execution at 1808-1810 may be omitted.

[0292] Prior to execution at 1808, the QNC can directly send quantum connection reservation cancellation requests to the QNT-S / QNT-D and QNR to remove one or more (e.g., all) configured but pending entanglement operations. Execution at 1808-1810 is optional.

[0293] Prior to execution 1808, the QNT-S (or QNT-D or QNR) may send an entanglement operation cancellation request to the QCM to cancel some pending entanglement operations. The QCM may contact the QNT-D (or QNT-S and other QNRs) to remove one or more (e.g., all) configured but pending entanglement operations. The QCM may notify the QNC of such cancellations reserved for one or more quantum connections. Execution 1808-1810 may not be performed.

[0294] Prior to execution at 1808, the QCM may send an entanglement operation cancellation request to the QNT-S, QNT-D, and one or more (e.g., all) QNRs to cancel one or more (e.g., all) configured but pending entanglement operations corresponding to one or more quantum connection reservations. It may notify the QNC of such cancellation regarding one or more quantum connection reservations.

[0295] It can provide joint quantum connection creation and classical connection creation. Figure 19 An example flowchart for jointly creating quantum connections and classical connections is shown. A scenario may exist where QNT-S and QNT-D can establish a quantum connection (e.g., a pair of entangled qubits) and a classical transport-level or application-level connection (e.g., a TCP or HTTP connection). For performance improvements, the quantum and classical connections can be jointly requested and established. The QNC can use a quantum reservation request to indicate a request for a classical connection and can indicate that the establishment of the classical connection can utilize the quantum connection to make the classical connection more secure. Furthermore, to establish a classical connection between QNT-S and QNT-D, one or more classical resources (e.g., classical bandwidth) on the classical nodes between QNT-S and QNT-D can be used. If the QCM knows that these classical nodes may not have sufficient resources (e.g., classical resources) to establish a classical connection, the QCM may choose not to establish a quantum connection between QNT-S and QNT-D.

[0296] Figure 19 The process for establishing a joint quantum and classical connection is illustrated. Figure 19 1901-1903 and Figure 17 Similar to 1901-1903, but with some differences. In 1901, the QNC could include the additional parameter `classicConnReq` to indicate a request to also create a classical connection between QNT-S and QNT-D, which could occur immediately after the quantum connection was established. In 1902, the QCM could also compute a classical path between QNT-S and QNT-D. The QCM could also check if sufficient resources (e.g., classical resources) existed on the computed classical path. If the QCM might not find a classical path with sufficient classical resources for the requested classical connection, and a quantum connection might have already been used to create the classical connection, the QCM could neither create any classical connection nor a quantum connection, and could report a failure in 1903. Furthermore, 1904-1907 could be skipped. If the QCM could find a classical path with sufficient classical resources, but might not find a suitable quantum path, the QCM could neither create any classical connection nor a quantum connection, and could report a failure in 1903. Furthermore, 1904-1907 could be skipped. If a QCM can find a classical path with sufficient classical resources and a quantum path with sufficient quantum capabilities, then a QCM can execute 1904-1907.

[0297] exist Figure 19 At point 1904, execution can be performed with... Figure 17 Actions similar to those in 1704-1711, or actions that can be performed similarly. Figure 18 Similar actions were taken in 1804-1810 to establish a quantum connection between QNT-S and QNT-D.

[0298] exist Figure 19 In 1905, the QCM can send a classical connection creation request to the QNT-S. This request can contain information about the established quantum connection (such as a quantum connection identifier), which can instruct the QNT-S to use the quantum connection to establish a secure classical connection with the QNT-D.

[0299] exist Figure 19 At point 1906, QNT-S can use a quantum connection to establish a classical connection with QNT-D. For example, the quantum connection can be consumed to achieve quantum instantaneous teleportation or quantum ultra-dense coding, which can be utilized to establish a classical connection. In another example, QNT-S and QNT-D can use this quantum connection to perform QKD to establish a secure key between QNT-S and QNT-D. QNT-D and QNT-D can then use the secure key to establish a secure classical connection between them, such as a QKD-based TLS / DTSL session. Figure 19In 1907, the QNT-S (or QNT-D) can send a response to the QCM to indicate that the quantum connection may have been consumed and that the classical connection may have been successfully established or not.

[0300] Quantum connectivity can be provided as a service. Figure 20 An example implementation for providing quantum connectivity as a service is illustrated. The established quantum connectivity (e.g., entanglement between a source QNT and a destination QNT) may not be maintained for a long time with minimum fidelity, but the entanglement coherence time can be greatly improved. Thus, quantum connectivity can be provided as a service. For example, a QCM can actively establish quantum connectivity between different QNTs and can provide them as a service to a QNC. For example, a QNC may not request the QCM to create quantum connectivity (e.g., new quantum connectivity), but can request existing quantum connectivity from the QCM. The QCM can then search for its established quantum connectivity and assign one or more established quantum connectivity to the QNC by informing the QNC of the identifier of the assigned quantum connectivity, the DNT-S of the assigned quantum connectivity (e.g., each assigned quantum connectivity), and the QNT-D of each assigned quantum connectivity. The assigned quantum connectivity can be used and consumed to support quantum applications such as QKD. For example, a QNC can contact the QNT-S (or QNT-D) to use the assigned quantum connectivity (e.g., entanglement) to support quantum applications such as QKD. The QNC or the source (or destination) QNT of the assigned quantum connection can send a notification to the QCM to report the consumption of the assigned quantum connection.

[0301] Figure 20 The process for providing quantum connectivity as a service is illustrated. QCM may have already been used in 2000. Figure 17 and Figure 18 The process establishes one or more quantum connections between each pair of QNTs. In 2001, the QNC can request the number of existing quantum connections from the QCM. This request message can contain one or more of the following parameters:

[0302] • NumOfQConn: Indicates the number of quantum connections that the QNC can request from the QCM.

[0303] ·qntAddr: Indicates the addresses of the source QNT and destination QNT on which the requested quantum connection may have been established.

[0304] • appInfo: Indicates the type and / or name of the application that can use / consume the requested quantum connection.

[0305] In 2002, the QCM can search for one or more (e.g., all) existing and still usable quantum connections established in 2000. The QCM can select one or more quantum connections and assign them to the QNC, as requested in 2001. The message can contain the following parameters:

[0306] ·qConnIDs: Identifiers that can indicate one or more (e.g., all) quantum connections that are assigned or distributed to a QNC.

[0307] ·qntAddr: can indicate the addresses of the source QNT and destination QNT of the assigned quantum connection (e.g., each assigned quantum connection).

[0308] In 2003, the QNC can send a request to a QNT (which can be a source QNT or a destination QNT, as included in 2001 or received in 2002) to trigger the consumption of one or more assigned quantum connections. The identifier of the corresponding quantum connection (e.g., qConnIDs already received in 2002) can be included in this message. The appInfo can also be included in this message. In 2004, the QNT can use / consume the specified quantum connection to support an application as represented by the appInfo in 2003.

[0309] In 2005, QNT could send a response to QNC. This response could indicate whether the specified quantum connection could be successfully utilized and consumed. The response could also contain application-related information.

[0310] In 2006, the QNC could notify the QCM of the consumption of a specified quantum connection. The identifier of the consumed quantum connection could be included in this message. In 2007, the QCM could receive notifications from the QNC. It could mark the status of the consumed quantum connection as "consumed" and / or "unavailable." It could send a response to the QNC as an acknowledgment.

[0311] about Figure 20 The QNT can be either a source QNT or a destination QNT that may be involved in the quantum connection. In 2003, the request could be sent from the QCM to the QNT. In 2004, a QNT could contact another QNT (e.g., a destination QNT) to consume a specified quantum connection to support quantum applications. The notification sent in 2006 could be from the QNT to the QCM. For example, the QNT could also send a quantum connection consumption notification to the QCM.

[0312] It can provide advanced quantum link layer services. Figure 21An example quantum link layer service is illustrated. In a quantum network, the protocol stack for a quantum network node (QNN) can consist of a quantum physics layer, a quantum link layer, a quantum network layer, a quantum transport layer, and / or a quantum application layer. Among these layers, the quantum network layer, quantum transport layer, and quantum application layer can be classified as higher layers, which may not generate or maintain quantum properties (e.g., any quantum property), such as qubits, but can interact with the quantum link layer to access, utilize, and manage qubits and entangled qubits. The QNN can be a quantum network terminal (QNT) or a more functional quantum network router (QNR). The QNR can support advanced entanglement operations, such as entanglement swapping and entanglement distillation.

[0313] In one embodiment, a QNR can be a base station in a cellular network, a satellite, a vehicle with a quantum channel (e.g., a satellite link or free-space optics) to other network nodes, a backhaul router in a cellular network, and / or a broadband access router, etc. In one embodiment, a QNT can be a vehicle with a quantum channel (e.g., a satellite link or free-space optics) to other network nodes, a customer premises equipment (CPE) with optical fiber as a quantum channel, a satellite, a satellite ground station, a user equipment (UE) in a cellular network that may have a quantum channel to other UEs or to its base station, and / or a base station in a cellular network, etc.

[0314] In this way, quantum link layer services (e.g., basic link layer services for creating entangled qubits) can exist between the quantum link layer within the QNT or QNR and higher layers (e.g., quantum network layer, quantum transport layer, and / or quantum application layer), so that the higher layers can efficiently access the quantum link layer to create and manipulate qubits, including entangled qubits. Figure 21 As shown, the quantum link layer service may include multiple services.

[0315] Figure 21 An example embodiment of a quantum link layer service is shown. This quantum link layer service can provide advanced entanglement creation. Higher layers can request the quantum link layer to create entangled qubits with one or more requirements, such as the lifetime of the entangled qubits, the need to distribute an entangled qubit to another quantum network node, and / or similar requirements.

[0316] The quantum link layer service can provide periodic entanglement creation. Higher layers can request the quantum link layer to periodically create entangled qubits. This periodic entanglement creation enables periodic quantum key distribution (QKD) and periodic changes to the secure key.

[0317] The quantum link layer service can provide updates to pending entanglement creation requests. Higher layers can request the quantum link layer to update one or more parameters associated with a pending entanglement creation request. As a result, the quantum link layer can use the values ​​of these parameters (e.g., new values) to process the pending request to create entangled qubits (e.g., new entangled qubits).

[0318] The quantum link layer service can provide the ability to cancel pending entanglement creation requests. Higher layers can request the quantum link layer to remove pending entanglement creation requests.

[0319] The quantum link layer service can provide the ability to query existing entanglement creation requests. Higher layers can query the status and related parameters of existing entanglement creation requests that may have been received at the quantum link layer.

[0320] The quantum link layer service can provide the ability to trigger qubit measurements. Higher layers can request the quantum link layer to measure some qubits. The quantum link layer can store the measurement results or return them to higher layers.

[0321] The quantum link layer service can provide configuration / querying of quantum statistics. Higher layers can configure the quantum link layer to calculate and collect one or more quantum statistics, which can then be retrieved / queried by the higher layers.

[0322] The quantum link layer service can provide entanglement distribution. Higher layers can trigger the quantum link layer to distribute one or more entangled qubits to one or more other quantum network nodes.

[0323] The quantum link layer service can provide the ability to trigger entanglement swaps. Higher layers can trigger the quantum link layer to perform entanglement swaps on one or more sets (e.g., two or more sets) of entangled qubits to generate a new set (e.g., a new set) of entangled qubits.

[0324] The quantum link layer service can provide triggered entanglement distillation. Higher layers can trigger the quantum link layer to perform entanglement distillation on one or more sets (e.g., two or more sets) of entangled qubits to improve the fidelity of a set of entangled qubits.

[0325] The quantum link layer service can provide automatic entanglement swapping and distillation. Higher layers can configure one or more entanglement swapping / distillation strategies to the quantum link layer, enabling the quantum link layer to automatically trigger and execute entanglement swapping and distillation based on the configured strategies.

[0326] Of these services, triggered entanglement swapping, triggered entanglement distillation, and automatic entanglement swapping and distillation are applicable to the quantum link layer at quantum network routers (or quantum repeaters) and may not be applicable to conventional quantum network nodes that act as simpler quantum network endpoints.

[0327] Figure 22 An example embodiment of information maintained at the quantum link layer is shown. To support these quantum link layer services, the quantum link layer may maintain one or more databases (such as...). Figure 22 As shown in the figure, these databases can be accessed by higher levels.

[0328] A request database can be provided. This database can store one or more (e.g., all) requests received from higher layers, such as entanglement creation requests and their status. In the case of entanglement creation requests, their status can be pending, successful entanglement creation, and / or failed entanglement creation, etc. Higher layers can search and query requests (e.g., any request) from this database, including their status. Higher layers can also request the quantum link layer to cancel and remove existing requests. The quantum link layer can remove the corresponding requests from this database.

[0329] A quantum policy database can be provided. Higher layers can configure quantum policies (e.g., when and how to perform entanglement swaps on which entangled pairs) and send them to the quantum link layer. The quantum link layer can store these policies in the database and use them to protect its actions and behaviors (e.g., policy-based automatic entanglement swaps and / or distillation). Higher layers can also update the configured policies in the database and remove them from the database.

[0330] An entanglement database can be provided. The quantum link layer can use this database to store identifiers of one or more (e.g., all) entanglements (e.g., previously created entanglements, consumed entanglements, swapped entanglements, and / or distilled entanglements, etc.), their states (e.g., entanglement fidelity), and identifiers of the entangled qubits involved. Higher layers can send requests to this database to query the state of existing entanglements or trigger the swapping of two existing entanglements.

[0331] A qubit database can be provided. This database can store the logical identifiers of one or more (e.g., each) existing qubits, their state bases, their states, and the logical identifiers of other related and entangled qubits, and / or the like. Higher layers can send requests to this database to trigger qubit measurements.

[0332] A quantum statistics database can be provided. The quantum link layer can calculate and collect one or more quantum statistics parameters, such as the successful entanglement generation rate, the successful entanglement swapping rate, and / or the number of entanglements generated per second. Higher layers can search and query quantum statistics parameters from this database. Higher layers can also add quantum statistics parameters to the database.

[0333] While the description of the quantum link layer service as described herein can be based on the case where entanglement contains only two qubits, the quantum link layer service embodiments can also be applied to and extended to cases where entanglement also contains more than two qubits.

[0334] It can provide advanced quantum link layer services for entanglement creation. Figure 23 An example embodiment of an enhanced link layer service for entanglement creation is shown. For example, Figure 23 An enhanced link layer service for entanglement creation is illustrated, where higher layers can instruct the quantum link layer to provide additional parameters (e.g., new parameters) to support high-level features for generating entangled qubits, such as: entanglement with a specific lifetime, entanglement creation with a specific number of attempts, entanglement distribution instructions or reservations, entanglement use reservations, and / or similar features. In this context, creating entanglement can mean creating a pair of entangled qubits (or a set of more than two entangled qubits).

[0335] exist Figure 23 In step 2301, higher layers can send entanglement creation requests to the link layer. The request primitive can include one or more of the following parameters to support advanced entanglement creation:

[0336] • entanglementLifetime: This indicates how long entangled qubits need to be maintained after they are generated. After this duration, the entangled qubits may be destroyed.

[0337] ·maxAttempt: It indicates the number of attempts (e.g., the maximum number of attempts) that the quantum link layer can attempt to successfully generate the requested entanglement.

[0338] • timeForEntanglingWithRemoteNode: This parameter indicates when a qubit in a generated entangled pair can be distributed to another quantum network node (QNN). This parameter tells the quantum link layer to prepare to distribute the entangled qubit to the remote node at a future time.

[0339] • `timeForUsingEntanglement`: This parameter indicates when the generated entangled pair (e.g., qubit A and qubit B) can be applied and used. For example, after one qubit (e.g., qubit A) in the entangled pair can be distributed to another QNN, this parameter can indicate when the other qubit (e.g., qubit B) can be used for quantum applications and / or used to perform entanglement swaps. This parameter tells the quantum link layer to be ready to use the generated entanglement in the future.

[0340] • targetAppID: It can indicate an identifier that can be used for the target quantum application created by the entanglement.

[0341] • requestID: It can indicate the identifier of the request, and higher layers can set this identifier for use in the quantum link layer.

[0342] exist Figure 23 At 2302, the quantum link layer can process the request and prepare to generate entanglement as requested at 2301. For example, if maxAttempt is indicated at 2301, the quantum link layer can attempt (=maxAttempt) multiple times to the quantum physical device until the requested entanglement can be successfully created. If the requested entanglement can be successfully created, the quantum link layer can assign it an identifier, called entanglementID.

[0343] exist Figure 23 At 2303, the quantum link layer may send a response to higher layers to indicate whether entanglement creation at 2302 has been successful by including an entanglementID. The response may also include a requestID if it may have been set or modified by the quantum link layer. The response sent at 2303 may be a response received after 2302 but before any requested entanglement can be created (e.g., an immediate response).

[0344] It can provide quantum link layer services for the creation of periodic entanglement. Figure 24 An example embodiment of a link-layer service for creating periodic entanglement is shown. Figure 24 An example process for creating periodic entanglement is illustrated. In this case, a higher layer can send a request to the quantum link layer, asking it to generate multiple entanglements (e.g., multiple pairs or multiple sets of entangled qubits).

[0345] exist Figure 24 In section 2401, higher layers can send periodic entanglement creation requests to the quantum link layer. This request can indicate the number of entanglements to be generated (e.g., numOfEntanglements), the time interval between two entanglements (e.g., timeInterval), and how the quantum link layer can send responses to the generated entanglements to higher layers (e.g., responseMode). The request may also include information regarding... Figure 23 The parameters in 2301.

[0346] exist Figure 24At 2402, the quantum link layer can process the received request to prepare for the creation of entanglement (e.g., new entanglement). At 2403, the quantum link layer can send a response to the higher layer. This response may include an identifier of the request sent at 2401 (e.g., requestID). The requestID can be assigned by the link layer, or it can be set by the higher layer and sent at 2401.

[0347] exist Figure 24 In steps 2404-2407, the quantum link layer sequentially generates two entanglements. For each (e.g., each) generated entanglement, the quantum link layer can assign an entanglementID as its identifier. The quantum link layer can include the entanglementID in its response and can send it to a higher layer. Depending on the responseMode at 2401, for example, if responseMode = Aggregated, the quantum link layer can send a response after generating two (or more, if requested) entanglements. If numOfEntanglements at 2401 is greater than that at 2402, the quantum link layer can continue to generate more entanglements.

[0348] At 2408, at some point and possibly before one or more (e.g., all) of the requested entanglements can be generated, the higher layer may decide to cancel one or more (e.g., all) of the pending entanglements to be generated that can be associated with the periodic entanglement request (e.g., requestID). The higher layer may send a cancellation of the pending entanglement creation request to the quantum link layer. As a result, the pending entanglements associated with the periodic entanglement request (e.g., any pending entanglements) and any entanglements that may be generated soon can be canceled. At 2409, the quantum link layer may send a response to the higher layer. This response may indicate the number of entanglements successfully generated.

[0349] A quantum link layer service can be provided for updating pending entanglement creation requests. Figure 25 This illustrates a sample flowchart of a link-layer service used to update pending entanglement creation requests. For example, Figure 25 This illustrates a link-layer service (e.g., a new link-layer service) for updating a pending entanglement creation request. In this example, a higher layer may have already sent a previous entanglement creation request to the quantum link layer, but the requested entanglement may not yet have been generated. This request may be referred to as a pending entanglement creation request. The higher layer may decide to update this pending entanglement creation request to instruct the quantum link layer to generate the remaining entanglement in a different manner. In 2501, the higher layer may send a request to the quantum link layer. This request may include an identifier of the pending entanglement creation request (e.g., requestID) and parameters for one or more parameters (such as...). Figure 23 2301 and Figure 24 The values ​​(e.g., new values) indicated at position 2401 in the table.

[0350] At 2502, the quantum link layer may receive the request and may adjust the method used to create future entanglement for the pending entanglement creation request (e.g., requestID) based on the parameter values ​​included in 1 (e.g., new parameter values). At 2503, the quantum link layer may send a response to a higher layer, indicating whether it can accept the parameter values ​​(e.g., new parameter values) suggested in 2501. The quantum link layer may accept one or more parameter values ​​and may reject other parameter values, which may be notified to the higher layer in the response.

[0351] A quantum link layer service can be provided to cancel pending entanglement creation requests. Figure 26 This diagram illustrates an example flowchart of a link-layer service for canceling pending entanglement creation requests. A higher layer may have already sent one or more entanglement creation requests to the quantum link layer, but it may still be too early to generate one or more of the requested entanglements, and therefore those requests may still be pending. The higher layer can request the cancellation of those pending requests. At 2601, the higher layer can send a request to cancel the pending entanglement creation requests. This request may include a requestID, which may indicate one or more pending entanglement creation requests to be canceled. At 2602, the quantum link layer can locate and remove one or more (e.g., all) pending requests as indicated by the requestID. At 2603, the quantum link layer can send a response to the higher layer indicating whether one or more (e.g., each) pending requests have been successfully removed. If some pending requests may not have been successfully removed, the response may include a list of pending requests that may have been removed or may not have been removed.

[0352] A quantum link layer service can be provided for querying existing entanglement creation requests. Figure 27 This diagram illustrates a sample flowchart for querying an existing entanglement creation request from a link-layer service. Figure 27This illustrates a link-layer service (e.g., a new link-layer service) for querying existing entanglement creation requests. In this case, the quantum link layer may have already received some previous entanglement creation requests, which may have been fully executed or may still be pending, but they can be considered existing entanglement creation requests and can be maintained at the quantum link layer. At 2701, a higher layer can send a request to the quantum link layer to query one or more existing entanglement creation requests. The identifiers of those existing entanglement creation requests can be included in the requestID. At 2702, the quantum link layer can locate those existing entanglement creation requests and retrieve their status (e.g., whether it may have been executed, whether the requested entanglement has been generated, how long the link layer needs to wait until the requested entanglement is generated, etc.). At 2703, the quantum link layer can send a response to a higher layer. This response may contain the status of those existing entanglement creation requests retrieved at 2701 (e.g., requestStatus).

[0353] It can provide quantum link layer services for triggering qubit measurements. Figure 28 An example flowchart for a link-layer service used to trigger qubit measurements is shown. For example, Figure 28 A quantum link layer service for triggering qubit measurements at the quantum link layer can be demonstrated. In 2801, a higher layer can send a qubit measurement request to the quantum link layer. This request can indicate a logical identifier (e.g., qubitID) or an identifier of existing entanglement for the qubit to be measured, and a quantum state basis (qBasis) on which the measurement can be performed. The higher layer can also indicate additional measurement conditions (e.g., measurementConditions). In 2802, the quantum link layer can receive the request, locate the specified qubits that may be existing entanglement, and wait to measure them until the indicated measurement conditions are met. In 2803, the quantum link layer can send the qubit measurement results to the higher layer.

[0354] A quantum link layer service can be provided for configuring / querying quantum statistics. Figure 29 A sample flowchart for configuring / querying quantum statistics in the link layer is shown. For example, Figure 29A quantum link layer service for configuring and querying quantum statistics at the quantum link layer is illustrated. At 2901, a higher layer can send a request to configure an action or strategy for collecting quantum statistics (e.g., qubits and entanglement) at the quantum link layer. For example, qStatisticParameters can include a list of quantum statistical parameters that the quantum link layer can compute and collect. At 2902, the quantum link layer can process the request primitive at 2901 and can begin computing the specified quantum statistical parameter. At 2903, the quantum link layer can send a response to the higher layer. This response can contain an identifier for one or more (e.g., each) quantum statistical parameters, allowing the higher layer to use that identifier (e.g., at 2907) to query and retrieve their values. At 2904, after a period of time, the values ​​of the quantum statistical parameters can become available.

[0355] At 2905, the quantum link layer can proactively and periodically report selected quantum statistical parameters to the higher layer. This behavior can be requested and specified by the higher layer at 2901. For example, the higher layer can indicate at 2901 a list of quantum statistical parameters to be reported and the reporting frequency. At 2906, the higher layer can send a response to the quantum link layer. At 2907, the higher layer can send a request to query certain quantum statistical parameters. The higher layer can learn from 2903 the identifiers of one or more (e.g., each) statistical parameters created and stored at the quantum link layer. At 2908, the quantum link layer can send a response to the higher layer.

[0356] A quantum link layer service for entanglement distribution can be provided. After entanglement may occur at a QNN, a higher layer of that QNN can trigger its quantum link layer to distribute the entangled qubit(s) to other QNNs. This can happen in several ways. Here are three example scenarios, although others may exist:

[0357] • Scenario 1 - The quantum link layer can distribute one qubit of an entangled pair to another QNN. The other qubit in the entangled pair may not be distributed to any other QNN, but may be stored locally.

[0358] •Scenario 2 - The quantum link layer can distribute the two qubits of an entangled pair to the same QNN.

[0359] • Scenario 3 - The quantum link layer can distribute one or more (e.g., each) qubits in an entangled pair to different QNNs.

[0360] Figure 30 An example flowchart is shown for a link-layer service used to trigger entanglement distribution. For example, Figure 30The diagram illustrates a link-layer service (e.g., a new link-layer service) for entanglement distribution in scenarios 1 and 2 described above. In this scenario, the quantum link layer of QNN-1 may have already created one or more entangled qubits, and a higher layer of QNN-1 can request the quantum link layer to distribute one or more entangled qubits to another QNN (e.g., QNN-2). At 3001, the higher layer of QNN-1 can send an entanglement distribution request to the quantum link layer. This request may include one or more of the following parameters:

[0361] • entanglementDistMode: This can instruct the quantum link layer how to perform entanglement distribution, for example:

[0362] • When entanglementDistMode=1, the quantum link layer can distribute one qubit of the entanglement pair to another QNN. The other qubit of the entanglement pair may not be distributed to any other QNN, but can be stored locally.

[0363] • entanglementDistMode = 2, the quantum link layer can distribute the two qubits of an entangled pair to the same QNN.

[0364] With entanglementDistMode=3, the quantum link layer can distribute each qubit of an entangled pair to a different QNN. This is in... Figure 30 It may not be shown in the image.

[0365] • entanglementDistTime: This indicates when the quantum link layer can perform entanglement distribution. For example, a higher layer can send its request in advance at 3001, giving the quantum link layer time to prepare for entanglement distribution.

[0366] `entangledQubitInfo`: This parameter can indicate information about the entangled qubits to be distributed and the identifiers of the QNNs to which the entangled qubits can be distributed. This parameter can contain a list of elements, and one or more (e.g., each) of these elements can be used for different entanglements to be distributed. For example, each element can be represented as: `(entanglementID, qubitIDToBeDistributed, qnnID)`, where `entanglementID` can be an identifier of an existing entanglement, `qubitIDToBeDistributed` can be an identifier of one or more qubits that can be distributed and associated with an existing entanglement as represented by `entanglementID`, and `qnnID` can be an identifier of one or more QNNs. `qubitIDToBeDistributed` can be optional.

[0367] • If entanglementDistMode = 1, then qnnID contains an identifier for a QNN.

[0368] • If entanglementDistMode = 2, then qnnID contains an identifier for a QNN.

[0369] • If entanglementDistMode = 3, then qnnID contains identifiers for both QNNs. This is in Figure 30 It may not be shown in the image.

[0370] • targetAppID: The target quantum application that can use the distributed entangled qubits.

[0371] exist Figure 30 At 3002, this can be optional. If entanglementDistTime can be included at 3001, the quantum link layer of QNN-1 can wait for a certain time, as represented by entanglementDistTime, before it can distribute entangled qubits to other QNNs. However, it can send an immediate response to the higher layers of QNN-1 to confirm that the request received at 3001 has been received, and can later perform the requested entanglement distribution, such as at 3003.

[0372] At 3003, it can be optional that, after a time such as entanglementDistTime, the quantum link layer of QNN-1 can perform the requested entanglement distribution. The quantum link layer of QNN-1 can send an entanglement distribution request to the quantum link layer of QNN-2 to notify QNN-2 that QNN-1 can transfer some entangled qubits to QNN-2 at 3004. This request message can contain one or more of the parameters included at 3001, and can include one or more of the following parameters:

[0373] • Identifier for QNN-1.

[0374] • Identifier of the quantum link layer of QNN-1.

[0375] • An identifier for a quantum channel that can be used to transmit qubits at position 3004.

[0376] • The duration that can continue in the quantum channel in 3004.

[0377] At 3004, the quantum link layer of QNN-1 can transfer one or more specified qubits to the quantum link layer of QNN-2 via a quantum channel. This can occur after 3003 or after a time such as entanglementDistTime. Furthermore, one or more of the following actions can be performed:

[0378] • If entanglementDistMode = 1, then the quantum link layer of QNN-1 can instruct the quantum physical layer to transfer one designated qubit in each entanglement to another QNN (i.e., QNN-2).

[0379] • If entanglementDistMode = 2, the quantum link layer can instruct the quantum physics layer to transfer the two entangled qubits to the same QNN (i.e., QNN-2).

[0380] • If entanglementDistMode = 3, the quantum link layer can instruct the quantum physics layer to transfer each pair of entangled qubits to a different QNN, which can happen one after another. This is in Figure 30 It may not be shown in the image.

[0381] At 3005, the quantum link layer of QNN-2 receives the transmitted qubits that can be sent at 3004. It can send entanglement distribution instruction primitives to higher layers of QNN-2. These instruction primitives can contain one or more parameters received at 3003.

[0382] At 3006, a higher layer of QNN-2 can send an entanglement distribution response to the quantum link layer of QNN-2 as an acknowledgment. The higher layer of QNN-2 can also send primitives to a target quantum application that can reside on QNN-2 and use the distributed qubits. An identifier for the target quantum application can be included at 3001, and this identifier can be retransmitted at 3003 and / or 3005.

[0383] In 3007, the QNN-2 quantum link layer can send an entanglement distribution response message to the QNN-1 quantum link layer. This message can contain identifiers of the qubits that have been successfully received in 3004. In 3008, the QNN-1 quantum link layer can send an entanglement distribution acknowledgment message to higher layers of QNN-1 to notify which entanglements have been successfully distributed and which have not.

[0384] exist Figure 30In this context, 3004-3007 can be used to distribute one or two qubits of the same entangled pair. If 1 contains multiple entanglements to be distributed (e.g., N entanglements), then 3004-3007 can be repeated N times. Furthermore, 3003-3004 can be combined in one or more actions on the quantum channel, but the information contained at 3003 can be transmitted before the qubit contained at 3004.

[0385] Figure 31 An example flowchart of a link layer service for entanglement distribution is shown. The quantum link layer can distribute one or more (e.g., each) qubits in an entangled pair to different QNNs. For example, Figure 31 A link-layer service (e.g., a new link-layer service) for entanglement distribution is illustrated, where a quantum link layer can distribute one or more (e.g., each) qubits from an entangled pair to different QNNs. In this scenario, one or more entangled qubits may have already been created by the quantum link layer of QNN-1. A higher layer of QNN-1 may request the quantum link layer to distribute one entangled qubit to QNN-2 and the remaining entangled qubits to QNN-3. Alternatively, the following operations can also be performed:

[0386] ·3101-3102: can be similar to Figure 30 3001-3002 in the middle.

[0387] ·3103(a) / 3(b): can be similar to Figure 30 3003.

[0388] ·3104(a) / 4(b): can be similar to Figure 30 3004.

[0389] ·3105(a) / 5(b): can be similar to Figure 30 3005.

[0390] ·3106(a) / 6(b): can be similar to Figure 30 3006.

[0391] ·3107(a) / 7(b): can be similar to Figure 30 3007.

[0392] • 3108: The quantum link layer of QNN-1 can aggregate responses received from 3107(a) and 3107(b).

[0393] ·3109: can be similar to Figure 30 3008.

[0394] It can provide quantum link layer services for triggering entanglement swaps. Figure 32An example flowchart for a link-layer service used to trigger entanglement switching is shown. For example, Figure 32 A link-layer service (e.g., a novel link-layer service) for triggering entanglement swaps is illustrated. In this scenario, the physical device can hold two or more unrelated qubits: qubit B and qubit C, which come from two or more different entanglement groups (e.g., qubit B comes from entanglement pair #1 including qubit A and qubit B, and qubit C comes from another entanglement pair #2 including qubit C and qubit D). A higher layer can trigger a quantum link layer to perform an entanglement swap between entanglement pairs #1 and #2. The result of this entanglement swap can be the entanglement of qubit A and qubit D by performing one or more operations on qubit B and qubit C.

[0395] At 3201, the higher layer may send an entanglement swap request to the quantum link layer. This request may include identifiers of two entangled pairs (e.g., entangledPairID1 and entangledPairID2) and identifiers of two unrelated qubits (e.g., qubitID1 and qubitID2). The request also indicates the method or protocol (e.g., swapProtocol) that the quantum link layer should use to perform the entanglement swap. At 3202, the quantum link layer may perform an entanglement swap on the two unrelated qubits (e.g., as indicated by qubitID1 and qubitID2) using the protocol indicated by swapProtocol in 3201. At 3203, the quantum link layer may generate an entanglement identifier (e.g., a new entanglement identifier) ​​and send it as a response to the higher layer. Alternatively, or otherwise, the higher layer may generate an entanglement identifier (e.g., a new entanglement identifier) ​​based, for example, on entangledPairID1 and entangledPairID2, since the original entanglement represented by these two identifiers may no longer exist.

[0396] A quantum link layer service can be provided to trigger entanglement distillation. Figure 33An example flowchart for a link-layer service used to trigger entanglement distillation is shown. In this scenario, the quantum link layer may have successfully created multiple entangled pairs, and the quantum link layer has access to these multiple entangled pairs. Their fidelity may become below a threshold and may not be utilized by quantum applications. Entanglement distillation can be used to improve the fidelity of one or more entangled pairs by consuming and / or sacrificing other entangled pairs via entanglement distillation. At 3201, a higher layer may send an entanglement distillation request to the quantum link layer. This request may contain a list of existing entangled pairs (e.g., entangledPairIDs) and may also indicate the minimum fidelity (e.g., minFidelity) that can be requested for entanglement distillation implementation. At 3202, the quantum link layer may receive the request and may perform entanglement distillation on those existing entangled pairs. The quantum link layer may use only one or more entangled pairs to improve the fidelity of another entangled pair above minFidelity. It may not operate on and / or consume one or more of the entangled pairs (e.g., all entangled pairs) represented by entangledPairIDs to give a pair a fidelity greater than minFidelity. At 3203, the quantum link layer may send a response to a higher layer indicating whether the requested entanglement distillation is likely to succeed, and also indicating identifiers of one or more consumed entanglements (e.g., all consumed entanglements). Optionally, if the quantum link layer has the ability to estimate it, it may indicate the fidelity achieved in 3202 in that response.

[0397] It can provide quantum link layer services for policy-based automatic entanglement swapping and distillation. Figure 34 An example flowchart for a link-layer service using policy-based automatic entanglement swapping / distillation is shown. For example, Figure 34 A link-layer service (e.g., a new link-layer service) for policy-based automatic entanglement swapping and distillation performed at the quantum link layer is illustrated. At 3401, a higher layer can send a request to the quantum link layer to configure some policies (e.g., entanglementPolicies) for entanglement swapping and distillation. At 3402, the quantum link layer can verify these entanglement policies and store them locally. At 3403, the quantum link layer can send a response to the higher layer. At 3404, an event may occur at the quantum link layer that matches one or more stored entanglement policies. At 3405, the quantum link layer can perform entanglement swapping and / or distillation as specified in the matched entanglement policy. At 3406, the quantum link layer can send the results of the performed entanglement swapping and distillation to the higher layer.

[0398] The embodiments described herein may use multiple different networks. The network may include a quantum internet that utilizes wired systems (e.g., fiber optic systems) and / or wireless systems (e.g., laser-based communication systems). For example, embodiments may use a quantum internet that employs quantum satellites capable of sending and / or receiving entangled photons.

Claims

1. A device for managing one or more quantum nodes within a quantum network, the device comprising: The processor is configured as follows: Receive a first message, wherein the first message indicates a request to create a quantum connection between a source quantum network terminal (QNT) and a destination QNT, and wherein the first message further indicates the time when the quantum connection should be created; A quantum path for the quantum connection is determined, wherein a first quantum network router (QNR) and a second QNR are associated with the quantum path, wherein the quantum path is determined based on a first QNR having one or more first quantum capabilities that satisfy one or more capability criteria at an indicated time and a second QNR having one or more second quantum capabilities that satisfy the one or more capability criteria at the indicated time. A second message is sent to the first QNR, wherein the second message indicates a request for the first QNR to create a first entangled qubit pair for the first hop of the quantum path. Send a third message to the second QNR, wherein the third message indicates a request for the second QNR to create a second entangled qubit pair for the second hop of the quantum path; Send a fourth message to the first QNR, wherein the fourth message indicates a request for the first QNR to perform an entanglement swap by using the first entangled qubit pair and the second entangled qubit pair to provide the quantum path for the quantum connection; Send a fifth message to the second QNR, wherein the fifth message indicates a request for the second QNR to perform entanglement swap by using the first entangled qubit pair and the second entangled qubit pair to provide the quantum path for the quantum connection; and Receive an acknowledgment message indicating that the quantum connection has been created.

2. The device according to claim 1, wherein, The device is a quantum network manager (QNM).

3. The device of claim 1, wherein the processor is further configured to receive a response message from the first QNR, the response message indicating that the entanglement swap has been performed.

4. The device of claim 1, wherein the processor is further configured to send a fourth message indicating a quantum connection identifier to one or more of the source QNT, the destination QNT, or a quantum network client (QNC), wherein the quantum connection identifier is associated with the quantum path and the quantum connection.

5. The device according to claim 1, wherein, The processor is also configured to send a sixth message to one or more of the source QNT, the destination QNT, or the quantum network client (QNC), wherein the sixth message indicates that the quantum path for the quantum connection has been established.

6. The device of claim 1, wherein the first message further indicates a strategy specifying when the quantum connection should be created.

7. The device of claim 1, wherein the one or more capability criteria are associated with any of the following: (1) availability of one or more quantum resources, (2) capability to perform entanglement swapping, (3) capability to perform entanglement distillation, and (4) capability to support quantum applications.

8. A method for managing one or more quantum nodes within a quantum network, the method comprising: Receive a first message, wherein the first message indicates a request to create a quantum connection between a source quantum network terminal (QNT) and a destination QNT, and wherein the first message further indicates the time when the quantum connection should be created; A quantum path for the quantum connection is determined, wherein a first quantum network router (QNR) and a second QNR are associated with the quantum path, wherein the quantum path is determined based on a first QNR having one or more first quantum capabilities that satisfy one or more capability criteria at an indicated time and a second QNR having one or more second quantum capabilities that satisfy the one or more capability criteria at the indicated time. A second message is sent to the first QNR, wherein the second message indicates a request for the first QNR to create a first entangled qubit pair for the first hop of the quantum path. Send a third message to the second QNR, wherein the third message indicates a request for the second QNR to create a second entangled qubit pair for the second hop of the quantum path; Send a fourth message to the first QNR, wherein the fourth message indicates a request for the first QNR to perform an entanglement swap by using the first entangled qubit pair and the second entangled qubit pair to provide the quantum path for the quantum connection; Send a fifth message to the second QNR, wherein the fifth message indicates a request for the second QNR to perform entanglement swap by using the first entangled qubit pair and the second entangled qubit pair to provide the quantum path for the quantum connection; and Receive an acknowledgment message indicating that the quantum connection has been created.

9. The method according to claim 8, wherein, The device is a quantum network manager (QNM).

10. The method of claim 8, further comprising: A response message is received from the first QNR, indicating that the entanglement swap has been performed.

11. The method of claim 8, further comprising: A fourth message indicating a quantum connection identifier is sent to one or more of the source QNT, the destination QNT, or the quantum network client (QNC), wherein the quantum connection identifier is associated with the quantum path and the quantum connection.

12. The method according to claim 8, further comprising: A sixth message is sent to one or more of the source QNT, the destination QNT, or the quantum network client (QNC), wherein the sixth message indicates that the quantum path for the quantum connection has been established.

13. The method of claim 8, wherein the first message further indicates a strategy specifying when the quantum connection should be created.

14. The method of claim 8, wherein the one or more capability criteria are associated with any of the following: (1) availability of one or more quantum resources, (2) capability to perform entanglement swapping, (3) capability to perform entanglement distillation, and (4) capability to support quantum applications.

Images