The Internet of Things (IoT) is connecting our world together more intimately than ever. It’s also adding a whole new level of complexity and confusion on the shoulders of the electronic designer. The biggest problem is the overwhelming amount of choices and considerations that have to be made for an IoT project. Which protocol is the best? Will my chosen protocol be irrelevant a year from now? Do I have the time to design RF and an antenna? In this blog, we’ll be focusing on the topic of protocols, how they fit into the networking stack, and how you can use modules to make easy work for your first IoT project.

Product Requirements First, Protocols Second

Which protocol you choose for your IoT project is one of the most important decisions you’ll make. Not only do you need to meet specific bandwidth and node requirements, but you also need a protocol that is interoperable with the other devices on your network. The protocol you choose will also have an impact on your hardware selections. Need to transmit data long distances? If you go with WiFi, it’s going to require an increase in processing power and power consumption.

Engineers new to IoT get held up on choosing the “best” protocol, or a protocol that won’t be irrelevant by the time their product gets released to market. The truth is, there is no “best” protocol, and there are no set standards, yet. So what do you do? Pick the protocol that best solves the problems you’re dealing with today and focuses on your technical constraints, such as:

• What kind of range and bandwidth requirements does your application require?
• How many nodes are going to be supported (or potentially supported) on your device’s network?
• What kind of security and power demands will your application require?

These three questions alone will drive what kind of protocol you choose for your IoT device. Step one, define your product requirements, then look over the available IoT protocols below to determine the best fit.

Where Your Protocol Fits in the Stack

There’s a big misconception floating around that there will be a “one protocol to rule them all” future. We don’t see this happening. Why? There are a variety of protocol standards to choose from, and they all solve very different problems. Expecting one protocol to satisfy all of these needs just isn’t realistic.

Let’s start with wrapping our hands around how all of these protocols fit together. An easy way to understand the bigger picture is to look at an existing OSI framework for telecommunications and computer networking. Take a look at the image below:

We can use this framework to organize protocols into a series of layers where control and data are passed from one layer to the next. The lower layers deal with raw electrical and binary data, whereas the higher levels deal with network requests and the representation of data. Each layer has a specific job.

1. Physical Layer

This layer is responsible for transmitting digital data from the physical layer of a source device to the physical layer of a receiving device. This transmission typically happens over Ethernet cables, hubs, and repeaters. At this layer, data takes the form of voltages, radio frequencies, pulses of infrared, or light.

2. Data Link Layer

This layer verifies data sent from the Physical Layer and checks for any errors as it organizes bits into data “frames.” This layer also assigns addresses for physical devices with MAC addresses. The Data Link Layer is the most complex layer in the OSI model and is typically divided into Media Access Control and Logical Link Control sublayers.

3. Network Layer

This layer takes data from the Data Link Layer and examines the source and destination addresses in each bit frame. If the frame has reached its final destination, then this layer organizes the data into packets and sends it home. Otherwise, the Network Layer will update the destination address and send the frame along to another destination.

4. Transport Layer

This layer handles all of the mass transit of data from source to node to the final destination. Here we have data traveling along a TCP networking protocol which provides capabilities for error recovery, flow control, and re-transmission.

5. Session Layer

This layer manages how data gets broken down at various network connection points. It also handles the flow of events that occur for crossover connections.

6. Presentation Layer

This layer handles all of the syntax processing for message data, which includes format conversions, encryption, and decryption.

7. Application Layer

This layer connects data directly to its end destination application in the hands of the user. The most common example of this is the HTTP protocol which allows data to be sent to/from a web browser.

Most of the protocols that you’ll be worrying about as an electronics designer will sit within the Transport Layer. It’s here where you’ll be concerned with how data is being transported over a network from source to n the de to end destination. At this point, you have a good idea on how protocols fit into the bigger picture of a networking stack. Let’s now look at the top 10 protocols you’ll want to consider for your first IoT project.

The Top 10 Protocols to Consider

Bluetooth

Specifications

• Standard: Bluetooth 4.2 Core Specification
• Frequency: 2.4GHz (ISM) frequency hopping
• Range: 50-150m for BLE
• Data Rates: 1Mbps for BLE
• Cloud Access: Yes, with added IPv6 routing in Bluetooth 4.2

Details

Bluetooth is one of the most widely used short-range wireless technologies. For IoT, you’ll commonly find Bluetooth applications in wearable technologies that pair with a smartphone. The newly introduced Bluetooth Low-Energy (BLE) protocol provides the range of traditional Bluetooth with lower power consumption.

