There are many wireless protocols used by IoT devices. If you are new to the field, it can be quite overwhelming as you explore the space.
Below we provide a brief and frank overview of some of the most common wireless IoT protocols, and the advantages and disadvantages from the viewpoint of a product designer.
In our tables we reference the layers in the OSI model. If you are not familiar with the concept of OSI layers read this.
IP based protocols
Let’s start with protocols that can ride over IP (Internet Protocol). We do not discuss 6LoWPAN protocols here, for those jump below.
| Protocol | Layer 3 | Layer 4 | Layer 5+ | Description | |
|---|---|---|---|---|---|
| LwM2M LwM2M |
IP | UDP (5683, 5684) TCP (optional) (5683, 5684) |
CoAP. Variants exist for HTTP and MQTT |
LwM2M (Light weight M2M) over CoAP. 5684 is typically used for secure CoAP using DLTS, but in practice, both are used. The 1.0 version was published in 2017. Besides providing ways to update key - values, LwM2M specifies standards for how devices bootstrap, do firmware updates, and manage connectivity. Devices implementing LwM2M should work through their lifecycle on different implementations of LwM2M. Additionally, LwM2M functions very well in low bandwidth environments where connectivity may be spotty. | |
| MQTT MQTT |
IP | TCP (1883) TCP, TLS variant (8883) UDP (via MQTT-SN) |
MQTT | A pub-sub style protocol which was originally conceived in 1999 at IBM. MQTT centers itself around a broker which essentially provides a device shadow capability, keeping track of the device’s state. MQTT 5.0 now supports connections over QUIC. | |
| AMPQ AMPQ |
IP | TCP (5671, 5672) | AMQP | AMQP (Advanced Messaging Queuing Protocol) is a protocol with some similar characteristics of MQTT but designed to support much larger messages and more advanced routing of those messages. AMPQ servies are usually used for inter-application communications between micro-services. The 1.0 version is substantially different than the 0.9.1 version. Larger IoT devices with big bandwidth sometimes use the protocol - but it’s not suitable for low bandwidth, tiny devices due to client code size and bandwidth needs. | |
| UPnP UPnP |
IP | UDP (1900) TCP (5000) |
HTTP over UDP | A protocol which grew in popularity in the late 2010s, but is generally seen as insecure. Used in lower-end consumer devices. | |
| XMPP XMPP |
IP | TCP (5222, 5269, 5280, 5298) |
XMPP or XMPP over HTTP (BOSH) |
XMPP (Extensible Messaging and Presence Protocol) is a bi-directional streaming protocol originally designed for messaging. Despite the name, there are many additions to the protocol including IoT-specific RFCs, and a pub-sub feature. XMPP is overseen by IETF. | |
| OPC-UA OPC-UA |
IP | TCP | SOAP (XML) | OPC-UA (Unified Architecture) is an industrial protocol. A different protocol than its predecessor OPC-DA (Data Access) which is based on Microsoft Windows tech - DCOM, OPC-UA can run on more devices. Major implementations are available in Java and .NET | |
| DDS DDS |
IP | UDP 7400 + more, 59992, 59668 |
DDS | Data Distribution Service (DDS) is a pub-sub protocol for machine-to-machine communications. An industrial protocol, DDS targets a wider audience than OPC-UA. DDS began as a protocol used in military systems, including systems inside a ship. One of the original developers was Thales. Overseen by Object Management Group. - DDS assignment of ports is non-trivial - Discovery needs multicast UDP |
|
| OPC-DA OPC-DA |
IP | TCP | DCOM | OPC-DA (for Data Access) is the older version of the OPC specifications for publishing real-time data. OPC-DA has traditionally been used in industrial / factory environments. Its most severe limitation is that DCOM (Distributed Common Object Model) is a Windows-only protocol based on OLE. As Linux grew to be the primary OS in embedded systems this became more of a limitation for the OPC Foundation, pushing the need for OPC-UA. There is no open-source OPC-DA for Linux. |
| Protocol | Layer 3 | Layer 4 | Layer 5+ | Description | |
|---|---|---|---|---|---|
| LwM2M LwM2M |
IP | UDP (5683, 5684) TCP (optional) (5683, 5684) |
CoAP. Variants exist for HTTP and MQTT |
LwM2M (Light weight M2M) over CoAP. 5684 is typically used for secure CoAP using DLTS, but in practice, both are used. The 1.0 version was published in 2017. Besides providing ways to update key - values, LwM2M specifies standards for how devices bootstrap, do firmware updates, and manage connectivity. Devices implementing LwM2M should work through their lifecycle on different implementations of LwM2M. Additionally, LwM2M functions very well in low bandwidth environments where connectivity may be spotty. | |
| MQTT MQTT |
IP | TCP (1883) TCP, TLS variant (8883) UDP (via MQTT-SN) |
MQTT | A pub-sub style protocol which was originally conceived in 1999 at IBM. MQTT centers itself around a broker which essentially provides a device shadow capability, keeping track of the device’s state. MQTT 5.0 now supports connections over QUIC. | |
| AMPQ AMPQ |
IP | TCP (5671, 5672) | AMQP | AMQP (Advanced Messaging Queuing Protocol) is a protocol with some similar characteristics of MQTT but designed to support much larger messages and more advanced routing of those messages. AMPQ servies are usually used for inter-application communications between micro-services. The 1.0 version is substantially different than the 0.9.1 version. Larger IoT devices with big bandwidth sometimes use the protocol - but it’s not suitable for low bandwidth, tiny devices due to client code size and bandwidth needs. | |
| UPnP UPnP |
IP | UDP (1900) TCP (5000) |
HTTP over UDP | A protocol which grew in popularity in the late 2010s, but is generally seen as insecure. Used in lower-end consumer devices. | |
| XMPP XMPP |
IP | TCP (5222, 5269, 5280, 5298) |
XMPP or XMPP over HTTP (BOSH) |
XMPP (Extensible Messaging and Presence Protocol) is a bi-directional streaming protocol originally designed for messaging. Despite the name, there are many additions to the protocol including IoT-specific RFCs, and a pub-sub feature. XMPP is overseen by IETF. | |
| OPC-UA OPC-UA |
IP | TCP | SOAP (XML) | OPC-UA (Unified Architecture) is an industrial protocol. A different protocol than its predecessor OPC-DA (Data Access) which is based on Microsoft Windows tech - DCOM, OPC-UA can run on more devices. Major implementations are available in Java and .NET | |
| DDS DDS |
IP | UDP 7400 + more, 59992, 59668 |
DDS | Data Distribution Service (DDS) is a pub-sub protocol for machine-to-machine communications. An industrial protocol, DDS targets a wider audience than OPC-UA. DDS began as a protocol used in military systems, including systems inside a ship. One of the original developers was Thales. Overseen by Object Management Group. - DDS assignment of ports is non-trivial - Discovery needs multicast UDP |
|
| OPC-DA OPC-DA |
IP | TCP | DCOM | OPC-DA (for Data Access) is the older version of the OPC specifications for publishing real-time data. OPC-DA has traditionally been used in industrial / factory environments. Its most severe limitation is that DCOM (Distributed Common Object Model) is a Windows-only protocol based on OLE. As Linux grew to be the primary OS in embedded systems this became more of a limitation for the OPC Foundation, pushing the need for OPC-UA. There is no open-source OPC-DA for Linux. |
Non-IP Wireless Protocols
The following are non-IP based wireless protocols:
| Protocol | Layer 2 | Layer 3 | Layer 4 | Layer 5+ | Description |
|---|---|---|---|---|---|
| LoRa LoRa |
LoRa | LoRa | LoRaWAN | LoRaWAN (and others) | LoRa is a proprietary, physical layer protocol for long range wireless communications. For LoRa devices to talk to something outside the LoRa network there must be a LoRa base station. The LoRa base station would usually have Ethernet or WiFi, allowing it to communicate on a LAN or onto the Internet. LoRa does not define a network layer or application layer protocol. The LoRa Alliance oversees LoRaWAN which provides these layers. There are various software implementations of LoRaWAN to be used in a gateway to bring LoRa devices onto the Internet / LAN / WAN allowing LoRa devices to be IoT devices. |
| SigFox SigFox |
SigFox | SigFox | SigFox | any | SigFox is a LPWAN (Low Power Wide Area Network) technology using its own proprietary wireless encoding scheme and protocol. Radios / chipsets are which are compatible with SigFox are available from a number of well known semiconductors. SigFox’s main advantage is lower power usage and sub Ghz radios (operating at 868 Mhz in Europe and 902 Mhz in the US) which are known to have better penetration through materials such as concrete and metal, and be able to transmit farther on the same power. Consequently, SigFox had to be build out a network with base stations on towers which could handle this frequency and did this by partnering with many telecoms, either in renting towers are in an operational agreement. It was an ambitious plan, that at least to this author, seemed unlikely to ever succeed. Sigfox (the company) went bankrupt in 2020 and was purchased by Unabiz, a Singapore based IoT company.[^1] It’s unclear how operational the network currently is. |
| Helium Helium |
LoRA | LoRA | LoRAWAN | any | Helium is a decentralized IoT network, with cells created by many individual participants attaching their own hardware to the Helium network. Helium provides an IoT network using LoRaWAN. If you are building an IoT device, plan on or are willing to use LoRa and need goegraphical coverage across the world, look at their website to understand the coverage. Helium is also building a 5G network which is in its early stages. That being said both networks can be spotty. Our recommendation would be to use Helium as an ancillary, roaming or backup network. |
| Protocol | Layer 2 | Layer 3 | Layer 4 | Layer 5+ | Description |
|---|---|---|---|---|---|
| LoRa LoRa |
LoRa | LoRa | LoRaWAN | LoRaWAN (and others) | LoRa is a proprietary, physical layer protocol for long range wireless communications. For LoRa devices to talk to something outside the LoRa network there must be a LoRa base station. The LoRa base station would usually have Ethernet or WiFi, allowing it to communicate on a LAN or onto the Internet. LoRa does not define a network layer or application layer protocol. The LoRa Alliance oversees LoRaWAN which provides these layers. There are various software implementations of LoRaWAN to be used in a gateway to bring LoRa devices onto the Internet / LAN / WAN allowing LoRa devices to be IoT devices. |
| SigFox SigFox |
SigFox | SigFox | SigFox | any | SigFox is a LPWAN (Low Power Wide Area Network) technology using its own proprietary wireless encoding scheme and protocol. Radios / chipsets are which are compatible with SigFox are available from a number of well known semiconductors. SigFox’s main advantage is lower power usage and sub Ghz radios (operating at 868 Mhz in Europe and 902 Mhz in the US) which are known to have better penetration through materials such as concrete and metal, and be able to transmit farther on the same power. Consequently, SigFox had to be build out a network with base stations on towers which could handle this frequency and did this by partnering with many telecoms, either in renting towers are in an operational agreement. It was an ambitious plan, that at least to this author, seemed unlikely to ever succeed. Sigfox (the company) went bankrupt in 2020 and was purchased by Unabiz, a Singapore based IoT company.[^1] It’s unclear how operational the network currently is. |
| Helium Helium |
LoRA | LoRA | LoRAWAN | any | Helium is a decentralized IoT network, with cells created by many individual participants attaching their own hardware to the Helium network. Helium provides an IoT network using LoRaWAN. If you are building an IoT device, plan on or are willing to use LoRa and need goegraphical coverage across the world, look at their website to understand the coverage. Helium is also building a 5G network which is in its early stages. That being said both networks can be spotty. Our recommendation would be to use Helium as an ancillary, roaming or backup network. |
The IEEE 802.15.4 protocols
802.15.4 is a lower power 2.4Ghz (same bands as original WiFi) standard layer 2 protocol which operates in the same spectrum as WiFi and Bluetooth.
802.15.4 is appealing to many protocol / standards implementers due to its lower power and the various SoCs available from silicon providers, such as Texas Instruments, Nordic, NXP, Silicon Labs, to name a few. The main reason so many radios are available is that most silicon which can do Bluetooth can also be used for 802.15.4, sometimes with little if any physical design adjustment. Some 802.15.4 SoCs even allow the operation of both Bluetooth and 802.15.4 without a hard reboot of the SoC (note, this is not the same as simultaneous use); an example being the KW32 series from NXP. \
Another advantage of 802.15.4 is it operates in the same, unlicensed bands as 2.4Gh WiFi, which are available virtually world wide. 802.15.4 also has sub-Ghz radio options available in the US and Europe.
There are a number of Layer 3+ protocols that use 802.15.4:
| Protocol | Layer 2 | Layer 3 | Layer 4 | Layer 5+ | Description |
|---|---|---|---|---|---|
| 6LoWPAN 6LoWPAN |
any | 6LoWPAN | CoAP (usually) | any | 6LoWPAN is a loose standard that gets its guidance from a number of IETF RFCs. The concept of 6LoWPAN is to run IP over even the smallest footprint devices with networks which have smaller MTUs than ethernet or WiFI (normall 1500 or greater). The base for it is RFC 4944. While any Layer 2 transport could be possible, 6LoWPAN RFCs are focused on IEEE 802.15.4 and Bluetooth. 6LoWPAN itself is the basis for a number of more formal standards, including Thread and Matter. |
| Thread Thread |
802.15.4 | Thread Based on 6loWPAN |
Thread Based on CoAP |
any | Thread is a standardized form of 6LoWPAN which has support for multiple border routers in the same WPAN. The 6LoWPAN RFC itself does not state how IP addresses will be assigned or routing information will be passed. Thread provides answers for this (based on other RFCs) and glues them together as a standard. Thread was originally targeted at smart home but has branched out into other spaces including some industrial. Thread is a layer 3 and 4 protocol, and a self-organizing mesh topology. It does not state how devices should talk above CoAP. The OpenThread release from Google provides a completely open-source (BSD 3-clause) implementation for Thread and Thread border router that is not tied to a specific silicon vendor. Thread the standard is governed by the Thread Group. |
| Matter Matter |
any typically 802.15.4 WiFi |
any Usually Thread |
any Usually Thread |
Matter | Matter is an application layer protocol that provides significant standardization on how smart home devices should talk. Technically Matter is an application protocol only, but we place it on this list because for all practical use cases it is a 802.15.4 application protocol. However, we are beginning to see some WiFi Matter based devices hit the market as WiFi 6 becomes mainstream. Matter is governed by the Connectivity Standards Alliance. CSA makes Matter (unlike ZigBee) available as an Apache 2.0 license. However, for your product to be certified, your organization must be a member of CSA. |
| Zigbee Zigbee |
802.15.4 | ZigBee | ZigBee | ZigBee | ZigBee is a full stack built on 802.15.4 with a self-organizing mesh topology. There are a number of profiles and versions of ZigBee, including but not limited to the : legacy HA (Home Automation), SE (Smart Energy), and ZLL (ZigBee Link Light), the newer ZigBee 3.0 which unifies the prior ones, ZigBee PRO, and some others. If you think this is confusing, you are not alone. ZigBee is overseen by the Connectivity Standards Alliance, which also oversees Matter. While actual goals are not 100% clear with CSA, the general momentum in the industry seems to be moving to Thread / Matter based stacks. Matter’s design has many of the elements found in ZigBee. Note Thread is not overseen by CSA but Matter is. ZigBee is proprietary and not available unless a member of CSA. |
| WirelessHART WirelessHART |
802.15.4 (TDMA) |
WirelessHART | HART | HART | WirelessHART is the wireless incarnation of HART, which is an old wireline protocol designed industrial automation use cases, usually for real-time, process critical sensors and monitors. Of these protocols, WirelessHART is one of two that makes use of the other way to use 802.15.4. 802.15.4 can run as CSMA/CA or TDMA mode. WirelessHART is a self-organizing mesh topology. Using the time-sliced mode of 802.15.4 makes sense understanding the history of HART. Implementing a WirelessHART device would probably only make sense if you are in the type of industries where HART is already employed, or if you need incredibly consistent delivery of frames for real time performance. |
| ISA100.11a ISA100.11a |
802.15.4 (TDMA) |
6LoWPAN | any | any | The only ISA standard here, ISA100.11a was officially released in 2009, but continues to evolve. Like WirelessHART it uses the TDMA mode of 802.15.4 but is a star-topology.[^2] It also shares some characteristics of Thread, being formed on a 6LoWPAN base. In industrial markets, WirelessHART and ISA100.11a compete for technical wins. Newer forms of ISA100.11a form vendors are adding encryption capabilities including blockchain to ensure accuracy and authenticity of sensor data. |
| Protocol | Layer 2 | Layer 3 | Layer 4 | Layer 5+ | Description |
|---|---|---|---|---|---|
| 6LoWPAN 6LoWPAN |
any | 6LoWPAN | CoAP (usually) | any | 6LoWPAN is a loose standard that gets its guidance from a number of IETF RFCs. The concept of 6LoWPAN is to run IP over even the smallest footprint devices with networks which have smaller MTUs than ethernet or WiFI (normall 1500 or greater). The base for it is RFC 4944. While any Layer 2 transport could be possible, 6LoWPAN RFCs are focused on IEEE 802.15.4 and Bluetooth. 6LoWPAN itself is the basis for a number of more formal standards, including Thread and Matter. |
| Thread Thread |
802.15.4 | Thread Based on 6loWPAN |
Thread Based on CoAP |
any | Thread is a standardized form of 6LoWPAN which has support for multiple border routers in the same WPAN. The 6LoWPAN RFC itself does not state how IP addresses will be assigned or routing information will be passed. Thread provides answers for this (based on other RFCs) and glues them together as a standard. Thread was originally targeted at smart home but has branched out into other spaces including some industrial. Thread is a layer 3 and 4 protocol, and a self-organizing mesh topology. It does not state how devices should talk above CoAP. The OpenThread release from Google provides a completely open-source (BSD 3-clause) implementation for Thread and Thread border router that is not tied to a specific silicon vendor. Thread the standard is governed by the Thread Group. |
| Matter Matter |
any typically 802.15.4 WiFi |
any Usually Thread |
any Usually Thread |
Matter | Matter is an application layer protocol that provides significant standardization on how smart home devices should talk. Technically Matter is an application protocol only, but we place it on this list because for all practical use cases it is a 802.15.4 application protocol. However, we are beginning to see some WiFi Matter based devices hit the market as WiFi 6 becomes mainstream. Matter is governed by the Connectivity Standards Alliance. CSA makes Matter (unlike ZigBee) available as an Apache 2.0 license. However, for your product to be certified, your organization must be a member of CSA. |
| Zigbee Zigbee |
802.15.4 | ZigBee | ZigBee | ZigBee | ZigBee is a full stack built on 802.15.4 with a self-organizing mesh topology. There are a number of profiles and versions of ZigBee, including but not limited to the : legacy HA (Home Automation), SE (Smart Energy), and ZLL (ZigBee Link Light), the newer ZigBee 3.0 which unifies the prior ones, ZigBee PRO, and some others. If you think this is confusing, you are not alone. ZigBee is overseen by the Connectivity Standards Alliance, which also oversees Matter. While actual goals are not 100% clear with CSA, the general momentum in the industry seems to be moving to Thread / Matter based stacks. Matter’s design has many of the elements found in ZigBee. Note Thread is not overseen by CSA but Matter is. ZigBee is proprietary and not available unless a member of CSA. |
| WirelessHART WirelessHART |
802.15.4 (TDMA) |
WirelessHART | HART | HART | WirelessHART is the wireless incarnation of HART, which is an old wireline protocol designed industrial automation use cases, usually for real-time, process critical sensors and monitors. Of these protocols, WirelessHART is one of two that makes use of the other way to use 802.15.4. 802.15.4 can run as CSMA/CA or TDMA mode. WirelessHART is a self-organizing mesh topology. Using the time-sliced mode of 802.15.4 makes sense understanding the history of HART. Implementing a WirelessHART device would probably only make sense if you are in the type of industries where HART is already employed, or if you need incredibly consistent delivery of frames for real time performance. |
| ISA100.11a ISA100.11a |
802.15.4 (TDMA) |
6LoWPAN | any | any | The only ISA standard here, ISA100.11a was officially released in 2009, but continues to evolve. Like WirelessHART it uses the TDMA mode of 802.15.4 but is a star-topology.[^2] It also shares some characteristics of Thread, being formed on a 6LoWPAN base. In industrial markets, WirelessHART and ISA100.11a compete for technical wins. Newer forms of ISA100.11a form vendors are adding encryption capabilities including blockchain to ensure accuracy and authenticity of sensor data. |
Bluetooth
Bluetooth really deserves a section all its own, because the Bluetooth standards and profiles vary greatly and can be used for many applications. As noted above, IEEE made an 802.15.1 standard for the original Bluetooth, and it resembles 802.15.4. However, new versions of Bluetooth have evolved and changed the look and market applications of the protocol.
Bluetooth evolved out of collaboration work between IBM and Ericsson. The Bluetooth SIG was formed in 1998, and the first Bluetooth device shipped in 1999. Bluetooth SIG oversees all updates to the protocol.
Bluetooth, unlike WiFi and 802.15.4, Bluetooth uses frequency hopping spread spectrum (FHSS). Classic Bluetooth (not BLE) will change the frequency it uses by 1Mhz over 1600 times a second. The advantage of using FHSS over direct sequence spread spectrum_ (DSSS) is that FHSS tends to hold up better when there are other devices using the same spectrum.1 This can help explain why dozens of people right next to each other in an office can have their Bluetooth headsets in and still get consistent playing music in their ear. DSSS, however, provides better data throughput. This explains why WiFi can push up to multi-gigabit speeds today.
Bluetooth Versions vs. Bluetooth Profiles
Bluetooth versions refer to major revisions of the protocol itself. In some cases such revisions have required new SoCs, especially where encoding or frequency hopping improvements have been made. Profiles refer to the functions a Bluetooth device may implement. You might think of Bluetooth Profiles sort of like the Layer 4+ part of Bluetooth, sort of its Application Layer. Profiles themselves may have various versions.
As an example, the Bluetooth A2DP profile is a profile most end-users will have used. This profile is used to transfer stereo in a variety of formats, which is negotiated between a device (headphones, speakers) and the host (usually a laptop or smartphone). Profiles are updated like the versions of Bluetooth. For instance, A2DP supports new encoding options such aptX and aptX HD.
Below we will go over the major protocol versions and their applicability to IoT.
| Protocol | Releases | Introduction | Description |
|---|---|---|---|
| Bluetooth 1.x Bluetooth 1.x |
1.0, 1.1, 1.2 |
1998 (1.0) | The very early versions of Bluetooth were really more of engineering products. Bluetooth 1.2 is where most consumers got familiar with Bluetooth. The major products were handsfree headsets. |
| Bluetooth 2.x Bluetooth 2.x |
2.0, 2.1 | 2004 (2.0) 2007 (2.1) |
Some of the main improvements in Bluetooth 2 is faster data rates. 2.1 introduced Secure Simple Pairing (SSP) which is the pairing you are used to using on most end-user facing Bluetooth devices. The faster data rates, termed Enhanced Data Rate (EDR) opened up the type of Bluetooth devices that could be used, which in turn saw the creation of more profiles for Bluetooth. Previous data rates were referred to as Standard Data Rate (SDR) |
| Bluetooth 3.0 Bluetooth 3.0 |
3.0 | 2009 | Bluetooth 3.0 introduced a number of enhancements mostly improving the performance and possible applications of end-user devices. Improvements include the HS specification, which essentially transfers data faster on a 802.11 type link. Other improvements include power efficiency and features for simpler devices. |
| Bluetooth 4.0 Bluetooth 4.0 |
4.0, 4.1 4.2 |
2010 (4.0) Mesh: 2017 |
Bluetooth 4.0 was one of the most important and market-changing updates to Bluetooth. It’s the first version of Bluetooth which really began to matter for IoT devices. 4.0 introduced Bluetooth Low Energy (BLE). BLE use a different frequency hopping and modulation scheme, and consequently has a different, lower data rate. It also has an entirely different stack, with new profiles. Per the name, one main advantage of BLE is its lower power consumption. It is possible for devices to implement both BLE and Classic Bluetooth (i.e. Bluetooth 3.0 or earlier). For a period of time BLE devices were marketed as Bluetooth Smart devices. 4.0 also introduced the GATT (Generic Attribute) profile, which allows IoT devices to describe a published service they can provide. Bluetooth Mesh One of the most interesting BLE additions are the mesh profiles. The mesh profiles have opened up Bluetooth for wireless networks of IoT related devices. Mesh profiles were introduced in 2014 and officially adopted by Bluetooth SIG in 2017. This positioned BLE to compete directly against 6LoWPAN, Thread and ZigBee devices all of which already mesh their networks. BLE and these other protocols have differences in the way they mesh (a topic for further discussion). Going one step beyond this, Bluetooth 4.2 has the IPSP (Internet Protocol Support Profile) that provides capabilities to help run IPv6 on BLE. RFC 7668 describes how this profile can be used to build 6LoWPAN networks using IPSP and GATT profiles. |
| Bluetooth 5.0 Bluetooth 5.0 |
5.0 | 2016 | Bluetooth 5.0 is mostly an improvement on BLE in regards to IoT devices. One new feature is a 2M PHY mode which allows for using a 2Mhz wide bandwidth instead of 1MHz. The 2M mode allows for higher bandwidth with a tradeoff for more potential interference. There is also a new LE Coded format which goes the opposite way, allowing slower data rates, albeit at lower power, but with individual bursts being bigger, up to 256, versus the maximum in a Bluetooth frame of 31 bytes in Bluetooth 4. These new features provide more options for Bluetooth device implementors. The new modes make longer range possible using BLE, with stated distance being up to 1000m (outdoors and probably under perfect conditions - btw, these same numbers can be achieved with 2.4Ghz 802.15.4 as well). |
| Bluetooth 5.1 Bluetooth 5.1 |
5.1 | 2019 | 5.1 introduced some powerful features which really allow some Bluetooth IoT devices to differentiate themselves. One of the more interesting is AoA (Angle of Arrival) and AoD (Angle of Departure) specifications. Devices that implement this can effectively get an indication of the direction of the signal they received from another Bluetooth device. Combined with RSSI (Received Signal Strength Indicator) devices can determine with reasonable accuracy where other devices are, for applications like indoor location tracking. Before 5.1 some products already were using features like this, such as Tile, but 5.1 standardized the capabilities. Other enhancements in this update include a standardized way for stack to cache GATT information, improving performance on BLE and enhancements to the BLE meshing mechanism. |
| Bluetooth 5.2 Bluetooth 5.2 |
5.2 | Dec 2019 | Bluetooth 5.2 came less than a year after 5.1 and brought more enhancements for BLE devices: BLE power control capabilities, which can improve performance by allowing devices to request that peers dynamically change power to improves signal-to-noise ratio. EATT (Enhanced Attribute Protocol) - is an improvement on GATT. The main purpose id allowing more sophisticated devices, which may use multiple profiles and modes on Bluetooth simultaneously, to transmit data from these different services interleaved. The biggest update was LE Audio. LE Audio is a new audio mode, and provides for entirely new uses cases. For instance, multiple people with headsets listening to a single smartphone player. See page 30 in the BLE 5.2 official update for more. |
| Bluetooth 5.3 Bluetooth 5.3 |
5.3 | 2021 | Bluetooth 5.3 saw some pretty technical changes. LE Enhanced Connection Update is a way for devices that already may be using Bluetooth in multiple ways, to subrate a connection. Subrating essentially allows devices to put a certain feature in standby mode, while still having periodic connectivity to a peer. The Bluetooth SIG provides the example of a hearing aid device which also maintains a link to a smartphone, so it can immediately function as a headset when needed, but this connection to the phone uses less power than a normal connection. The 5.3 specification also had updates to advertising capabilities, where a device may periodically send a message about capability or a critical event. |
| Bluetooth 5.4 Bluetooth 5.4 |
5.4 | 2023 | Bluetooth 5.4 is a technical but important update for IoT devices. The big feature is the new PAwR (Period Advertising with Responses) transport. This new transport will allow Bluetooth IoT deployments to scale to a larger number of devices, when the topology is one-to-many. Examples of one-to-many Bluetooth devices are already in the field. For instance, Bluetooth electronic shelf labels (ESL) are already deployed in many stores. 5.4 formalizes and improves the capabilities needed to produce applications such as ESL, but in a generic way, and with devices that provide information back to the Broadcaster (typically the Bluetooth gateway talking to the many devices) from the Observer (the edge sensor, device, tag, etc). Performance improvements in PaWR allow for the Broadcaster to only target a subset of Observers and it allows for Observers to send data back to the Broadcaster frequently. PaWR should open up Bluetooth for IoT applications that previously were not possible due to scalability issues. Other enhancements include encoding and security improvements for advertising. |
| Protocol | Releases | Introduction | Description |
|---|---|---|---|
| Bluetooth 1.x Bluetooth 1.x |
1.0, 1.1, 1.2 |
1998 (1.0) | The very early versions of Bluetooth were really more of engineering products. Bluetooth 1.2 is where most consumers got familiar with Bluetooth. The major products were handsfree headsets. |
| Bluetooth 2.x Bluetooth 2.x |
2.0, 2.1 | 2004 (2.0) 2007 (2.1) |
Some of the main improvements in Bluetooth 2 is faster data rates. 2.1 introduced Secure Simple Pairing (SSP) which is the pairing you are used to using on most end-user facing Bluetooth devices. The faster data rates, termed Enhanced Data Rate (EDR) opened up the type of Bluetooth devices that could be used, which in turn saw the creation of more profiles for Bluetooth. Previous data rates were referred to as Standard Data Rate (SDR) |
| Bluetooth 3.0 Bluetooth 3.0 |
3.0 | 2009 | Bluetooth 3.0 introduced a number of enhancements mostly improving the performance and possible applications of end-user devices. Improvements include the HS specification, which essentially transfers data faster on a 802.11 type link. Other improvements include power efficiency and features for simpler devices. |
| Bluetooth 4.0 Bluetooth 4.0 |
4.0, 4.1 4.2 |
2010 (4.0) Mesh: 2017 |
Bluetooth 4.0 was one of the most important and market-changing updates to Bluetooth. It’s the first version of Bluetooth which really began to matter for IoT devices. 4.0 introduced Bluetooth Low Energy (BLE). BLE use a different frequency hopping and modulation scheme, and consequently has a different, lower data rate. It also has an entirely different stack, with new profiles. Per the name, one main advantage of BLE is its lower power consumption. It is possible for devices to implement both BLE and Classic Bluetooth (i.e. Bluetooth 3.0 or earlier). For a period of time BLE devices were marketed as Bluetooth Smart devices. 4.0 also introduced the GATT (Generic Attribute) profile, which allows IoT devices to describe a published service they can provide. Bluetooth Mesh One of the most interesting BLE additions are the mesh profiles. The mesh profiles have opened up Bluetooth for wireless networks of IoT related devices. Mesh profiles were introduced in 2014 and officially adopted by Bluetooth SIG in 2017. This positioned BLE to compete directly against 6LoWPAN, Thread and ZigBee devices all of which already mesh their networks. BLE and these other protocols have differences in the way they mesh (a topic for further discussion). Going one step beyond this, Bluetooth 4.2 has the IPSP (Internet Protocol Support Profile) that provides capabilities to help run IPv6 on BLE. RFC 7668 describes how this profile can be used to build 6LoWPAN networks using IPSP and GATT profiles. |
| Bluetooth 5.0 Bluetooth 5.0 |
5.0 | 2016 | Bluetooth 5.0 is mostly an improvement on BLE in regards to IoT devices. One new feature is a 2M PHY mode which allows for using a 2Mhz wide bandwidth instead of 1MHz. The 2M mode allows for higher bandwidth with a tradeoff for more potential interference. There is also a new LE Coded format which goes the opposite way, allowing slower data rates, albeit at lower power, but with individual bursts being bigger, up to 256, versus the maximum in a Bluetooth frame of 31 bytes in Bluetooth 4. These new features provide more options for Bluetooth device implementors. The new modes make longer range possible using BLE, with stated distance being up to 1000m (outdoors and probably under perfect conditions - btw, these same numbers can be achieved with 2.4Ghz 802.15.4 as well). |
| Bluetooth 5.1 Bluetooth 5.1 |
5.1 | 2019 | 5.1 introduced some powerful features which really allow some Bluetooth IoT devices to differentiate themselves. One of the more interesting is AoA (Angle of Arrival) and AoD (Angle of Departure) specifications. Devices that implement this can effectively get an indication of the direction of the signal they received from another Bluetooth device. Combined with RSSI (Received Signal Strength Indicator) devices can determine with reasonable accuracy where other devices are, for applications like indoor location tracking. Before 5.1 some products already were using features like this, such as Tile, but 5.1 standardized the capabilities. Other enhancements in this update include a standardized way for stack to cache GATT information, improving performance on BLE and enhancements to the BLE meshing mechanism. |
| Bluetooth 5.2 Bluetooth 5.2 |
5.2 | Dec 2019 | Bluetooth 5.2 came less than a year after 5.1 and brought more enhancements for BLE devices: BLE power control capabilities, which can improve performance by allowing devices to request that peers dynamically change power to improves signal-to-noise ratio. EATT (Enhanced Attribute Protocol) - is an improvement on GATT. The main purpose id allowing more sophisticated devices, which may use multiple profiles and modes on Bluetooth simultaneously, to transmit data from these different services interleaved. The biggest update was LE Audio. LE Audio is a new audio mode, and provides for entirely new uses cases. For instance, multiple people with headsets listening to a single smartphone player. See page 30 in the BLE 5.2 official update for more. |
| Bluetooth 5.3 Bluetooth 5.3 |
5.3 | 2021 | Bluetooth 5.3 saw some pretty technical changes. LE Enhanced Connection Update is a way for devices that already may be using Bluetooth in multiple ways, to subrate a connection. Subrating essentially allows devices to put a certain feature in standby mode, while still having periodic connectivity to a peer. The Bluetooth SIG provides the example of a hearing aid device which also maintains a link to a smartphone, so it can immediately function as a headset when needed, but this connection to the phone uses less power than a normal connection. The 5.3 specification also had updates to advertising capabilities, where a device may periodically send a message about capability or a critical event. |
| Bluetooth 5.4 Bluetooth 5.4 |
5.4 | 2023 | Bluetooth 5.4 is a technical but important update for IoT devices. The big feature is the new PAwR (Period Advertising with Responses) transport. This new transport will allow Bluetooth IoT deployments to scale to a larger number of devices, when the topology is one-to-many. Examples of one-to-many Bluetooth devices are already in the field. For instance, Bluetooth electronic shelf labels (ESL) are already deployed in many stores. 5.4 formalizes and improves the capabilities needed to produce applications such as ESL, but in a generic way, and with devices that provide information back to the Broadcaster (typically the Bluetooth gateway talking to the many devices) from the Observer (the edge sensor, device, tag, etc). Performance improvements in PaWR allow for the Broadcaster to only target a subset of Observers and it allows for Observers to send data back to the Broadcaster frequently. PaWR should open up Bluetooth for IoT applications that previously were not possible due to scalability issues. Other enhancements include encoding and security improvements for advertising. |
Closing Thoughts
Which protocol should you use? Generally, consider the following:
- What protocols and standards are already in use in my industry?
- How much custom development can my team afford? put another way: Do we need a standard that already provides a blueprint for us?
- What are the key technical requirements? Power, range, bandwidth, interference, and materials your wireless device will need to go through (RF penetration)
- Is the product meant to be, or does it benefit from an ecosystem? Or is it intended to deploy isolated - only talking to its own cloud?
Feel free to reach out to us at Izuma Networks. We have vast experience in many IoT applications: IoT gateways of all types, LwM2M microcontroller devices, 6LoWPAN devices, Thread and Bluetooth - to mention a few.
