Many business decision-makers have moved beyond the point where IOT is just a buzzword. They are seeing the tangible benefits of IOT and what it can do for business productivity, profits and future growth.
Typical questions that every decision-maker faces during the planning phase of adopting an IOT strategy into their business operations is:
Where do I start? And which IOT solution will best fit my business needs?
There are various factors to consider.
For example, when considering the advantages and disadvantages of the type of IOT connectivity to use, it should be based completely on the use case of the IOT product you are developing, which is, in turn, based on stakeholders’ needs. In addition, you have to consider which communication protocols (such as MQTT, HTTPS or COAP) best serve the purpose of your IOT product.
To guide you through this complex process, we have drafted a decision-making tree premised on various questions/statements with basic yes/no answers and which route to take in each case.
We will unpack each branch of the tree in successive articles. This article focuses on branch one: your device is IP-enabled with custom firmware.
Definitions
However, before we explore these questions, a few definitions:
- COAP (Constrained Application Protocol): COAP is a specialised Web transfer protocol for use with constrained nodes and constrained networks in the IOT.
- HTTP(S) (HyperText Transfer Protocol): HTTP is the World Wide Web’s underlying protocol that determines how messages are formatted and transmitted as well as what actions Web servers and Web browsers should take in response to commands. HTTPS is simply an encrypted version of HTTP.
- IP (Internet Protocol): The Internet Protocol (IP) is the method or protocol by which data is sent from one computer to another on the Internet. Each computer (known as a host) on the Internet has at least one IP address that uniquely identifies it from all other computers on the Internet.
- LoRaWAN: LoRaWAN is a low speed, but long-range and low power communication protocol. It is an open specification, so anyone is free to implement the protocol themselves on their own equipment. The RF spectrum used is also unlicensed, so anyone is free to roll out their own LORAWAN network.
- MQTT (Message Queuing Telemetry Transport): MQTT is an M2M/IOT connectivity protocol designed as a lightweight publish/subscribe messaging transport.
- NB-IOT: NB-IOT runs in the mobile telephone radio spectrum, and piggybacks on old, unused GSM channels, or free space between LTE channels.
- Sigfox: Sigfox is a proprietary network and protocol. It is typically used for remote meter reading but can be used for any remote data uplink. It is low speed and low power, but also long range.
- TCP (Transmission Control Protocol): TCP defines how to establish and maintain network communication through application programs that exchange data. TCP works with IP and defines how computers transfer packets of data to each other. It establishes and controls a connection on top of IP.
- TCP/IP (Transmission Control Protocol/Internet Protocol): TCP/IP is the protocol a device uses to access the Internet. It comprises protocols designed to establish a network of networks to grant Internet access to a host. It is also two layers of the most common four-layer stack used on the Internet.
- UDP (User Datagram Protocol): UDP is an alternative to TCP and is used mainly to establish low-latency and loss tolerating connections between applications on the Internet.
Explaining the IOT decision-making tree
The overarching question when commencing the development of your IOT product is whether your device is or will be IP-enabled. In this regard, the predominant networking stack is an IP stack which includes an application library to open or close connections to remote devices and can send and receive data between the remote devices. The four-layer IP stack is discussed in more detail below.
A typical use case is, whether your device needs to be connected and enabled to send or receive data via the Internet? This requires a connection via an IP-enabled device, either with its own IP protocol or via a secondary IP-enabled communication device which is discussed later.
1. Scenario 1: Your device is IP-enabled
1.1 The next question to resolve is can you implement and control the firmware yourself? Having a device that has an IP-enabled stack with full control over the firmware gives you a lot of flexibility to develop and build exactly what you want with full control down to chip-level, that is, software compiled onto the device and updating the firmware etc.
1.1.1 If you can implement and control the firmware yourself, the next consideration is whether you require frequent communication to and from the device such as sending commands and firmware updates. The details of this decision is discussed below.
1.2 If you cannot implement and control the firmware you have to ascertain if your firmware is already connected to a backend.
1.2.1 If yes, this would mean the device pushes data to a backend that the hardware manufacturer controls. You would need to pull the data from their backend using an API they provide. This could also be possible through a provided MQTT broker.
1.2.2 If the device is not connected to a backend, typically the device will publish data to a message broker online that you can integrate with to receive the data. In this case the protocol that is used is usually MQTT. Sometimes the device can, however, be set up to push data to an HTTP end point that you can configure on the device. The answer of which protocol to use here is therefore dictated by the hardware manufacturer, and you have to integrate with what is provided.
2. Scenario 2: Your device is not IP-enabled
If your device is not IP-enabled your options include LORA, Sigfox and NBIOT. With these protocols, your focus is on connecting things over fairly long distances and you are able to pull data into your own data pipeline via a bridge between your backend and the provider’s backend.
Unpacking branch one of the IOT decision-making tree
For ease of reference, branch one of the tree is colour-coded in yellow and, as mentioned above, concerns an IP-enabled device with firmware you can implement and control yourself. The next consideration of this branch is whether you require frequent communication with the ability to send firmware updates?
a) If yes:
Do you require reciprocal communication and real-time feedback? This approach runs on a publish/subscribe mechanism which means that nodes in this network can communicate with each other. MQTT that runs on TCP/IP is an example of this. This does not include a central server with clients; communication is directed at the broker that in turn transmits the data to the correct node. This means the frontend can communicate with and send commands to any of the devices. It’s an always-on connection that allows frequent communication with the ability to send commands and firmware updates to the device.
An example of this approach is smart irrigation to manage irrigation schedules and decrease water overflows, where commands such as when to switch on/off are sent to an irrigation and real-time data is returned for analysis.
b) If no:
Do you only require data to be sent to the cloud at regular intervals without any/minimal return communication (such as running a firmware update) with the end goal being to store large chunks of data? A practical example is a weather station that only needs to capture data and log it logically on an IOT service; in other words, send the data only one way. For this type of architecture, you will look at HTTP or COAP. COAP is semantically aligned with HTTP to allow one-to-one mapping to and from HTTP.
The benefit of this form of architecture is that it is fairly simple to use as there is only one-way communication, the client is in complete control. You can, for example, add an HTTP stack to your device, open firewalls for your HTTP etc.
The ultimate question is, therefore, which option do you want to use. It is a complex, multifaceted question.
