Re: [Qirg] Measurements in link layer service

[Axel Dahlberg <[e-mail]>]

Hi Wojtek!

Maybe I am misunderstanding what you mean but I do not see how this would work. In the case of measure directly, if one wants to have a higher rate by having multiple photons in flight at the same time, the measurement needs to be performed in every attempt and thus needs to be part of the entanglement generation request. If a measurement operation comes after the entanglement generation one anyway needs to wait for the heralding signal for each attempt and can therefore not have a higher rate.

In the case of remote state preparation, one anyway cannot go faster, since one of the nodes need to store the entanglement qubit. However, it might be that the requesting node is a very simple end-node with no memory and cannot therefore support a create and keep request and then measure it.

/Axel Dahlberg

________________________________
From: Wojciech Kozlowski
Sent: 20 November 2019 03:15:43
To: Axel Dahlberg; Gelard Patrick; [e-mail]
Subject: Re: Measurements in link layer service


Would it not be possible to separate the measurement operation from the link layer entanglement geneartion (at least logically)? Currently you're defining three requests types, create and keep, measure directly, and remote state preparation, but they all differ only in when and where you perform a measurement which is just a standard local operation. So would it not be possible to simply have one request type, create, and if you want to measure directly, the higher layer will have immediately scheduled a measurement operation to follow?

________________________________
From: Qirg <[e-mail]> on behalf of Axel Dahlberg <[e-mail]>
Sent: 19 November 2019 16:05:27
To: Gelard Patrick; [e-mail]
Subject: Re: [Qirg] Measurements in link layer service


Hi Patrick!

1. Yes! This might be quite confusing but one way to understand this is that local measurements (in general operations) commute, i.e. the order does not matter. For this reason it does not matter if the measurements of the photons at the heralding station, which would entangle the local spins, happens before or after the measurements at the end-nodes. Independently of whether the measurement in the midpoint happens before or after the local measurements at the end-nodes, the measurement statistics will be the same. For this reason, the outcomes of the local measurements can still be used to for example generate key. Note that one still needs to take into account the outcome from the heralding station to generate secure correlated bits.

2. On might argue that in this case it is not really BB84 but more like E91, since BB84 concerns preparing a state and sending it to another node. However, note that preparing an entangled state and measuring on one side is almost equivalent to sending a random state, except for how the state that is received is sampled.

Let me know if you have other questions :)

/Axel Dahlberg

________________________________
From: Gelard Patrick <[e-mail]>
Sent: 19 November 2019 14:23:00
To: Axel Dahlberg; [e-mail]
Subject: RE: Measurements in link layer service

Hi Axel,

Thank you for your presentation, as well as the others presentations which were very clear.

Just to understand.

You write :

1/ “In the case of measure directly, the nodes can, directly after the photon emission but before receiving the heralding outcome, measure their local communication qubits and again start a new entanglement generation.” It can be useful that the node can measure the communications qubits (i.e matter/memory qubit)  even if it's not yet entangled with the communications qubits of the other repeater ? Or even if the swapping return an echec ?

2/ “for example a scenario where two remote nodes want to for example to BB84 QKD”; Even if BB84 isn’t an entanglement  based QKD protocol ?

Best regards
/Patrick



De : Qirg <qirg-bounces@irtf..org> De la part de Axel Dahlberg
Envoyé : mardi 19 novembre 2019 13:29
À : [e-mail]
Objet : [Qirg] Measurements in link layer service

First of all, thank you everybody who organised and participated in the meeting today, it was very nice :)

I would like to come back to the point that came up during the meeting regarding measurement bases specification for "measure directly" (M) type of requests to the link layer service. There were points raised that this should be higher in the stack. However, I don’t agree with this and will try to explain why I think so here. That being said, I’m very much looking forward hearing other’s thoughts and will be open to being convinced otherwise.

To start with I would again like to emphasise that the draft (https://datatracker.ietf.org/doc/draft-dahlberg-ll-quantum/) specifies a the link layer service and the vertical interface to this service. That is, the headers in the draft (which I think causes confusion and should be updated) are the vertical requests to this service and not horizontal messages in the protocol implementing this service. Thus, my claim is that the information about in what bases the nodes should measure in, in the case of measure directly entanglement generation, should be part of the vertical request/message to the link layer service. Besides this, even though this is out of the scope of this draft (since it’s only about the service), I also believe that any protocol realising this service needs to also communicate these measurement bases between the nodes. The reason for this is that the entanglement generation request is on one side (i.e. the requesting node) but both nodes need to agree on that they are going to perform measure-directly-type of entanglement generation. Furthermore, they also both need to know in which basis they should measure in before entanglement generation is started.

One might ask why include this functionality and not just have “create and keep” entanglement generation and the nodes can then measure this entanglement when it is generated. The reason is that one can in many situations have a much higher rate if the qubit is measured directly. For example, in the case of heralded entanglement generation where the nodes each have one communication qubit (for example nitrogen-vacancies in diamond), both nodes will entangle their local communication qubit with a traveling photon which is sent to a heralding station. The heralding station will interfere and measure both photons and send back the measurement outcome to the nodes. In the case of measure directly, the nodes can, directly after the photon emission but before receiving the heralding outcome, measure their local communication qubits and again start a new entanglement generation. In this way there can be multiple photons in flight to the midpoint at the same time. This is in contrast to the case of create and keep, where entanglement generation rate is, among other things, restricted by the RTT from the nodes to the midpoint.

After the meeting, me and Bruno also discussed how things would work for nodes which are not directly connected the network (i.e. connected by controllable repeaters nodes in the network), but however just want to create correlated bits for for example QKD. In the naive approach there can be create-and-keep requests to all the links in a chain connecting the two nodes, which is then subsequently measured at the end-nodes and swapped (entanglement swapping) in the intermediate nodes. However, it might be the case the end-nodes don’t have memory and thus cannot perform a create-and-keep request. In this case the link layer service we’ve proposed actually supports a third type, which is for remote state preparation (R). This remote state preparation is essentially a one-sided measure directly request, where the requesting nodes measures the entanglement but the receiving node stores it. In the current proposal the requesting node is always the one measuring the half of the entanglement. There was a discussion if it would also be useful for the requesting node to also be able to specify that it will store the qubit and the remote node will instead measure it. This might be useful but should be thought about.

Bruno also suggested that it might be useful to write down an example of how these different requests and control messages would be used in for example a scenario where two remote nodes want to for example to BB84 QKD. I think this is a good idea and could probably help clarify some points raised in the meeting.

Anyway, I hope my wall of text is somewhat comprehensible :) If you disagree or have any thoughts/questions I’m happy to hear them.

Enjoy the rest of IETF!

/Axel Dahlberg