*4.3. Performance Evaluation*

During the identity authentication stage, the system administrator or data owners can launch a transaction to the microchain, which encapsulates a capability access token assigned to an entity. Then, any user can query such a token from microchain participants and verify it during the access validation process. We designed a capability-based access control (CapAC) scenario [11] in which one HPC simulates a service owner to record CapAC tokens into the microchain, and another RPi simulates a service provider to query CapAC tokens from the microchain for the access control process. We conducted 100 Monte Carlo test runs and used the average of results for evaluation.

#### 4.3.1. End-to-End Latency of Authorizing Access Tokens

Figure 4 demonstrates how committee size *K* represented by the number of validators and access authorization transaction throughput *ThS* measured by the transactions per second (tps) affects the end-to-end latency incurred by committing a transaction on a microchain network. As the microchain executes an efficient consensus protocol within a small consensus committee, it brings a lower total latency, which has marginal impacts for an increasing committee size *K*. As a trade-off, a small consensus committee containing resource-constrained RPi devices as validators has limited capability to process large volumes of transactions. Thus, the end-to-end latency is almost dominated by *ThS*, as Figure 4 shows. We assume that each node within LightMAN waits no less than 5 s to collect UAV data and then launch a transaction. Thus, the network latency of committee transactions on microchain can satisfy real-time requirements of access authorization.

**Figure 4.** End-to-end latency of committing CapAC tokens on Microchain: committee size vs. tps.

4.3.2. Processing Time and Throughput in Access Authentication

For comparing our LightMAN's performance metrics with conventional centralized frameworks in access authentication, we designed basic scenarios as a benchmark, which did not cooperate with any access control strategy for UAV data access requests. To evaluate the processing time and throughput of access authentication operations, we used an HPC to simulate a cloud-based UAV server, which provided drone data query services given basic and LightMAN scenarios. Then, we let an RPi send multiple access requests to a UAV server and wait until all responses are correctly received.

Figure 5 shows average delays that evaluate how long a CapAC access request can be successfully handled by the UAV data server as increasing *ThS* from 20 tps to 1000 tps. Regarding the fixed bandwidth of the test network, the capacity of UAV servers dominates the performance of handling access requests. Thus, the delays of access authentication are almost linear scale to *ThS* given basic and LightMAN scenarios. However, LightMAN still demonstrates efficiency in the decentralized access authentication process that queries CapAC tokens from microchain and verifies access control policies, and it only incurred limited extra overheads (no more than 18%) compared with basic scenarios.

**Figure 5.** Processing Time of querying CapAC tokens and validating access rights.

To evaluate the data processing capability, we calculated throughput as *ThS TD* , where *TD* is the time latency of completing *ThS* data tasks. A higher throughput indicates better system performance. Figure 6 presents the transaction throughput of handling access authentication requests, given that *ThS* varies from 20 tps to 1000 tps. Each access request in LightMAN mode demands more computation resources on CapAC token validation; therefore, LightMAN demonstrates a lower transaction throughput than the basic mode even if the access request send rate *ThS* is the same. Owing to system capacities, such as the network bandwidth and computation power of service providers, the transaction throughput of LightMAN and the basic mode become saturated under conditions where *ThS* <sup>≥</sup> 500 tps. Compared with the baseline, our solution can provide security and privacy features without significantly reducing system performance.

**Figure 6.** Throughput of querying CapAC tokens and validating access rights.

#### 4.3.3. Computation Cost by Preserving Data Privacy

We assumed that MAVLink message data streams of a drone were encrypted and then recorded into DDS for each 60 s duration. As a result, each data file was about 1 MB, and we used these sample data files to evaluate computation overheads incurred by sharing UAV data via DDB along with data encryption and decryption procedures. Figure 7 shows the processing time of accessing data from Swarm and data encryption algorithms given different host platforms. Regarding DDS operations such as uploading files onto and downloading files from a private Swarm network, delays are almost the same on both platforms. Unlike downloading data, which simply query data from a DDS service site, uploading data onto DDS takes a longer time than is used to synchronize data units across distributed service sites within a Swarm network. Owing to constrained computation resources, RPi takes a longer process time to encrypt and decrypt data than the desktop does, even if sample data files have the same size. Compared with a 60 s cycle time of recording a drone's data, encrypting a data file and then uploading it onto DDS only brings marginal delays on both platforms (2.4 s on desktop and 3.2 s on RPi). Given data-in-use scenarios that frequently download files from a DDS service node and then decrypt them, the encryption algorithm incurs more computation overheads than Swarm operations. Given a data query request rate *ThS* = 500 tps that takes an average of 3.05 s on access authentication, accessing UAV data incurs an extra 19% (0.57/3.05) of delays on desktop and 59% (1.79/3.05) of delays on RPi. As a trade-off, using encrypted data to protect private information is inevitable at the cost of a longer processing time.

**Figure 7.** Processing time of data operations: accessing DDS and symmetric encryption.
