Device connectivity
Device connectivity: a broad topic to consider early in the design process
While envisioning a connected device and its associated IoT platform in charge of receiving the generated data, several decisions about its connectivity have to be made very early on in the design process.
They impact both the hardware and the software sides which must be co-constructed in a tight feedback loop. Therefore, a series of criteria must be reviewed at each stage of the build flow to ensure that the behavior of the product will correspond to the intended usage.
They impact both the hardware and the software sides which must be co-constructed in a tight feedback loop. Therefore, a series of criteria must be reviewed at each stage of the build flow to ensure that the behavior of the product will correspond to the intended usage.
main decisions to make when it comes to device connectivity
Localization
Will the device live mostly indoor, for instance in a commercial building, an industrial facility like a factory or even in a customer home? On the contrary, is it expected that the connected thing will evolve in remote areas, in harsh conditions or even both? Will it be part of a broader mobile transportation unit with an always moving location?
Contexts of use
Some devices may need to send data very frequently but with non-critical payload that may sometimes be lost or duplicated. On the contrary, other kind of connected things may emit telemetry less regularly but expect that every bit of information has to be retrieved with measurable confidence. Overall robustness of the whole data pipeline is key.
Security concerns
Some collected data, especially coming from public or shared sources, may look innocent enough to skip any questions about security. The “We have nothing to hide” adage is still way too often employed. But by doing so, we only focus on the confidentiality aspect of the transfer… Security encompasses much more facets.
SUCCESS STORY
Ensuring Velan's Industrial Valve Connectivity
Velan’s new range of connected valves gives users up-to-date, accurate telemetry, thanks to Witekio’s device connectivity and app development expertise.
- A custom-built, Windows IoT platform to migrate data from the sensors to a data lake.
- A web application with an intuitive GUI.
- Security advice for data transfers, cloud connectivity and more.
Strengths and weaknesses of communication protocols
The OSI network model is well known to engineers, but its onion shape structure where each upper layer depends on some guarantees offered by the lower layer makes it non trivial to master holistically. Various profiles of developers have expertise around separate concerns, but in the end everything has to work reliably, top to bottom.
For example, embedded developers have strong opinions on the data and link layers which are closer to the metal. During the design process of a product they work with the hardware teams and must be able to understand their constraints and conclusions, even sometimes positively influence them.
Application and cloud developers rely on this initial set of physical decisions to confront them with business needs and the way the data has to be expose to the end user. Let’s go through a non exhaustive list of technical solutions on the table when device connectivity is at stake.
Long distance transport
Lorawan, SigFox or NB-IoT really shine for a fleet a devices spread out over a broad geographical area hundreds of kilometers wide, over many regions/countries. Heavy machinery, mining equipments, weather stations or agricultural vehicles may be monitored via these means. These protocols are energy efficient but do not allow to carry heavy data payload. The same concern apply to relay via satellite such as Iridium. Also the data must often be routed via the infrastructure of the chosen partner which must therefore provide strong SLA depending of the use-case.
Proximity solutions
At the opposite end of the spectrum, some devices expect to communicate only in a radius ranging from a few centimeters to a few meters. This is where technologies such as NFC/RFID, UltraWide-Band (UWB), BlueTooth, BlueTooth Low-Energy or ZigBee are the perfect feet. The data is delivered to a pair device, such as a local gateway or a smartphone. The payload can be aggregated, processed before being eventually forwarded to bigger sinks such as a remote back-end. IoT devices such as, factory sensors, home appliances or domotic equipment fall into this category.
If possible, wireless solutions can also be substituted to more traditional ones to increase the reliability of connections. A device which can accept an RJ45 Ethernet or a USB cable in place of WiFi, has better chance to be less troublesome in the long run.
Mid-range coverage
If the device is expected to work in urban areas or well covered countryside, then the last generation of GSM connectivity, 5G can deliver the right promises in term of latency, bandwidth and availability. A SIM card (virtual or not) is involved and decisions about which telco operator is better suited must be handled by the financial team. How to diminish the cost of a huge fleet of thousands of devices each with the contracts? What about roaming between frontiers?
TCP/UDP/IP
This trio of protocols are the pillar of Internet exchanges since several decades. IoT solutions can rely on these strong foundations. Depending of the use case, UDP datagrams can be enough for “fire and forget” non-critical lightweight messages. On the contrary the redundancy and acknowledgement obligations offered by TCP are often non negotiable and this becomes the only choice for a robust data collection.
Billions of IoT devices are expected to join the already crowded network years after years. Yet despite warning about addresses exhaustion, IPV4 is still alive! Strong NAT support in routers lets sub-network transparently use this limited range of addressees. But if all the nodes in the communication are able to “speak” IPV6, this can be a net advantage, especially in scenario where we an operator needs to target a device for remote diagnostic.
HTTP
HTTP being a stateless protocol (with no cookie, token or session involved) we can put it to good use when device-to-cloud telemetry needs to be emitted. To go the other way around, and stay up to date when a configuration change on a digital twin needs to be applied, regular polling can be setup with an interval that makes sense.
The main advantage is that regular infrastructure (web servers, proxies…) and well-known practices such as REST API can be reused and the workforce is plentiful. The format of the payload is non constrained: it can be binary data in Protobuf or even JSON if there are not strong constraint on the bandwidth.
For update over-the-air, HTTP is able to support range responses which helps to resume or chunk big package download. Also recent version of the protocol, like HTTP 3 which relies on QUIC layer can also be put to good use in certain context.
MQTT
For more persistent and lightweight connection, MQTT can be a better alternative where the ephemeral nature of HTTP fells short. This tailored-made IoT protocol just celebrated its 25 years mark, and, especially with new features of version 5, is still as relevant as ever for the purpose it was designed. Like WebSocket giving bi-directional capabilities to web applications with partial updates of user-interface, two way communication and topic based broadcasting can really help to handle possibly fleet-wise cloud-to-device needs. For quasi-real-time remote-procedure calls are well supported.
TLS
Both HTTP and MQTT offers no guarantee ticking the marks on the topics we discussed about security. Hopefully, these protocols can be declined in HTTPS and MQTTS flavors, which are basically short names to depict the TLS support underneath. Recent advances in this area, like TLS 1.3 simplifies the handshake procedure with fewer necessary round-trips to establish the connection which can really helps in capricious environmental conditions.
Also, cipher suites are adjusted to state of the art of algorithm which are more secure and lighter. As mentioned earlier a strong PKI is needed to obtain its full potential.
Security facets of device connectivity
Data integrity
Data integrity is important, to ensure that payload has not be tampered with: a single bit change can have dreadful consequence down the line on how a measurement is interpreted. Even worse: poisonous messages could be crafted to compromise the receiver.
Communication authenticity
Authenticity of the communication is also critical, for both parts of the network.
Like a human browsing the web would trusts their bank website presenting a legit certificate, devices also have to trust the server acting as their partner during a communication. Load balancers, servers or brokers have the same needs: they should only establish connection with devices which identity has been verified. In simple scenario, or during the development stage a shared secret can be the way to go. But soon enough, a more robust solution has to be put in place. Client certificate, often following the X.509 specification, must be presented by the devices. It means that a private key is involved. It must be protected at all cost, which involves the presence of a Trusted Platform Module or Hardware Security Module which acts as an impenetrable vault.
To setup this chain of trust between parties, a public key infrastructure has to exist which requires both technical and organizational expertise. The happy path, when everything goes well can be put in place with moderate efforts. But many aspects need to have answers too: what happens when the certificate of a device expire? What happen in case of compromision? What if the private key of the authority leaks?
In any case, a trivial but often forgotten rule has to be followed to the letter: never roll our own cryptographic primitives! It is way too easy to shot ourselves in the foot with silly mistakes by trying to reinvent the wheel. Battle-tested cipher suites exist, must be used when relevant and deprecated when no longer secure enough.
Beyond the network layer, the same questions can still be asked for the micro-services part of the IoT Platform itself. Even if the ingestion point is in charge of the encryption termination with the device, data can still transit in the various queues and pipelines in a secure manner.
Like a human browsing the web would trusts their bank website presenting a legit certificate, devices also have to trust the server acting as their partner during a communication. Load balancers, servers or brokers have the same needs: they should only establish connection with devices which identity has been verified. In simple scenario, or during the development stage a shared secret can be the way to go. But soon enough, a more robust solution has to be put in place. Client certificate, often following the X.509 specification, must be presented by the devices. It means that a private key is involved. It must be protected at all cost, which involves the presence of a Trusted Platform Module or Hardware Security Module which acts as an impenetrable vault.
To setup this chain of trust between parties, a public key infrastructure has to exist which requires both technical and organizational expertise. The happy path, when everything goes well can be put in place with moderate efforts. But many aspects need to have answers too: what happens when the certificate of a device expire? What happen in case of compromision? What if the private key of the authority leaks?
In any case, a trivial but often forgotten rule has to be followed to the letter: never roll our own cryptographic primitives! It is way too easy to shot ourselves in the foot with silly mistakes by trying to reinvent the wheel. Battle-tested cipher suites exist, must be used when relevant and deprecated when no longer secure enough.
Beyond the network layer, the same questions can still be asked for the micro-services part of the IoT Platform itself. Even if the ingestion point is in charge of the encryption termination with the device, data can still transit in the various queues and pipelines in a secure manner.
Witekio can support your device connectivity project
While in no-means all encompassing, the various explanations above expose many interrogations and common answers around device connectivity that must be tackled by engineering teams like Witekio’s. For each of these key concepts, some well understood recipes can apply to reach 80% of the solution meanwhile a non-negligeable expertise and savoir-faire is needed to reach the gap and finish the remaining 20% and ensure the fleet of devices is able to perform to its full potential.
Your trusted embedded software, application and connectivity partner
4 countries
ISO 27001 certified
