4.2.4. Cloud Server

The "Things Network" Cloud Server is an open-source decentralized network service enabling devices (such as a LoRa Node) as well as Gateways (such as Dragino LG01-P LoRa Gateway) to be connected to it [37]. The Things Network is an open community with more than 3000 Gateways up and running, and 35,000 registered members. The goal of The Things Network is building a distributed IoT data infrastructure by creating sufficient data connectivity through LoRaWAN technology [37].

Certainly, there are various alternative options of Cloud Servers, such as the Mbed Cloud and the IBM Watson. Here the Things Network Cloud Server is chosen for its open-source providence and its concentration to the LoRaWAN technology. This aligns with this research which applies LoRaWAN into monitoring agriculture.

### 4.2.5. Data Visualization and Client-Side Application

The "All Things Talk" application platform is chosen as it provides open-source data visualization through either web or mobile dashboards using an in-house HTTP API [38]. Some core features of All Things Talk API are real-time data gathering and instant notifications through either Web/Mobile dashboards or registered e-mail. Finally, All Things Talk API's end-user(s) has/have the privilege of viewing, processing and downloading any historical measurements for data analysis purposes.

### *4.3. Software Development*

### Lora Node

Software architecture of LoRa Node can be observed in Algorithm 1. Functions, events and possible errors are illustrated. At first instance, setUp() function represents a local function call intended to initialize ARM mbed operating system environment as well as SX1272 Radio's and IBM's LMiC libraries configuration aspects. As a result, LMIC\_setSession() application callback can then be implemented for acquiring an activation by personalization session. For a successful session establishment, static constants such as Network ID, Device Address, Network Session Key and Application Session Key extracted from The Things Network Cloud Server should be employed. After LMIC\_setSession() callback, LoRa stack should output either EV\_JOINED or EV\_JOINED\_FAILED event, indicating successful or unsuccessful join to the network service.

Then, getTemperatureHumidity() local function call is core for gathering related measurement parameters. Beyond that, DHT11 library which is intended to be used for temperature and humidity sensor's implementation provides various error enumerations. Specifically, error enumerations of temperature and humidity sensors are ERROR\_NONE, BUS\_BUSY, ERROR\_NOT\_PRESENT, ERROR\_ACK\_TOO\_LONG, ERROR\_SYNC\_TIMEOUT, ERROR\_DATA\_TIMEOUT, ERROR\_CHECKSUM and ERROR\_NO\_PATIENCE in sequence. Additionally, both light-intensity and soil moisture measurement parameters are collected through getLightIntensity() and getSoilMoisture() local function calls, respectively.

Moving to data transmission, a time-triggered local function call should be initialized for sending desired LoRa packet to the Gateway in a context of set time interval. As with LMIC\_setSession() application callback, events such as EV\_TXCOMPLETE, EV\_LOST\_TSYNC or EV\_LINK\_DEAD should be outputted from transmit() function call indicating whether LoRa packet had successfully be transmitted to the connected Gateway. Apart from that, IBM's LMiC library provides a \_setTimedCallback() application callback which settles the program down until set time interval is being triggered signaling the next LoRa packet transmission.

Following embedded systems good principles, reset button deployment is giving the opportunity of completely resetting the LoRa Node, manually, at any time.

Finally, yet importantly, software architecture of LoRa Node has been implemented in a sequential form, avoiding any unnecessary computational complexity which could result in poor performance and increased power-consumption.

**Algorithm 1:** LoRa Node algorithmic software architecture.

```
T IMEINTERVAL ⇐ 300  5 min. transmission rate;
setUp();
LMICsetSession();
if LMICsetSession() is EV JOINED then
   EV JOINED;
else
   EV JOIN FAILED;
end
while EV JOINED and TIME INTERVAL is 300 do
   getTemperatureHumidity();
   getLightIntensity();
   getSoilMoisture();
   transmit();
   os setTimedCallback();
end
```
### *4.4. Network Architecture*

This section provides the implementation of network architecture.

### 4.4.1. Gateway

The LoRa Gateway's block architecture is given in Figure 2. This Gateway can handle LoRa packets coming from the LoRa Node using the SX1276/78 LoRa wireless module which is attached on ATMega328P micro-controller. Then the Arduino environment communicates and passes LoRa packets to the Dragino HE AR9331 Linux module by employing a bridge library.

The Linux environment of Dragino's LG01–P LoRa Gateway provides three different options for bridging the LoRa wireless network to an IP network for the successful transmission of LoRa packets to a Cloud Server: namely 802.11 b/g/n Wi-Fi, Ethernet (LAN and WAN RJ45 communications), and 3G/4G module. Please note that the chosen Dragino LG01–P LoRa Gateway does not include an internal 3G/4G module. As a result, cellular communications cannot be applied to our IoT system for agriculture.

The gateway is configured in a way that acts as the "middle station" between the LoRa Node and the IoT Cloud Server.

**Figure 2.** Block diagram of Dragino LG01–P LoRa Gateway architecture [36].

### 4.4.2. Cloud Server

The block architecture of the "Things Network" Cloud Server is illustrated in Figure 3. Its opensourced elements such as packet forwarder, router, broker, handler, network and discovery servers enable the employment of the LoRaWAN standard for IoT systems [39].

The main functionality of this cloud server includes: first, this cloud server forwards LoRa messages using a remotely configurable and secure packet forwarder [39]. Then, the router microservice is liable for identifying a broker to forward the LoRa message [39]. When it comes to the handling procedure, a micro-service handler is reliable to encrypt as well as decrypt the play-load and therefore publishes it to the desired Application Manager API through a suitable integration [39]. Please note that the integration functionality bridges The Things Network Cloud Server with the IoT applications to support data visualization, analysis and storage [39].

In this infrastructure, both Discovery and Network servers are being employed. The discovery server keeps track of network's components such as router, broker and handler. On the other hand, the network server monitors device states as well as device registries [39].

This cloud server is designed and implemented in a distributed and scalable way by allowing high-performance, high-availability and end-to-end security [39]. In addition, stack components such as gateway software, device libraries, cloud routing services and integration are being covered [39].

### 4.4.3. Client/User Interface API

We have chosen "All Things Talk API" to support clients and User Interface. Its architecture is illustrated in Figure 4. Entities such as applications, notifications, connectivity and data management, together build up an application manager API. This offers end users the opportunities to visualize, store and process gathered sensor data (measurements).

The All Things Talk API offers the choices of joining a device through either WAN, LPWAN or Gateway connections. In particular, the LoRa Node of our IoT system for agriculture, is integrated through the Low-Power Wide-Area Network (LPWAN) connection with The Things Network Cloud Server.

In the IoT system for agriculture, the measurement parameters such as temperature, humidity, light intensity and soil moisture will be displayed on the client side. In addition, a virtual watchdog has been initialized for monitoring any potential warnings or errors.

**Figure 3.** Block diagram of The Things Network Cloud Server architecture [39].

**Figure 4.** Domain diagram of All Things Talk API architecture [40].
