The typical architecture of IoT solutions is usually far more complex than the architecture of most enterprise systems. One of the main factors that increases the complexity of IoT systems is that backend services residing in the data center, which is the heart of most enterprise systems, are actually just a piece of the bigger IoT picture. With IoT solutions, we have to deal with a myriad of devices working in the field. Because the nature of these devices is very different from web, desktop, or even mobile clients, we need an intermediate architectural element that will act as a proxy between the world of field devices and the enterprise data center. What we need is an IoT gateway.
Why You Need an IoT Gateway
You may be wondering now: what exactly are the key reasons behind introducing a gateway into your IoT architecture? Let me shed some light on this issue by discussing some of the most important aspects of how gateway architecture functions.
First, sensors usually have very limited capabilities in terms of networking connectivity. Your sensors can likely utilize Bluetooth Low Energy (BLE), just as the majority of beacons available on the market can; there is also the possibility that some of your sensors offer connectivity using the ZigBee protocol. There are also a bunch of other protocols that can be found in the Local Area Network (LAN), Home Area Network (HAN), or Personal Area Network (PAN). All of these protocols have one thing in common—they can’t directly connect to larger networks like Wide Area Network (WAN) or the Internet. You need a gateway that can provide your sensors with a single point of contact with external networks by using WiFi, GSM, or some other type of connectivity.
Keep in mind that a gateway is not just a dump proxy that forwards data from sensors to backend services. Sending all the information collected by sensors to a data center would be highly ineffective in terms of performance and network utilization. An IoT gateway is needed to perform the pre-processing of information in the field, before they’re sent to the data center. Such pre-processing includes message filtering and aggregation.
The gateway should also act as a single point of access for monitoring the selected area of the operational field. You don’t want to connect to every sensor with your monitoring software; it is easier to monitor only the gateway, which in turn is responsible for gathering all the necessary metrics from the sensors.
The following gateway architecture diagram is the most common architectural design where the gateway itself is not equipped with sensors. The gateway software installed on the device is responsible for collecting data from the sensor, pre-processing that data, and sending the results to the data center.
Keep in mind that it is possible to have variations on this sensor architecture where some of the sensors are located at the gateway device, as illustrated in the following diagram.
Embedded sensors that might be present at the gateway could include options like a GPS unit or a temperature sensor connected to the gateway using the GPIO interface.
The Gateway Software
The software application is the heart of the gateway. The gateway software is responsible for collecting messages from the sensors and storing them appropriately until they can be pre-processed and sent
to the data center. The gateway software decides if the data at a given stage of processing should be temporary, persistent, or kept in-memory.
The gateway software should be designed with failure and disaster recovery in mind. Since gateway devices are often operated in the field, you should prepare for working conditions that are far from ideal. For example, the gateway software should be prepared for a power outage or other actions that may result in an interruption of gateway processing. The gateway software should be bootstrapped and started automatically as soon as power returns to the device, and it should continue to work from the point where it was interrupted.
Gateway software should also be smart enough to properly handle system logging. It has to find the right balance between the number of log entries stored on the device and those sent to the data center.
Software Installation and Updates
How does the gateway software get into the device? There are three main approaches for this issue.
The first approach is pre-installing the software on the gateway disk (or memory card). This approach is called factory bootstrap. As you may guess, this technique doesn’t scale well if your solution includes a larger number of the gateways.
The second approach is the server-initiated bootstrap. In this mode, the central software management server communicates with the gateway device and deploys the proper version of the software to it. This approach scales much better than the factory bootstrap, but still requires the initiation of deployment action on the server side.
The third approach is the client-initiated bootstrap. This mode assumes that it is the gateway’s responsibility to connect to the central repository server and download the proper version of the software. In this scenario, the gateway is required to have lightweight bootstrap software installed so it can communicate with the software management server. This approach is the most scalable one, as it doesn’t require any centralized coordination of the deployment action. Every gateway device downloads the software as soon as it is powered on.
One extremely important feature of IoT gateways is the ability to download updates over-the-air. Keep in mind that after you install the gateway software onto a device and deliver it into the field, you have very limited capabilities in terms of the gateway software maintenance. The ability to download software updates over-the- air is particularly important from a security perspective, as it can affect the delivery time of critical security fixes.
If the software application is the heart of the gateway, then the sensors are the eyes and ears of the gateway. Sensors are small hardware devices that can measure some aspects of the real world. Common types of data collected by the sensors are temperature, GPS coordinates, humidity, air pressure, and so on.
The messages collected by the gateway from the sensors are usually small in size. For example, the current value of the temperature measured by the sensor is just a decimal number. GPS coordinates are two decimal numbers, which represent longitude and latitude. This is an important thing to remember: the gateway operates on a large number of small messages.
While the sensors themselves can generate messages frequently, it is important to anticipate how many messages we really need to gather from the sensors. For example, we can read the temperature from a sensor every millisecond, but do we really need this kind of precision when measuring temperature changes? In the majority of cases, reading the sensor value a few times per second is more than enough, as we are more interested in the metric changing over a longer period of time. Gateway software usually polls the sensor data periodically. Good gateway software allows you to easily configure the polling interval for every sensor. You definitely don’t want to put unnecessary sensor data into the gateway, as obsolete messages consume the precious processing power of your constrained gateway device.
Gateway Data Transfer
Usually gateways are connected to the Internet using GPS, WiFi, or ethernet. Some gateways can also work in both GPS and WiFi modes (for example, gateways mounted in moving vehicles). In general, non-GPS connectivity is preferred to send data, as it doesn’t require a subscription to a paid mobile plan. Some gateways will be constantly connected to inexpensive local networks, but those using GPS connectivity should be very conservative in terms of what data they send to the data center. The gateway should apply business logic against the data it collects to understand which messages should be sent over expensive GPS networks, and which data can be cached on the device for deferred offline processing.
The gateway is a key component of every IoT solution. Before you decide what kind of hardware you would like to purchase as your gateway platform, spend some time analyzing your message f low and the data formats of the payloads, and try to filter out or aggregate as much data as you can before sending it from the gateway to the data center. Also, while the choice of proper hardware for your IoT solution is very important, you have to keep in mind that picking up the right gateway software and management infrastructure (like the LWM2M server for managing your devices) is a factor that will highly impact the total maintenance cost of your system.
For more insights on IoT security, protocols, and standards, get your copy of the Guide to the Internet of Things – 2015 Edition now!