How do you make IoT deployments work? I’ve been asking myself this question over and over recently trying to understand both how to enable IoT for our partners and customers in general and how Peplink devices fit into IoT specifically.
Focus on Business Problems First
The answer of course depends very much on who you are speaking to. To make IoT deployments work from a business and commercial perspective you need to focus on business problems and how they can be fixed by IoT solutions.
As yet most enterprises haven’t thought out how to use IoT or what it means for them – they need to identify and analyse specific workflows and processes that can benefit from IoT first and that is quite a specialist skillset as it needs business analysts, and software developers and network engineers and electronic designers.
Use Existing IoT Solutions
Lets face it, in house development is time consuming and risky, most enterprises want and need to outsource these projects (or at the very least elements of them) to specialist IoT consultancy companies who can help build custom solutions, or they need to buy into existing IoT services (designed for narrow verticals) that a number of IoT service providers are currently offering. Things like electricity meter monitoring, vehicle telematics, building security and HVAC systems providers who have already done the hard work and built end to end solutions based on custom built sensors, cloud services and management platforms.
Whatever the approach though, everything starts by focusing on specific workflows in the business, workflows that are messy or time consuming and always ones with high operational costs and then working back from those to see how an IoT solution can help.
From experience what I am seeing is the beginning of this. Businesses who identify workflows that would benefit from IoT that then go to market and find an IoT solution off the shelf that’s the closest fit to their requirements.
Combine Multiple IoT Stacks
It takes a lot of time and effort to build a great commercial IoT platform as there are so many moving pieces needed to make it work. As such no commercial IoT provider (yet) can offer a single silver bullet for all a business’s IoT needs. Instead each IoT provider tends to limit themselves to a small number of sensor types, methods for those sensors to communicate, and a highly focused cloud service and management platform that fulfills the requirements of a specific workflow or activity.
In my house for example, I use Hive to control my central heating, Cloudview to manage my CCTV, Smartbel in combination with OpenVBX to monitor my front door, OpenEnergyMonitor to keep an eye on power usage and InControl2 combined with freematics in my vehicles for tracking and monitoring as well as a whole host of arduino, ESP8266 and Particle MCUs for custom DIY monitoring and control.
Integrate them at a platform level
Each of these IoT solutions is completely independant of the other, using different communication technologies, and cloud services to function. Each has their own smartphone app and/or web management platform that I use to manage them individually and then I link them together using 3rd party services like If This Then That, and then Zapier which provide the platform integration I need to make them work together.
In the same way, IoT in the enterprise requires the integration of all of these separate IoT platforms that are solving (or providing the information needed to solve) key operational challenges in the business. but additionally, they need services that create a link between existing back office systems and the new IoT platforms they are deploying.
Back Office Integration Happens At the Top of the stack
We’re still in the very early days of IoT, with only a small number of enterprises currently using any kind of IoT solution at all and even less who have successfully integrated multiple IoT stacks with their back office systems. However eventually I think that most will end up with a collection of different IoT Stacks used for specific functions within their business, and will mash all of these platforms together with management platforms higher up the stack to realise the benefit of all of this additional data and bridge the gap between their back office and field based activities.
I’m confident that the real time business intelligence and overall system awareness that IoT can bring will ultimately drive operational costs and subsequent service pricing down – which will then improve customer satisfaction and increase sales. I’m also sure that those enterprises that leverage IoT successfully will have an unfair advantage over those that don’t. The big question for me as a network engineer is how will enterprises cope with the additional complexity and security risks multiple IoT stacks will bring to their network infrastructure and how will they build, deploy and manage future networks that need to support this level of complexity?
Complexity Hurts
Enterprise IT departments already have experience of integrating complexity in their networks today, particularly those that support multi-site deployments of real-time services (like VoIP, HD video streaming, remote desktops etc) and networks that support thousands of users connecting from multiple locations over corporate and home VPN connections. However that experience tends to be from using a comparatively standard (and relatively small) set of tools and vendors.
The benefit of intentionally limiting the number of tools of vendors is obvious – reduced training, simplified centralised management and standardised replicated deployments that can be made secure by design, are all ingredients in a reliable, secure efficient network infrastructure.
IoT Adds more Complexity to everything
IoT on the other hand requires the use of a wide range of sensors and devices and things – logically separate but nethertheless mixed technology stacks with their own management and monitoring platforms. And there will be lots of them. Every article on IoT written today says there will be 10’s of Billions of IoT devices in the next decade (Gartner Says 21 billion by 2020).
Some of the issues around supporting such diversity are mitigated to a certain degree by combining multiple end to end solutions since those solutions should provide adequate management and monitoring of the range of devices in their scope and provide easy interfaces for enterprise IT staff to work with and support them. In fact I would expect most of the IT systems for these solutions to be in the public cloud and managed by the IoT service companies and providers themselves anyway, so from an enterprise datacenter perspective little will likely change – just the need to support the in house enterprise management platform for back office integration.
No the real challenge here I think – and the one I am most interested in, is how to connect and secure sensor networks in the field and those deployed at your corporate locations.
IoT Security Risks are very real
If I came to you or your enterprise IT team and said I wanted to install a couple of hundred (or even thousand) of low cost network connected devices on your network – devices that collected data that was important to you and your customers and will be directly connected to internet services and not to worry about security because I have that under control – what would you say? I would hope and expect you to say no – especially if your business was a bank, or a hospital or a government organization. You wouldn’t leave network security upto me, you’d want the devices to be isolated from your core network, and kept away from your systems.
Yet many IoT solutions on the market today have WiFi enabled sensors, actuators and internet access gateways that are designed to do exactly that – connect to existing enterprise networks for internet access and local sensor to sensor communication.
IoT Sensor Network Isolation Is Key
One way IoT solution providers mitigate those risks is through the use of alternate dedicated network connections, it’s a tried and tested approach that has been going on for decades – think of industrial building control systems (heating, air conditioning and power management) that used to connect via dedicated physical dial up lines and now tend to have dedicated private fixed line internet circuits like DSL and Fiber.
The modern – more agile approach, uses the proliferation and general availability of cellular connectivity to provide that network isolation, with MVNOs offering secure private APN’s accessed over mobile operator networks to provide an air-gap between IoT sensors and the local network infrastructure. Additionally new Low Power WAN (LPWAN) technologies (like LoRa and Sigfox) are also being deployed to provide ubiquitous metro coverage to reduce the amount of power required by IoT sensors to communicate, creating city wide networks of IoT sensors that can run for months on a single charge (and potentially forever with solar backup).
These approaches to network isolation are all technically viable today – especially cellular connectivity since it is available just about everywhere in the developed world, and the Low Power WAN technologies will likely fit those deployments that they are being designed for like a glove tomorrow – when they are more readily available
Cellular Connectivity Is Going to Win the remote connectivity race
In my view though, cellular based connectivity (and in particular LTE-M the emerging low power variant) is likely going to win the IoT connectivity race for remote and isolated deployments, since as an already incumbent and proven connectivity technology it is available immediately making it a low risk approach to building IoT networks today. In fact, I would expect nearly all IoT sensor networks in the future to have key elements connected via cellular, if not the actual sensors themselves then potentially internet access gateways in the locality of the sensors that bridge whatever low power WAN technology stack the sensors are using to the internet over cellular.
IoT Sensor networks need reliable secure Internet Connectivity
Whichever way your IoT sensor networks connect to the internet , whether individually using onboard cellular modules, or indirectly as groups via an internet access gateway over local wifi or ethernet connectivity – that Internet connectivity needs to be reliable and secure.
It also needs to be ubiquitous and enable the easy deployment of IoT sensors everywhere using whatever connectivity is available- in farmers fields to monitor crops, in vehicles to monitor driver behaviour and cargo, in buildings and city wide deployments to monitor heating and cooling systems, electricity usage, the stock levels of vending machines, and air temperature and quality.
IoT Sensor networks need managed internet connectivity
All of the largest IoT deployments I have seen so far have required two key elements to be successful, remote management and monitoring – for both sensors/devices and their connectivity.
For IoT sensors that use onboard cellular connectivity, managing the SIMs themselves (their activation, tariff profiles and cancellation) and their associated live data usage is very important, both operationally and technically.
Operationally, knowing exactly how much data is passing over the cellular network provides early indicators of configuration issues, and acts as a commercial capacity planning tool, since at scale, cellular data tends to be aggregated across estates of sim cards / devices.
SIM card and bandwidth monitoring and management is a specialty of MVNO’s – all the best ones have advanced management platforms capable of showing and reporting SIM card status and bandwidth usage across an estate – with additional features and interoperability with other systems added continuously.
What about Wi-Fi enabled and wired IoT Sensors?
If your IoT sensors are wifi enabled, or physically cabled to the local network infrastructure (perhaps with a LPWAN to ethernet bridge) you need to manage their connectivity at the internet access device – this is typically an ISP gateway/router.
In exactly the same way as the cellular connectivity on enabled sensors needs operational and commercial management, so does the connectivity provided by internet access devices. Additionally those devices need to provide security in the form of network isolation too.
A popular option is to use wifi and wired sensors in combination with a cellular enabled internet access device, so understanding and planning your IoT network topology in combination with your monitoring and management requirements becomes even more important as your networks get more complex as more sensors are deployed.
The challenges with embedded Cellular and LPWAN connectivity
IoT sensors with embedded cellular and LPWAN connectivity have some really attractive features and capabilities, not least their ability to be installed just about anywhere and their potential battery friendly lower power consumption profiles. However they also have their own drawbacks.
LPWAN sensors need to be in the coverage area of a matching LPWAN radio access network and cellular devices need cellular network coverage too. Neither is guaranteed, particularly deep within buildings or in remote rural locations.
If you are deploying hundreds and then thousands of cellular enabled sensors management of the increasing number of SIMs becomes a significant task – even with MVNO management interfaces and apps. And although new IoT tariffs are appearing everyday to mitigate the commercial issues (such as shared bandwidth traffic across large numbers of SIMs, and dynamic tariff assignment based on usage), each sensor will require its own SIM and generally each SIM comes with an initial cost (the price of the SIM card itself and network activation charges).
The case for WiFi enabled and wired IoT sensors/gateways
In contrast to cellular, Wifi and wired IoT sensors have no inbuilt direct internet access, instead they rely on a shared internet access gateway for their connectivity. This can simplify deployments considerably, particularly when many sensors are deployed within buildings and in rural locations and all connect back to a single access gateway.
In manufacturing environments, machines can be monitored by wifi enabled sensors that connect via a factory wide dedicated secure IoT WiFi network. Isolated from the rest of the enterprise network in this way, their traffic can then be routed direct out to the internet over fixed line connectivity (DSL, Fiber) as well as cellular, and subsequently over secure VPN to a central datacenter if desired.
In rural deployments where a farmer might need to monitor crops in fields, cellular enabled outdoor Access points can be installed on high ground where there is good cellular signal and WiFi coverage can be extended from there using point to point and segmented wifi antennas to where coverage is required.
Wi-Fi enabled IoT sensors tend to be cheaper and can be smaller than cellular enabled devices too, which in turn makes them more suitable for large volume deployments.
Management challenges of mixed IoT sensor deployments
The expectation is that enterprises will initially deploy multiple end to end IoT solutions within their business units – each focused on solving a specific business problem in a specific vertical.
As all IoT solution providers will choose the underlying technologies that best suit their specific use cases and challenges, it is possible (and I would argue very likely) that an enterprise will need to provide support and day to day management for multiple connectivity technologies. Some IoT solutions might use embedded cellular devices each with their own internet connection and so are effectively isolated from the enterprise network already, but others will be connected directly to the corporate LAN via ethernet – or indirectly via a low power RF to ethernet gateway, and there will likely be Wi-Fi enabled IoT sensors too.
From the point of view of network administration this can raise some challenging requirements (network security and resilience, the need for mobile and remote deployments, and the requirement for additional diverse bandwidth) and become resource intensive – particularly when the number of IoT sensors increases exponentially and the traffic they generate is mixed with other business nework traffic on the LAN/WAN.
A typical approach would be to isolate IoT network traffic using VLANs or dedicated physical network hardware, but this comes with its own challenges.
Deployment support and management overheads
An enterprise will likely have a mix of networking equipment vendors and models so careful documentation and processes will need to be put into place to guarantee the separation of traffic – increasing network complexity and deployment times.
Complex Internet connectivity configurations
When more bandwidth is required to support the increasing number of IoT sensors and their network traffic, or diverse connections (multiple fixed lines and cellular) are desired to guarantee internet availability, the network design can get even more complex – especially when using typical vendor equipment that treats multi-WAN configurations and management as an afterthought.
Typical network equipment vendors approach multi-WAN configurations in a traditional manner, generally supporting an active/failover configuration successfully but without the intelligent granular control of traffic when using multiple active WAN connections that a specialist multi-WAN product can achieve.
IoT Network Visibility and Monitoring
Visualising IoT network status, availability and capacity from a network admin perspective can get increasingly difficult when IoT networks are intentionally isolated from the rest of the corporate LAN/WAN by design and so inaccessible to existing network monitoring and management tools.
In fact if the desired level of isolation is achieved, the only way to successfully monitor an internal Isolated IoT network is from within the IoT network itself. This typically requires a dedicated monitoring and management platform specifically for the deployed IoT network connectivity.
In the next post on this topic I take a look at how Peplink Products and Technologies can be used to enabled IoT Sensor network deployments in the enterprise.
