Keith O’Byrne, head of solutions, Asavie
Keith O’Byrne, head of solutions at Asavie, discusses why connectivity needs to be at the heart of IoT projects.
Everybody’s talking about the internet of things (IoT), and it’s not hard to see why: who wouldn’t be drawn to the possibilities of smart cities, connected cars, or wearable health sensors? Just look at Fergus O’Dea’s recent piece on IoT in healthcare, and this is to name just some of the potential use cases.
Until now, the industry conversations – not to mention the hype – have mostly focused on the devices gathering the data, the servers crunching it and the apps and analytics that could result. That leaves a huge gap in the middle, though, and it’s the glue that binds the bigger IoT story together: connectivity.
Things were simpler in the days of machine-to-machine (M2M) communication, which was the forerunner of what we now think of as IoT. Back then, when industrial control and monitoring systems were starting to become automated, their communication was via closed channels on the user organisation’s own network.
IoT, on the other hand, is designed to be open – all the better to be able to take massive amounts of data from large numbers of distributed sensors, and aggregate it to get really powerful insights and outcomes. By its nature, IoT stands on the shoulders of M2M, but it’s a lot more complex in nature.
The IoT ecosystem
So what does a typical IoT ecosystem look like? We’ve found it helps to visualise it as four quadrants of a circle.
Starting at the bottom right, we have the collection of information from sensors and devices such as the Dell Edge Gateway and Firmwave Edge IoT sensor platforms. Let’s go anti-clockwise to the collate part, which is where all of this data gets analysed in platforms such as SAP HANA and Dell Statistica. Next, in the top-left quadrant, we have the control element – the IoT platform (ThingWorx, Kore) that gives the IoT project sponsor the ability to manage the data, devices and the network.
Finally, we get to the connectivity.
Cracking this challenge with the internet of things is actually a surprisingly difficult problem. As Alan Woolhouse describes in his recent post about the great connectivity race, there are myriad standards relating to low-power short-range technologies and long-range cellular technologies. There are strong discussions about alternatives to cellular, and LPWA networks are a good alternative in some scenarios. In an industrial IoT setting, depending on where the sensors will be deployed, you could be looking at a wide range of possible networks, from 2G, 3G and 4G, to LPWA networks (LoRa, Sigfox etc.), satellite and possibly even fixed-line connections.
There is no right or wrong answer to this connectivity race but, depending on the use case, some networks are more suitable than others in terms of coverage, bandwidth, reliability or cost, among other factors
How to get connected
There is no right or wrong answer to this connectivity race but, depending on the use case, some networks are more suitable than others in terms of coverage, bandwidth, reliability or cost, among other factors.
There are a lot of prototyping and early-stage ideas happening in IoT, and that activity has been christened ‘the maker community’, covering anything from a hobbyist to a start-up to project teams inside some of the world’s biggest organisations. The goal of a prototype is, typically, to validate technical and commercial assumptions, and then be able to grow. An appropriate connectivity choice in the early stages of a project removes uncertainty and is a key factor for future success. And this choice must be able to scale with the project, without compromising the security and reliability of the solution.
For example, as things stand today, if a maker talks to a carrier about getting connectivity for an IoT project, they’ll be given a SIM card similar to the one you get in a smartphone. That SIM might be perfectly good for use in an iPhone but that doesn’t necessarily mean it’s suitable to be deployed in a moving delivery truck that has to talk to the warehouse. There are a whole host of issues that need to be resolved with this model, not least of which are security and billing concerns.
From traffic signs to energy power plants to baby monitors (that are on the internet if you know where to look), there’s plenty of ammunition out there for people who have used inappropriate connectivity for their IoT applications to get burned.
Consider the use case
There are many different use cases emerging for the IoT and the different network connectivity options that might be considered appropriate.
An appropriate connectivity choice in the early stages of a project removes uncertainty and is a key factor for future success
One possible use case would be monitoring. It’s important, but probably not a mission-critical job, and it applies to several of the possible scenarios outlined above. You have a low-power sensor or device making regularly timed, low-volume updates or transactions. As a result, a low-bandwidth connection is probably sufficient in this environment. Perhaps it has to allow bi-directional flow of data because you’re probably going to want – or need – some degree of remote management and configuration of your endpoint device.
Next, let’s consider payments transactions like those you find in retail. This retail business model means the transaction volume will probably spike and dip in any given day, so you’ve got to allow for varying usage patterns and much greater frequency. What’s more, each transaction involves larger volumes of information passing from the devices than in our previous example. That means you’re going to need higher bandwidth. In this case, a bi-directional flow is probably a must for remote key management or software upgrades when a security breach is found. In retail, sales are the lifeblood of the business, so a crucial difference between this and our earlier use case is that a connectivity failure is mission-critical.
Our third use case adds a further layer of complexity. If we think about media or content passing across a network, it needs even higher bandwidth than in the other examples. There could well be digital signatures involved and chances are there will be some element of payment transaction. As before, the frequency of transactions will vary and, again, reliable connectivity is a must.
So, which connectivity option do you choose?
There’s plenty of ammunition out there for people who have used inappropriate connectivity for their IoT applications to get burned
The connectivity conundrum
On the face of it, you’ve got lots of choice. There’s NFC, cellular and Bluetooth for starters. LoRA will get you 12 bytes a week but the battery lasts for 12 years. Meanwhile, getting on to Wi-Fi is challenging – can you get a device to reliably sign on to a hotspot for the next 15 years? LoRA ticks the low power box but it’s also extremely low volume, and there’s very little transportation to devices.
I believe cellular connectivity can address a lot of the issues that are starting to emerge in some of the use cases like the ones we’ve described here. There’s a lot of life left in earlier networks like GSM, 3G and 4G, and that’s an important consideration.
What has perhaps deterred some of the maker community from factoring cellular connections into their thinking has been the difficulty of accessing the network. Creating simple and flexible IoT connectivity solutions for end users is a complicated process for a communications service provider. Unless you’re a big corporate with budgets to match, it has proven hard to get an audience with large mobile carriers to make the case for special dispensation to test new projects.
So, if you’re at an early prototyping stage, it soon becomes prohibitively expensive to do things like creating a private network or pushing software patches out to endpoint devices over the cellular network. Depending on the type of devices you’re using – and it’s often multiple types – then you might also find you’re not just dealing with a single network.
There’s a lot of life left in earlier networks like GSM, 3G and 4G, and that’s an important consideration
The challenge lies in removing the guesswork from the connectivity conundrum for both carriers and end-user enterprises so that the former can enable the latter to securely scale their projects from one to many connected devices and accelerate the time to market. Carriers must differentiate their IoT connectivity propositions from the competition, while the IoT maker needs to enable connectivity between devices, and also to aggregate connectivity across diverse networks in a way that makes it straightforward to manage.
As head of solutions with Asavie, Keith O’Byrne consults with carriers in the US, Europe and Asia on next-generation IoT and mobility solutions. With over 18 years’ security and IT experience advising global organisations on their infosec posture and network design, O’Byrne represents Asavie on the Industrial Internet Consortium and is a regular guest speaker at industry events such as IoT World, ThingMonk and Industrial Internet of Things.
