We’ve been thinking a lot about the stages that an IoT innovation goes through, from the light bulb over the head moment through to (hopefully) mass deployment. We’ve grouped these into five steps, each presenting a set of challenges and considerations about IoT connectivity. The decisions you make at each point about connecting the “thing” to the internet will intensify as you scale.
We’ve summarized in the image below the five key stages of an IoT project and the IoT connectivity considerations (Wi-Fi, LoRa, Satellite, LTE, NB-IoT, etc.) you’ll need to make along the way.
Every IoT project starts with an idea, not a purchase order for $100,000. Today, makers have never had it so good for quickly turning those concepts and “what-ifs” into something real. In many cases, a Raspberry Pi or Arduino will do the job fine. Connectivity also isn’t a problem at this stage. You could even use a physical cable to link the sensor to an IoT gateway such as the Dell Edge Gateway, although Wi-Fi is the more likely option.
In my time in the industry, rapid prototyping has become easier and cheaper. It used to be very expensive and a big commitment to create early-stage proof-of-concept devices; now, you can get a Chinese manufacturer to build in volumes of one. But once you bring the proof of concept from your lab to the field — whether that’s to an actual farm or to an investor meeting — can you really rely on the Wi-Fi signal? Depending on the environment, you might think cellular connectivity is your best option, so traditionally, many makers have you gone to their nearest mobile operator to buy a cheap SIM card.
Here’s where the questions start to come thick and fast, however. Once you have an idea of what you’re trying to build, will any of the connectivity options you adopted at the earlier stage still be with you as you refine your original idea? Will you be able to source SIMs reliably at higher volume? Will the cost model of buying retail SIMs work with a 500-unit-a-month deployment? This step is where you’ll encounter issues like security, authentication or authorization on your connectivity. Can your chosen connectivity handle these issues reliably?
By design, IoT devices are constrained — that term has a specific meaning which implies limited processing power, storage and bandwidth. Where you plan to physically deploy will be a factor: if you aim to put a miniature computer on every streetlight, it isn’t practical to visit every one of them every Tuesday to install a patch. Or, if you fit a sensor in the road which is then embedded under concrete, you only have one time to get it right.
So, what type of connectivity are you going to embed in your service as you deploy it? This isn’t a trivial question. If you’re serious about building an IoT innovation to operate on a global scale, it makes sense to think about IoT connectivity from the very start. Otherwise, you’re stuck on the treadmill, continually solving the same problems over and over again as you progress through the five steps as outlined here. SIMs from the EU will not roam in Saudi Arabia, and a U.S. SIM won’t necessarily work in France. In some of the biggest growth markets, Saudi Arabia, Turkey and Brazil, governments don’t permit global or permanent roaming. We’ve seen similar restrictions in places like Cambodia, Indonesia and Myanmar. So if you want to ship your “thing” all over the world, you’d better be sure at the idea, prototype and iterate stages that you’ve built in connectivity that works for your global application.
The assumption we’ve made all along is that connectivity is hard. Simply putting your devices on Wi-Fi doesn’t give you guaranteed service, besides the fact that connecting constrained or low-power devices to the public internet is not a good idea. As we like to say, there’s nothing quite as complicated or dangerous as simple connectivity.
Fortunately, technological advancements have come to our rescue yet again. In the old days, you had to pay in advance for technological capacity that you guessed you might need to use months from now. Cloud computing services like Salesforce and, later, Amazon Web Services or Microsoft Azure completely upended that model, giving enterprise-class software tools to smaller companies who only had to pay for what they used.
That same model now applies to connectivity, to let you link services and “things” over the internet at industrial scale but at volumes of one (idea), so you can start small and then flex your network as you go through the subsequent steps (prototype, iterate, deploy and scale).
When considering what technology to enable your IoT project scale the network connectivity you need to look to the models developed for infrastructure as a service and computing elasticity. Look for technologies that can automate the “declaration” of an IoT network topology via simple API calls and that remove the manual, time consuming bespoke steps. Consider technologies that can aggregate different bearer networks so that you can mix and match multiple different connectivity types, and avoid lock-in from one single communication service provider.
For more information on this topic read our ebook on IoT connectivity.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.