# A LoRa-Based Linear Sensor Network for Location Data in Underground Mining
## 3 System Implementation and Trials  
### Design  
The network we describe is comprised of three types of nodes: tags which generate location information, relays which forward location information received from tags and neighbouring relays, and a headend to which the location information is destined. All nodes are implemented on low cost hardware using Dragino LoRa shields on Arduino Uno microcontrollers. Tags transmit location information of the tag holder. Location underground cannot use Satellite Positioning systems so need to be based on other information sources such as Received Signal Strength from a relay or some form of dead reckoning based on accelerometer data from the tag [8]. Relays both receive data from tags and other relays. Relays must also address the problem of broadcast storms and contention for the shared wireless medium in order to minimize collisions. The headend is the destination of all traffic generated by the tags. It is a relay that connects to the remaining functioning part of the pre-existing network. The relay incorporates three key design decisions to address its requirements. The first is that it is based on LoRa because of LoRa's long range capabilities making it suitable for both collecting sensor data from tags and also as a backhaul technology (although at a low bit-rate) for communication between relays. With line of sight LoRa can transmit several kilometers. LoRa is usually implemented as a star network in association with the LoRaWAN network protocol. The network described in this paper does not use LoRaWAN but uses an alternative approach using LoRa nodes as relays, where a relay forwards messages to neighbouring relays. The head ends as a gateway between the LoRa relay network and the remaining underground wired network, usually Ethernet. The second design decision is that communications is flood rather than unicast based. Unicast involves identifying a route through the network to the destination and each node having sufficient information to forward the message to the next node which upon receipt of the message, makes a similar decision as to which node it forwards it on to. Unicast in a shared medium wireless network requires that messages have a destination address and all nodes receiving the message, other than the one to which it is addressed, ignore it. Unicast communication requires some form of routing information to be known by the node, either in the form of static routes or via the exchange of routing information from a routing protocol. In contrast flooding based communication merely requires the node to make a decision based on minimal state information as to whether or not it should broadcast a message it has just received. Messages need not have an address. The long and thin topology of relay networks and the fact that there is only one destination (the headend) for all messages, means that it is not necessary to use a routing protocol in message forwarding. Using flooding based on broadcast has the advantages of robustness and that there is no delay caused by routing protocol convergence. However, flooding networks must deal with Broadcast Storms. A Broadcast Storm occurs when a node, \(n1\) transmits a message which is then transmitted by a neighbouring node \(n2\). The first node \(n1\) sees the message, fails to recognise that it has already transmitted it and transmits it again. The second node \(n2\) also retransmits it leading to endless flooding of the message throughout the network. To avoid this happening the flooding must be controlled. The emergency network incorporats two control mechanism. The first is the use of sequence numbers. Each message contains an identifier of the tag that initiated it and a sequence number. Each message generated by the tag has a sequence number. Each relay records the highest sequence number it has received from each tag. When a message arrives, if the message number is less than the highest sequence number seen for that tag, the relay assumes it has already seen and forwarded the message and ignores it.