ABSTRACT
Recently, researchers are focusing on a new use of the Internet called the Internet of Things (IoT), in which enabled electronic devices can be remotely accessed over the Internet. As the realization of IoT concept is still in its early stages, manufacturers of Internet-connected devices and IoT web service providers are defining their proprietary protocols based on their targeted applications. Consequently, IoT becomes heterogeneous in terms of hardware capabilities and communication protocols. Addressing these heterogeneities by following open standards is a necessary step to communicate with various IoT devices. In this research, we assess the feasibility of applying existing open standards on resource-constrained IoT devices.
The standard protocols developed in this research are OGC PUCK over Bluetooth, TinySOS, SOS over CoAP, and OGC SensorThings API. We believe that by hosting open standard protocols on IoT devices, not only do the devices become self-describable, self-contained, and interoperable, but innovative applications can also be easily developed with standardized interfaces. In addition, we use memory consumption, request message size, response message size, and response latency to benchmark the efficiency of the implemented protocols. In all, this research presents and evaluates standard-based solutions to better understand the feasibility of applying existing standards to the IoT vision.
PUCK OVER BLUETOOTH
Figure 2. The overall workflow for accessing the sensor measurements
According to Figure 2, a client first runs the PUCK Detector application to discover PUCK-enabled devices. The PUCK Detector then sends out a PUCK command to devices which are in the PUCK mode. After successful discovery, a connection is established via Bluetooth and the client can send other PUCK commands to the device. Since PUCK provides access to data saved in the PUCK memory, it does not support communications in the device protocol.
In order to handle such communications, we apply another OGC standard named Sensor Interface Descriptor (SID). Firstly, a SID file is stored on the device which includes the description of the device protocol. Then, the client uses the SID Interpreter to retrieve sensor readings in the instrument mode, and finally the data is uploaded to an online SOS.
Figure 3. Procedures of the sensor protocol
The purpose of the sensor protocol is to allow users to simply query sensor capabilities, observations, and presentations of observed features in the instrument mode. Figure 3 depicts the procedures of the sensor protocol. We designed the sensor protocol based on the concept of OGC SOS to serve the demonstration purpose. Most of the terms used in this part follow the terminology in the OGC SOS.
Because of the limited resources for IoT instruments, the command and response formats should be considered as simply as possible. Therefore, unlike the SOS applying XML as the format, this protocol simply defines “separators” (e.g., {#, :, |}) to format requests and responses (Figure 3). Similarly with the OGC SOS, we define the GETCAPABILITIES operation in order to show the capabilities of the device.
Figure 4. The system architecture supporting the PUCK protocol
As shown in Figure 4, the architecture we proposed for the device follows a layered structure which has three major layers: Communication Layer, Service Layer, and Sensor Layer.
Communication Layer: This layer includes the Bluetooth hardware and its protocol. When a request is received, the layer forwards the request string to the service layer for processing. After the service layer finishes processing the request, a response string is returned to the communication layer to be sent back to the client
Service Layer: The service layer handles business logic of the system. This layer itself consists of three modules: sensor data repository, response engine, and memory management unit (MMU). Sensor data repository archives historical records of sensor observations. In order to parse the commands and compose the response messages on low-memory IoT devices, we propose a response engine. This unit is equipped with a buffering mechanism to handle large requests and responses.
Sensor Layer: The sensor layer consists of physical sensors and a sensor controller. The sensor controller tasks sensors to collect sensor observations. Next, it sends the collected sensor observations to the sensor data repository of the service layer.
TINYSOS
Figure 5. The system architecture supporting the TinySOS protocol
As we saw from the previous sub-section, to support the three core operations of the SOS, an IoT device needs the functionalities to validate the HTTP request type (i.e., GET, POST) and content type (i.e., text/xml), in order to parse the XML request, and to create the XML response. To achieve these functionalities, we present the proposed system architecture of the TinySOS. There are three major layers in the TinySOS service (Figure 5), including Communication Layer, Service Layer, and Sensor Layer.
SOS OVER COAP
Figure 6. High level view of the SOS over CoAP strategy
The major contribution of this section is that we are the first to bind the OGC SOS to the CoAP proxy denoted as SOSCoAP proxy. According to Figure 6, SOSCoAP proxy can communicate through CoAP regulations to the CoAP nodes (i.e., IoT devices) from one side, and it can speak through the SOS standard from another side. As a result, we achieve interoperability while maintaining minimal resource consumption on IoT devices.
Figure 8. The architecture of the SOSCoAP Proxy
Figure 8 shows the architecture considered for the SOSCoAP proxy. The SOSCoAP proxy consists of a CoAP proxy and a SOS proxy. For the CoAP proxy, we use jCoAP, which is an open source Java library. While the CoAP proxy is important, we do not address its components in this section as they are completely unchanged from the CoAP specification.
OGC SENSOR THINGS API
Figure 9. Ecosystem of the OGC Sensor Things API
The Sensor Things API follows a REST-like web service interface to access the registered resources on the server. Each resource is assigned a unique identification (UID) by the server. The API supports the four basic operations of persistent storage: CREATE, READ, UPDATE, and DELETE (CRUD).
The API also consists of two major profiles: Sensing Profile and Tasking Profile, which are built based on the OGC Sensor Web Enablement standards. The Sensing Profile defines an interoperable framework to manage and access sensors and observations, whilst the Tasking Profile introduces an interoperable way to submit tasks to control sensors and actuators. Figure 9 depicts the ecosystem of this API.
Figure 10. The device architecture supporting the OGC Sensor Things API
As describe in the former sections, devices supporting the OGC Sensor Things API follow a system architecture to process requests and responses. In this section, we describe the proposed system architecture for IoT devices displayed in Figure 10. In this architecture, the three common layers are introduced which includes Communication Layer, Business Logic Layer, and Sensor/Actuator Layer.
EVALUATION AND RESULTS
Figure 11. Request size evaluation for the get observation request
Both IoT devices and the network they use are highly constrained. This means that the payload packet size is very important. To identify the efficiency of the above standard protocols, we recorded the request size generated for a specific use case (i.e., get one sensor measurement) that is possibly the most widely used. To do this, we use Wireshark, a network protocol analyzer software for all tests except PUCK. That is Wireshark is unable to monitor the serial ports that are the communication ports of the PUCK.
Thus, to measure the PUCK request size, we simply count the characters of its plain text request. According to Figure 11, PUCK generates the smallest request since the request is made of a short string of characters with no header, description or complicated format. In addition, CoAP request is at least 67% smaller in comparison with other Internet-based protocols. This efficiency is due to using UDP instead of TCP in the transport layer, which makes the header size much smaller. The simple web service communicates through HTTP GET request with no request content.
Figure 15. Response latency vs. the number of sensor readings (removed TinySOS)
Figure 15 removed the TinySOS trend in order to determine the behavior of other implementations. The SOS over CoAP has more latency than PUCK since the CoAP communicates over the World Wide Web.
Due to the fact that the data service of the Sensor Things is a regular PC, if we ignore this protocol, the PUCK over Bluetooth is the most efficient implementation in this experiment. For the PUCK evaluation, we applied Device Monitoring Studio software in order to monitor the serial port of the PC.
CONCLUSIONS
We conclude this paper in the final section by summarizing the research that has been carried out and outlining the conclusions drawn from the result. We also comment on the limitations and propose areas for future work.
We began by choosing a class-1 IoT object as categorized in the framework of Bormann et al. for our development platform. Firstly, we equipped the class-1 IoT device with a Bluetooth transceiver in order to establish wireless network within a limited range. We standardized its connection by means of OGC PUCK. Due to the fact that Internet access is a key requirement for IoT devices, we applied additional software components to enhance this functionality for the Bluetooth-enabled PUCK instrument.
In the second stage, we removed the intermediary gateway in the path between user and IoT device by developing a web service on a Thing itself. Since device owners or manufacturers might have their own design for data representation, we introduced a lightweight version of the OGC SOS, TinySOS. As a result, the sensor measurements could be accessed remotely in a standardized way simply through a web browser.
In accordance to the complicated nature of the OGC SOS, we proposed another approach which was more suitable for the class-1 IoT devices. As such, the third contribution of this research was integrating CoAP into the OGC SOS for which the SOS operations were processed on the CoAP proxy with enough computational resources.
Source: University of Calgary
Authors: Mohammad Ali Jazayeri | Steve H.L.Liang | Chih-Yuan Huang
>> 200+ IoT Led Projects for Final Year Students
>> IoT Software Projects for Final Year Students
>> More Wireless Bluetooth Projects for Final Year Students