# Implementation of an IoT Based Radar Sensor Network for Wastewater Management
## 6 Background
### LoRaWAN MAC and Security  
The LoRaWAN specification utilises an unslotted ALOHA scheme at the MAC layer which, on top of the LoRa physical layer, allows for communication between many multiple devices at the same time, on different channels and/or spreading factors; offering robust communication in even busy ISM-band channels [30].  
The packet encryption techniques, for both 'network session' and 'application session' allows end devices to broadcast to multiple gateways, and hop from base station/s to base station/s without extra signalling overheads.  
Packets are encrypted end-to-end to AES-128 standards; using a 128-bit network session key; which is known only by the LoRa module on the end device and the network server, and a 128-bit application session key; which is known only by the LoRa module on the end device and the application server. The encrypted packet is sent over the air, with the intermediate LoRa gateways and corresponding network server only forwarding encrypted packets to the application server. This eliminates the ability for packet sniffers to read sensitive data over the air, as well as reducing the networks cyber-attack surface for bad actors.  
(c) _The Things Network Backend_  
The Things Network (TTN) is a \"global, open, crowd-sourced Internet of Things data network\" [31]. Utilising their backend for this project, it is this network server that is responsible for decoding the data packets forwarded from the gateway; distributing to the correct application server based on the application session key. As shown in Figure 27 below, packets are broadcast from the end devices, to corresponding gateways in range, forwarded to the designated network server and then further to the application server.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**LoRa** & & & & & & **Receive** \\
**Modulation** & **Range** & **Spreading** & **Factor** & **(kHz)** & **Bitrate (bps)** & **Sensitivity** \\  & & & & & & **(dBm)** & **Consumption** \\ \hline
0 & 7x & 12 & 125 & 292 & \(-136\) & 22x \\
1 & 6x & 11 & 125 & 537 & \(-133\) & 13x \\
2 & 5x & 10 & 125 & 976 & \(-132\) & 9x \\
3 & 4x & 9 & 125 & 1757 & \(-129\) & 7x \\
4 & 3x & 8 & 125 & 3125 & \(-126\) & 5x \\
5 & 2x & 7 & 125 & 5468 & \(-123\) & 3x \\
6 & 1x & 7 & 250 & 10937 & \(-120\) & 2x \\
7 & 1x & – & – & 50k & \(-108\) & 1x \\ \hline \hline \end{tabular}
\end{table}
Table 4: Data Rate and Spreading Factor vs Bitrate and Time-on-air.  
TTN's network server is responsible for the de-duplication of packets if received by more than one gateway. This is whereby if more than one packet is identified with a header including the same device address, frame count and timestamp, only the packet with the highest SNR and RSSI is kept, while the duplicate packets are dropped. An example of the event data captured from each uplink by the TTN network server is shown in Figure 28 below.  
TTN's web interface allows useful monitoring of packets both sent and received by end devices and user-owned gateways, however to process, store, analyse and/or display this information, further communication between third-party application programming interface (API) sources is required to provide access to various dashboard-style web interfaces.