Hero Pattern
May 23 2016

Choosing the right mobile communications technology for IoT

  • Deloitte Digital
As an IoT architect, defining your device context can help you choose the right mobile communications technology for your IoT application.

How should IoT devices communicate with the web?

Devices that independently gather data and report back to the cloud while roaming free in the world used to be science fiction, but now they represent a major piece of the Internet of Things (IoT).  The sensing and actuating that these devices do are the sexy part of the IoT story, but they have to talk to the cloud to do their job. As systems architects it is our job to design functional, reliable, and cost effective solutions, and in a mobile, cloud-connected application the choice of communications technology can have a huge impact on all three. If you do a web search on “mobile IoT wireless standards” you will have to sort through a sea of acronyms and technical papers written by companies who claim to be the “leaders in the space.” The reality is that there are only a few technologies that provide mobile connectivity for IoT devices – so what are they and how do we choose the right one?

That’s right—machines use cell phones to talk each other just like people do. Because cellular networks were invented to allow people to talk to each other, these networks have great coverage where people live, but not so much where they don’t. This people-bias also brings baggage: cellular technology changes rapidly as older technologies get phased out to make room for newer, faster networks to support web-surfing and streaming video.

Sounds really cool doesn’t it?  Yes – it is! Today you can actually build a device that talks to a satellite ORBITING THE EARTH and get an internet connection. Satellites can give your device truly global coverage, but it comes at a price – both monetarily and in design constraints. Because the satellites are so far away their signals are weak and dropouts can be a problem depending on where your device is deployed. 

Low-power wide-area networks (LPWAN)
LPWAN technologies are relatively new and purpose-built for IoT – they are growing up together like siblings. These networks are designed for low-data-rate, long-battery-life applications and allow devices to communicate over long distances using very little power, all while providing carrier-grade reliability. LPWANs are not widely deployed yet and there are competing standards with no clear leader, so choosing one can be a gamble if you don’t fully understand what you’re signing up for. 

Define the Context

The right communications technology is critical to a successful IoT solution, so how do we choose? We first need to define the device context – the critical aspects of the application and device requirements that the communications technology must support. Like most things in life it helps to break the problem down into manageable pieces. 

Mission Requirements
Let’s start with focusing on what the device has to do and how it has to do it. Constraints involving size, user interface, power availability, and location must all be supported by the technology used to talk to the cloud. If your device has to be the size of a golf ball with a battery that lasts two months, the communications technology has to help make that happen.

  • Physical size – How small must the device be?  Communication technologies such as cellular and satellite have antenna and battery requirements that directly impact how small a device can be, whereas LWPAN technologies are specifically designed for small size.
  • Power consumption – How much power can the device consume? Consider whether the device is battery powered or if power is readily available. 
  • Data rate – How fast must data move between the device and the cloud to meet latency or response-time requirements?
  • Data volume – How large is the data moving through the system? Consider not only device-to-cloud data, but also configuration data coming from the cloud to the device and over-the-air (OTA) firmware updates.
  • Device Access – How easy is it for your cloud application to initiate contact with the device?  Does it have to wait for the device to wake up and initiate a connection, or is the device always reachable?
  • Network reliability – How reliable must the communications network be? Consider how tolerant the system is to spotty network connections and dropouts within a particular region.
  • Regional coverage – How mobile is mobile?  Will the device need to have connectivity worldwide or only within a small region?  Is the region small enough to deploy your own network infrastructure?
  • Obsolescence – How long does the device need to remain in the field? Consider the risk of the communications technology becoming obsolete during the life of the device.


Cost Requirements
Now that the functional context has been defined we need to consider the business side of the application. How will our technology choice fit into the overall business requirements from a cost standpoint?

  • Manufacturing – How expensive is the device to manufacture, including materials, assembly, and test costs?
  • R&D – How much will it cost to develop the product from a man-hour, equipment, and prototyping standpoint?
  • Deployment – How expensive will it be to deploy any required infrastructure? Satellite networks won’t have deployment costs since the satellites are already in orbit, but LPWAN technologies may require deploying hardware to establish coverage.
  • Data – How much does it cost to transfer data?
  • Sustaining and support – How much does it cost to support the device?  How often will a technology refresh be required? Consider customer support when problems arise, customer/device on-boarding and configuration, dealing with network outages, etc.