A discussion of challenges in designing an IoT gateway and designing a generic Gateway platform
By –
1. Indar Prakash Singhal, Staff Engineer , AMG Central Lab, STMicroelectronics, India
2. Prashant Pandey Technical Leader, AMG Central Lab, STMicroelectronics, India
3. Raunaque Mujeeb Quaiser, Senior Manager, AMG Central Lab, STMicroelectronics, India
The promise of efficient and intelligent use of resources enabled by IoT has raised the expectations of the technical as well as the consumer community. Internet of Things (IoT) entails adding sensing capability and internet connectivity to everyday objects (Things) around us making them a network node. However it’s not always possible to connect the IoT nodes directly to the public internet due to power or computational limitations. IoT Gateway help connect Things to broader internet by using connectivity technologies suitable for resource limited Things. There are a myriad of technologies which can be used for communication between Things and Gateway. Similarly there are multitudes of protocols to further connect IoT gateway to cloud application. There are many more challenges in designing an IoT Gateway like security, authentication and provisioning. It is not trivial to make the correct choices for a specific application. In this paper, we present a flexible architecture for Internet of Things Gateway Platform known as “Wireless Bridge” which supports different wireless technologies. We will also discuss various connectivity technologies and protocols that can be used to exchange the Things data with the Cloud Application with the help of IoT Gateway platform. The ideas presented here can help in building a secure, flexible and extendible IoT Gateway.
IoT is a network of connected objects (Things) with embedded electronics allowing them to sense, report and controlled remotely and sometimes take simple decisions. Other terms used to define similar concepts are M2M (machine to machine communication) and IoE (Internet of Everything). The concept of objects with electronics connected to a network has been in existence for quite a long time now. At a cursory glance IoT does not look like a new concept. There are however subtle differences between IoT and classical M2M. IoT seeks to connect every device (things) that we interact with including those which are generally not connected to the network. One more difference is that it intends to leverage existing IP based networks instead of creating dedicated network infrastructure as is the practice in current generation of M2M, thus creating a global network of things. While the premise of connection to the internet increases reach of IoT, it also poses unique challenges. One such challenge is that many IoT nodes have limited memory, storage and computation capabilities and are not able to connect to the IP based networks directly. An IoT Gateway fills in this gap by acting as bridge between IP based public network and local networks designed with specific needs of the IoT nodes in mind. It can also provide additional security, storage and processing services allowing the end nodes to be as cost effective and power efficient as possible. It also enables nodes using different communication technologies to talk to each other within the network. Unfortunately designing an IoT gateway for an application with future needs in mind is a herculean task because of so many variables affecting the design. The IoT space is very fragmented with thousands of vendors and almost no widely agreed standards. There too much literature available on the subject from technology vendors each promoting their own technologies. This paper aims to provide a holistic view of all available options to the implementers without going into vendor specific protocols.
Challenges in designing an IoT gateway
Node Connectivity: We need to select a short range Radio Frequency (RF) technology to connect to the IoT nodes. This selection is dependent on the various parameters like frequency band, modulation scheme, channel number, data-rate, latency, robustness etc. Additionally this decision is also dependent on local regulatory requirements. The selection is easier when we have a homogenous network having same types of nodes but become much more complicated when we have multiple types of nodes with different requirements.
Backend Connectivity: The IoT Gateway may use short range radio technology to connect to the IoT nodes but a long distance link is needed to connect to the internet. This selection is based on bandwidth requirements, available connectivity options in the area and criticality of the application. Since connectivity options vary from area to area, it’s a good idea to have multiple backend connectivity options
Management Server: IoT nodes are not generally accessed (through the gateway) on the internet as standalone entities. It’s more prevalent to have a central server manage the nodes, while IoT gateway facilitates this communication. We need to identify protocols for communication with the management server
Local intelligence: In a true cloud architecture, nodes send all the data to the cloud for processing and control. However this is not an ideal scenario to send useless data to the cloud because this results in wasted bandwidth, extra load on server and data loss in case of connectivity outage. The concept of edge computing solved this problem. If IoT Gateway can take most of the decisions locally and send only the filtered data to the cloud, it can make the system more efficient. The gateway decision logic may be programmed by the server for flexibility. The amount and type of local intelligence is application dependent and must be given deep thought as it would affect the gateway design decisions.
Power considerations: The power source of gateway and source also affects our decisions in related to the above points. As sensor networks become more prevalent and embedded in things they would need to be as unobtrusive as possible scavenging power from its environment.
Security: This is a factor that can make or break the success of large scale IoT networks. As these networks become part of more application (some of them critical in nature), security will assume paramount importance. Security should be a factor at every stage of design process, it’s a mistake to add security after everything else has been designed.
Serviceability: This is an often ignored requirement. A look at history tells us that no system is perfect. Irrespective of the amount of pre deployment testing done, bugs and security loopholes would be found invariably after deployment. There must be a provision to service and update the IoT gateway (and nodes) in the field. There should not be sole dependence of remote serviceability, we should have additional connectivity options to service the installation.
Let’s discuss some of these points in detail with available option. We would also discuss in what scenario each of these options may be used.
Node Connectivity Technologies
In current landscape, many communication technologies are well known such as Bluetooth, Wi-Fi, NFC, ZigBee. There are also several new emerging networking options such as Sub GHz, Thread, ANT, Z-Wave that can be readily used for smart home, smart city, smart lighting, and smart metering applications.
Depending on the application, factors such as operating range, power consumption, data rate, operating frequency, battery life will dictate the choice of one or more from combination of the technologies. The table below draws a comparison of features of the major communication technologies on offer today. Comparison of these technologies in given in the table 1.
Backend Connectivity
Connectivity to the management server (backend) involves selection of backhaul connectivity technology as well as protocols for connecting to backend. Backhaul connectivity refers to the long range connection of the IoT Gateway to the ISP endpoint. Cellular technologies like 2G/3G/LTE are the most popular options. However we may use PLC (power line communication) for smart street lights or other applications involving power lines. Optical fibers can be used for applications requiring high bandwidth. For remote areas not covered by cellular connectivity options like satellite links or microwave point to point connections may be used.
Communication Protocol
There are many communication protocols which can be used by the IoT gateway to communicate with the cloud application. Here we discuss some of the more popular technologies along with their pros and cons.
Plain HTTP: This is by far the most ubiquitous protocol. It’s widely accepted by servers and being backed by internet standards has least compatibility issues. It also maps naturally with the RESTful APIs. However it suffers from large overhead in form of HTTP headers and text based format. It is stateless despite being run on top of TCP. That makes it unsuitable for real-time usage. The client must send a request in order to get a response (command) from the server. Client has to keep polling for updates from the server.
CoAP: Constrained Application Protocol can be considered to be binary version of HTTP. It improves on some limitations on HTTP. It has very concise headers and supported binary data format thus reducing the overhead. It can be used on top of TCP or other transport as well even SMS. CoAP packets can be easily translated to a HTTP packet. However because of negligible internet infrastructure support it does not play well with firewalls, proxies and routers. Thus this protocol is only suitable for private networks typically inside the sensor network.
Web sockets: It is a new protocol also backed by web standards. It has the same addressing and handshake mechanism as used by HTTP. Thus making it compatible with existing network infrastructure. Once handshake is complete it switches to duplex communication on top of TCP. This makes it suitable for real time, two way communication. It’s especially suited in shared hosting environments and gateways operating behind proxies.
MQTT: Is also a popular protocol running (optionally) on top of TCP. It has a topic subscriber model. Though more suited for broadcasting messages to interested gateways, it’s also used for gateway to server communication. It has some features like last message persistence and will and testament message that make it useful for IoT application.
AMQP: This perhaps is the most suited protocol for gateway server communication. This protocol acts as a storing queue and ensures that packets are not lost, even in case of temporary outage.
XMPP: Extensible Messaging and Presence Protocol is a popular protocol used by chat clients for real time communication. It standardizes lot of things like user authentication and message IDs. However owing to its complex specification and exchange of data using verbose XML format makes it unsuitable for IoT application.
IoT Gateway Platform Architecture
We here present a flexible design created by us for sensor data monitoring and control. The application is a generic one without special requirements for security or reliability.
Wireless Bridge IoT Gateway: Wireless Bridge is STM32 based IoT Gateway Platform solution as shown in figure 1 having different connectivity technologies. The system comprises of Bluetooth, Wi-Fi, Sub-GHz and Near Field Communication. Each of the communication technologies has its own benefits. Wi-Fi is used for exchanging Things or Node data on the Cloud Platform through Gateway Platform. Bluetooth is used for communicating the Things or Node data with the Android App through Gateway Platform and Sub-GHz is used for exchanging data between Gateway Platform and Things or Node. Bluetooth Wi-Fi and Sub-GHz modules are used in the Wireless Bridge platform which communicates with the STM32 on UART communication lines and NFC transceiver communicating with STM32 on SPI lines. The main challenge for STM32 microcontroller is to work with different communication devices without delay, serving all the request efficiently. The above architecture helps us to meet different use case requirements on different communication technologies. An Application layer is added on the Gateway solution that acts as bridge between the Cloud Application and Things. Contiki OS is used for the 6LoWPAN network. Smartphone application communicates with the Gateway board over the Bluetooth interface.
Key Communication Elements
Sub-GHz Module: The communication between the Gateway and Things is based on Sub-GHz using SPIRIT1 module on 6LoWPAN networks. SPIRIT1 module are ultra-low power & fully integrated RF modules operating respectively in the 868 MHz / 915 MHz ISM bands. These modules are based on the SPIRIT1 RF sub-GHz transceiver (with integrated SMPS), STM32L1 microcontroller, integrated filter/balun and chip antenna. The UART host interface allows simple connection to an external microcontroller with a standard firmware, allowing AT commands to facilitate RF configuration, data transmission and reception, using simple point-to-point communication.
Wi-Fi Module: The Wi-Fi module connects the Wireless Bridge Gateway with the Cloud Application. The SPWF01Sx intelligent Wi-Fi module is a standalone plug and play 802.11 b/g/n solution with integrated PA and an STM32 32-bit microcontroller. The modules also incorporate clock and voltage regulators.
Near Field Communication: The Gateway has CR95HF transceiver used as NFC reader/writer device to communicate with the NFC Passive Tag on the Things for configuration purpose. CR95HF is 13.56-MHz multi-protocol contactless transceiver device.
Bluetooth Module: The SPBT2632Cxx Bluetooth module provides complete RF platform in a small form factor. It is used in home automation applications for communicating with Bluetooth devices and smart phones.
Things Architecture
Things in this solution are based on Multi Sensors-RF platform which has 2 parts (STEVAL-IDI002V2 and STEVAL-IDI003V2). STEVAL-IDI002V2 is the master board consisting of a STM32L1 Cotex-M3 microcontroller, dual-EEPROM and Sub GHz Communication interface. STM32L1 runs Contiki3x based 6LoWPAN stack. It’s selected because it has very low power requirements. Dual Interface EEPROM enables the Multi sensor RF platform to store the data from the sensors and gives an option to the user to access this data using a NFC enabled Smart Phone.
STEVAL-IDI003V2 consists of a multiple sensors like MEMS Accelerometer, MEMS Pressure sensor, MEMS Humidity sensor, MEMS Microphone and light sensor. The whole system can be powered by single cell Li-Ion battery.
The Multi sensor-RF platform works as ‘Thing’ and the Sub-GHz module on the Wireless Bridge (Gateway) acts as a Root Node in the 6LoWPAN network. The sensor node reads the sensor data and transmit to the Root Node through the 6LoWPAN network. The node also has GPIOs which can be used to control actuators.
The IoT gateway has local and remote connectivity options to access sensor data and actuator on the nodes (Figure 4)
Web Access: A remote user can view sensor data and send command for the actuators using the web interface provided by the Management Server.
Android Application: A local user can access the nodes using the Bluetooth connectivity on smart phones. A mobile app can be used to pair the phone to Wireless Bridge platform and access the node functionality.
NFC Support: Wireless Bridge has NFC reader/writer support. This functionality can be used to configure the nodes (radio channel etc.) and Gateway (Wi-Fi and BT settings etc.)
Design of Management Server Application
We also designed a cloud application called ST CloudBridge that works as a bridge between sensor / actuator Things or Nodes and the end user. The block diagram of the Cloud Application is shown in figure 3. The Things or Nodes upload the data to the ST CloudBridge and fetch command and configuration information. The end user can monitor the sensor data stream. User can also set alarms for various situations. The platform also enables provisioning, control and configuration of the nodes. Cloud Bridge has two major parts: device module and web module. The device module interacts with the sensor / actuator nodes and the web module handles the web and mobile clients which are used by end users. The modules interact with each other using shared objects or cloud service bus. The solution runs on top of Azure websites platform. The Cloud Application has security features which allow to work with the registered nodes only so that data integrity is not compromised. The Cloud Application exposes standard REST based APIs that can be consumed by “Things” via the IoT Gateway.
It’s important for an IoT management application to support multiple protocols. We must have modules for device management, monitoring, reporting and provisioning.
IaaS is a preferred way of hosting cloud applications because of inherent load variability of IoT applications. Many cloud providers are now providing IoT specific services making the development and maintenance of IoT applications even more convenient.
Applications of Internet of Things
Home Automation
Smart Home: These applications allow users to monitor and control security devices and home appliances remotely. It also allows for efficient energy usage by automatically shutting down appliances when the user is not home.
Smart City
Smart Street Lights: Monitoring of parameters like ambient light and traffic can allow us to control the brightness and timing of lighting providing substantial energy saving. Any failures light can be immediately reported and rectified to avoid accidents and crime incidents.
Smart Metering: Wirelessly connected meters enable remote meter reading along with applications like differential tariffs and two way metering. Such meters can also detect and report theft and other power leakage in circuits.
Smart Parking: Enabled by proximity sensors, this is yet another IoT application. Jams and bottlenecks can be avoided if users can get vacant parking information in advance. Users can also be charged more accurately on basis of parking time.
Smart Agriculture: Accurate moisture and nutrient monitoring can indicate when watering or fertilizers are needed. It can save water and fertilizer costs while also improving the production substantially. Coupled with weather forecast such systems can prove to be really helpful for farmers.
Healthcare
This is an upcoming area where IoT can bring revolutionary changes for the end users. Various wearable sensors collect patient’s vital parameters such as temperature & blood pressure and transmit it to patient’s online health profile via IoT Gateway. This allows for an accurate history of parameters to be maintained. This data correlated with patient’s health history is a powerful tool in hands on healthcare professionals. The data can be analyzed in real time and in case of an emergency, swift action can be taken to provide immediate care to the patient.
Industrial
IoT can play an important role in monitoring and optimization of industrial processes. The availability of low power sensor nodes open new avenues in the Industrial automation which was earlier challenging. It’s also useful in areas where human presence is hazardous and sometimes not possible.
Conclusion
We proposed a general-purpose IoT gateway working with Smartphone and Cloud Application connected to Things on 6LoWPAN network. The Things are connected to IoT Wireless Gateway on IPv6 network. The system solution can be customized for different application use cases. Availability of high quality open source mesh networking stacks like Contiki has helped the proliferation of IoT into consumer space. Security still remains a challenging subject implicit to all the IoT applications. The existing security techniques are holding well, but as IoT networks become more prevalent we would unearth more challenges. Communities are still working to find better low cost / low power solutions that will lead to a secure IoT network. Advances in the semiconductor manufacturing process, decreasing cost and better power management along with energy harvesting would be another gate opener in IoT space.
