# A Visitor Assistance System Based on LoRa for Nature Forest Parks
## 5 The Proposed Visitor Assistance System
### Protocol and Application  
The proposed application is monitoring the visitor's location, aiming at faster and more effective action by search and rescue teams. This monitoring is done transparently, without disturbing personal experience in the natural environment. The idea is that a wearable terminal, in the shape of a bracelet  
Figure 8: Two mobile nodes scenario. Figure 7: Short-term static scenario. or key chain, sends location data periodically. Location can be obtained through a GPS, a totem or by exchanging location data in collaboration with other visitors. Mobile terminals establish contact with each other when entering their coverage area, approximately a circle with a diameter of 500 m for LoRa SF12. Location data must be exchanged during this contact time, which depends on the speed of the person carrying the device. Considering the experimental measurements presented in [30], the shortest average contact time, which occurs when visitors are trained hikers, is about 2.5 min. During this interval, the terminals must discover each other's presence, negotiate communication parameters and exchange records of location information. Every minute, the terminal emits a beacon that allows the start of communication with another node. This period keeps battery consumption low while still allowing at least two communication opportunities during each contact interval. The opportunity must not be unique as the transmission is unreliable and the beacon may be lost. The beacon contains the terminal identification, its last known position, and a timestamp associated to this position. This information is used to estimate their location and travel. The location application used to provide the visitor monitoring and security service is based on [7; 15]. They propose to estimate the visitor's location through the exchange of messages between RF sensors. The concept of witness sensor is presented, which makes a sighting record to store and transmit location information, aiming to describe the movement of other sensors. When people meet along the way, the sensors become witnesses to each other and exchange their location data, which will be sent to a central repository via an access point. This data, which makes up the history of previous locations of various sensors, can be used to estimate their locations. Our application runs directly on the physical layer, using its own medium access control mechanism. This simple mechanism is a variation of CSMA, with Clear Channel Assessment (CCA) considering the use of different spreading factors. Beacons are sent using SF12, but sighting records are exchanged using another SF, which allows the highest possible baud rate. The choice of SF is made based on the RSSI and SNR of the received beacon. If the measured values of RSSI and SNR are within the threshold that allows operation for a given SF, it is chosen. If not, another higher SF is evaluated. The lowest possible SF is always chosen to increase the transmission rate. The exception is SF7, used only for communication within groups. Different from [7; 15], the proposed system allows an active help request by the user. This is done by creating two new message types and adding a field, the help flag. The messages are the help request and rescue notification, identified by the help flag. These adjustments allow the faster rescue of the endangered visitor. There is no need to wait for a long time for the problem to be noticed through the absence of data from this specific visitor in other visitors' records. Additionally, groups composed of visitors who travel together are used to avoid the continuous exchange of messages between terminals that are constantly within range of each other. Only the group leader sends messages on behalf of other terminals in the group. A new message type and two new fields are also created to allow the dynamic formation of groups and the election of their leader. The choice of a leader is based on the participants' available battery capacity. Figure 9 shows the messages used in the proposed protocol.