As you develop your idea for a smart, connected thing you will quickly realize the "connected" part of the design will really drive how your IoT application will take shape. The connection between your device and you affects the whole model of how your application needs to function. Connectivity determines how much traffic can be sent, how far can it be sent, what other devices does the IoT device talk to directly. How you answer these questions will shape your project in form, function and cost. Let's look at why.
Communications is a challenge for any information technology related project, not much is accomplished today without involving it. But, IoT has an additional set of communication challenges and operating characteristics. Limited processing power and memory, small size, battery life, and mobility all increase the communication challenges unique to IoT projects.
There are two basic connection models for IoT projects: always-on and intermittent. Certain communication technologies impose a connection model; Bluetooth imposes an intermittent connection model unless you intend to leave your tablet or phone next to your IoT devices. The always-on model is available when using connection technologies like WiFi where a connection relies only on standard and available infrastructure like your Internet gateway (cable or DSL modem).
While always-on may appear better, consider an application where no always on technology is available or allowed. Yes… not allowed, maybe your organization disallows IoT devices to connect to the company network. In both of these scenarios, an alternative would be an intermittent connection while a hand-held tablet is in proximity to the IoT device. This “passer-by" connectivity would present other IoT project design challenges but it addresses the network availability and enterprise security concerns that may exist.
One significant drawback of intermittent connection models is the inability for devices to notify or alert central application of significant events occurring at the IoT device. A disconnected device can sense a critical issue or alarm condition, but without communications it cannot summon a response. There are hybrid approaches available with some technologies like cellular, where a device can “phone home”, but as we will discuss later in this article cellular has drawbacks primarily due to operational costs and ease of implementation.
Usually IoT platforms, including iotQi, can support disconnect\reconnect as a part of normal operations, but intermittent connectivity model applications will need to be tailored to accommodate connectivity changes in unique ways and will add complexity to the IoT device. Consider the need for store-and-forward capabilities, where offline data can be cached for the next available connectivity session. This requires additional project capabilities such as SD storage, increased hardware and software costs. Additionally, your IoT device software will need to be able to support detection of connection establishment so that cached data can be forwarded to your host application.
For applications that store data on the Internet, some communication technologies will impose the requirement for an intermediary or gateway; Bluetooth, LoRa and SigFox are technologies that generally impose this requirement. This need arises from the fact that cloud and Internet connections are inherently TCP/IP based and these technologies do not support IP protocols without adaption.
If you need to connect to a phone or tablet, maybe Bluetooth will decrease your project complexity with the widespread availability of Bluetooth on almost all smart-phones and tablets. Where your host application resides is a consideration that goes together with your application’s peer model.
Outside of Bluetooth some piece of infrastructure will be required for your IoT device to communicate with your host application and the world. WiFi will need an access-point (AP or router), LoRa and SigFox will require gateways.
The throughput of IoT communication technologies vary dramatically. In general though, IoT does not need a lot of bandwidth. Typically, with IoT your bandwidth demands will be measured in KBPS (yes… kilobytes per second). So, technologies such as WiFi and full-bandwidth LTE (cellular) are not usually included in an IoT project solely for their speed capabilities.
Existing IoT focused communication technologies are attempting to solve other design hurdles such as battery life and by limiting throughput these other design constraints can be satisfied. Emerging technologies such as NB-IOT and LTE-M are also assuming limited bandwidth to save energy in small, lower power devices.
There are “data intensive” IoT applications; consider the smart doorbell where you can screen visitors from anywhere. This application clearly relies on some video and audio capabilities; even with compression and minimized frame rates certain communication technologies are not going to work well, or may not work at all, for application such as this. Look at this applications profile: static location (home's front door), needs high speed, needs Internet capability (your are anywhere other than your front door) = WiFi.
Security and Interface Options
Security awareness for IoT applications is growing, this is a very good thing! Implementing security in IoT is a continuing challenge, maybe this is why we have witnessed issues in the press about IoT security shortcomings. The easiest approach to IoT security is to skip implementation, this is not an approach we support at LooUQ.
A key constraint on security implementation with IoT is the processing power available on development devices and embedded platforms. The Arduino family by example has only a couple devices capable of processing SSL encryption; the Arduino devices supported by our iotQi platform all offload SSL encryption on to the WiFi interface hardware. Without this functionality in the Atmel WINC1500 chipset (the device behind the Arduino WiFi101 library), iotQi could not support the Arduino family since LooUQ requires SSL for device connections.
The ability for either the communications interface or the IoT device to support critical security protocols may drive the IoT device selection. To support wired Ethernet you are moving SSL security to the IoT device. For this reason, LooUQ iotQi supports wired Ethernet only on Win IoT devices like the DragonBoard and Raspberry PI. There are wired Ethernet interfaces with embedded SSL processing (Digi.com) however these interfaces can double the hardware costs for an IoT solution.
Where you host your central application is another important consideration for which communications technology you select. Phone or tablet based applications may favor Bluetooth because of its widespread availability on those platforms and by choosing Bluetooth for your tablet based IoT application all required communications may complete. If you still must forward traffic to the Internet, you can use the tablet’s IP capabilities to act as a gateway. With other technologies (WiFi), your tablet based application will need to converse over the Internet to get to IoT devices directly connected to the Internet.
If your application is enterprise or web-based local processing by a phone or tablet may not offer any advantage and could complicate your project’s design by adding a piece of code running on the tablet. Enterprise and web-based applications generally favor always connected, non-gateway technologies such as WiFi.
The location of your network and your IoT devices are going to be a key constraint on your communications technology selection. Most IoT projects implement some form of radio based communications, so the transmission distance is going to be the key in determining whether the technology can function for your project.
Bluetooth, WiFi and LoRa give your project the ability to span increasing distances; from feet to kilometers. Bluetooth was designed for connecting peripherals and works for ranges up to about 50 to 75 feet. WiFi distances are greater (typically up to 100-200 feet) and with multiple access points can span enterprise campuses. To go further, LoRa and SigFox stretch distances up to 10 km to 20 km outside and to over a km inside structures.
To go further, you will need to leave your infrastructure behind and implement technologies based on open, shared communications facilities such as cellular providers or public networks such as The Things Network (LoRaWAN). IoT is pushing cellular to be new and old simultaneously, by introducing new IoT specific low-bandwidth, lower cost LTE-M in North America. Elsewhere NB-IOT and GSM 3G are adapting the existing cellular infrastructure to support IoT project profiles.
Full cellular modems exist for applications requiring the most flexibility for device locations, but keep in mind that each device is a separate charged “line”, adding up these costs may break your project’s budget. Also, adding cellular to a data driven IoT application usually involves more integration development on your part.
Medium throughput (less than WiFi, but higher than LoRa)
Data is secured over the Bluetooth link
Will likely required gateway functionality unless application is limited to a tablet or similar device
Interface hardware for IoT devices is inexpensive and readily available
Security is frequently handled by interface hardware (SSL offloaded to interface)
Inexpensive interface modules available for most IoT device platforms and increasingly built-in to newer devices
Can be challenging to provision many devices with SSD and WEP\WPA keys
Low throughput, typically 5-20 kbps
Long distance, typically at least 1 km and up to 20 km with ideal conditions
Requires gateway technology to connect in most enterprises
Data security relies on the application developer
Inexpensive and available radio modules are available, software libraries exist for common radio modules on the market
Many module manufacturers but only a single radio chip producer (SemTech)
Many of the same characteristics of LoRa
Slightly longer distance than LoRa
Interfaces are not as readily available as LoRa and are more expensive
Multiple radio manufacturers operating, licensing SigFox endpoint technology
A complete network stack running on top of LoRa radios
Includes security, addressing and gateway specifications
Availability based on attaching to public networks such as “The Things Network” (TTN)
Governed by the LoRa Alliance
Simple LoRa radios cannot be attached without implementing the security and other functionality in the LoRaWAN specification
Implementation of standard cellular technology for IoT devices
Generally higher cost, particularly regarding month service subscription fees
Some GSM services can be purchased from niche providers at lower costs than typical cell line charges
Data connectivity requires application developer efforts to implement connectivity
Future technologies, just emerging
Cellular networking technologies built specifically for IoT applications
LTE-M for North America, NB-IOT for Europe
No ready to use commercial modules available just yet (2nd Quarter, 2017) but expected in 2nd half of 2017
It Is All a Balancing Act
No matter your application, your devices or your environment, designing your IoT project’s device communications is a balancing act. In almost every regard, optimize for one characteristic and others characteristics will suffer. Do your homework, ensure you understand your project’s use cases and choose wisely.