Device Twins: values and development

The architecture of IoT cloud platforms is becoming increasingly complex. For further development, it is necessary to introduce standardized principles and approaches, which we are already seeing: Cloud Native, Edge Computing, OpenAPI, etc. Another such approach is the concept of Device Twins (DT), which we will discuss today.

Imagine a situation: You need to travel to another country for business, the language and customs of which you are not familiar with. It would be good in such a situation to have a local resident as a friend, who also speaks your language. He knows who to contact for various matters, and can also make a call via local connection (cheap, without roaming) and even arrange a meeting (for metadata exchange).

Something similar happens with an IoT device when it starts interacting with a platform. Several contradictions arise:

• data consumers of devices want to work with structured metadata, while devices cannot send them due to traffic constraints and differences in structure;
• device owners want to seamlessly connect them to various platforms;
• some services sometimes need to urgently obtain the status of the device or the latest state, and the device communicates periodically according to a schedule (at least here you can assume when this will happen) or by event (here there is complete unpredictability);
• the same thing, but in the other direction - from the platform to the device, this is especially true for firmware updates;
• you want to endow the device with new properties, for example, delegate decision-making, but it is not physically capable of doing this;
• the device moves through distributed infrastructure, connecting to its different edge points: transit traffic within the platform is growing, there is a need for autonomous operation when disconnected from the rest of the cloud.

In such scenarios, Device Twins can act as an intermediary that understands the language and capabilities of both the IoT device and the platform. It can store metadata, manage communication schedules, and even make autonomous decisions based on pre-defined algorithms.

When a device is mobile and connects to different edge points, the Device Twin can ensure seamless communication and management across the distributed infrastructure. For this, the Device Twin can be implemented in a hybrid manner - a simplified part residing in the Network Exposure Function (NEF) for low latency operations, and a more complex, intellectual part in the Application Function (AF) for data processing and decision-making in 5G or into the Service Capability Exposure Function (SCEF) in 4G.

This approach could solve many of the contradictions mentioned, while also adding the benefits of scalability, data consistency, and distributed resilience. However, challenges such as integration complexity, data synchronization between the Device Twin parts, and increased management costs should also be considered.

For effective implementation, it’s crucial to follow the standardized principles and approaches like Cloud Native for scalable microservices, Edge Computing for distributed processing, and OpenAPI for interoperable communication.

The development of standardized approaches and the adoption of Device Twins can lead to more efficient, scalable, and resilient IoT systems, opening new opportunities for innovation and addressing the challenges of complex IoT ecosystems.

Cloud Services Architecture

Typically, the lower-level architecture (specific to devices) of cloud services is represented as follows:

Separate layers are services necessary for interaction with devices: data acquisition, command sending, maintenance, etc. At the same time, each such layer performs standard functions for all devices or a certain group. In other words, we have functional separation of services.

Pros of this solution:

• each layer can be optimized for the function it performs, meaning that the most suitable technology stack can be selected;
• logically understandable separation for developers and engineers, the ability to decompose development and support tasks by functions.

Cons:

• each layer turns out to be monolithic - it is difficult to scale horizontally;
• all development is carried out by the platform vendor, device manufacturers do not participate in this in any way;
• IoT devices possess strong diversity, so technical solutions in each layer cannot be optimal for all classes of devices.

To address these challenges, the architecture can be rethought to involve more modular approaches such as microservices, which allow for better scalability and flexibility. Adopting Cloud Native principles can aid in optimizing for diverse device classes by allowing customization at each layer.

Moreover, involving device manufacturers in the development process can lead to more informed decisions and optimizations for particular device classes. An open, collaborative development process can contribute to creating a more adaptable and effective architecture.

This evolved architecture must also consider security, as IoT devices are often vulnerable to cyber attacks. By incorporating security at every layer and ensuring strong encryption and authentication mechanisms, the cloud services can become more robust and reliable.

In conclusion, while the traditional lower-level architecture offers logical separation and optimization possibilities, embracing modern approaches such as microservices, Cloud Native principles, and collaborative development can significantly enhance the scalability, flexibility, and security of cloud services for IoT devices.

Device Twins

To resolve existing contradictions and ensure further flexible development of IoT platforms, Device Twins of devices can come into play:

Device Twins will be those "smart" representatives of devices on the platform, having the same or a larger set of constants and variables (state) as their devices, synchronizing them when possible.

Drawing another analogy, Device Twins can be called a smart device driver on the platform: just as we now buy a component for a PC with a set of drivers for the main operating systems, so in the future we will be able to connect IoT devices to well-known platforms.

