Protocol
Table of contents
Drone Storage
Each drone has a table of beacon ping results. Each row contains the IP address of the drone, beacon identifier from its frequency, the coordinates of the drone the time it was received, and calculated distance about a ping result. Each time a drone successfully pings a beacon, a new row is added.
Flow of a Single Drone
All drones have a pre-determined protocol to follow during the simulation. Figure 1 displays how a drone reacts to different events. While these events are happening, each drone will still follow a set path, try to connect to a beacon and try to establish a connection with a drone or a central hub. These continuous tasks are displayed as the first three actions in the flow chart.
Figure 1: Flow chart of the protocol that each drone follows.
Flow for RTS/CTS in Half Duplex
A system sending packets through wireless connections could easily loose information from collisions in messages. Using RTS/CTS reduces the chances of this happening substantially. Figure 2 visualizes this flow.
Figure 2: Flow chart for sending a message through a half-duplex connection.
Data Between Nodes
Drones have three nodes it can to communicate with. Nearby drones, the central hub, and beacons. They function on their own or while communicating with all three at the same time.
Nearby Drones
The network of drones closely resemble a VANET. Drones work synchronously in a fast pased environment. Following a similar path, they can stay in close proximity and be connected to each other. As explained in figure 1, drones use RTS/CTS before sending a packet. This reduces ensures that communicating over half-duplex does not result in lost packets by collisions. There is overhead in packets sent using RTS/CTS, but at the same time secure in all situations where other solutions would require a complex synchronization structure.
The network of drones is decentralized. They do not depend on a single source of truth. If just one drone reaches the end, a hub that uses the drone’s data, it should be able to provide the information that the entire network has gathered. As the network is decentralized, drones do not need to send packets directed towards a specific drone. They can instead use flooding to broadcast the message through the mesh. All connected nodes receive the message. If a drone receives a ping result from a another drone, it first checks if it already has it in its table. If it is, it does not send the message further. Otherwise, the message is sent to all conncted drones except for the drones that sent it. A hop count is standard to use with the flooding techique. As the mesh can constantly change and drones need to broadcast the message to all nodes, no hop count is necessary.
Nearby drones communicate using DSRC technology. This solution provides a reliable connection between drones with high data rates and a range where drones are a secure distance from each other. To avoid disturbance, noise and information collision, authentication in the form of HMAC secures that validated messages are between trusted nodes.
Connecting drones use TCP for reliable connections. As it is important for the mesh to have the correct information, packet loss tracking in TCP is used.
Central Hub
The central hub represents a starting and ending point for the drones. This is the node that triangulates the position of a beacon with the data from the drones. Each time a drone connect with it, the drones’ ping results are sent. The connection between the drones and the central hub are similar. Several connections to the drones are possible and the central hub uses all the information to find all beacons.
Beacons
Helping in the emergencies require the drones to actively search for beacons. The beacons can be buried deep under the ground after a landslide or avalance. Connecting to the beacon needs to be reliable.
Avalanche beacons’ low frequency provide a long range and reliable connections through the ground which can also last over a long period of time. Additionaly, it is already widely used in the field of search and rescue. Using this technology is therefore beneficial for the drones in these emergency situations.
Triangulation
As drones only search and do not rescue, they do not need to triangulate the position of a beacon. This task can be given to the central hub when it retrieves the table of ping results. With a table of combined ping result, the central hub can calculate the position of beacons.
Ad-Hoc Connections
A requirement for ad-hoc mesh networks is to be able to manage new connections. As the network is decentralized, making sure all drones have the available and most updated information can be tricky.
Drones always look for the central hub or other drones it can connect to. When a new drone is in range, it is connected by a TCP three-way handshake.
To make the list of ping results between drones synchronized, one of the drones in the connection sends the entire ping result table. This list of ping results are cross checked with its own list. Ping results that it already has are ignored, new rows are sent through the network except for the source drone and rows that it has which were not sent by the source drone are sent to the source. This ensures synchronization between the meshes that the drones were connected to.
Self Healing
All drones always try to connect to drones in the area if they are in range. Lost connections to drones that are lost are in that way always trying to reconnect. The emergency situation that the drones are in, require them to handle lost connections and still be able to provide the best information to the central hub. Keeping a mesh that is as fully connected as possible is important for synchronizing new ping results.
Another improvement that this provides is that packets sent between nodes only need to contain a few ping result and not the entire table which is sent on new connections. This reduces the overhead of sending packets between nodes. Keeping connections are therefore preferred.
Previous: Theory Next: Simulation