## 4 Secure, and Private Data Filtering, and Aggregation
Upon receiving a new block, each node checks the list of added onions to determine the starting node on the route. This is made possible by keeping encryption integrity checks on the first layer. The node whose key passes the integrity check is able to decrypt the first layer and initiate the query. Note that even if the onion is publicly available, no third party can decrypt it or determine the route the query will take. From a network point of view, every query has a sink node, which is pseudo-randomly selected amongst the set of nodes in the underlying WSN, as detailed in Section 4. The route ends at the starting node, which submits a transaction to the contract storing the result of the computation encrypted with the public key of the original sender. This protects the results on the public ledger so that only the owner of the corresponding private key can view them. ### Role-Based Access Control

RBAC is a smart contract deployed on the blockchain that allows the creation, removal, revocation, and transfer of roles to actors that interact with the sink node contract and underlying WSNs that are queried. Upon adding a new building, the transaction signer is automatically given the role of admin. We divide assets into buildings, areas, and sensors. Initially, each sensor must be registered using the public key and assigned to a area within a building. After the configuration, new roles can be assigned to each of the resources by protecting their getter methods. This enables administrators to limit access to queries on individual area; i.e., an open space in a public building can be queried by anyone to learn how crowded it is. However, the offices of the public building can only be queried by the manager and occupants. Each of the public functions exposed by the sink contract is first filtered by the RBAC to determine if access is granted. ## 6 Validation

To validate the proposed privacy-aware framework, we designed an experiment to assess the average response time. We define the response time as the elapsed time between the execution of the sink smart contract and the subsequent transaction storing the result of the data filtering and aggregation. To conduct this investigation, we individually considered the latency introduced by blockchain operations (sink contract execution and subsequent result transaction) and the technique presented in Section 4 for data filtering and aggregation. Specifically, we validated the privacy-aware framework for the wireless configuration of the floor location system. We considered only the wireless configuration since the latency introduced by messages moving in the wireless multi-hop network is inherently higher than in wired settings. ### Data Filtering and Aggregation

To evaluate the data filtering and aggregation duration, we used the simulator PPWSim [53]. PPWSim is based on the NS3 discrete-event simulation environment for Internet systems [54] and is designed to simulate the General Purpose Data and Query Privacy Preserving Protocol described in [13] and estimate network delays. We refer to the network delay as the latency for an OM (onion message) to travel from one node to the node at the next-hop address. To obtain valuable results to validate the proposed framework, we further extended PPWSim to estimate the delay of OM processing. Experimental Setup

Since the detailed simulation description can be found in [53], in the following, we will outline the simulator parameters selected to obtain network delay results. The simulator was set up to construct an ad hoc wireless network of 200 nodes. Nodes were deployed according to a grid structure; each node was equidistant from the closest nodes in cardinal directions. The simulated wireless communication conforms to the IEEE 802.11n standard operating at 2.4 GHz at the data rate of 13 Mbps (Modulation Coding Scheme index 1), abd the wireless communication range was set up to allow direct communication only between neighbouring nodes.