Adding Energy-Harvesting Sensors to the Waggle Platform with LoRa Technology


Hey everyone! My name is Lance Go, and I am a rising junior at Northwestern University studying computer engineering and economics. Over these past few weeks, I have been working with the Sage/Waggle group at Argonne National Laboratory (ANL) and Northwestern University with guidance from Dr. Rajesh Sankaran and Dr.Jennifer Dunn. Furthermore, Dr. Josiah Hester and Dr. Branden Ghena from Northwestern University provided additional guidance and support for my research and development work. My project revolves around developing a framework to integrate energy-harvesting sensors into the already existing Waggle architecture.

What is Sage/Waggle and what is energy-harvesting?

The Waggle project is a multi-year initiative at ANL to bring edge computing to scientific sensing. Sage, a Cyberinfrastructure built on Waggle, is an NSF-funded project to bring Waggle infrastructure to various urban and rural scientific research activities. Waggle is a network of devices known as nodes loaded with many environmental sensors and a computer. This allows data to be collected and computed at the source in a process known as “edge computing.” The edge-computing capabilities of the nodes allow them to excel in a wide variety of settings and environments; however, this means the platform can be energy and bandwidth-intensive. Scenarios where energy or space is limited call for smaller energy-harvesting sensors.

An energy-harvesting device is any device that gets its power from naturally occurring phenomena or sources in its environment(i.e. not a battery). This can be solar power, thermal energy, kinetic energy, and piezo-electric among others. Since these devices require no physical connection to power and are typically very small, they fill the gaps in the current Waggle platform quite nicely.

What is LoRa and how can we use it?

The main approach to combining energy-harvesting devices and Waggle nodes is to place them in the close vicinity of the node and have them wirelessly communicate the data they collect to the node. With this approach, we can have a robust system to collect and process a large volume of data without having many high-energy nodes with the Waggle node acting as a data aggregator too. However, this poses a significant problem: how can these sensors communicate with the main Waggle node? The answer is LoRa.

LoRa is a low-power long-range radio modulation technique. Compared to more familiar network protocols like Wi-Fi or Bluetooth, LoRa offers very low bandwidth, which means it cannot quickly transmit a lot of data. However, what LoRa lacks in bandwidth, it makes up for in excellent range and reduced energy consumption; this makes it the ideal communication protocol for energy-harvesting sensors.

Implementing LoRa on the Waggle platform

A simple LoRa network contains two fundamental parts: the end nodes and the gateway. The end nodes are the devices in the network that collect and send data. The gateways collect the data sent by the end nodes and backhaul this data to be processed and archived. In the Waggle platform, the energy-harvesting devices are the end nodes and the Waggle node itself is the gateway. Besides the end nodes and the gateways, there are two popular approaches to implementing LoRa: public LoRaWAN and point-to-point communication. Both of these approaches have upsides and downsides.

Public LoRaWAN is the standard protocol for using LoRa protocol. Typically used in IoT applications, LoRaWAN allows gateways to backhaul data received from end nodes to a server managed by a private company. From there, the data can be managed and processed by an adjacent public application server (see figure 1). Public LoRaWAN protocols are strictly governed by rules laid out by the LoRa Alliance and require every gateway and end node to be registered on the network. This is ideal for IoT since it allows anyone to use any gateway registered on the network for their own IoT projects. Additionally, LoRaWAN has a lot of already established features that aid in managing data like encryption and multi-channel gateway support. Despite these conveniences, the dependencies on private entities for data-backhaul and also the general lack of consistent availability of public LoRaWAN in all areas of Sage/Waggle deployment make it less suitable for our application. A network like this also does not take advantage of the Waggle node’s existing hardware, nor does it easily integrate with the Sage CI architecture.

Figure 1: Typical private LoRaWAN network architecture

Unlike public LoRaWAN, point-to-point communication (P2P) can allow us to build our architecture on the Waggle platform entirely. P2P does not need any type of server and directly sends data received by the gateway to the Waggle node to be processed. This is the simplest approach but is held back by its scalability. For a few sensors, a single-channel gateway can manage most of the work but starts to falter when there are upwards of fifteen to twenty sensors. This is in part due to the lack of multi-channel gateway support from P2P connections. Furthermore, any of the features natively included in LoRaWAN architecture need to be developed on our end.

Figure 2: Point-to-point style network

My proposed method is a private LoRaWAN server, which lies somewhere in between the two extremes. Using ChirpStack, an open-source toolkit for making private LoRaWAN servers, we can retrofit the onboard computing of the Waggle node into a network and application server. This allows us to cut out the extra step required by using a public LoRaWAN server managed by another company. This way we can take advantage of all of the LoRaWAN features but still use our own architecture within the Waggle/Sage platform. The hardware setup of this network is also only slightly more complicated than the P2P and requires the single-channel LoRa gateway to be swapped with a multi-channel gateway. Figure 3 shows a typical private LoRaWAN server setup with two gateways targeting end nodes at different ranges. Increasing the number of gateways on a network is a simple approach toward increasing the possible number of end nodes supported.

Figure 3: Private LoRaWAN network with two gateways

Next Steps

As my internship winds down, my main goals are to gain a better understanding of using private LoRaWAN servers. Currently, I only have single-channel gateways in possession and have only physically implemented a P2P-type network. To explore private LoRaWAN gateways further, two multi-channel gateways are being shipped to me currently, one of which (Discovery Kit 2) has a Raspberry Pi 4 built-in. With these two gateways, I want to test two approaches to implementing a private LoRaWAN server. The first is the traditional approach, where both servers are connected to the Waggle node and the computer onboard the Waggle node hosts the network and application server. The second involves backhauling all data from both gateways onto the Raspberry Pi on the Discovery Kit. The Raspberry Pi will host the servers and then forward the data to the Waggle node to be processed.