Leading IoT platform providers have adopted the Device Twin approach, including AWS Device Shadow and MS Azure Device Twins. Currently, JSON is used for this, which is a lightweight and platform-independent construct, but does not provide sufficient isolation. A more promising solution appears to be based on WASM (Web Assembly), which is an ultra-lightweight virtual machine that can run microservices (or more precisely, nanoservices).

It's also worth noting that this approach will have its own overhead, as identical services for similar devices must run in the cloud in a large number of copies. This, on one hand, appears to be a problem, but it is solvable. The fact is that the image of the Device Twin can be one for many similar devices, and the difference is only in the context (state, secrets, data). This approach can be compared to deduplication in data storage. It is possible to work efficiently with this – it is not necessary to constantly keep the context in memory. And it is important to note that cloud resources are relatively cheap, and they can be scaled almost infinitely, which is not the case with device resources.

Another interesting effect is that the launched Device Twin can be provided with the maximum level of protection, especially if it does not have to go for secrets to external sources, and the memory area is securely encrypted.

Integrating Device Twins into IoT platforms allows for a much more dynamic and flexible interaction model. It can ensure that device states are always available for applications and services even when the devices themselves are not reachable. Furthermore, it enables devices to utilize the processing power of the cloud for more complex analytics and decision-making processes that might not be feasible on the device itself due to resource constraints.

However, with these advantages, there are also challenges such as managing the overheads, ensuring security, and keeping the twins synchronized with the physical devices.

In conclusion, integrating Device Twins in IoT platforms presents an innovative way to enhance device management and functionality. It allows for more robust and flexible device interactions, better security, and can pave the way for new opportunities and use cases in the IoT ecosystem.

Projection on NB-IoT Architecture

Mobile operators were among the first to offer connectivity for IoT through NB-IoT (Narrow Band IoT), which is a narrowband communication protocol. This protocol is a part of the LPWAN (Low Power Wide Area Network) class, which aims to use device resources economically. For communicating with devices, the NIDD (Non-IP Data Delivery) transport protocol is used since using the IP stack is too cumbersome for LPWAN scenarios. This required the implementation of a new component to maintain the convenience of communicating with devices over the network – SCEF (Service Capability Exposure Function), a kind of API for device interaction. One of the most important changes in the interaction scheme of AS (Application Servers) with devices when working through SCEF is the emergence of a universal identifier. Now, instead of a phone number (MSISDN) or IP address, as it was in the classic 2G/3G/LTE network, the device identifier for the application server becomes an "external ID". It is defined by the standard in the format familiar to application developers as “<Local Identifier>@<Domain Identifier>”.

SCEF performs the following functions:

• Binding the SIM card identifier (IMSI) to an external ID
• Transmission of non-IP traffic (Non-IP Data Delivery, NIDD)
• Group operations, using an external group ID
• Support for acknowledged data transfer mode
• Data buffering
• Authentication and authorization of devices and application servers
• Simultaneous use of data from one UE (User Equipment) by several AS
• Support for special UE state control functions (MONTE - Monitoring Events)
• Triggering of devices
• Support for non-IP data roaming

All of this makes SCEF an ideal place for implementing Device Twins. In this case, some of the standard and typical functions will transition from the IoT platform to the operator in the form of additional services (VAS - Value Added Services).

In summary, the integration of Device Twins within the NB-IoT architecture through SCEF enables efficient, scalable, and flexible communication with IoT devices. By utilizing the non-IP data transmission and unique identifiers, it’s possible to ensure streamlined communication with the IoT devices without burdening them with complex IP stacks. Moreover, the SCEF can serve as the central point for implementing Device Twins, thus enabling more advanced functionalities such as monitoring, triggering, and state control. This approach enhances the IoT network by facilitating better control, scalability, and resource management for the IoT devices operating on LPWAN networks.

What Device Twins offer today?

1. Interoperability: The owner of the device can easily transfer it from one platform to another, which eliminates the lock-in to specific vendor ecosystems (Vendor-lock).
2. Binary Protocol: A fast, simple protocol with low overhead is used to communicate with the device, while enriched data (structured, corrected, normalized) is provided for the platform.
3. Engagement in Platform Integration: By involving device developers in the integration with platforms through the development of Device Twins, this process can be significantly accelerated.
4. Microservices Architecture Compatibility: Device Twins are inherently compatible with microservices architecture, allowing for distributed, scalable, and independent deployment of services.
5. Granular Security: Issues with one device do not affect the operation of others. Device Twins allow for isolated security, ensuring that a compromise or failure in one does not cascade to others.
6. Instant Device Inventory: Device Twins allow for real-time inventory management of devices. The state and properties of each device can be known and managed instantaneously through their Device Twin.

