## 2 Prototype
### Two-Stage Detection
#### 2.3.2 Sensor Node
Both nodes generate a pair of 2048-bit RSA asymmetric keys (public and private) the first time they are started, and the public keys of each are sent to the peer node. This process is illustrated in Figure 17.  
The bridge node continuously checks that it remains connected to the sensor node. At all stages of data exchange communication, a timeout of 2 s is set to prevent a node from being blocked at a certain stage of the process. Thus, if the communication is not completed within a certain period, the connection is terminated. Continuing the authentication process, the bridge node sends the universally unique identifier (UUID) [58] to the sensor node, which then checks it to continue communication or terminate it if the UUID is incorrect. If communication continues, the sensor node sends a confirmation message to the bridge node. The bridge node confirms that the confirmation message is correct and, if it is, sends a message to the sensor node informing it that it is ready to receive data. Figure 18 describes this initial preparation before the data are transmitted. Then, the sensor node confirms that the bridge node is ready to receive the data. If it is, the sensor node starts sending the data in a cycle. In other words, the data are transmitted in blocks of 10 records, from the oldest to the most recent, to the bridge node. Instead of sending all of the user count records (i.e., data) at once, the records are transmitted in smaller blocks, significantly reducing the likelihood of failures (i.e., contact duration). If a transmission error occurs, only the blocks of records that were not successfully transmitted will be present (see Table 1, A5). To determine the optimum number of records to transmit per block, the contact time between a sensor node and a user moving on a bicycle was calculated. Considering that a bicycle passes the sensor node at an average speed of 20 km/h and that the Bluetooth range of the sensor node is around 40 m, as shown in Figure 19, the contact time would be approximately 7.27 s. Users who travel by motorcycle cannot be used as a bridge node due to their high moving speed, which potentially does not allow them to negotiate the connection and exchange data successfully (see Table 1, A3). Figure 17: Connection to Bluetooth service and exchange of RSA public keys. Figure 18: Process of preparing to transmit data. From this estimated contact time of 7.27 s, a period of 2.56 s is deducted for setting up the Bluetooth connection. This value was determined after carrying out 10 tests in environments with and without obstacles, within a radius of 20 m around Raspberry Pi. This leaves a useful contact time of 4.71 s for data exchange. Equation (1) illustrates how this time was calculated. \[\mathit{Useful\ Contact\ Time}\left(s\right)=\frac{\mathit{Distance\ }\left(m\right)}{\mathit{ Velocity\ }\left(m/s\right)}-\mathit{Setup\ time\ Connection}\left(s\right) \tag{1}\]  
The transmission rate of Bluetooth 5.0 is assumed to be 1.3 Mbits/s. It is known that a block contains 10 records plus the encrypted AES key. Therefore, this message will have a maximum of 642 bytes (equivalent to 5136 Kbits). This conversion is represented by Equation (2). \[\mathit{kilobits}=\frac{\mathit{bytes\times 8}}{1000} \tag{2}\]  
This value was determined by taking the largest possible size for the block of 10 records plus the size of the AES key. The _id_ attribute is not transmitted to the bridge node. The _class_ with the most characters is \"motorcycle\", so it can be up to 10 characters long. The _timestamp_ attribute has 19 characters in the format provided (e.g., \"1 May 2024 10:00:00\").