Wireless IoT Networks Protocols and Standards
Short-Range and Long-Range communication options
Choosing the right IoT network protocol may look straight-forward. Most can assume that Wi-Fi is the best for short-range IoT deployments, while cellular is the best connectivity for long-range deployments; however, several other choices are available depending on the use case and maturity. Selecting the appropriate wireless technology is a critical design decision. Several factors, such as protocol, interoperability, range, transmit power, receiver sensitivity, frequency, and specific use-case, must be considered holistically before deciding the right wireless technology.
An IoT ecosystem:
a) connects multiple heterogeneous devices (such as sensors, actuators, cameras, vehicles, robots, gateways, etc.),
b) ensures communication protocols are translatable,
c) verifies the accuracy and security of the data across the entire network (events from edge to the cloud and actions in the reverse direction),
d) captures, manages and analyzes, data to create better business outcomes,
e) integrates operational data with existing information technology systems and applications,
(f) and gains intelligence at the edge.
IoT sensors are typically small in size, inexpensive, and consume less power, as they are usually constrained by battery capacity and deployment ease. Sensors collect real-world events and transform them into digital signals. Actuators react according to those events. The actuators can be classified into electrical, hydraulic, and pneumatic, depending on their operation.
Typically, a sensor only has short-range connectivity and can not directly connect to the Internet. As a result, we need an intermediary device, a gateway, that can bridge this gap.
A smart gateway:
a) connects to multiple heterogeneous sensors/edge devices,
b) collects, preprocesses, and filters sensor data,
c) provides compute, storage, and networking services to IoT devices,
d) communicates with the cloud by sending only necessary data,
e) monitors power consumption, activities, and services of IoT devices, and
f) ensures security and privacy of data.
The exponential growth of low powered heterogeneous IoT devices results in communication challenges, such as:
a) Identification of individual devices: For this, we need a large addressing space and a unique ID for each device.
b) Low power transmission: Transmission of data between devices consume significant power, especially for wireless communication. Therefore, we need a solution that facilitates low power communication.
c) Routing protocol: A protocol optimized to efficiently route data with a shallow memory footprint.
d) High-speed real-time communication.
e) Provide exactly-once semantics for intermittent network connectivity
f) Handle the mobility of smart objects such as sensors in moving cars.
g) Correlate telemetry with contextual data to generate better models.
Users must apply specific criteria for selecting the right wireless technology for their use-case. The following list covers the major criteria:
a) Range: The distance between the transmitter and the receiver. Is the distance fixed or varies?
b) Number of nodes: The number of transmitters and receivers on the network and the interaction between them, such as star, mesh, peer-2-peer.
c) Data rate: The required data rate between transmitter and receiver; for example, monitoring may work with a low data rate, whereas video transfer requires a high data rate.
d) Duplex or simplex communication: Some applications can live with 1-way communication (from the transmitter to receiver). Others need 2-way communication (events from the transmitter to receiver and control signal from the receiver to transmitter).
e) Potential interference: Are there any interferences from the nearby wireless devices or systems? For example, having many devices operating in the 2.4 GHz band creates a problem.
f) Environment: Is the application indoor or outdoor? For outdoor applications, consider physical obstacles such as buildings, other structures, trees, vehicles, etc. For indoor applications, consider walls, floors, ceilings, furniture, etc.
g) Power source: What is the power source for the device: AC power or battery. If the battery, consider battery size, life, recharging needs and options, battery replacement intervals, and costs. Is solar power an option?
h) Regulatory compliance: Some use cases need wireless technologies that are FCC licensed. Most of the short-range wireless technologies are unlicensed.
i) Size and space: What is the size of wireless circuitry, and is there adequate room to accommodate that?
j) License fees: Is the technology free or requires a license or pay royalties?
k) User experience: Who plans to use the technology: an end consumer, or an experienced engineer or technician? How easy is it to install, setup, operate, and maintain?
l) Security: Does it support encryption and authentication? What other security features does it have?
m) Communication architecture: The network topology, such as peer-2-peer, star, or mesh, among connected devices.
Note: This article focuses explicitly on Wireless IoT network-level protocols and corresponding standards. A future article will discuss application/data-level protocols, such as MQTT, XMPP-IOT, AMQP, CoAP, WebSocket, OPC-UA, Pravega, Kafka, etc., and an example of end-to-end data flow.
IoT Networking Protocols
The following table summarizes prominent wireless IoT networking protocols.
Table 1: IoT networking protocols summary
Communication channels to transfer IoT data
As IoT devices are usually installed at geographically dispersed locations, the communication among them is generally wireless. These channels are often unreliable and have high rates of distortion. Due to this, communication technologies for IoT are important to ensure that we avoid too many retransmissions.
Before we talk about IoT protocols, let’s understand the basics related to IoT communication. The data from the edge to the cloud/data center primarily uses four types of communication channels. Hence, we need to understand the set of protocols that can satisfy the need to transmit the sensor’s data to the cloud.
1. Device to device: This involves direct communication between two smart sensors/devices without any gateway or intermediary involvement. For example, sensors and industrial robots communicate directly to coordinate their actions and perform the assembly of components more efficiently.
2. Edge endpoint to gateway: Sensor or endpoints are considered a thing or an object. It could be a connected home security system, thermostat, dishwasher, GPS tracker, or a door lock. It is the device that is creating a real business value through its sensor data. In most cases, these devices are resource-constrained and typically have a single protocol to communicate within the edge ecosystem. Gateways usually have more computing resources supporting multiple protocol stacks. For example, gateways use Bluetooth or Wi-Fi to talk to sensors but use cellular to connect to the cloud. Gateways primarily have two main functions: (a) Aggregate data from various heterogeneous sensors and route it to the relevant back-end data system (at cloud or datacenter), (b) Analyze data at the edge and take appropriate action.
3. Gateway to back-end data systems (cloud or datacenter): Gateways receive data from endpoints and are typically connected to the Internet. For Bluetooth, the gateway is often a smartphone; for cellular-based or M2M (Machine to Machine) IoT devices, the gateway generally is on the cellular tower; for Wi-Fi, the gateway is usually the Wi-Fi router. Gateways typically support multiple protocols as they bridge the sensor network with the data center or cloud network. Gateways choose some criteria to determine the appropriate protocol, for example, needed security, congestion and the amount of burst, the number of parallel connections, etc.
4. Within datacenter and cloud: The data from edge locations is ingested, stored, and analyzed at the cloud or private datacenters. The analytics at the cloud/datacenter sends alerts to an edge application (such as a mobile app) for an anomaly or predictive failure. This area is well established and outside the scope of this article.
Wireless Network Protocols and standards related to IoT
The wireless IoT network protocols can be categorized based on the distance they serve. The following section briefly describes wireless networking technology categories and associated IoT protocols involved in an end-to-end IoT data flow.
Before we dive deep into different protocols, let’s understand a sample use-case of how the Tesla Model 3 uses a couple of short-range protocols for the keyless entry.
Tesla has two types of keys:
1) Key card: This card communicates with model 3 using short-range RFID protocol. To unlock model 3, the driver needs to briefly tap the card against the hidden RFID transmitter located below the driver assistance camera on the drive’s side door pillar. The key card must be positioned within a one or two-inch range of the RFID transmitter. This allows the RFID reader to read and authenticate the card’s metadata before the door is unlocked.
2) Authenticated smartphone: Tesla mobile app on smartphone communicates with the model 3 using Bluetooth. Besides supporting automatic locking and unlocking, it supports multiple other functions. Model 3 detects the smartphone’s Bluetooth signal as the driver approaches the car and automatically unlocks the door. When the driver exits the car and walks away, model 3 locks the car as soon as the connected smartphone goes out of Bluetooth range, typically 30 feet.
The following is a simple visual representation of wireless IoT networking protocols.
NFC (Near-Field Communication)
NFC provides a technology used for contactless data exchange over a very short distance, 4 cm or less. NFC-capable devices connect using the point-to-point connection between them. One of these two devices typically has an internet connection to transmit the data to the target destination. The combination of very close-range data transfer and ease-of-use make NFC suitable for environments where data transactions need to have location-specific access. For example, you don’t want credit-card to be accessible for more than a few centimeters away. NFC’s communication protocols and data exchange formats are based on available RFID standards, including ISO/IEC 14443 and Felica. The standards include ISO/IEC 18092 and those defined by the NFC Forum. For more information about NFC, refer to http://nearfieldcommunication.org/. NFC device can act both as a tag and reader. NFC can be used for contactless payments, ID cards and badges for attendance tracking and record-keeping, wireless pairing and synchronizing data between two NFC capable devices, and many more.
RFID (Radio Frequency Identification)
RFID systems consist of a reader with an antenna and a transponder (tag). There are primarily two types of tags — active and passive. Active tags have their own power source, whereas passive tags draw power from the reader. RFID is best suited for asset tracking. RFID is how items are uniquely identified using radio waves, whereas NFC is a branch of high-frequency RFID, and both operate at the 13.56 MHz frequency. An RFID device can either be a reader or a tag. Mostly, an NFC reader can read RFID tags. RFID only provides 1-way communication, from tag to reader, whereas NFC provides 2-way communication, from tag to reader and peer-to-peer (e.g., device pairing). RFID tags can be read over 30+ meters of distance. RFID is primarily used for identification, location, tracking, and inventory. For more information about RFID, refer to RFID standards.
WBAN (Wireless Body Area Network)
BANs consist of sensors and actuators around the human body to monitor human organs or deliver either impulses or medicine on or inside (such as a pacemaker) the body. BAN devices may be implants in the body, externally mounted on the human body at a fixed position, or carried by humans in bags, pockets, etc. As these devices are implanted under the human body’s skin, they are highly power-constrained and require years of uptime on a single battery. The IEEE 802.15.6 standard provides a standard for low power, short-range, and extremely reliable wireless communication within the human body’s surrounding area, supporting a vast range of data rates for different applications. It uses existing industrial, scientific, and medical (ISM) frequency bands approved by national medical and/or regulatory authorities. BAN is required to provide quality of service with extremely low power and data rates ranging from a few Kbps up to 10 Mbps while simultaneously complying with strict non-interference guidelines where needed. A BAN system can use WPAN technologies as gateways to reach more extended ranges such as the Internet. The data available in the cloud/data center allows medical professionals to access patient data online using the Internet regardless of the patient’s location. For more information about WBAN, refer to IEEE 802.15 WPAN Task Group 6 page. BAN can be used for sports and fitness monitoring, assess soldiers’ fatigue, allow predictive actions, monitor patients’ health, alert the hospital if needed, and many more.
WPAN (Wireless Personal Area Network)
A PAN is a network for interconnecting devices within a short distance range. PANs can be used to communicate among personal devices or connect to a higher level network and the Internet via gateways. A PAN may be wireless (WPAN) or can use wired interfaces such as USB, Ethernet. A WPAN is a PAN carried over a low-powered, short-distance wireless network technology such as Bluetooth, Zigbee, Z-Wave, etc. The reach of a WPAN varies from a few meters to a few 100 meters. The following are a few industry standards and technologies related to WPAN that are in the mainstream:
1. Bluetooth Classic: Bluetooth is a non-IP, short-range wireless communication technology used in cellular devices, sensors, actuators, headsets, keyboards, etc. Bluetooth is a WPAN protocol based on the IEEE 802.15.1 foundation. IEEE 802.15.1 only defines the PHY and MAC layers of the Bluetooth protocol stack. Bluetooth Special Interest Group (SIG) standardizes higher protocol layers. Bluetooth classic is typically used for device-to-device file transfers, wireless peripherals, audio streaming through wireless headsets, speakers and soundbars, and many more. Bluetooth is not optimized for low power applications. For more information about Bluetooth SIG, refer to www.bluetooth.org
2. Bluetooth Low Energy (BLE): Bluetooth Low Energy (BLE) is a significant protocol for IoT use-cases. While it offers range, similar to classic Bluetooth, it is designed to transfer a small chunk of data and consume significantly reduced power than the classic Bluetooth. To save energy, BLE stays in sleep mode except when it initiates a connection. This feature makes BLE ideal for use cases, such as heart rate and blood pressure monitors, smart car access, personal electronics, wireless keyboards, asset trackers, wearable fitness trackers, and many more. BLE is not designed for applications requiring long-range connections. Bluetooth would need a gateway bridge to connect to an IP network. For more information about Bluetooth SIG, refer to www.bluetooth.org
3. Zigbee: Zigbee is a non-IP, 2.4 GHz local area network protocol that supports multiple network topologies: point-to-point, point-to-multipoint, and mesh networks. Zigbee supports self-forming and self-healing mesh. Zigbee targets commercial and residential IoT networking constrained by the cost, power, and space. Zigbee is a proprietary closed standard based on the IEEE 802.15.4 foundation. IEEE 802.15.4 only defines the PHY and MAC layers of the Zigbee protocol stack. Zigbee alliance standardizes higher protocol layers. Zigbee requires a licensing fee and agreement provided by the Zigbee Alliance. A Zigbee network can support up to 64K nodes. Zigbee can achieve long-range through its mesh network capability by daisy-chaining multiple Zigbee routers in the network. Zigbee is often used for various home automation controls such as wireless thermostats, light switches, lighting systems, and many more. Zigbee requires an IP network, via a gateway, and an address translation layer to connect to the cloud. For more information about the Zigbee alliance, refer to www.zigbee.org
4. Z-Wave: Z-Wave is a non-IP, closed protocol based on the IEEE 802.15.4 foundation. IEEE 802.15.4 only defines the PHY and MAC layers of the Z-Wave protocol stack. Z-Wave is a sub-GHz mesh network protocol standardized by the Z-Wave alliance. Z-Wave is often used for home automation, security systems, and lighting controls, and many more. For more information about the Z-Wave alliance, refer to www.zwavealliance.org
5. 6LoWPAN (IPv6 over Low-Power WPAN): 6LowPAN is an IP-based network protocol that defines encapsulation and header compression mechanisms allowing lightweight IP packets to be transported over IEEE 802.15.4 network designed for low-power communication. 6LoWPAN intends to support low-power RF communication for power and space-constrained devices that do not need high bandwidth. The main advantage of 6LoWPAN is that the sensors can have IP addressability. Additionally, IPv6 provides significant theoretical addressability of 2128 or 3.4x1038 unique addresses. This address space is sufficient to cover an estimated 50+ billion internet-connected devices in 2021 and beyond. Therefore, 6LoWPAN is well-suited for IoT growth. 6LoWPAN can be used across multiple transport types such as 802.15.4, cellular, Ethernet, Wi-Fi using several frequency bands. 6LoWPAN is primarily used for building and home automation, and many more.
6. Thread: Thread is a relatively new protocol based on 6LoWPAN for IoT. This IP protocol leverages IEEE 802.15 protocol for the physical and MAC layers; whereas, it relies on 6LoWPAN for security and routing features. Thread is a mesh-based IP protocol supporting up to 250 nodes. Thread self-heals and self-forms, meaning that it automatically promotes or demotes nodes to ensure no single-point failure in the network. Also, Thread works with any IPv6 gateway, making it easy to commission new devices to the network. Thread networks can be used in various home automation devices like light bulbs, electronic locks, and many more. IEEE 802.15.4-enabled devices can deploy and run Thread via a simple software upgrade. Thread can be used for home connectivity and home automation, and many more. For more information about Thread Group, refer to www.threadgroup.org
7. Connected Home over IP (CHIP): CHIP is an open-sourced royalty-free home automation connectivity standard. Amazon, Apple, Google, and the Zigbee alliance launched this project in December 2019. This standard is expected to leverage Thread as well as Wi-Fi and BLE. The Connected Home over IP project goal is to simplify development for manufacturers and increase compatibility for consumers. For more information about CHIP, refer to https://www.connectedhomeip.com/
WLAN (Wireless Local Area Network)
A WLAN is a wireless computer network that connects two or more devices using a wireless connection to form a LAN within a limited range. Through a gateway, a WLAN can also connect to the broader Internet. Most modern WLANs are based on IEEE 802.11 standards and marketed under the Wi-Fi brand name. IEEE 802.11 protocol represents a family of wireless radio communication based on different modulation techniques in the 2.4 and 5 GHz frequency bands. While typically used as a wireless LAN (WLAN), IEEE 802.11 protocols are also used in IoT deployments. The following section highlights the variant of IEEE 802.11 protocols relevant to power and cost-constrained IoT sensor devices. For more information about the Wi-Fi alliance, refer to www.wi-fi.org
1. IEEE 802.11ah: 802.11ah is a sub-GHz range variant of the 802.11 wireless protocols targeted to the IoT sensors. The protocol design tries to optimize for constrained sensor devices that require long battery life, extended range, and low-throughput. The extended range is essential for the sensors in remote areas, such as sensors used in the agriculture field.
2. IEEE 802.11ax: This is the next generation of IEEE 802.11ac protocol for highly efficient wireless communication. It increases capacity and throughput by 4x over 802.11ac.
3. IEEE 802.11p: IEEE 802.11p is considered a dedicated short-range communication protocol. The 802.11p protocol goal is to provide a standard for secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication used for vehicular safety, toll collection, traffic status/warnings, roadside assistance, and e-commerce within a vehicle.
The following figure shows the evolution of IEEE 802.11 protocols.
WWAN (Wireless Wide Area Network)
WWAN unites multiple smaller networks, including LANs and MANs (Metropolitan Area Networks). A WWAN uses cellular network technologies such as 4G LTE and 5G to transfer data instead of WLAN, limited to a specific area and uses technologies within a limited range. Typically the cellular service providers, such as AT&T, T-mobile, etc., deliver WWAN service. WWAN traffic is encapsulated in mobile communication technologies such as mobile WiMAX (Worldwide interoperability for Microwave Access), UMTS (Universal Mobile Telecom Systems), CDMA (Code Division Multiple Access), GSM (Global System for Mobile), or 4G LTE/5G and many more. The cellular network allows users with WWAN cards or built-in cellular radios (GSM/CDMA) to browse the web and perform any networking function as if they are physically connected to WWAN.
1. Cellular (2G/3G/4G LTE): The use of cellular for IoT devices is different from its use by a smartphone. For example, A smartphone typically uses a downlink to pull the information off the Internet. The data is often large and needs to stream in real-time, such as video data or music data, whereas for an IoT device, the data can be bursty in small chunks and travel to the Internet using the uplink. Though 3G/4G LTE can be used for IoT devices, especially sensors, they are not a natural fit for the IoT use cases due to their high power requirements. However, cellular can be used by gateways, which are required to send the data to the cloud or core data center over the Internet. These gateways can use, for example, 4G LTE, allowing multiple carriers (such as Verizon, AT&T) so that they can switch between carriers in case of connectivity issues with one career. This carrier switching is an important feature for mobile and transportation-based IoT systems such as logistics, emergency vehicles, and asset tracking.
2. LTE Cat-1 and Cat-0: LTE Cat 1 and 0 are typically more suitable for IoT devices. Cat-1 is currently an excellent choice in cellular connectivity for IoT and M2M devices with a wide range and low power. Cat-1 can support 10 Mbps downlink and 5 Mbps uplink speed. At these rates, Cat-1 is still capable of transporting audio and video streams in addition to IoT and M2M data. Cat-1 operates with less power than traditional 4G LTE.
3. LPWAN (Low Power WAN): IoT applications have specific requirements such as long-range, low data rate, low energy consumption, and cost-effectiveness. The widely used short-range radio technologies (e.g., ZigBee, Bluetooth) are not suitable for scenarios that require long-range transmission. Solutions based on cellular communications (e.g., 2G, 3G, 4G, and 5G) can provide long-range, but they consume excessive device power. Therefore, IoT applications’ requirements have driven the emergence of new wireless communication, LPWAN. LPWAN technology is a perfect fit for IoT devices looking to send tiny amounts of data over a long distance while maintaining long battery life. For example, a parking garage sensor only transmits information when a spot is open or occupied. Most LPWAN technologies use a star topology network. The following are a few LPWAN technologies:
a. LTE-M or LTE Cat-M1: Cat-M1 was built from the ground up for IoT and M2M use-cases. The significant difference between LTE and LTE-M is power efficiency. LTE-M allows battery-powered devices to send and receive data online over a cellular network. Besides, LTE-M allows in-vehicle or V2V (Vehicle to Vehicle) communication. It provides enough bandwidth for voice communication. LTE-M is suitable for tracking objects, utility metering, and energy management, among others. LTE-M has a significant power and cost advantage over LTE Cat-1.
b. Cat-NB or NB-IoT: NB-IoT, or Narrowband IoT, is another LPWAN protocol. NB-IoT has a very narrow channel bandwidth compared to LTE-M. As the channel width is low, it cannot support voice or video traffic; however, better suited for IoT devices. NB-IoT does not support handover and must remain associated with a single cell or remain stationary.
c. 5G: 5G is an emerging standard that promises to address substantial IoT and transportation (vehicle-to-vehicle) use cases. 5G also improves latency, bandwidth, density, and user cost.
d. LoRa (Long Range)/LoRaWAN (Long Range Wide Area Network): LoRa is a physical layer IoT protocol for long-range and low-power communication, whereas LoRaWAN is an open MAC layer protocol. LoRaWAN is designed to support large networks with millions of low-power devices. Its range makes it suitable for key IoT applications such as smart-city (street lights, parking place detectors, and so on). However, it only supports a low data rate and limited payload, which may not meet the needs of applications requiring real-time communication. While Sigfox and LoRa are better in terms of capacity, cost, and battery life, NB-IoT offers better latency and quality of service. Wi-Fi covers short, and medium-range use cases at a high data rate (can reach up to 1 Gbps under certain conditions). It has an obvious cost in terms of battery consumption. LoRaWAN covers long-range use cases, at a low data rate (0.3 KBps up to 50 KBps), with extremely low battery consumption, meeting up to 5 to 10-year battery lifetime, depending on device communication frequency. For more information about the LoRa alliance, refer to www.lora-alliance.org
e. Sigfox: Sigfox is an alternative wide-range technology. It uses the unlicensed ISM bands to transmit data over a very narrow spectrum for connected objects. Sigfox is useful for many M2M applications that run on a small battery and send a small and infrequent burst of data. The Wi-Fi range is too short for such applications, and cellular is too expensive while consuming excessive power. Sigfox uses Ultra Narrow Band (UNB) technology, designed to handle low data-transfer rates of 10 to 1,000 bytes per second while consuming only 50 microwatts compared to 5000 microwatts for cellular communication. For example, a 2.5Ah battery can deliver a typical standby time of 20 years for Sigfox, while it can last only 0.2 years for cellular. For more information about Sigfox, refer to www.sigfox.com
f. DASH7: Dash7 is a wireless network protocol that is open-source and operates in the 433 MHz, 868 MHz, and 915 MHz unlicensed ISM frequency band. DASH7 provides multi-year battery life, a range of up to 2 Km, low latency for connecting with moving things with a data transfer rate of up to 167 Kbps. For more information about the DASH7 alliance, refer to www.dash7-alliance.org
The following picture maps wireless IoT networking protocols in an OSI model.
Wrap up
IoT ecosystem has an overwhelming number of protocols to choose from. It doesn’t get easy as there is no unified standard to work with. So which protocol do you choose? That all boils down to your use case. Start by narrowing down the choice by determining the range, bandwidth, node, and power consumption requirements.
It all comes down to choosing a protocol that solves your use case while being interoperable with other devices on your network. These two requirements alone can turn an overwhelming list of protocols into a manageable set of choices.
Disclaimer
All content (e.g., words, scripts, images) provided on this blog is for informational purposes only. I make no representations of the accuracy or completeness of any information on this blog or found by following any link on this blog. I will not be liable for any errors or omissions in this information nor for the availability of this information. I will not be liable for any losses, injuries, or damages from the display or use of this information. The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect Dell’s views and opinions, nor does it constitute Dell’s official communication. Always check official documentation hosted by either company for support or verified technical information.
