Gateways for the Internet of Things Speak Multiple Protocols



With multiple wired and wireless communications protocols in use on the factory floor, office, and home, today’s IoT gateways must speak multiple protocols.

As more industrial systems get connected to the Internet, the amount of data collected from the multiple endpoint sources tends to grow exponentially, and that data must be forwarded to a host system for analysis and potential feedback for endpoint control. However, the devices used to transmit the data from the endpoints (sensors, switches, etc.) often consist of a mix of different technologies and protocols—some might use WiFi, Bluetooth, ZigBee, LoRa, SigFox, Thread, or yet another wireless communications scheme. To collect all the data and provide a translation from one protocol to another (for instance, ZigBee in/WiFi out, or Bluetooth in/LoRa out) the IoT gateway can do the translation and, if desired, can do some pre-processing of the data to reduce the amount of data sent to the host.

Gateways are commonly connected to the Internet using either Ethernet, WiFi, or a cellular interface, and in some cases the gateways may include more than one uplink interface—for example in a truck or other moving vehicle, both cellular and WiFi radios might be present. Which interface to use is often a case of economics—the cost of a cellular connection includes a subscription fee plus a fee for the data being transferred. Thus, if lots of data is transferred, the cost of the cellular connection can escalate very quickly.

Figure 1: In this machine-to-machine (M2M) gateway architecture example presented at the 2014 IEEE World Forum on Internet of Things, EURECOM authors detail a system collecting many sensor outputs by the M2M proxy inputs on the south side of the gateway, then preprocessed by the gateway and sent to the host using WiFi or cellular (3G or LTE) interfaces. (source: courtesy of EURECOM, Biot, France)

Figure 1: In this machine-to-machine (M2M) gateway architecture example presented at the 2014 IEEE World Forum on Internet of Things, EURECOM authors detail a system collecting many sensor outputs by the M2M proxy inputs on the south side of the gateway, then preprocessed by the gateway and sent to the host using WiFi or cellular (3G or LTE) interfaces. (source: courtesy of EURECOM, Biot, France)

The main benefit of a cellular connection is widespread availability and large range due to the many cell towers distributed in cities and through the countryside. However, if the data traffic is more localized, such as in a factory, smart building, or smart home, then WiFi or wired Ethernet would be the preferred interface to the Internet, since there are no data charges or subscription fees. The gateway software or user should consider the cost to transfer data in light of the data collected to determine which messages should be sent over expensive cellular networks, and which data can be cached on the device for deferred offline processing.

Many Options for Gateway Design

The design of the IoT gateway can thus take several directions—a simple gateway that just collects various sensor data streams and forwards the data, a multilingual gateway that handles multiple communications protocols, and a more intelligent gateway that can pre-process the data to deliver a more efficient data stream to the host. Each of these approaches has a similar architecture, as shown in Figure 1. The main differences will be in the number of wireless or wired interfaces on the sensor–input side, the horsepower of the internal CPU that manages all the data streams, the output wired or wireless interface, and, of course, the internal firmware and operating system.

Depending on the amount of processing the gateway’s internal CPU performs, processor choice spans simple microcontrollers to highly integrated SoCs. For instance, Intel® offers a range of x86 compatible devices starting with the Intel Quark™ processor on the low end. For increased performance designers can move up to the Intel Atom™ family of CPUs, and for still higher processing requirements an Intel Core™ M3, i3, i5, or i7, or even one of the high-end Xeon® processors. Of course, as processor performance increases, so does the power consumption. Thus, when selecting a processor, the power envelope must also be taken into account, since cooling the CPU could become an issue. For most smart home/smart building and moderate industrial applications, processors such as the Intel Atom, Core M3, or Core i3 could handle most of the system requirements, while for very simple gateways, the Quark or Atom processors are more than up to the task.

In addition to the various Intel processors, there are many other processor solutions, with some that integrate many of the interfaces and memories needed to build a complete gateway. Processors from Qualcomm, NXP, STMicroelectronics, as well as small boards based on the Arduino or Raspberry Pi architecture can also be used to implement gateways. At the board level, single-board computers such as the Aaeon PICO-APL1, which is based on the Intel Atom N4200 or N3350 CPUs. The board can be used in fanless systems and includes support for up to 8 Gbytes of DDR3 DRAM, SATA 3.0, mSATA, and MiniCard expansion slots. It also includes a configurable BIO connection for daughter boards. Another board from Gigabyte Corp., the BXBT-3825 is also based on an Intel Atom dual core CPU, the E3825, and packs a 1 Gbit Ethernet LAN interface, multiple USB ports, WiFI (802.11 b, g,n), Bluetooth 4.0, 500 Gbytes of hard-disk storage and HDMI and VGA interfaces. This board also runs the Wind River Intelligent Device System Platform software.
Software Manages the Gateway

At the heart of the gateway is the embedded software (such as offered by Wind River) that manages the interfaces, performs the data management, and collects and possibly pre-processes the data streams coming from the endpoints. The gateway software also determines if the data at a given stage of processing should be temporary, persistent, or kept in-memory. The gateway software should also be designed with security features to prevent hackers and malware from affecting or intercepting the data. Additionally, the software should have features that support failure and disaster recovery as well as over-the-air updates.

Many gateways are often mounted on mobile platforms, so the hardware and software design should be ruggedized to handle working conditions that are far from ideal. For example, the gateway software should be able to survive a power outage or other actions that may disrupt operation. When power returns, the software should automatically restart and pick up where it left off when it was interrupted. To accomplish the recovery, a client-initiated bootstrap approach can be used (Figure 2). In this mode it is the gateway’s responsibility to connect to the host server and download the proper version of the software. The gateway contains a lightweight bootstrap routine that allows it to communicate with the host server. This approach is very scalable, and each gateway in the system can download the software it needs as soon as it is powered on.

Figure 2: By including bootstrap software in the gateway designers can have the gateway download a new copy of the executable software if an incident disrupts the gateway’s operation.

Figure 2: By including bootstrap software in the gateway designers can have the gateway download a new copy of the executable software if an incident disrupts the gateway’s operation.

Connecting to the Real World

Sensors that measure some aspects of the real world such as temperature, GPS coordinates, humidity, air pressure, and so on, constantly feed data to the gateway. The data streams collected by the gateway from the sensors are usually small—often a few bytes to a few hundred bytes—and might be collected every few milliseconds to every few seconds depending on the nature of the measurement. The gateway can often receive hundreds of such messages every second and will then organize and process the data packets into a stream it uploads to the host system over the Internet. Gateway software can typically poll the sensors periodically to collect the data, and the software should permit the user to easily configure the polling interval for every sensor.

Sensor endpoints come in many forms and incorporate many communication interfaces, ranging from basic hardwired connections, to Bluetooth, ZigBee, WiFi, and still other wireless protocols. The variety of interfaces allows designers to optimize each sensor’s interface to match the data rate and power requirements (sensor lifetime if battery powered) to the application.

Designing a gateway subsystem must take into account many factors to deliver a viable solution that collects data from the endpoints, processes the data, and delivers the data to a host system. Where appropriate, feedback from the host can control actuators and other subsystems for the end-to-end system to deliver optimal performance.


bursky_dave copyDave Bursky, the Semiconductor Technology Editor for Chip Design magazine, is also president of PRN Engineering, a Technical Writing and Market Consulting company. In addition to joining Chip Design magazine in 2006, he was also the technical editorial manager at Maxim Integrated Products, and prior to Maxim, Bursky spent over 35 years working as an editor and engineer.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis