Starting in the early 80s with Ethernet running through to todays’ sophisticated and ubiquitous Internet offerings; wired to wireless, fixed to mobile, with all the tools and methods a vast pool of experience in ‘networking’ has built up. Against this background it seems strange to focus on the networking challenge, but are IoT Devices the same as IT Devices from a networking perspective?
IT was, and is, about connecting computers into computer systems around significant data exchanges; or in the case of the Internet, then usually human driven Web navigation. Whilst the popular expectation is that the Devices of ‘Internet’ of Things will connect and interact in a similar manner on a network, that may not be true.
To make the point consider the example of Sensity an IoT company that uses LED lights and lighting as IoT sensors. Quote; ….has been designed to instantly convert any lighting manufacturer’s LED fixtures into IP-enabled sensory node in a light sensory network that provides both the lighting control and cloud-based IoT services via a standard NEMA socket. Examples of Sensity deployments range from monitoring car parking bays to counting people moving around retail stores and much more.
Its an example of IoT; its network connected, has a link to IP, but its not networked in a manner that any IT networking professional will find it easy to relate to. (take this link for details of NEMA connectivity). Sensity, is an impressively innovative IoT solution with huge business value in any number of ways, but it’s also an example of the all too common IoT problem of ‘new’ networking solutions.
Just at the time when IT networks and protocols have become relatively standardized to support ubiquitous network connectivity the arrival of IoT networked devices disrupts this with a whole range of ‘differences’. The innovative IoT solutions are usually complete packages from sensors to graphical user displays, including the network topography, to bypass these differences. However there is general a requirement to use an Enterprise IT network for as a backbone connection to the Cloud where the service element will be hosted. (N.B. using conventional TCP/IP protocols for IoT data can often mean the packet header payload is bigger than the data being transported).
The implication inherent in the name, and the claims of ubiquitous connectivity, is that todays IT networks providing Internet connectivity will support IoT; in reality for many deployments that’s only likely to be true about the backbone element.
In the Telecom Industry the concept of the ‘Final Mile’ challenge being made up of any number of different connection formats was at least limited in its diversity of network content to voice and bell signaling. Currently the IoT Final Mile diversity exists in just about any, and every, facet of ‘networking’, from physical media layer upward.
In small scale and pilot sensor networks this level of diversity may not be noticeable for the impact its traffic with have Enterprise IT networks for backbone connectivity, some pilots may even taking place in totally closed special IoT sensor networks. With time and scale the convenient separate local IoT closed network will soon vanish, and IoT network traffic levels will be felt on the Enterprise IT network.
At the MIT Technology Review Digital Summit Todd Greene Follow the CEO of PubNub made the observation that a new type of Network for connecting IoT embedded devices is required. His argument was based on both the scale and latency implications resulting from the complex infrastructure of the real ‘internet’ Quote; ‘Unfortunately the Internet isn’t just one network, and considerations include heterogeneous networks, including cell towers, slow connectivity, fast connectivity, proxy servers, and firewalls; all things that can disrupt connectivity’.
Todd Greene Follow could be expected to make this point as his company, PubNub, has, since 2009, been actively promoting their alterative interconnection network for exactly the kind of low latency, small data packet traffic that makes up IoT sensing. PubNub can certainly argue they have something right in their assessment given the size and number of messages they are now carrying for a collection of well-known companies. So is it really the answer to deploy a new parallel network infrastructure as his message in respect of IoT and traditional IT networks would suggest.
For the majority of enterprises integrating with and using IoT will need to be a part of their existing Enterprise IT network as, unless in a specialized sensing process based interconnected industry such as Oil Refining, there is unlikely to be an economic argument in shifting to a specialized alternative IoT sensing network.
The obvious consideration of IoT traffic impacts on the Enterprise IT network will be sheer amount of traffic, but it’s the size of network packets and the frequency of device transmissions that introduce some basic issues that have to be addressed. The two starting points for any Network Professional are Traffic impacts of volume, timing and latency, and Security management. Just how these concerns are addressed will depend on choosing whether device connection management, or data stream/flow management, is the better primary choice.
Summarizing the numbers of variables to be considered into just these two headings may seem at odds with the huge amount written on the issues of IoT networks. The concern for those facing the reality of supporting IoT sensor deployments on Enterprise IT networks is to find the approach that addresses their particular requirement, and not become lost in a sea of individual issues.
Are the issues unimportant? Of course not, but as with everything to do with IoT it’s all about outcomes! In this case that means choosing tools and techniques to manage the devices connectivity, or to consider the alternative to manage consolidated data streams. Is it is possible to have such a neat separation? In the long term no, the two are equally important and required, but in the short term when tactical success matters then it helps to understand what is the dominant issue as a priority.
As in all markets in the early stages much of the information available comes from a vendor of a product therefore the presentation of the ‘facts’ will by necessity be concerned with the product. ‘Issues based selling’ is a well-known technique so it pays to establish an overall approach to use to consider products within an objective context.
Googling the term ‘IoT Connection Management’ will provide papers from Cisco, Huawei and others, which define how to control and manage the huge number of different types and ways that IoT devices are connected. Connection management is a necessity when faced with the diversity of large numbers and types of devices that an enterprise might have in use across both cellular and traditional enterprise IP addressed devices.
Naturally when first starting to consider IoT pilots and small-scale deployments extending traditional IT Network connection management to include IoT Devices is seen as the starting point. At this stage the impact of managing the service level availability of new connections exceeds the potential impact of the data stream management.
However as IoT sensing moves into production systems the number of IoT sensors and the concentration rises dramatically. Deloittes new headquarters building in Amsterdam has 22000 sensor points to manage its abilities to be a ‘Smart’ Building. Consider the network impact these thousands of simple IoT sensing connections make in communicating only a few bytes of data each, but doing so frequently. In aggregate that’s a lot of traffic, but the individual IoT sensor connections may have little capability to be managed beyond checking for their presence, (think of the example of Sensity). Counting its data transmissions can check the presence of a sensor just as well.
Deloittes Smart Building ‘The Edge’ is expected to provide more than 3 petabytes of data a year from its 22000 IoT sensors, at that level of mature IoT deployment the challenge has to move to Data Streaming management. This is a specific new functionality arising from the technologies associated with IoT and a new challenge for IT Network Managers.
The example of The Edge Smart Building graphically makes the point that the immediate connectivity onboarding management swiftly moves to becoming massive traffic management challenge. IoT devices introduce a volume of connections x the minuscule amounts of data x frequency of sending that taken together impose a very different traffic profile for management purposes. Even if the answer is to segment IoT sensors onto a different network there is still likely to be a Data Streaming management challenge.
The business value from IoT sensors is in either ‘real-time’ Smart Services, or in Analysis of Things, AoT, and for both that means interconnection with the Enterprise IT network to access Cloud based resources. At this connection point even if at no other connection point, IoT Data Streaming management will be a necessity
Googling Data Streaming or Data Flow management will produce a lot of results, as usual most are written around products rather than in the context of the issues to be considered. As data is what provides the business value the whole question of the creation of data by sensors, through to the consolidation data in a form suitable for consumption by Smart Services and Analytics processing does need to be addressed. But that’s a further topic in its own right, and here consideration rests purely on the network impacts.
In the course of little more than a year developed from the growing experience gained from deploying IoT based sensor systems the focus has changed from the IoT Sensors themselves to the aspects of creating, managing and using the IoT Data. The whole topic of Data Streaming and Flow management together with the new forms of Analysis of Things, AoT, has expanded to make Data Architecture a pressing consideration somewhat overtaking network connection Architecture.
At the beginning of this blog Sensity, with their clever LED lighting IoT solution, was used to illustrate high levels of IoT connections, where the value lies in the aggregation of data rather than the management of each individual connection. Should, or even could, this be managed via individual Network Connections, or is it one Gateway connection with management of the resulting Data Stream?
However Network Connections come back into the picture when considering non Enterprise IT network Wireless connected deployments. Connecting cars, goods in transit, high value large items in storage yards etc., require IoT deployments that rely on 3/4G, SigFox, LTE, even sometimes Wifi. Here connectivity and service management becomes the priority.
These forms of public Wireless services are, for the foreseeable future, going to be subjected to ongoing change with new specifications/capabilities, even Service Providers Business models, changing. Recently the LoRa Alliance claimed to be the fastest growing standards alliance in IoT, and of course, there is the arrival of 5G on the horizon, all of which require connection level changes to be managed.
In Public Wireless Networks the service provider usually provides the IoT Network Connection management together with business / commercial management as an important competitive differentiator. That means the device connection point itself is often overlooked, with focus only at the IT Enterprise connection point. Flexibility in IoT Device connections is key to trying to avoid Service provider lock-in preventing changes to better commercial deals.
The barrier to change on the IoT devices themselves is not inconsiderable as, if originally intended for WiFi direct connectivity, there will be an inbuilt full TCP/IP network stack with protocols payloads exceeding data payloads. This level of message size is likely to exceed the capacity of specialist IoT networks such as SigFox. There are similar problems associated with each network type, ie 3/4G, LTE, etc. that render changing from one to another as somewhere between an expensive redevelopment of communication stacks and effectively impossible.
This is a not inconsiderable issue to face up to before making a choice of Network Connectivity types for an IoT deployment using public wireless networking services. To change low cost simple sensors the answer will be to ‘rip and replace’, but investment in complex ‘Smart Sensors’ needs to address future proofing. As with most areas where IoT stretches the capabilities of existing technologies start-ups are providing new answers.
An interesting example is Wivity who claims to ‘eliminate the complexity of public wireless connectivity with a - “Build Once, Connect Everywhere” approach based on a hardware modem being incorporated in the Smart Device design. The interchangeable Wivity modems accept the same HTTP calls from the IoT device no matter what network connection is being deployed so providing an ongoing path to new upgraded network types. Together with using lightweight protocols and other edge based techniques Network connectivity is made simpler and flexible. Wivity call for some re thinking on the Telecoms market and IoT in their blog https://wivity.com/blog/IoT-is-a-Different-Animal
To summarize; deploying IoT pilots means considering and testing more than simple sensor connectivity to GUI, or analytics. IoT is a generational change in the type of technology and its business role, resulting in understanding network and data connectivity needing careful investigation. IoT pilots make low enough demands on IT Enterprise Networks that the impact of full-scale rollouts are easy to miss.
This is a last post for five weeks as i will be taking a sabbatical break though continuing to follow the technology market as usual