Three main models of device-to-device communication in the Web of Things and then discussion on asynchronous patterns.
By Sergey Efremov, Nikolay Pilipenko and Leonid Voskov
Higher School of Economics, Moscow, Russia
via Science Direct
The recent advances in technology enabled the transition to the Internet of Things (IoT), in which physical objects around us become an integral part of the global information system. A major technical challenge, however, is to make these numerous objects interact seamlessly with each other.
In this article, we first give an overview of the three main models of device-to-device communication in the Web of Things and then discuss asynchronous patterns. Asynchronous being the most important, as many of today’s widely used web standards were not designed for it.
1. Direct Access
In this scenario, one of the interacting devices acts as a web-server. It is possible that in the near future most of embedded systems will support a complete TCP/IP protocol stack to allow each device to have its own IP-address and provide a RESTful API. However, it requires high processing capabilities and cannot be implemented on every device.
There are a number of solutions on the market that implement the described approach. For example, in the Sun SPOT project [1] each sensor (luminance, temperature, accelerometer and others) has an integrated server providing RESTful interface. The devices connect to a global network through a specialized proxy server.
2. Communication through a Gateway
Providing direct network access is a complicated task for embedded systems. There is a significant number of technologies that focus on maximizing energy-efficiency of individual devices. As a result, their processing capabilities are very limited and it becomes impossible to implement a complete network stack on a microcontroller. A good example is wireless sensor networks.Usually a sensor node only implements 2 or 3 bottom OSI layers, which in most cases are not directly compatible with TCP/IP (protocols like IEEE 802.15.4, Bluetooth, ZigBee).
The problem can be solved by using internet gateways, which on the one hand use HTTP for communication with each other and on the other hand support specialized protocols for interacting with devices. A gateway has a separate IP-address in the global network and acts as a web-server.
For example, the Ploggs system [1] consists of intellectual wireless sockets measuring energy consumption and transmitting data through Bluetooth and a central gateway with a web server installed, which allows users to gain remote access to devices.
3. Middleware Data Platforms:
The primary goal of such platforms is to provide a centralized point to store, search, control as well as to visualize data from smart things. A server or a group of servers is maintained to store data from all connected devices. Different information systems can be built on top of such platforms, e.g. for monitoring equipment or human health.
In the case of an open platform, a toolkit for developing custom scenarios of interaction between smart devices can be provided.
A number of data platforms are available on the market today. Some of them are strictly proprietary solutions and not designed for public use, some others were developed as open systems [2].
Asynchronous Web of Things
Providing a downlink to a smart device in WoT, so that it can quickly get updates or commands, and organizing interaction of autonomous devices in multi-agent systems [3] are not at all easy tasks. In general, it does not depend on which of the three schemes discussed above an individual device uses.
Historically web standards were oriented towards synchronous communication – a client sends requests to a server, which in turn responds with the data required. Transition to Web 2.0 with its dynamic content lead to the appearance of multiple asynchronous schemes built on top of the standard HTTP.
There are several asynchronous technologies grouped by the name of COMET [4]: polling, long polling, forever frame and server sent events.
The most straightforward technique is polling. When using polling, a client sends regular requests to server checking whether any data is ready for it. The obvious disadvantage is large overhead required for message transmission even though no data may be ready for the client. The technique can be optimized by making polling interval dynamic, depending on what events are expected from the server.
When using long polling a client sends a request to a server, which then keeps the connection open until data is ready to be sent back. The approach is very similar to regular polling except that intervals between client requests are dynamic and depend on data update frequency on the server. The drawback of long polling is an increase in the number of open connections on the server.
The forever frame technique utilizes a hidden iframe integrated into a web-page. This iframe is sent as a chunked block, which enables dynamic transferring of new data while the connection is active. When an event is ready to be sent to a client, the server creates a new "script" block, which is sent through the iframe connection. As soon as the web browser receives the whole block it executes javascript code that is inside. Although this is a very convenient approach supported by all browsers, it cannot be easily implemented in resource-constrained devices.
For Server-Sent Events (SSE), which are part of the HTML5 standard, a client subscribes to server events through a similar approach with a chunked block. The connection is kept open after the initial request and the server immediately send new events to the client through this connection. At the present time, this technique is not supported by all browsers.
The WebSockets technology [5, 2], which is also a part of HTML5, is seen by many as the best solution proposed so far for asynchronous communication on the web. It is built on top of the HTTP protocol and provides the functionality of classic sockets with duplex communication channels. At the moment of writing the present paper, only drafts of the standard are available and the standard is not supported by all browsers and proxy servers.
However, none of these schemes can be directly applied to the Web of Things for a number of reasons. Firstly, devices in WoT are often resource limited, thus it is not possible to implement protocols that require parsing and execution of Javascript code on a microcontroller.
Secondly, in the traditional web, a server is assumed to be ubiquitous in terms of available resources and supported protocols. In the WoT a service implementing RESTful API can operate on an end device. This device may also have its own preferences concerning the choice of particular communication protocol. As a result, a two-sided agreement on a protocol is required.
Finally, smart devices often have changeable requirements to the quality of service and hence the protocol. For example, a battery-powered alarm sensor will have different preferences for a regular beacon message and a message signaling an alarm. The first one may be transmitted with energy conservation in mind, while the second one has to be passed as quickly as possible.
As it is stated in [6], different protocols have different characteristics in terms of delay, overload and energy consumption.
Considering all these factors, we propose to use an adaptive scheme of protocol choice, which has a handshaking procedure before the actual data exchange takes place. This handshaking procedure takes into account preferences of both sides and chooses the best protocol for a particular moment in time, according to a number of criteria.
Publication Details:
1877-7058 © 2015 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer review under responsibility of DAAAM International Vienna doi: 10.1016/j.proeng.2015.01.486 ScienceDirect
References:
[1] D. Guinard, V. Trifa, T. Pham, O. Liechti. Towards physical mashups in the Web of Things. Proc. of the Sixth International Conference on Networked Sensing Systems, (INSS), 2009, pp. 1–4.
[2] Balamuralidhara, P., Misra, P. and Pal, A. (2013) Software Platforms for Internet of Things and M2M. Journal of the Indian Institute of Science, 93, 487-498.
[3] B. Gastermann, M. Stopper, B. Katalinic. Outline of an Autonomous Control Concept for Continuous Flow Production using RFID and Agent-Based Services, Annals of DAAAM for 2010 & Proceedings of the 21st International DAAAM Symposium, 20-23rd October 2010, Zadar, Croatia, Katalinic, B. (Ed.), pp. 0863-0864, Published by DAAAM International Vienna, Vienna.
[4] S. Duquennoy, G. Grimaud, J.-J. Vandewalle. The web of things: interconnecting devices with high usability and performance. In Proceedings of ICESS ’09, HangZhou, Zhejiang, China, May 2009, pp. 323-330.
[5] Si-Ho Cha, Yoemun Yun. HTML5 Standards and Open API Mashups for the Web of Things. Computer Applications for Web, Human Computer Interaction, Signal and Image Processing, and Pattern Recognition Communications in Computer and Information Science, 342, 2012, pp. 189-194.
[6] E. Estep. Mobile html5: efficiency and performance of WebSockets and server-sent events [Master’s thesis]. School of Science Double Degree Programme NordSecMob, Aalto University, June 28, 2013.
For Server-Sent Events (SSE), which are part of the HTML5 standard, a client subscribes to server events through a similar approach with a chunked block. The connection is kept open after the initial request and the server immediately send new events to the client through this connection. At the present time, this technique is not supported by all browsers.
The WebSockets technology [5, 2], which is also a part of HTML5, is seen by many as the best solution proposed so far for asynchronous communication on the web. It is built on top of the HTTP protocol and provides the functionality of classic sockets with duplex communication channels. At the moment of writing the present paper, only drafts of the standard are available and the standard is not supported by all browsers and proxy servers.
However, none of these schemes can be directly applied to the Web of Things for a number of reasons. Firstly, devices in WoT are often resource limited, thus it is not possible to implement protocols that require parsing and execution of Javascript code on a microcontroller.
Secondly, in the traditional web, a server is assumed to be ubiquitous in terms of available resources and supported protocols. In the WoT a service implementing RESTful API can operate on an end device. This device may also have its own preferences concerning the choice of particular communication protocol. As a result, a two-sided agreement on a protocol is required.
Finally, smart devices often have changeable requirements to the quality of service and hence the protocol. For example, a battery-powered alarm sensor will have different preferences for a regular beacon message and a message signaling an alarm. The first one may be transmitted with energy conservation in mind, while the second one has to be passed as quickly as possible.
As it is stated in [6], different protocols have different characteristics in terms of delay, overload and energy consumption.
Considering all these factors, we propose to use an adaptive scheme of protocol choice, which has a handshaking procedure before the actual data exchange takes place. This handshaking procedure takes into account preferences of both sides and chooses the best protocol for a particular moment in time, according to a number of criteria.
Download the Paper - LINK
Publication Details:
1877-7058 © 2015 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer review under responsibility of DAAAM International Vienna doi: 10.1016/j.proeng.2015.01.486 ScienceDirect
References:
[1] D. Guinard, V. Trifa, T. Pham, O. Liechti. Towards physical mashups in the Web of Things. Proc. of the Sixth International Conference on Networked Sensing Systems, (INSS), 2009, pp. 1–4.
[2] Balamuralidhara, P., Misra, P. and Pal, A. (2013) Software Platforms for Internet of Things and M2M. Journal of the Indian Institute of Science, 93, 487-498.
[3] B. Gastermann, M. Stopper, B. Katalinic. Outline of an Autonomous Control Concept for Continuous Flow Production using RFID and Agent-Based Services, Annals of DAAAM for 2010 & Proceedings of the 21st International DAAAM Symposium, 20-23rd October 2010, Zadar, Croatia, Katalinic, B. (Ed.), pp. 0863-0864, Published by DAAAM International Vienna, Vienna.
[4] S. Duquennoy, G. Grimaud, J.-J. Vandewalle. The web of things: interconnecting devices with high usability and performance. In Proceedings of ICESS ’09, HangZhou, Zhejiang, China, May 2009, pp. 323-330.
[5] Si-Ho Cha, Yoemun Yun. HTML5 Standards and Open API Mashups for the Web of Things. Computer Applications for Web, Human Computer Interaction, Signal and Image Processing, and Pattern Recognition Communications in Computer and Information Science, 342, 2012, pp. 189-194.
[6] E. Estep. Mobile html5: efficiency and performance of WebSockets and server-sent events [Master’s thesis]. School of Science Double Degree Programme NordSecMob, Aalto University, June 28, 2013.
.jpg)
