## 5 Discussion
### Summary  
In this section, we summarize the steps needed to implement the proposed approach in a UAV delivery scenario with multiple stops, particularly in remote areas without internet connectivity.  
* First, the trajectory of the UAV is planned at the Control Center. It can be programmed on the UAV, the goods can be loaded, and the drone can be sent on its way.
* Then, the UAV can deliver the goods following the optimized path, e.g., following the approach suggested in [22] and outlined in Figure 1.
* At each location, the recipients of the carried goods can identify themselves through an app or code, then get the item dedicated to them. The removal of the item at the given location is detected using, for example, the approach summarized in Figure 2, which  
\begin{table}
\begin{tabular}{c c c c} \hline \hline \multicolumn{1}{c}{**AES**} & \multicolumn{1}{c}{**XOR Operation**} & \multicolumn{1}{c}{**AES**} \\
**Encryption** & & & **Decryption** \\ \hline
32.24 ms & 2.3 μs & 62.45 ms \\ \hline \hline \end{tabular}
\end{table}
Table 1: CPU time for AES and XOR operations.  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multicolumn{1}{c}{**RSA Key**} & \multicolumn{1}{c}{**RSA Key**} & \multicolumn{1}{c}{**RSA Encryption**} & \multicolumn{1}{c}{**RSA Encryption**} & \multicolumn{1}{c}{**RSA Decryption**} & \multicolumn{1}{c}{**RSA Decryption**} \\
**Generation (\(p=13\))** & **Generation Generation Generation** & **(\(p=13\), \(q=9319\))** & **(\(p=5381\), \(q=9319\))** & **(\(p=5381\), \(q=9319\))** & **(\(p=13\), \(q=113\))** & **(\(p=5381\), \(q=9319\))** \\ \hline
0.295 ms & 688.8 ms & 0.173 ms & 0.347 ms & 0.183 ms & 0.407 ms \\ \hline \hline \end{tabular}
\end{table}
Table 2: CPU time for RSA Operations.  
is described in more detail in [23]. A notification is sent to the user in case the wrong item is removed, and they are informed to take only the item(s) dedicated to them.
* The outcome of this transaction (whether success, taking a wrong item, or failing to find the recipient after a certain time), is encrypted using the approach proposed in this paper and summarized in Figure 3: (i) a symmetric encryption key is generated using physical layer security techniques, (ii) this key is used to encrypt the current transaction using a symmetric encryption algorithm, such as AES, after XOR-ing it with the output of the previous transaction (the very first block is encrypted at the Command Center, indicating, for example, the trip number, date and time, planned trajectory, etc.), and (iii) the key is safely stored after encrypting it with the Control Center's public key, using an asymmetric algorithm such as RSA.
* The drone then moves on its way to the other target destinations, repeating the above two steps (delivery and encryption) at each stop, until returning to base.
* After the drone's return, the Control Center's private key is used to decrypt the symmetric encryption keys. Then, each key is used to decrypt the corresponding transaction in the chain. The data can then be analyzed, processed, and stored. Appropriate action can be taken as needed: Correct deliveries could be marked as such. If payment is required, it can be made by charging, for example, a corresponding credit card number of the customer, stored safely at the Control Center. Incorrect deliveries can be detected and identified. Suitable measures can be taken (e.g., legal action).