Deploying a Pilot Trial LoRaWAN Network in a Limited Backhaul Network Environment
Overview
In this post, I share from first-hand experience on how one can easily deploy a pilot LoRaWAN network, particularly in an area far from grid power as well as Wi-Fi or Ethernet backhaul. In my context, the network is deployed 185.2 km away from the closest major city — Mombasa and the most interesting bit is that the area of deployment has only one LTE base station, which serves the region covering approximately 50km. The topography is quite hilly which comes with both pros and cons in terms of selecting the site to mount the Gateway/base station and ensuring the IoT nodes can reach the gateway to successfully relay data respectively. While the challenges are unique based on the area of deployment, the most important part is to maintain the core IoT functional stack to achieve a successful IoT deployment. As a background, from an architectural standpoint, several components have to work together for an IoT network to be operational (borrowed a lot a Cisco publication on IoT Fundamentals: Network Technologies, Protocols and Use Cases for the Internet of Things):
1. “Things” layer: At this layer, the physical devices need to fit the constraints of the environment in which they are deployed while still being able to provide the information needed.
2. Communications network layer: When smart objects are not self-contained, they need to communicate with an external system. In many cases, this communication uses a wireless technology. This layer has four sublayers:
2.1. Access Network Sublayer: The last mile of the IoT network is the access network. This is typically made up of wireless technologies such as 802.11ah, 802.15.4g and LoRa. The sensors connected to the access network may also be wired but are mostly wireless.
2.2. Gateway and backhaul network sublayer: A common communication system organises multiple smart objects in a given area around a common gateway. The gateway communicates directly with the smart objects. The role of the gateway is to forward the collected information through a longer-range medium ( called the backhaul) to a headend central station (cloud-based) where the information is processed. This information exchange is a Layer 7 (application) function, which is the reason this object is called a gateway and is the focus of this post. On IP networks, this gateway also forwards packets from one IP network to another and it therefore acts as a router.
2.3. Network transport sublayer: For communication to be successful, network and transport layer protocols such as IP and UDP must be implemented to support the variety of devices to connect for use.
2.4. IoT network management sublayer: Additional protocols must be in place to allow the headend applications to exchange data with the sensors. Examples include CoAP and MQTT.
2.5. Application and analytics layer: At the upper layer, an application needs to process the collected data, not only to control the smart objects when necessary, but to make intelligent decisions based on the information collected and in turn instruct the “things” or other systems to adapt to the analysed conditions and change their behaviours or parameters.
Licensing Issues
LoRaWAN is one of the few unlicensed Low Power Wide Area Networks (LPWAN) that seems established and is backed by an industry alliance supported by a substantial number of companies across the globe. Details on this have previously been shared in this post but it is worth noting that despite the fact that LoRaWAN operates in the ISM band, a number of countries have established radio regulations for its utilisation with appropriate frequency plans as highlighted by thethingsnetwork here. My country, Kenya, has not explicitly published any guidelines for LoRaWAN yet but any large-scale commercial deployments are required to be communicated to the Communications Authority of Kenya (CA), our national regulatory authority. Moreover, details of the National Frequency Allocation in Kenya are here by the CA although no specific mention of the 863–868 MHz allocated to LoRaWAN or LPWAN as ISM is provided. The band is given out as a fixed wireless access network (FWAN) or a public cellular mobile network, although based on research activities, the CA authorises LoRaWAN study deployments. I highly suggest that one checks the frequency requirements for his/her country while working on LoRaWAN or any Radio Frequency (R.F.) developments for that matter.
The Pilot Gateway
In my case, I have used the RAK LoRaWAN gateway with the LTE backhaul. I have earlier on shared the details of its setup here but I also share the updated details for a more stable packet forwarder here. To achieve LTE setup, this video tutorial provides a comprehensive way to set it up. Additional link for its set up can also be found here. It is important that one acquire the right SIM card for the LTE network. In my case, I have used an LTE SIM card from Safaricom, which is the biggest Mobile Network Operator (MNO) in Kenya and have an LTE base station in the region of my deployment — Kutima Ranch in the Taita Taveta county of Kenya. The backhaul network takes some time before establishing connection, but once established, the network is very stable and the gateway appears online on the TTS console. As I have already mentioned, the region is quite hilly as shown in Figure 1 which provides a better cellular link given that the LTE base station is placed on one of the hills.
Powering the Gateway
Apart from backhaul issues, powering a network in a place far from grid power can be challenging, especially when you are not familiar with the solar power requirements of your network. It is important to understand both voltage and current requirements of a LoRaWAN gateway. Another major consideration factor is the solar power manager to ensure the power supply needs do not damage nor underpower the network. In this case, I have used a 40W solar panel with 18V output voltage and 2.23A current. Since the RAK runs on a Raspberry Pi SBC (in my case it is Raspberry Pi 3 B+) whose current requirements are 2.5 A at a voltage of 5 V (link). Although this is the case and the Pi 3 B+ consumes 400 mA at 5.0V without any USB devices connected, my setup runs at 3.7 V (due to my solar power manager) with a current input of 1.5A from the solar manager. This shows that my set up is running on under voltage as well as undercurrent, which I will be making changes to in the near future, but it still runs perfectly fine at this point with the charging system having two batteries to ensure the system continually runs even in the night. This setup is shown in figure 3.
Additional Components
Taita Taveta is one of the regions that experience high temperatures (25 to 35 degrees Celsius) at this time of the year (the last quarter of the year), hence it is also important to consider the heat dissipation coming from the Gateway while running. I therefore have hooked a 5V DC fan to the system to help cool the gateway while running. I might be changing this as well in the near future in order to achieve a better cooling system as the fan looks small to support the network in the long run. Although for the current tests, I will still keep it to observe the performance of the network. The entire set up of this pilot network is shown in figure 4.
Next Steps
With the network up and running and a few test nodes on the ground, I will be sharing in the coming days the experience of the network and the deployment use case and other IoT deployments that can leverage the network. Details of the RSSI, Spreading factor, coverage, packet losses, SNR, bandwidth, power, frequency etc will be covered then.
