In July 2023, Transforma Insights published a Position Paper entitled ‘Connected-by-Design: Optimising Device-to-Cloud Connectivity’, sponsored by Eseye, in which we outlined the reasons why it is critical for IoT developers to build their applications with considerations of connectivity permeating the development process. In this blog post we examine one perspective on the march towards Connected-by-Design, specifically some of the alternative approaches and the pitfalls associated with them.
Providers of IoT products and services need to be able to cope with the implications of the constrained environments in which IoT is deployed, as well as the very specific requirements from any given IoT application. There are effectively four possible approaches, each incrementally more sophisticated than the previous.
For many decades the deployment of IoT (and before it ‘machine-to-machine’ and telematics) solutions were done using technologies that were developed for, and optimised for, other use cases. It is not unusual to find the Android operating system being used on IoT devices, or Raspberry Pi hardware used as the main platform for an IoT deployment.
Most obviously, the connectivity technologies used to connect most IoT devices were not really designed for or optimised for IoT. Considering wide area connectivity, 2G, 3G and 4G networks were all deployed before anyone had really given much consideration to connecting machines. Those technologies were optimised for personal phones, or (at best) mobile broadband devices such as laptop dongles. For short-range connectivity the picture was slightly more diverse, with numerous industrial networking technologies. However, even today Wi-Fi remains the most widely used technology for connecting IoT devices, despite not being optimised for the job and having inherent security flaws.
The challenges of deploying using this approach are clear. While the technologies may be mature and widely deployed, they are far from being optimised for use with IoT. These weaknesses tend to manifest themselves most obviously in being expensive and power-hungry.
In August 2021, Transforma Insights published a report ‘What is the ‘Thin IoT’ stack and why do I need it?’ which describes an emerging norm within the development of IoT applications to make use of specific off-the-shelf technologies that have been created explicitly to be optimised for use in constrained environments, such as limited access to power, low bandwidth connectivity, and limited processing and memory. The elements of the Thin IoT stack cuts across devices, software and connectivity, including device components, operating system, connectivity platforms, networks, device management, eSIM, machine learning, and more.
The trends outlined in that report are a major enabler of the wider adoption of IoT, removing significant barriers to entry for developing solutions. The further evolving implication has been that the technology functionality within these layers becomes less and less of a differentiator, being easily accessible for any vendor and increasingly based on standards. The long-term trend will see almost any vendor able to integrate the functionality within these layers easily within their offerings, whether it be device management, eSIM or new access technologies.
We should note that optimisation is not always universally positive. The big advantage with using undifferentiated components was that they were often over-specified for the job at hand. With the use of components that are optimised for constrained environments, and produced at lower costs, the functionality is almost always more limited. This can have implications for things like security. In some cases on-device processing is very limited, or networking protocols may not support end-to-end encryption, or the available data transmission may be so limited (due to the available technology or the desire to maintain battery life) that firmware updates are difficult to achieve. With the constantly evolving IoT security threat landscape it’s often critical to be able to do firmware over the air (FOTA) updates, which may not be possible with some constrained technologies.
Picking the right components, as per Approach 2, is not enough. With the limitations of some of the constrained technologies, it is also critical to make sure all elements of the IoT solution, the full stack, is optimised to work with each other. It’s not just about picking the best tech (although there are some combinations that work better than others e.g. don’t use MQTT with NB-IoT), it’s about picking the right tech, both in terms of what works in the context of, say, the device alone, but also in the context of the device on the network and with the application requirements also considered. What’s needed is a holistic end-to-end view.
There are numerous examples of where different elements of the stack will need to be traded off against others, in order to ‘cross-optimise’ the whole solution. For instance:
The above are just a selection of examples. In some way, almost all of the different decisions have some implications for others.
Increasingly, vendors are focusing attention on how to support this type of decision-making, through enhanced professional services aimed at support with modelling IoT deployments, for device design, business case analysis, and technology assessment.
Ultimately, the optimum approach goes even beyond the cross-optimisation envisaged by Approach 3. Because connectivity is absolutely critical to IoT deployments, managing the inter-relationships of compute and storage resources, and having the greatest sensitivity to constraints (all topics tackled in the report), IoT developers need an approach of being ‘Connected-by-Design’, i.e. considerations of connectivity optimisation permeate through the whole IoT solution development process rather than being layered on at the end.
In the same way the ‘secure by design’ principles require that developers consider security throughout the development process, rather than overlaying after the event, so too should considerations of connectivity. Choices about connectivity technology, protocols and architecture will have enormous implications for other elements of the stack, meaning that connectivity can not simply be bolted on at the end as an afterthought.
Vendors should be providing something like a black-box. Devices are connected at one end, data is put into the cloud service at the other end, and what happens in between is really not a huge consideration for the enterprise user, as long as it’s compliant, reliable and cost-effective. Most will not care if it uses CoAP or MQTT, won’t care if it uses LoRaWAN, NB-IoT or Wireless MBUS, won’t care if multi-country cellular solutions uses multi-IMSI, roaming or eSIM localisation, and won’t care if the operating system is FreeRTOS, RIOT or Zephyr.
As a result, ideally the vendor of the IoT component will be able to provide a full stack, spanning all of this ‘in between’. The enterprise customer should not be forced to investigate, assess and integrate the various different component parts of IoT. It adds a level of complexity and will be outside of that enterprise’s skill-set, at least for most enterprises. This is a specialist task, and one that should be provided by a specialist service provider.
This article is based on the recently published Transition Topic Position Paper ‘Connected-by-Design: Optimising Device-to-Cloud Connectivity’ from Transforma Insights, sponsored by Eseye. The report examines the transition occurring in the way Internet of Things solutions are developed. The IoT is moving from a one-size-fits-all approach built on technologies that were not developed with the constraints of IoT in mind, to a 'Connected-by-Design' approach, reflecting the unique requirements of each IoT use case, complexity of the mix of components, and where careful consideration is given to how all the elements are optimised, particularly connectivity.
