Internet of Things" />
Image Credits: a-image/shutterstock.com
The term Internet of Things (IoT) refers to a network of connected objects or things with integrated electronics that enable them to remotely sense, report, and control, and occasionally make simple decisions.
Machine to machine communication (M2M) and Internet of Everything (IoE) are other terms, which are used to define similar concepts.
The concept of objects with electronics linked to a network has been around for a long time. At a cursory glance, IoT does not appear to be a novel concept. However, there are slight differences between the classical M2M and IoT. IoT links each device (things) that humans interact with, and this includes devices that are not generally linked to the network.
It also intends to exploit present IP-based networks, rather than generating dedicated network infrastructure as is the practice in today’s M2M, forming a global network of things.
Although the premise of the connection to the internet increases the reach of IoT, it also creates unique issues. One issue is that most IoT nodes have limited storage, memory, and computation capabilities and cannot directly connect to IP-based networks.
This requirement is met by an IoT Gateway that acts as a bridge between IP-based public network and local networks that were designed considering the specific requirements of the IoT nodes. In addition, the IoT Gateway can provide extra storage, security, and processing services, making the end nodes as power efficient and cost-effective as possible. Nodes using various communication technologies can also interact with each other within the network.
It is very difficult to design an IoT Gateway for an application, keeping the future requirements in mind, because there are too many variables which impact the design. The IoT realm is divided with countless number of vendors and there are almost no widely agreed standards. Too many literatures are available on the topic from technology vendors promoting their own technologies.
This article aims to provide a holistic approach to all of the available options to the implementers, without venturing into vendor-specific protocols.
Challenges in Designing an IoT Gateway
Node Connectivity
A short range radio frequency (RF) technology should be selected to link to the IoT nodes. This selection depends on several parameters like modulation scheme, frequency band, latency, data-rate, robustness, channel number etc.
This decision also depends on local regulatory requirements. When there is a uniform network with same types of nodes the selection process becomes easier, but when there are multiple types of nodes with different needs then it becomes much more difficult.
Backend Connectivity
A short range radio technology may be used by the IoT Gateway to link to the IoT nodes; however, a long distance link is required to link to the internet. This selection is governed by the criticality of the application, existing connectivity options in the area, and bandwidth requirements. As connectivity options differ from one area to another, multiple backend connectivity options can provide a good solution.
Management Server
Generally, IoT nodes are not accessed (via the gateway) on the internet as standalone entities. Instead a central server is often used to control the nodes, while the communication is facilitated by the IoT gateway. Protocols should be identified for communication with the management server.
Local intelligence
In a true cloud architecture, all of the data is sent to the cloud by the nodes for processing and control. However, this does not provide a perfect scenario to send unnecessary data to the cloud, as this wastes the bandwidth, places additional load on the server, and results in data loss in the event of connectivity outage.
This problem was solved by concept of edge computing. The system can be made more efficient if the IoT Gateway takes most of the decisions locally and transmits only the filtered data to the cloud. For better flexibility, the server can be used to program the gateway decision logic. The type and amount of local intelligence is application dependent and should be carefully considered as it would impact the gateway design decisions.
Power Considerations
The source and power source of gateway can also affect decisions related to the above points. As sensor networks have become more common and are being integrated in things, they would need to be as unobtrusive as possible while gathering power from its environment.
Security
Security is a factor that can make or break the effectiveness of large-scale IoT networks. Security will become very important as IoT networks become part of more applications; some of them critical in nature. During every stage of the design process, security should be considered as a factor, it would be a mistake to add security after designing everything else.
Serviceability
Serviceability is often overlooked. If we look through history, there is no such thing as a perfect system. Despite the amount of pre deployment testing performed, security loopholes and bugs would be detected invariably following deployment. There must be a provision to update and service the IoT Gateway (and nodes) in the field.
Remote serviceability should not be solely depended upon, and additional connectivity options should be available to service the installation.
The following sections provide detailed descriptions of some of these points with the options available, and discuss how each of these options can be used in different scenarios.
Node Connectivity Technologies
In the present landscape, there are many well-known communication technologies such as Wi-Fi, Bluetooth, ZigBee, and NFC. Several new emerging networking options are also available such as Thread, Sub- GHz, Z-Wave, and ANT that can be directly applied for smart lighting, smart home, smart metering, and smart city applications.
Based on the application, factors like power consumption, operating range, battery life, operating frequency, and data rate will govern the choice of one or more from a group of different technologies.
Table 1 shows a comparison of features of the key communication technologies that are available today.
Table 1. Comparison of Wireless Connectivity Technologies
| Technology |
Standard |
Band |
Range |
Power |
Data Rate |
IoT Applications |
| Bluetooth |
Bluetooth 4.x specification |
2.4 GHz |
Medium
50 - 150 m
(Smart) |
Medium
Low (BLE) |
Medium
1 Mbps |
Wearable devices
Sensors Nodes
IoT application |
| Wi-Fi |
802.11b/g/n/ac |
2.4 / 5 GHz |
Medium
50 m |
High |
High
500 Mbps to 1 Gbps |
IP Camera
Gate way devices |
| NFC |
ISO/IEC 18000-3 |
13.56 MHz |
Low
10 cm |
Low |
Low
100 – 420 kbps |
Access Management
BT/Wi-Fi pairing
e-Tickets
Payment |
| Sub GHz |
802.15.4
6LoWPAN |
868 MHz /
915 MHz |
High |
Low |
Low
500 kbps |
Smart Street light
Energy meters
Smart Building |
| Zigbee |
802.15.4 |
2.4 GHz |
10 - 100 m |
Low |
Low
250 kbps |
Smart street light
Smart Building |
| Z-Wave |
ITU-T G.9959 |
900 MHz |
30 m |
Low |
9.6/40/100 kbit/s |
Home automation |
| Thread |
802.15.4 and
6LoWPAN |
2.4 GHz |
N/A |
Low |
250 kbps |
Home automation |
Backend Connectivity
Backhaul connectivity technology and protocols to link to backend are required for connectivity to the management server (backend). Backhaul connectivity is the long range connection of the IoT Gateway to the ISP endpoint.
2G/3G/LTE and other cellular technologies are the most popular options, but power line communication (PLC) can also be used for smart street lights or other applications where power lines are used. Optical fibers can be employed for high-bandwidth applications. Microwave point to point connections or satellite links can be used for remote areas that are not covered by cellular connectivity.
Communication Protocol
The IoT Gateway can use many communication protocols to communicate with the cloud application. Here, some of the more popular technologies are discussed along with advantages and disadvantages.
Plain HTTP
Plain HTTP is the most ubiquitous protocol. It is broadly accepted by servers and is being supported by internet standards with minimum compatibility issues. Although it suffers from large overhead in form of HTTP headers and text-based format, plain HTTP can map naturally with the RESTful API.
Despite being run on top of TCP, plain HTTP is stateless, making it unsuitable for real-time use. In order to get a response or command from the server, the client would need to send a request and must continue polling for updates from the server.
CoAP
Regarded as a binary version of HTTP, Constrained Application Protocol (CoAP) improves certain limitations of HTTP. It reduces the overhead through supported binary data format and highly concise headers. It can be employed on top of TCP or other transport, or even SMS.
CoAP packets can be effortlessly translated to a HTTP packet, but due to negligible internet infrastructure support it does not play well with routers, proxies, and firewalls. Therefore, CoAP protocol can only be used for private networks within the sensor network.
Web Sockets
Web sockets is a new protocol that has the same handshake and addressing mechanism used by HTTP. It is also backed by web standards and is compatible with current network infrastructure.
As soon as handshake is complete, it switches to duplex communication on top of TCP. This makes web sockets perfect for two way, real time communication. It is especially useful in real time and shared hosting environments that operate behind proxies.
MQTT
MQTT is also a well-known protocol that runs (optionally) on top of TCP. Although MQTT is more suitable for broadcasting messages to interested gateways, it is also employed for gateway to server communication. It has a topic subscriber model and includes certain features like will and testament message and last message persistence that make it useful for IoT application.
AMQP
AMQP is probably the most ideal protocol for gateway server communication. It acts as a storing queue and ensures that packets are not misplaced, even during temporary outage.
XMPP
Extensible Messaging and Presence Protocol (XMPP) is a well-known protocol, used by chat clients for real-time communication. It standardizes many things, including message IDs and user authentication, but data exchange based on verbose XML format and complicated specification makes it unsuitable for IoT application.
IoT Gateway Platform Architecture
This section presents a flexible design produced for data monitoring and control of sensor. This is a generic application and does not involve any special requirements for reliability or security.
Wireless Bridge IoT Gateway
Wireless Bridge is an STM32 based IoT Gateway Platform solution (Figure 1) that has various connectivity technologies. The system includes Sub-GHz, Wi-Fi, Bluetooth, and Near Field Communication. All of the communication technologies offer the following benefits:
- Sub-GHz is used for exchanging data between Node/Things and Gateway Platform
- Wi-Fi is used for exchanging Node data or Things on the Cloud Platform via Gateway platform
- Bluetooth is used for communicating the Node data or Things with the Android App via Bluetooth and Gateway Platform
NFC transceiver communicates with STM32 on SPI lines, while Sub-GHz, Wi-Fi, and Bluetooth modules are employed in the Wireless Bridge platform that communicates with the STM32 on UART communication lines. The key challenge for STM32 microcontroller is to operate with various communication devices without delay, efficiently serving all of the requests.
The above architecture helps to address different use case requirements on various communication technologies. The Gateway solution is added with an Application layer that acts as a bridge between the Things and Cloud Application. For the 6LoWPAN network, Contiki OS is employed. Smartphone application communicates with the Gateway board across the Bluetooth interface.
Figure 1. STMicroelectronics Wireless Bridge Solution
Key Communication Elements
Sub-GHz Module
The communication between the Things and Gateway is based on Sub-GHz using SPIRIT1 module on 6LoWPAN networks. The SPIRIT1 modules are fully integrated and ultra-low power RF modules that respectively operate in the 915 MHz/868 MHz ISM bands.
They are based on the STM32L1 microcontroller, SPIRIT1 RF sub-GHz transceiver (with integrated SMPS), chip antenna, and integrated filter/balun. In addition, the UART host interface enables easy connection to an external microcontroller using a traditional firmware. This allows AT commands to ease RF configuration as well as data transmission and reception using basic point-to-point communication.
Wi-Fi Module
The Wireless Bridge Gateway is connected to the Cloud Application through the Wi-Fi module. The SPWF01Sx intelligent Wi-Fi module is a standalone plug and play 802.11 b/g/n solution that comes with an STM32 32-bit microcontroller and a built-in PA. Clock and voltage regulators are also integrated in the modules.
Near Field Communication
CR95HF transceiver is used as a NFC reader/writer device in the Gateway to communicate with the NFC Passive Tag on the Things for configuration purposes. The CR95HF transceiver is a 13.56 MHz multi-protocol contactless device.
Bluetooth Module
The SPBT2632Cxx Bluetooth module comes in a small form factor, serving as a complete RF platform. It is mainly employed in home automation applications to communicate with smart phones and Bluetooth devices.
Things Architecture
In this solution, Things are based on Multi Sensors-RF platform which features two components - STEVAL-IDI003V2 and STEVAL-IDI002V2. The master board, STEVAL-IDI002V2, includes a dual-interface-EEPROM, Sub GHz Communication interface, and a STM32L1 Cotex-M3 microcontroller.
The STM32L1 runs Contiki3x-based 6LoWPAN stack and has extremely low power requirements. Through the dual Interface EEPROM, the Multi sensor RF platform stores data from the sensors and provides an option for users to access this data with a NFC-enabled Smart Phone.
The STEVAL-IDI003V2 includes various sensors such as MEMS Pressure sensor, MEMS Accelerometer, MEMS Humidity sensor, light sensor, and MEMS Microphone. A single cell Li-Ion battery can be used to power the entire system.
Figure 2. RF Sensor Node (Thing)
The Sub-GHz module on the Wireless Bridge (Gateway) works as a Root Node in the 6LoWPAN network, and the Multi sensor-RF platform acts as ‘Thing’. After reading the sensor data, the sensor node transmits this to the Root Node via the 6LoWPAN network.
In addition, the node has GPIOs that can be used to control actuators. Local and remote connectivity options in the IoT Gateway allow it to access actuator and sensor data on the nodes (Figure 3).
Figure 3. IoT Gateway Interfaces
Web Access
The web interface provided by the Management Server allows a remote user to view sensor data and send the command for the actuators.
Android Application
A local user can use the Bluetooth connectivity on smart phones to access the nodes. The phone can be coupled to a Wireless Bridge platform and the node functionality can also be accessed, all through a mobile app.
NFC Support
NFC reader/writer support is included for Wireless Bridge. This functionality can be used to configure Gateway (Wi-Fi and BT settings etc.) and the nodes (radio channel etc.)
Design of Management Server Application
A cloud application, known as ST CloudBridge, was also designed that acts as a bridge between the end user and sensor/actuator Things or Nodes. Figure 4 shows the block diagram of the Cloud Application.
Figure 4. Cloud Application for Node Management
The Nodes/Things upload the data to the ST CloudBridge and fetch configuration information and command. The sensor data stream can be monitored by the end user. Alarms can also be set for different situations. The platform allows provisioning, configuration, and control of the nodes.
Cloud Bridge has two key parts - web module and device module. The web module handles the mobile and web clients which are used by end users, while the device module communicates with the actuator/sensor nodes. The modules communicate with each other through cloud service bus or shared objects.
The solution works on top of Azure websites platform. Security features are included in the Cloud Application, enabling it to work only with the registered nodes so that data integrity is not affected. Standard REST-based APIs exposed by the Cloud Application can be consumed by Things through the IoT Gateway.
An IoT management application must support several protocols. Modules should be available for device management, provisioning, monitoring, and reporting. Due to the inherent load variability of IoT applications, IaaS is the preferred method for hosting cloud applications. There are many cloud providers who are now offering IoT specific services, making the development and maintenance of IoT applications much easier.
Applications of Internet of Things
Home Automation
Smart Home: These applications enable users to remotely track and control home appliances and security devices. They also enable efficient energy use by automatically shutting down appliances when users are away from their homes.
Smart City
Smart Street Lights: Monitoring traffic, ambient light, and other similar parameters allows users to control the timing and brightness of lighting. This provides considerable energy saving. In the event of failures, light can be instantly reported and rectified to prevent crimes and accidents.
Smart Metering: Wirelessly connected meters allow remote meter reading as well as applications like two way metering and differential tariffs. Such meters can even detect and report theft and other similar power leakage in circuits.
Smart Parking; This is yet another IoT application enabled by proximity sensors. If users can get vacant parking information beforehand, then Jams and bottlenecks can be prevented. Users can also be charged more accurately in relation to the parking time.
Smart Agriculture: Accurate nutrient and moisture monitoring can indicate when fertilizers or watering are required. This can save water and fertilizer costs, while improving the production considerably. Such systems, combined with weather forecast, can be helpful for farmers.
Healthcare
Healthcare is an upcoming area, where IoT can redefine changes for end users. Many wearable sensors are able to acquire a patient’s vital parameters like blood pressure and temperature, and transmit the same to the patient’s online health profile through IoT Gateway.
This provides an accurate history of parameters that need to be maintained. This data, when correlated with the patient’s health history, serves as a powerful tool for healthcare professionals. The data can also be inspected in real time, and during an emergency instant action can be taken to offer care to the patient.
Industrial
Internet of Things (IoT) can play a critical role in the optimization and monitoring of industrial processes. Access to low-power sensor nodes provides new opportunities in the Industrial automation, which was earlier very difficult. IoT is also useful in those areas, where human presence is risky and sometimes unfeasible.
Conclusion
A general-purpose IoT Gateway working with Cloud Application and Smartphone linked to Things on 6LoWPAN network is recommended. The Things are linked to IoT Wireless Gateway on IPv6 network. It is possible to customize the system for different applications. Access to high-quality open source mesh networking stacks such as Contiki has helped the proliferation in the IoT into consumer space.
Security continues to remain a challenging prospect in all IoT applications. Although the current security methods are holding well, increased proliferation of IoT networks can reveal more challenges.
Communities are still exploring ways to find better low power and low cost solutions that will promote a secure IoT network. Developments in the semiconductor manufacturing process, better power management, reducing cost, together with energy harvesting would be another gate opener in IoT space
This information has been sourced, reviewed and adapted from materials provided by STMicroelectronics.
For more information on this source, please visit STMicroelectronics.