One thing to keep in mind is that BLE is not intended for large file transfers and is better suited for small chunks of data. This is why Bluetooth rules the world of consumer mobile devices. The new Bluetooth Core Specification 4.2 adds a new Internet Protocol Support Profile that will allow Bluetooth Smart Sensors to access the internet directly through 6LoWPAN. This addition can make Bluetooth and BLE an attractive alternative to WiFi for short-range communications.

ZigBee

Specifications

• Standard: ZigBee 3.0 based on IEEE802.15.4
• Frequency: 2.4 GHz
• Range: 10-100m
• Data Rates: 250 kbps
• Cloud Access: Yes, requires bridge

Details

Like Bluetooth, ZigBee has a huge user base, but for industrial applications instead of consumer. This protocol operates at a 2.4GHz frequency and is perfect for industrial settings where data is exchanged over small rates within a building or home. ZigBee and the ZigBee Remote Control are known for providing low-power, secure, and scalable solutions with high node counts. ZigBee 3.0 has further unified the protocol into a single standard, which makes it more accessible for design integration.

WiFi

Specifications

• Standard: Based on 802.11n
• Frequencies: 2.4GHz and 5GHz bands
• Range: Approximately 50m
• Data Rates: 500Mbps-1Gbps with 802.11ac, depends on channel frequency and antennas
• Cloud Access: Yes, works on internet protocol standards

Details

WiFi is the preferred choice for IoT integration for many electronic designers due to its existing infrastructure, fast data transfer rates, and ability to handle large amounts of data. The most common WiFi standard 802.11 offers transfer rates of hundreds of megabits per second, making it ideal for data transfer but too power consuming for some IoT APplications.

NFC

Specifications

• Standard: ISO/IEC 18000-3
• Frequency: 13.56MHz (ISM)
• Range: 10cm
• Data Rates: 100-420kbps
• Cloud Access: Yes, requires bridge for tags and modules

Details

NFC takes advantage of secure two-way communications between electronic devices. Most recently we’ve seen this interaction occur with smartphones offering cardless payment transactions in retail stores. This protocol is ideal if your device needs to exchange data with another device that’s less than 10cm away. Compared with Bluetooth, NFC can be a great alternative that uses less power and doesn’t require pairing between devices.

Cellular

Specifications

• Standard: GSM/GPRS/EDGE (2G), UMTS/HSPA (3G), LTE (4G)
• Frequencies: 900/1800/1900/2100MHz
• Range: 35km max for GSM, 200km max for HSPA
• Data Rates: 35-170kps (GPRS), 120-384kbps (EDGE), 384Kbps-2Mbps (UMTS), 600kbps-10Mbps (HSPA), 3-10Mbps (LTE)
• Cloud Access: Yes

Details

If your device needs to communicate over hundreds of miles, then the cellular protocol is your best option. This communication technology can send large amounts of data with 4G, but the higher power consumption makes it hit or miss for many IoT applications. Some development boards like SparqEE offer shields that can add cellular connectivity to an existing Raspberry Pi or Arduino Project.

Z-Wave

Specifications

• Standard: Z-Wave Alliance ZAD12837 & ITU-T G.9959
• Frequency: 900MHz (ISM)
• Range: 30-100m
• Data Rates: 40-100kbit/s
• Cloud Access: Yes, requires bridge

Details

This protocol provides low-power RF communications that are typically used in home automation applications for lamp controllers, sensors, etc. Z-Wave is a low-latency technology that has the added benefit of shielding from WiFI and other wireless technologies by operating in the sub-1GHz band. Designers looking for a fast and simple development process often opt for this streamlined protocol known for its easy setup.

Thread

Specifications

• Standard: Based on IEEE802.15.4 & 6LowPAN
• Frequency: 2.4GHz (ISM)
• Range: 10-30m
• Data Rates: Up to 250 kbps
• Cloud Access: Yes, requires bridge

Details

Thread is one of the newest protocols to enter the scene from the creators of Nest and is ramping up usage in home automation applications. This IP-based IPv6 networking protocol is based on 6LowPAN and was designed to compliment WiFi within the home. The Thread protocol is available royalty-free from the Thread Group, supports mesh networking with IEEE802.15.4 radio transceivers, and can handle up to 250 nodes with authentication and encryption.

EnOcean

Specifications

• Standard: EnOcean Standard ISO/IEC 1543-3-1X
• Frequency: 315 MHz, 868 MHz, 902 MHz
• Range: 300m outdoors, 30m indoors
• Data rates: Up to 125 kbps
• Cloud Access: Yes

