IDM is a virtual-network protocol that supports peer-to-peer communication between devices connected to any type of network. In essence, and similarly to IP (or IPv6), IDM faces the problem of interconnecting heterogeneous networks.
However, there are several reasons so as to why IP cannot be directly applied to IoT and, for this reason, alternatives are being proposed. Despite being relatively simple, IP just takes care of delivering the message from source to destination and, therefore, the TCP/IP stack is required for more advanced transmissions. The use of the TCP/IP stack increases the complexity and, therefore, the resources required for its processing. This complexity might be prohibitive for IoT devices, characterized for being small in size, cheap, and energy efficient. Moreover, it is a fact that there are (and will be) networks using privative/domain-specific network protocols, designed by manufacturers for specific purposes such as industrial control, that cannot be directly embedded into IP.
Some of the alternative proposals are based on the use of a complex stack or just address one part of the problem. From our point of view, an IoT protocol should support the construction of an inter-net of different-technology devices that can intercommunicate in a direct and symmetric manner, without requiring any transformations nor the use of intermediaries or handlers.
On the contrary, many of the existing solutions for IoT are based on cloud solutions. These work as intermediary repositories where sensors send their values. Applications, afterwards retrieve from these cloud repositories the data posted by these sensors. As it can be observed, there is not a direct communication between the information source and the one that needs/uses it. When used on sensors, this model increases the latency and forces applications to implement a pull model or add an additional notification mechanism, with the inherent problem of scalability. When used on actuators, the solution is clearly inappropriate so application gateways are normally employed, highly coupled to each particular solution.
This talk, by Vinton Cerf, brings into light some of the key issues of the future internet in Vinton Cerf: The future Internet, challenges and opportunities.
The principles of IDM
The main characteristics of IDM are:
- IDM can employ any available protocols, provided by different vendors, at every network.
- IDM is a cross-layer approach so, this means that some stack layers can be absent when not necessary.
- IDM is a protocol that can be encapsulated over any link, network, or transport layer technology capable of transporting messages or packets from one point to another.
We can assume that any end device (either sensor or actuator) provides an interface (understood as a set of well-known operations). These operations are being invoked by clients and it is the role of the IDM protocol to transport such messages from the client to the end device. We can refer to these end devices as objects. The term is inherent to the current implementation of IDM which is based on an object-oriented middleware (ZeroC Ice). The use of this term is not totally precise since they are closer to a Service-Oriented Architecture (SOA) than to an object-oriented one.
IDM stands for Inter-Domain Messaging since its main objective is to support the intercommunication between network technologies that are, a priori, incompatibles. The use of the term domain, in the IDM name, is due to the fact that any device sharing a given technology and addressing scheme are considered as a unique entity (a domain). In this sense, the whole public Internet is seen as single IDM domain.
IDM relies on routers to support message transmission over the different domains. However, this routing process does not involve any modification in the message being forwarded. In this sense, for example, an IDM router can receive a message through its RS485 interface and forwards it to a device in a Bluetooth network. This is one of the key features of IDM. (NOTA: Aquí he quitado lo de los puntos claves)
IDM routers do not need to modify messages because of the IDM message, created at the client side, remains unaltered until it is delivered to the target. IDM routers just need to change the encapsulation, similarly to an IP router. Obviously, IDM routers need to have an interface for every domain that the router is interconnecting. The specific details of every network technology are transparent for the rest. Contrary to conventional network protocols, like IPv6, IDM addresses point to objects, rather than nodes. One node can host several objects. These two characteristics made possible for an IDM message to be encapsulated over the link protocol of the LAN, getting rid of the local network protocol.
Description of the validation prototype
IDM can be used to tackle different problems although this prototype has been specifically designed to evaluate its homogenization capabilities. As a result of such homogenization process, IoT objects are considered virtually equal inside an IDM infrastructure, although their communication and architecture details are different.
This prototype encompasses 5 domains:
- RS: 3 RS485-Moth nodes
- ZB: 3 ZigBee-Moth nodes (Arduino FIO + XBee)
- WF: 3 WiFi-Moth nodes and one sonoff (ESP8266)
- ITSI-office: 5 sonoff-nodes (ESP8266)
- The Internet (just for communication purposes)
- The Node-RED cloud
The first three domains are located at our laboratory, referred as ARCO, and the fourth domain at the ITSI laboratory.
We have designed the Moth prototypes and, despite having different controllers, they all have the following sensors/actuators:
- Rele for controlling a power load
- Red, green, and yellow LEDS
- PIR sensor (presence sensor)
- LDR sensor (light sensor)
- Temperature sensor
Every domain has its own IDM router. The IDM routers for the ZB, RS, and ITSI-office domains are run on a Raspberry Pi whereas the router for the WF domain is run on a conventional PC.
The following figure shows the logic topology of the described prototype.
Clients and objects
Both sensors and actuators can work as clients, therefore sending invocations.
- Sensors invoke a designated receptor when their state change (a new value has been read).
- Actuators can also invoke a third party when their state change as result of an incoming invocation.
Sensors and actuators are also acting as objects, and can, therefore, receive invocations. Both of them count on an interface that will provide a method for setting the IDM address of the object that is to receive such state changes.
IDM routers forward messages based on the hierarchy addressing process of IDM, similar to how an IP router works. However, its management complies with an SDN approach, highly inspired by OpenFlow. IDM routers are also IDM objects that share a management interface. The IDM Controller is in charge of implementing the routing scheme by adding description flows into the routers.
A description flow is comprised of a predicate and one or more actions. When the predicate is satisfied, the router executes the action/s. The forwarding flow is quite simple, consisting in: if the input message is targeting an address whose prefix matches the predicate, the action is executed which, eventually involves forwarding the message to the indicated address.
This way of managing routers is extremely flexible and, most of the times, simplifies their implementation. This managing protocol entitles routers to do things like:
- Discarding certain type of messages (as a firewall would do)
- Informing the Controller that an incoming message does not match any rule
- Associating a time-to-live to rules
- Recording errors and statistics
The following figure corresponds to a snapshot of the graphical interface of the IDM Controller. This supports an intuitive and visual editing of the routing flows.
Once the infrastructure is deployed, objects can address invocations between themselves by only knowing their IDM address.
For example, the object that controls the PIR sensor on the ZB1-Moth node (address 10:17) can be configured to send its state changes to one of the LEDs of the RS2-Moth node (for example, the red one has the address 12:22). This configuration will result in switching on the red LED when the PIR sensor detects presence. This proves that the invocation was originated in a device connected to a ZigBee network, going through a TCP/IP network, reaching the device (red LED) connected to an RS485 network.
It is important to highlight that objects can also be implemented in conventional PCs, smartphones, or any other computing platform that we can consider. In all these cases, the peer-to-peer communication works in the same way.
Additionally, we have created Node-RED components that supports the visual configuration of event receptors. Moreover, clients and objects can be virtually created, hosted in the Node-RED server and therefore constituted as a new IDM domain connected to the infrastructure.
The previous figure represents three different Node-RED flows, with the following meaning:
- The first flow represents the configuration of the object, with address 10:17, which corresponds to the PIR sensor on the ZB1-Moth node, in the ZigBee domain. This flow is being configured to forward the state-change notifications to the object with address 12:22 (the red LED of the RS2-Moth node, in the RS485 domain).
- The second flow involves the generation of a virtual object, with address DD:12, which is registered in the local IDM router. This object can be invoked from any point of the IDM inter-net. When the invocation is received, Node-RED prints out the output on the screen.
- The third flow can be used to send invocations with a boolean value to that very-same object with address DD:12. Similarly, invocations could be sent to any other object (real or virtual) in any other place just by stating its IDM address.