## 2 Prototype
### Two-Stage Detection
#### 2.3.2 Sensor Node  
The operating system running on the sensor node is Raspberry Pi OS (Legacy, 64-bit) Lite [50]. Two scripts are run there simultaneously: one for detecting and classifying the different types of users on the trails, adding these records to the local database, and the other for connecting and transmitting the data to the bridge node. The detection and classification script, described in Figure 14, runs the CNN model previously trained with YOLOv3-Tiny. If the model detects a user type, it only adds it to the local database (shown in Figure 15) if it is detected with a confidence value equal to or greater than the value indicated in the script execution command. This value was determined at 0.7 (70%) after a visual analysis of the detections made by the model at different confidence values. This approach helped identify a balance point where the model accurately detects users without generating too many false positives. Figure 14: A flowchart of the detection and classification algorithm. It is important to note that no images are stored in the database shown in Figure 15. Only information that classifies the type of user passing through the site is recorded, so as not to compromise privacy. The local database implemented in the sensor node, using the MariaDB database management system (DBMS) [51], is made up of two entities. The _Users_data_ entity is responsible for storing records relating to the detection of user types. The _id_ attribute identifies the record. The _class_ attribute identifies the class of the user type. The _timestamp_ records the moment the user was detected and classified. The _threshold_ is used as a control mechanism (see Table 1, A1). Its default value is 3 for each newly created record and it is decremented each time the record with this information is successfully transmitted to a bridge node. With this approach, it is guaranteed that each record with a specific user count will be transmitted to three different bridge nodes before being removed from the local database. To do this, the _Threshold_Mac_ entity was created, which helps with this control by storing the MAC addresses assigned to the bridge nodes' Bluetooth cards to which a given record has been transmitted. This approach is especially important to guarantee the delivery of the user count information stored in the sensor nodes to the remote database server available on the Internet. Furthermore, given the storage limitations of the sensor node, by setting a transmission limit for a limited number of bridge nodes, this makes it possible to effectively manage the storage available on Raspberry Pi. A data exchange system called a \"hybrid cryptosystem\" was used to establish the connection and transmit the data [52]. This system combines the advantages of symmetric and asymmetric cryptography to ensure both efficiency and security in communication. Initially, each node creates a pair of RSA-2048-bit asymmetric keys [53] and exchanges their public keys. Each time a node sends data, a new symmetric key (AES-256 bits [54]) is generated and encrypted with the recipient node's RSA public key. The data are encrypted with the symmetric key. The sending node sends the encrypted data along with the encrypted symmetric key. When this message is received, the receiving node decrypts the symmetric key with its private RSA key. Finally, it decrypts the data with the symmetric key. This process is shown in Figure 16.  
Figure 16: Hybrid cryptosystem. Figure 15: Sensor node local database. This approach offers both the efficiency of symmetric encryption and the additional security of asymmetric encryption [55] (see Table 1, A2). Initially, the mobile application running on the bridge node establishes a connection with the service provided by the sensor node. This connection is made via the RFCOMM protocol [56], which allows for serial communication over Bluetooth between the devices [57].