## 4 Secure, and Private Data Filtering, and Aggregation
### Data Filtering and Aggregation
The maximum transmission unit and maximum segment size were set to the ns-3 default value, 2296 bytes and 536 bytes, respectively. OMs were transmitted over the TCP protocol, and the routing of packets in the multi-hop network was handled using the Optimized Link State Routing Protocol (OLSR) [55]. As described in [53], the simulator operates by issuing OMs from a node in the center of the network. OMs are issued sequentially; after an OM returns back to the issuer node, the following OM is issued. The central node was set up to issue 30 OM for each value of \(n=\{10,20,30,40,50,60,70,80,90,100\}\), the OM path length. OMs are constructed by randomly selecting \(n\) nodes to include in the OM path. The OM path is encoded in the layered object. Encryption layers of the layered object are produced using an ECC-based [56] public-key cipher of 256 b key length implemented in the Libsodium library [57]. Each encryption layer includes a shared secret, the next-hop IP address, two 32b symmetric encryption keys, and the inner encryption layer. To replicate the transfer of computer code, OMs are including a payload consisting of padding \(p\) = 2.5 k bytes. The OM size at \(n\) path length is given in Table 1.

To assess the OM processing delay using PPWSim, we had to first estimate \(\Delta_{om}\) the maximum execution time of an OM. As described in [13], the \(\Delta_{om}\) is a fixed network parameter depending on implementation specifics. The \(\Delta_{om}\) is used to bound the OMsojourn time on nodes to only a specific amount in order to achieve privacy preservation, as discussed in Section 4. To estimate the \(\Delta_{om}\) specific to the privacy-aware framework, we measured delays introduced at each step of the OM execution on a node of the floor location system described in Section 3.2. Sixteen FSR sensors characterize each node of the floor location system, and one compute unit, in our implementation the ESP32-DevKitC V4. Table 2 presents the OM execution broken in individual operations, and the delays of operations are reported. We emphasize the fact that in the privacy-aware framework, the nodes of the floor system are executing only operations presented in Table 2. The OM construction involving the computation of many public-key encryption layers is achieved by the smart contract; therefore, this was executed on validator nodes of the blockchain as described in Section 5 and discussed in Section 6.2. Based on the data in Table 2, we estimated that the \(\Delta_{om}\) appropriate to our system specifics is 35 ms. This value was derived for the OM size at the path length \(n=100\). As reported in Table 2, the ECC decryption is computation intensive only in deriving the shared secret. The ECC decryption of the layered object of 8400 bytes requires 22.2 ms, payload decryption and encryption require 2.3 ms, and payload content execution requires 9.8 ms. Therefore, we obtained a rough estimate of \(\Delta_{om}=35\) ms. The \(\Delta_{om}\) estimate was included in the PPWSim following the guidelines defined in [13] specifying that the technique ensures privacy preservation if the OM sojourn time on WSN nodes corresponds to \(\Delta_{om}\times r\). \(r\) is a randomly chosen float bounded by \(1\leq r\leq 5\). Therefore, in the extended version of PPWSim, nodes receiving the OM decipher the outer encryption layer of the layered object to reveal the next-hop IP address and the inner encryption layer. The layered object size is uniform by adding the padding of the same number of bytes as the removed layer. The payload is of uniform size, and after the sojourn time of \(\Delta_{om}\times r\), the OM is forwarded to the next-hop node. Measurements are taken separately for network delays and OM processing, and the results are presented, respectively, in Figure 8 and Table 3.