By incorporating Device Twins into IoT architectures, businesses and developers can achieve higher levels of flexibility, efficiency, and security in managing IoT devices. This is particularly beneficial in environments where there is a need to efficiently manage a large number of devices, ensure interoperability, and maintain high levels of security.

What Device Twins are ready to offer in the future?

Edge Computing: Making Device Twins mobile across infrastructure allows them to operate closer to their corresponding physical devices. This has several benefits including lower latency, elimination of transit traffic, and, most importantly, the ability to operate on edge nodes such as routers, base stations, and even smartphones. This is important both for autonomous operation in case of connection loss to the cloud, and for confidentiality reasons as not all clients may want to send their primary data to an external cloud. An example of this is the KubeEdge project, which allows containers to move through infrastructure (similar to VMware vMotion). Furthermore, this flexibility allows for the implementation of new scenarios where a device is dynamically assigned the role of Edge.

Example 1: Self-organization of a group of sea buoys. Drifting sea weather buoys can appoint one of them to act as a gateway for the others, choosing the one with the highest battery charge as a criterion. This role can later be reassigned to another buoy.

Example 2: Managing a smart home using a smartphone. In the event of an emergency power outage, devices with autonomous power sources remain active. These include smartphones and some smart home devices. In this case, Device Twins can operate directly on a smartphone, maintain connectivity with devices, and provide minimum smart home functions.

The utilization of Device Twins in conjunction with Edge Computing can revolutionize how IoT ecosystems are managed and operated. By enabling more localized and dynamic interactions between devices and their digital counterparts, there is potential for more efficient, resilient, and secure IoT environments. This is especially relevant in scenarios where latency is critical, or where there is a need for autonomy and data confidentiality. Through Edge Computing, Device Twins can facilitate innovative solutions to complex problems in the IoT space.

Resource-Intensive Tasks and AI: Device Twins can be loaded with resource-intensive tasks such as forecasting and decision-making with fuzzy logic, etc. The physical device remains unchanged; it does not need to be replaced or even have its firmware updated.

Example: IoT on the Blockchain. There are solutions where devices interact with each other and people through blockchain technology and can enter into smart contracts as independent actors (such as on the Vodafone Economy of Things platform). In this case, the blockchain client will run on the Device Twin without burdening the physical device itself.

Composite Device Twins: Device Twins can be assembled into digital replicas of more complex systems or products.

Example 1: Connected car. If each electronic component of a car has a Device Twin, it will be easy to create a Device Twin (or Digital Twin) of the entire car.

Example 2: Smart agriculture. Device Twins can exist not only for devices but also for services, such as a weather forecasting service. Imagine creating a composite Device Twin from the Device Twins of a temperature and humidity sensor and a weather forecast service, which makes decisions about irrigation. Taking weather forecasts into account will allow for more precise maintenance of target humidity levels while saving water. This decision would be made by the composite Device Twin, which could operate directly on the LPWAN base station serving the field.

Standards: Standardizing the Device Twin subsystem in 3GPP will allow it to become a common component of 5G or 6G and reduce the go-to-market time for device and platform manufacturers almost to zero. This can be achieved by standardizing the internal architecture of SCEF, defining the runtime environment, and the API of Device Twins up to application servers. This will allow MNO/MVNO to launch VAS, and device and platform manufacturers to eliminate integration barriers. This approach aligns completely with the Open RAN concept.

By incorporating resource-intensive tasks, AI, and compositing, Device Twins can become an extremely powerful tool for managing complex systems. This, coupled with standardization, could lead to a significant breakthrough in how IoT systems are deployed and managed, making them more efficient, agile, and capable of handling advanced tasks that were previously not feasible.

Conclusion

In this article, it has been demonstrated that the application of the Device Twins  concept can address current challenges in IoT and also provide flexible and adaptive development over several years. The DT approach aligns with modern technological trends and does not require a radical modification of the existing infrastructure of mobile operators, cloud services, or other IoT service providers.

Implementing DT within the context of SCEF (Service Capability Exposure Function) provides operators with the opportunity to offer additional value-added services (VAS) in addition to standard SCEF subscriptions. For users and developers, this means simplifying processes, optimizing interactions with devices, and creating more complex and adaptive systems based on IoT.

The use of DTs contributes to increased interoperability, allows for efficient integration of devices with various platforms, and addresses more complex tasks such as edge computing, artificial intelligence, and blockchain technologies.

In the long term, the standardization and widespread adoption of the DT concept can become key factors in the development of the Internet of Things, providing flexibility, scalability, and the ability to implement new, innovative scenarios for device and service interactions.