# A Visitor Assistance System Based on LoRa for Nature Forest Parks
## 5 The Proposed Visitor Assistance System
### Protocol and Application
The following fields may be present depending on the message:  
* Type (4 bits)--indicates the message type. Currently, eight messages are defined, leaving space for future extensions. The defined types are: 1. help request--actively sent by the user at risk, requesting help, without the need to wait for processing other visitors' records; 2. rescue notification--reports that there is a rescue team on the way, send by paramedics at the park headquarters; 3. totem beacon--announes the presence of a totem and its coordinates as a reference for the visitor;  
permission to transmit its stored records. Terminal B also declares the channel chosen to exchange records, and its reception limits values for hop count, record time and the maximum number of records to be received. If A, the remote terminal that originated the beacon, has available memory, it stores the current contact data, sends its own reception limits for hop count, record time and the maximum number of records, and accepts the transmission. Both terminals also have to agree on which SF will be used to exchange the records. Upon receiving a beacon, Terminal B evaluates the RSSI and SNR level of the communication. Then B proposes the switch to another SF that allows a higher baud rate; when it is not possible, SF11 will be used. The definition of SF is made by the terminal that receives the beacon and informed along with its metadata (record time and hop count), sending its identification in the field CH. The choice of a channel can be accepted or changed by terminal A. If the values of RSSI and SNR in the reception of messages sent by B do not allow operation in the SF defined, then the terminal A changes to another higher SF. Only two bits in the message are needed for this purpose, once only SF8, SF9, SF10,  
Figure 11: Communication between totem and terminal. Figure 10: Communication between terminals. and SF11 are available. SF12 is used exclusively for beacon transmission and the initial handshake, whereas SF7 is used for group communication. Exchanging the records using a different spreading factor reduces collisions by leaving the common channel provided by SF12 clear for more time. Before starting the transmission, terminal A listens to the chosen channel in a mechanism similar to CCA to avoid collisions. After receiving all the transmissions from B, Terminal A then sends its own stored records. Hop count and record time allow improving terminal memory management by avoiding receiving records that are old or have been forwarded too many times. The max records field allows limiting the number of records received, even if they are in agreement with the hop count and record time parameters. Records that have values above the informed thresholds are not sent. Help request records are the first to be transmitted. After these, previous contact records with other devices and, finally, rescue notifications are forwarded. Help request messages are sent upon the visitor's initiative. For those emergency messages, it is important to reduce latency. To accelerate the rescue, copies of emergency messages must be passed on to all other mobile nodes, passing through the visitor at risk until he is rescued or receives a notification. The terminals that receive the message also replicate it until they reach the nearest totem or receive a notification. Only nodes that already have a copy should discard an emergency message. The response to the emergency message is a rescue notification message, informing the visitor that help is on the way, terminating the sending of help request messages. Notification messages should be sent by the totems closest to the location where the visitor at risk is. Thus, messages are replicated to other terminals that have a greater chance of reaching the visitor quickly and, therefore, be delivered with less latency. Figure 12 illustrates this communication. To make bandwidth usage more efficient, the monitoring system has the possibility to create groups of visitors traveling together or in close proximity.