Details

EnOcean takes a new twist on protocols by positioning itself as an energy harvesting and wireless sensing platform. This makes it ideal if you’re designing devices that need to respond to changes in lighting, temperature and other variable conditions. Most applications for the EnOcean protocol are currently used in industrial automation, home automation, transportation, and logistics.

Sigfox

Specifications

• Standard: Sigfox
• Frequency: 900MHz
• Range: 30-50km rural environments, 3-10km urban environments
• Data Rates: 10-1000bps
• Cloud Access: Yes

Details

Sigfox is an alternative wide-range technology that sits between WiFi and cellular for range capabilities. It was originally created for M2M applications that only transfer low levels of data and have a small battery. Sigfox takes advantage of the Ultra Narrow Band (UNB) which can handle low data-transfer speeds of 10-1,000 bits per second while consuming only 50 microwatts of power.

RFID

Specifications

• Standard: ISO/IEC 18000-3
• Frequencies: 120–150 kHz (LF), 13.56 MHz (HF), 433 MHz (UHF), 865-868 MHz (Europe)902-928 MHz (North America) UHF, 2450-5800 MHz (microwave), 3.1–10 GHz (microwave)
• Range: 10cm to 200m
• Data Rates: Varies by standard
• Cloud Access: Yes

Details

RFID uses a set of tags and labels in a radio-frequency identification system to send and receive signals. You’ll find this protocol being used in road tolls, building access control, and inventory control in either passive, active, or battery assisted passive configurations. Some RFID devices will only use battery power when in the presence of an RFID reader which makes it ideal for lower power consumption applications.

Using a Module for Your First IoT Project

Now that you have your protocol selected let’s jump into RF design! Well, hold on, if you’re working for a company that doesn’t have the resources or time to work with RF and antenna design, then you have a problem. Or maybe you feel overwhelmed with your current design requirements and don’t want to deal with FCC compliance and keeping up with the latest RF standards. If this sounds like your situation then using a module is your best bet.

While there are many modules available for the various protocols, we’ll be focusing only on WiFI here. Why? Some of the protocols we listed above still do not have native-IP functionality. Without this, your device won’t be able to send and receive data with over devices over the internet without added gateways and complexity.

This is where WiFi comes in. It’s already loaded with native IP functionality, is based on established IEEE 802.11 standards, and can easily scale for increasing data rates and power consumption requirements. Plus, you get the benefit of working with a platform that already has more than 6.8 billion installed devices. Access points should never be a concern.

Consider this, by adding a WiFI module to your first IoT project you’ll get to work with a part that is already fully tested, calibrated, and certified to meet all of your wireless communication needs. This becomes an attractive plug-and-play solution that can lighten the load on your design process. We’ve got three recommended WiFi modules that you can use for your upcoming project:

Microchip DM990001

This development kit includes two microchip components. The MRF24WG0MA/B supports both 802.11b and 802.11g standards. The PIC32MX695F512H microcontroller includes 128 Kbytes of RAM and 512 Kbits of flash memory. You’ve also got USB 2.0, 10/100 Ethernet MAC, and four dedicated memory access channels for both USB and Ethernet. This dev kit works out of the box with Amazon Web Services (AWS), which makes it easy to manage all of your connected devices in the cloud.

Texas Instruments CC3120MOD

This development kit includes the CC3100R11MRGC WiFi Network Processor along with a complete power management subsystem. It supports 802.11 b/g/n modes and includes all required clocks, SPI flash, RF filter, crystal, and passives in one convenient chip. Within this kit, you’ll also get all the software, sample applications, and reference designs you need to kick off your IoT connectivity.

STMicroelectronics SPWF04

This module offers a plug-and-play solution to quickly integrate 802.11 b/g/n and TCP/IP technologies into your IoT project. It sports some advanced internet security features like WPA2 Enterprise and a TCP/IP protocol stack with WebSocket support. This is a great module to use if you’re designing for a small form factor and low power consumption constraints.

The Illusion of Choice

There are an overwhelming amount of protocols to choose from when working on an IoT project. Your decision likely won’t get any easier knowing that there’s no unified standard to work with. So which protocol do you choose? That all comes down to your design requirements. Start by determining your range, bandwidth, node, and power consumption requirements. From there, you can start to narrow down the choices.  Here is more information to read up on.

It’s all about choosing a protocol that solves the problems your application is trying to address 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.

Ready to start designing your first IoT electronics project? Try Autodesk EAGLE for free today!