Wireless Sensor Networks (WSNs) are generally used to collect information from the environment. The gathered data are delivered mainly to sinks or gateways that become the endpoints where applications can retrieve and process such data. However, applications would also expect from a WSN an event-driven operational model, so that they can be notified whenever occur some specific environmental changes instead of continuously analyzing the data provided periodically. In either operational model, WSNs represent a collection of interconnected objects, as outlined by the Internet of Things.
Additionally, in order to fulfill the Internet of Things principles, Wireless Sensor Networks must have a virtual representation that allows indirect access to their resources, a model that should also include the virtualization of event sources in a WSN. Thus, in this paper a model for a virtual representation of event sources in a WSN is proposed. They are modeled as internet resources that are accessible by any internet application, following an Internet of Things approach. The model has been tested in a real implementation where a WSN has been deployed in an open neighborhood environment. Different event sources have been identified in the proposed scenario, and they have been represented following the proposed model.
Advantages and drawbacks of WSN virtualizations are described in and have been outlined in the previous section. The foundations of the WSN virtualization implementation to be detailed in the coming sections are described in the following paragraphs. nSOM is a middleware architecture that virtualizes a WSN node capabilities so that any tiny application could be run in such nodes. Moreover, such tiny applications might virtualize new capabilities in the node that is hos ting them, extending the catalog of its available functionalities. It has been designed for constrained devices and targets as objectives low memory and processor footprint utilization. The core elements in nSOM (as the service registry manager or the context manager) comply with the SOA principles, decoupling what an entity is able to do from the specific way the entity is implemented.
In this proposal the gateway provides a virtual representation of the nodes in the network. It does that by associating a virtual entity to the exposed resources, and thus defining a set of services that give access to the resources. It can also create new resources on demand to manage the new events that are notified by the nodes in the WSN. And everything is done according to the m odel put forward. Figure 1 shows a graphical depiction of the proposed model.
In our case the sensors are accessed by polling, so the Orchestrator periodically sends a request message to the registered services in order to get the new sensed data, as seen in the messages labeled as 1.X and 2.X in Figure 4. And then, as explained before, if the processing of the retrieved data implies the generation of an event, the Orchestrator follows the same behavior as any other event source, sending the same type of message directly to the Event manager as seen in Figure 4.
RESULTS AND DISCUSSION
Discovery time is outside the scope of this paper, as it depends on other issues like the time required for the transmission of the messages between the nodes and the gateway. The environmental conditions have also an influence in the transmission, and therefore in discovery time. For the other two, Figure 5 shows the relation between both of them after 230 tests.
Another datum of interest is the time required for an event to be dispatched from the gateway once it has been received from the WSN. This time is measured from the moment an event is notified to the gateway to the time the POST message is delivered to the proper subscribers. Figure 9 shows the results of this after 300 tests.
The communication protocol used by the WSN nodes, mentioned in the previous sections, is part of the nSOM middleware and enables its components to interoperate with each other. It is not standard, however, but it is quite similar to COAP as they both observe the ROA principles and avoid increasing the network or the node computational overhead significantly. Therefore, a significant improvement should be replacing the nSOM protocol by COAP, as the latter is a standard one recommended in several IoT based solutions. Nonetheless, COAP messages should be embedded straight to MAC layer frames, similar to the proposal, to counter the negative impact on the performance of the COAP protocol stack, normally handled over TCP/IP.
Another significant issue that would leverage system interoperability is the pervasive use of semantic annotations, complying with well-accepted ontologies. One of the most overwhelming activities when integrating solutions from different stakeholders is mapping each one’s information models. The system components must interchange semantically annotated data complying with a reduced set of well-accepted ontologies to overcome such drawbacks. Thus, providing the recipient with enough knowledge for unambiguous data processing is granted. Regarding service composition, it should be kept in mind that it is one of the proposed design patterns for Service Oriented Architectures.
As an Orchestrator has been designed and developed, the importance of orchestration and choreography should be acknowledged, as they are two typical, well-established ways to design a service composition. In the proposed model the orchestration concept has been selected, as it requires no extra capabilities in the already deployed basic sensors. A basic set of rules (capable of creating composed services for obtaining the average mean of a set of measurements, and creating new events when the measurements of the sensors go beyond certain threshold) has been defined. An additional rule has been added to the set so the composed service can also generate an event when the rate of change in the measurements exceeds some value.
Source: Technical University
Authors: Nestor Lucas Martinez | Jose-fernan Martinez | Vicente Hernandez Diaz