December 7, 2015

It seems like there is a new whitepaper every day describing, explaining and trying to simplify the Internet of Things.  I am guessing if you’re reading this, it isn’t the first time you’ve heard of the Internet of Things, so I’ll spare you the lofty introductions with the compulsory reference to a market report with the predicted number of IoT devices by 2025.  

The purpose of this post is to talk about your hardware and network choices as an IoT developer now and down the road.

What exactly is the Internet of Things?

I love Verizon’s concise executive summary of the Internet of Things in their State of the Market, IoT_Networks“The Internet of Things 2015” – “The least common denominator of the IoT is a network of sensors which autonomously uploads actionable data to the Big Internet.”  Let’s save the CAGR forecasts of connected devices, revenues, terabytes of data, etc., for another time.  

But just know this:  the Internet of Things is the Internet’s next big thing.  From cloud networks to cellular modems to antennas and batteries, the IoT will draw upon every facet of the wireless ecosystem.

As an RF guy, my interests are in the nitty gritty details of the sensors and the physical (PHY) and MAC layers of IoT networks.  All those sensors talking to the same network!!! How do they do it?!  But allow yourself to imagine your neighborhood, the roads on your commute to work, the pipes that deliver your water, the parking garage at the airport, or the soccer field where you play pickup games on Wednesday, all full of sensors delivering data which can be used to simplify or enrich your life.

It’s fun to get out of the hardware world and start imagining what can be done with all that data.  For me, it gets exciting when I think about accessing the data from one particular sensor which I can locate on a map.  Location awareness will transform the Internet of Things from useful to game-changing.

What exactly is the network?

Let’s come out of the cloud and talk about the hardware details of the network.  Going back to the simple description of the IoT: autonomous sensors collecting actionable data and uploading them to the big Internet.  There are countless types of data we might want to collect, most of which becomes more useful with a higher sample rate i.e. greater density of sensors.  All those sensors require a wireless connection to a gateway network (the other alternatives are to run copper or use some other wireless communications mechanism: blinking LEDs blasting Morse Code? Acoustic?).

The gateway network is the last stop before the Internet.  Examples of gateway networks include a cellular network, a WiFi network, or a proprietary network over unlicensed spectrum.  Other than the actual sensor and the data being collected, the biggest differentiator between IoT sensors and networks is the actual mechanism by which that data gets to the Internet through the gateway.  As an IoT system developer or integrator, your choice of gateway network has more impact on network Capex and Opex than any other decision you make.

Network Choices

Your choices of IoT sensor as related to the gateway can be grouped into the following categories:

    • Unlicensed, non-proprietary networks – e.g., WiFi, Zigbee, Bluetooth
    • Unlicensed, proprietary networks – e.g., LoRa, SigFox

Let’s talk very briefly about each of these network choices.

Unlicensed and Non-Proprietary Networks

Unlicensed non-proprietary networks use links such as Bluetooth, Zigbee, Xbee radios or WiFi to get data from the distributed sensor nodes to a gateway hub, and from there to servers via one of many choices where the data can be accessed remotely.  The idea is that the sensors rely on off-the-shelf wireless modules and communicate over unlicensed spectrum in the (mostly) 900 MHz, 2.4 GHz or even 5 GHz bands.

These networks enjoy existing economies of scale and the availability of both hardware and software reference designs (APIs) to expedite deployment.  The downside about unlicensed and non-proprietary networks is that – as the network developer or integrator – it is your problem how you get data from the gateway hub to the Internet.  Who maintains that WiFi network?  Whose expense is it to maintain a Zigbee or Bluetooth hub to collect hundreds of data points and pipe it through an enterprise network?  With non-proprietary networks, what you save in module costs you may end up spending in network maintenance costs.

I consider unlicensed and non-proprietary networks one of the ‘now’ categories of IoT networks.

Unlicensed and Proprietary Networks

There are a handful of companies in the US and around the globe who are deploying their own networks – i.e., their own towers with sensors designed to talk to those towers.   These networks still shuttle data over unlicensed frequency bands.  The advantage of these networks is that as the deployer of a sensor network, you don’t have to maintain the gateway and hubs.  Some examples include SiGfox (900 MHz), LoRa (900 MHz) and Ingenu (2.4 GHz).  These networks are in the adolescence of their rollout in the U.S., and so they are what I describe as on the one-year horizon of the Internet of Things.  Since these proprietary networks exist on unlicensed spectrum with power limitations, then the amount of data they can handle, the rate at which they can handle it, or the range over which they can transport it are competing parameters.  

For example, SigFox’s network optimizes range by employing databursts at power levels that are higher than normal short range 900 MHz radios, but the packet sizes are miniscule (12 bytes per message and up to 140 messages per sensor per day).  

The advantage? You don’t have to maintain that network, and presumably the radios (and thus the sensor Capex) are cheap since data and power draw are at a minimum!

Licensed Proprietary Networks

A licensed proprietary network is a fancy way of describing sensors using cellular modems and modules to connect to commercial cellular networks (Verizon, AT&T, etc).  This means a cellular connection to each sensor.  The current state of cellular IoT networks relies on mostly 2G and 3G modules, since LTE modems are still rather pricey, and rather power hungry for low datarate IoT sensor applications.  2G+ modems are perfect for low data applications (note AT&T’s shutdown of their 2G network at the very end of 2016).

The advantage of licensed proprietary networks is that you don’t have to maintain the network.  They are also a nice intersection of datarate and maximum range, as a result of using licensed spectrum without severe transmit power limitations.  The downside is that you will generally pay a premium for cellular modems as well as encounter the highest power requirements.  FierceWireless just published an interesting read about AT&T’s growth of cellular-first IoT devices.

The Five Year View of IoT

The five year view of the Internet of Things is dominated by licensed proprietary networks.  In fact one of the driving inputs to the genesis of 5G requirements is native support for the Internet of Things.  There are a few industry developments which will shape the future of cellular IoT deployments:

    • LTE-M / NB-IoT / clean-slate IoT – the idea is to refarm a sliver of 700, 800, or 900 MHz spectrum (depending on location) for dedicated cellular IoT use. (Read: Light Reading – Narrowband Cellular IoT Offers Clean Slate).
  • Potential opening of old TV stations in the 600 MHz band for dedicated IoT use – Designing small sensors with 600 MHz radios and, more specifically, 600 MHz antennas and RF front-ends, will be an opportunity.  We wrote about the 600MHz auction here.

Certain kinds of future IoT networks will rely on a hybrid of sensors on unlicensed networks with gateway hubs that connect to the Internet via licensed networks.  These are appropriate where licensed networks just don’t make sense due to the location of the sensors.

While there are many inputs to a complicated engineering and financial model of an IoT network, consider the following as key technical drivers which impact the capex and opex of your network:

    • The datarate and data payload requirements
    • The physical range between sensor and gateway, more broadly categorized as the complexity of the RF channel
    • The expected number of sensors talking to an individual gateway, and the extent of the overall network deployment
  • Sensor power requirements

Interested in digging deeper? Check out a few of the articles below.

Building an IoT device? We can help. Click here for antenna design info.