The integration of Wireless Sensor Networks and the Internet is growing in importance as WSNs have been employed in a great variety of applications which need a common means to share data over the Internet. In the recent years, many solutions have been proposed to provide that integration. The simplest and most popular one is the gateway-based approach
Mobile agents have also been used as an approach to dynamically access the WSN from the Internet
In order to overcome the aforementioned problems, this chapter introduces a framework for integrating WSNs and the Internet by allowing the interoperability of their services. Our approach aims at integrating applications (considered as services) instead of networks (i.e., protocol stack and/or logical address formats mapping). This service abstraction is an important advantage, since it offers to the application developers an easy and transparent way to integrate the networks with seamless handling of addresses and protocols. Furthermore, the provision of the capability of transparently requesting services in both directions is another benefit offered by our approach. Although sensors are typically providers of sensed data, there are some cases where it is better for the sensor to request a service outside the WSN. That happens, for instance, when the application is too computationally demanding, when it needs to store a huge amount of data, and/or when it requires global knowledge of the WSN.
The rest of this chapter is organized as follows. Section ▭ describes a scenario of usage and an overview of the framework. The framework elements, namely Smart, WISeMid, SAGe and Clever, are presented in Sections ▭, ▭, ▭ and ▭, respectively. Section ▭ discusses an energy consumption evaluation of those elements, and a real application that emphasizes the usefulness of the sensor nodes' capability of being service requestors is also analyzed. Finally, Section ▭ presents some concluding remarks.
2. Illustrative scenario
This section presents a scenario of usage of the framework which is depicted in Figure ▭ and comprises two distributed applications.
The first application monitors an area (such as a house, a factory, etc.) to detect and report the presence of intruders. It is composed by two services: Surveillance and Recognition. The Surveillance service runs in a sensor node and captures images of any moving target. Each captured image has to be analyzed to verify if the moving target is really a potential threat. This is necessary to avoid reporting the presence of a cat, for example. Therefore, the application has to perform an image recognition procedure to classify the moving target as human or non-human. This kind of task is too computationally demanding and resource consuming, which makes it non-suitable for the resource constraints of the sensor nodes. Considering this, it may be more worthwhile for the Surveillance service to invoke an image recognition service outside the WSN instead of performing itself that task.
Now consider that an Internet host provides the (image) Recognition service, which offers an operation that receives an image, analyzes it and classifies it as human or non-human. The Surveillance service sends the captured image to the Recognition service and, if it signals that the target is a human, the Surveillance service reports the presence of the intruder.
The second distributed application monitors the temperature of an area (such as a forest) to detect high temperatures and prevent potential fires. This application is composed by two services: Monitoring and Temperature (see Figure ▭). The Monitoring service runs in an Internet host and keeps track of the environment temperature of the area of interest. For that purpose, it uses a Temperature service that runs in a WSN which has been deployed in that area. This service measures and returns the environment temperature value. Hence, to observe the changes in temperature, the Monitoring service calls the Temperature service periodically.
Both described applications spread out through the Internet and a WSN. In order to allow the construction of this kind of distributed application composed by services from both networks, some issues should be addressed. First, there must be a uniform way of describing those services regardless of their provider being sensor nodes or Internet hosts. Then, based on that description, there must be a mechanism to discover those services and use them. Those services should be able to communicate with each other irrespective of their location. Also, the service location should not influence the way it is accessed. In other words, a service provided by a WSN node should be accessed the same way that a service provided by an Internet host.
Additionally, the distributed applications described above focus on specific areas of interest. The surveillance, for instance, would define the border region of a WSN as a critical one to be monitored, whereas forest fire detecting applications may define clearings that resulted from previous fires as the critical regions to be monitored (since they tend to be more propitious for new fires due to their dry vegetation and soil). Therefore, there should be a mechanism to select a group of nodes in the WSN so such areas can be delimited.
Those issues are handled by the presented framework as described in the following sections.
2.1. Framework overview
For the purpose of enabling the construction of applications that are distributed between WSN's and Internet's nodes, the framework comprises four components: a service model to describe services from both networks; a communication infrastructure (middleware) that enables the interoperability of WSN's and Internet's services; an advanced gateway which is responsible for providing the location and access transparency for the services' communication; and a service composition tool which enables the creation of logical regions in the WSN by just composing Web services that are available on the Internet.
The service model is named Smart (Service model for integrating Wireless Sensor Networks and the Internet)
Once the services have been described, a middleware called WISeMid (Wireless sensor network's and Internet's Services integration Middleware)
The access and location transparency provided by the middleware is performed by the gateway, which is called SAGe (Sensor Advanced Gateway)
The service-level integration of the WSNs and the Internet is enhanced by a Web service composition tool named Clever (Composing logical regions via services). This tool enables the definition of logical regions in WSN by composing Web services available in the Internet. Having a Web service acting as a proxy to each WSN node, the definition of a logical region in the WSN consists of defining a Web service composition. Once that composition is deployed, a new Web service is created and an invocation to it is passed to all sensors belonging to the WSN logical region and represented by the composition.
The next sections will describe in details each of those components.
The first element of the framework is Smart (Service model for integrating Wireless Sensor Networks and the Internet), a service model that is suitable for both Internet and WSN services, promoting the integration of those networks. In other words, both services designed for a WSN and services designed for the Internet may be described using the Smart model. Although there are many service models for the Internet
Either on the Internet or in a WSN, a service provider needs to characterize its service by making available some information about it. The essential and simplest information that must be available is the service identification and what it can do. The service interface offers that information by specifying the service name and the operations it provides. A description of how the service provides its operations may also be exposed. That information concerns the service functionality and thus compose the service functional description.
A service user may be interested in knowing specific details of the service provider, the service implementation or its running environment. That information is called nonfunctional description and may include, for instance, the bit rate of a service provider or its location.
Furthermore, for a service to be accessed, information on how to interact with it needs to be defined. That is so called interoperability information and includes the format of the messages the service understands and its access point.
With that in mind, the Smart model defines a service as being composed by functional and nonfunctional descriptions, from which depends its interoperability information.
3.1. Functional description
To be able to request a service and the execution of one of its operations, a service user (client) needs first to be aware of the service name and what operations it can perform. More than that, the client needs to know the input and output data of a successfully execution of the service, as well as the possible errors that an unsuccessful invocation may generate in order to handle them. That information is commonly referred to as the service interface.
Some services share the name and the operations they provide, but may produce different results by performing different actions or being under different conditions to execute the same operation. Those services are said to have the same type, and the differences between them are expressed using properties, which assume different values from service to service.
Another service characteristic that concerns its functionality is the period of time the service instance needs to exist, which is known as its lifecycle and is closely related to maintaining the service state between subsequent invocations. According to the lifecycle patterns defined in
Considering all that information about the service functionality, the Smart model defines the service
As previously stated, the interface contains the service name and the operation(s) it provides (see Figure ▭). The service's
Concerning the service operations, each
In the WSN context, an operation is either a
The service behavior includes a
3.2. Nonfunctional description
The functional description specifies what the service can do, but describing how the service can do it may be very useful or even necessary for a service user to choose the service that best fits their needs. This extra description includes characteristics (properties) that are not directly related to the functional description of the service, such as the server geographic location or the service security, and therefore is commonly referred to as nonfunctional description.
A particular subset of nonfunctional characteristics is very important for choosing the proper service: quality of service (QoS) parameters. Although the term QoS is typically related to network performance parameters (such as bandwidth, latency and error rate), in a service related context it covers a wider range of service properties which can be used as quality indicators, including, for instance, accuracy, dependability, robustness, security, customer service, etc.
With that in mind, Smart defines that the
The Smart model elements which describe properties (
In Smart, each
The service properties are actually classified in property types, which are related to the
3.2.2. QoS Parameters
QoS parameters refer to service properties that can be used as indicators of quality, as said previously. Based on the SMEPP service model description
Some QoS parameters are composed by two or more parameters. For example, the “performance” parameter is composed by “response time”, “throughput” and “latency”. Such compound QoS parameters may be described by a
Also, QoS parameters may affect other ones and this influence is expressed by the
3.3. Interoperability information
Before being able to exchange messages, the services need to find each other. By finding, we mean searching and retrieving information about the services which satisfy some user defined conditions. The service discovery procedure is responsible for that task and is implemented by some special services that offer operations for registering and searching services. The most simple discovery service is called Naming service and locates a service based only on the service name. Trading service is another special service that implements a discovery procedure, which discovers a service based on its type and a set of property values that describe it.
Still concerning service interoperability, a set of policies may be defined to guide the services interaction. Different policies may be involved in the process of service discovery to check the constraints that either the service provider or the service user specify to protect the process of communication or sharing the information.
|(a) UML Subsystem diagram of Interoperability information||(b) UML Class diagram of Policy|
UML diagrams of Interoperability information
In Smart, all that information that concerns the way a service may interact with another is represented by
As stated previously, policies may be used by either the service provider or the service user to protect the process of communication or sharing the information. For that end, each
In the Smart model, a
Constraints may contain quantifiers (e.g.: for all, there exists), constants, data types (e.g.: integer, String), operators (arithmetic operators, comparison operators, boolean operators, implication operators) and structural constructs (e.g.: let in, if then else)
Since Smart aims at integrating the Internet and WSNs, it specifies two kinds of end point to a service, one for each network. For an Internet service, the
As its name suggests, the
Smart defines two discovery procedures: the
As stated before, the trading service is concerned with discovering a service based on its type and a set of property values that describe it. The act of registering information about a service in the Trader is usually called exporting a service offer. A service offer consists of the service type name, a reference to the interface that is provided by the service, and zero or more property values for the service. Those properties correspond to the ones that are listed in the associated service type (and parents), and specifying a value for them depends on the mode assigned to each one of them. A value must be provided for every property that has been defined as mandatory (including both Mandatory and MandatoryReadOnly modes) in the service type. Providing a value for the other properties is optional.
As mentioned earlier, WISeMid provides a communication infrastructure for services interaction, where applications running in the Internet/WSN nodes act as service providers or service users that are able to communicate irrespective of being at the same network or not. As depicted in Figure ▭(a), those applications (services) should be developed in different technologies, such as Web Service, Java RMI, EJB and JMS, although WISeMid current implementation supports only WISeMid services and Web services.
|(a) WISeMid logical view||(b) WISeMid physical view|
Figure ▭(b) presents a physical view of how WISeMid spreads out through the Internet and WSN. The WISeMid implementation for WSN and Internet is not the same, as they have different requirements and components (that will be explained in the subsequent sections). Physical communication is performed through an Internet host that is connected to the WSN sink node via a serial port (USB). This host executes a special WISeMid service called SAGe, which acts as a proxy between both networks (see Section ▭).
The first step to enable the services interaction is to specify a notation to describe a service. For this particular purpose, we have defined the WISeMid IDL – WISeMid Interface Definition Language. It enables us to define service interfaces in a uniform way, wherever the service runs (Internet or WSN) and whatever the implementation language (Java or nesC). Based on Smart model definition of the service interface and its properties (see Sections ▭ and ▭), the general structure of a service definition in WISeMid IDL is presented below:
First, the module (package) that contains the service should be specified (1), followed by the service interface, which includes its name (2) and provided operations (3). Each operation has a name, input/output typed parameters and may raise exceptions. An operation is by default a request-response operation, but it may be defined as a one-way operation by using the reserved word
Property values are defined in
The service definition in a WIDL file may be used for automatic code generation. To perform that task, we have developed a tool, namely ProxiesGen, that can interpret a WIDL file and generate the proxies (i.e., stub and skeleton) related to the described service according to a command line parameter, which specifies if the service is supposed to be provided by a WSN node or by an Internet host. When service type and properties are defined, ProxiesGen adds to the server code the creation and registration of the service type in the Trader. Also, a service offer with the defined property values is created and exported.
Based on the DOC middleware layers
The Common Services layer includes services that are not particular to a specific application domain: Aggregation, which performs sensor data aggregation; Grouping, which defines clusters inside the WSN; Naming and Trader, that store information needed to find and access a service (they run in the Internet); and SAGe, that is in charge of converting and forwarding messages from/to WSN (it runs in the Internet). Additionally, SAGe also provides location transparency acting as a service proxy between both networks, as described in Section ▭.
The Distribution layer includes the following elements: Stub, Requestor, Skeleton and Marshaller, which are basic middleware elements
The Infrastructure layer consists of the Client Request Handler and the Server Request Handler, which handle network communication using the communication facilities provided by the operating systems, e.g., sockets (Windows) and ActiveMessageC (TinyOS).
The WISeMid implementation is divided into two parts, one for the WSN nodes, developed in nesC, and another for Internet hosts, developed in Java. The elements of the infrastructure layer (Client Request Handler and Server Request Handler) and of the distribution layer (Stub, Skeleton, Requestor, Marshaller and WIOP) have been implemented in both languages, as nodes from both networks may play the role of user or provider of the service. Actually, due to sensor nodes' limited resources, some elements are not present in the WSN: the Requestor is not implemented by the WSN service users (its functions are deployed by the Stub), and WIOP messages are treated as byte sequences, making the Marshaller unnecessary.
The above elements, except for WIOP, are basic middleware elements, thus their implementation will not be described here. The Aggregation and the Grouping elements are common services that run in the WSN. The Aggregation service may be considered as a method to save energy in the sensor nodes and therefore it is described in Section ▭ with other energy-saving approaches that have been implemented in WISeMid. The Grouping service was implemented as a web service composition approach that enables grouping the WSN nodes into logical regions. This approach is used by Clever and described in Section ▭.
As SAGe has an essential role in WISeMid, it is described in Section ▭. The other architecture elements (WIOP, Naming and Trader) are described as follows.
Specified by the Smart model as the message exchange pattern to enable service interoperability (see Section ▭), the WISeMid Inter-ORB Protocol (WIOP) is a GIOP-based protocol that defines the Request/Reply messages between clients and servers. A WIOP message is divided into header and body, as depicted in Figure ▭(a).
|(a) WIOP Message header||(b) WIOP Message body|
WIOP (WISeMid Inter-ORB Protocol)
The WIOP message header is composed by the following fields:
The WIOP message body may contain a Request or a Reply message. Those messages, which have also a header and a body, are illustrated in Figure ▭(b).
The Request message header's main fields are:
The Request body consists of the number of arguments (
The Reply message header main fields are:
Besides saving energy by its reduced size, the sensor message format also concerns about sensor limited processing as it is already deployed as a byte array, avoiding the need for a Marshaller implementation.
The WISeMid Naming Service, the Trader and Internet services use the Internet format (), while the sensor services use the WSN format (). Only SAGe handles both formats.
4.3.2. Naming service
The WISeMid Naming Service implements the Naming discovery procedure defined by Smart in Section ▭. It stores the references of services executing in the Internet and WSN in such a way that a service may only be accessed/used after being registered in the Naming Service.
The Naming Service's interface includes five operations: Bind, to register a service by its name, associating it with its reference; Lookup, to return the reference associated to a service name; Rebind, to change the reference that is associated with a service name; Unbind, to unregister a service name; and List, to list all registered services. The service reference includes the service ID, endianness and the Internet end point of the service, which consists of its IP address and port number. Note that, since the Naming service runs in the Internet, the service references handled by it have no information about WSN end points. Nevertheless, WSN services may also be registered using the Internet end point of SAGe, which handles another type of service reference to store WSN end point information, as described next. It is worth mentioning that WISeMid Naming Service has a flat architecture, with a global name space.
4.3.3. Trading service
WISeMid's Trader implements the Trading service, another discovery procedure described by Smart (see Section ▭). It has a graphical user interface (GUI) that allows users to define service types and property types, as well as export and query service offers.
The service type comprises a name, a reference for the service interface, a parent and a list of property types (those last two are optional attributes). When defined, each property type comprises a name, a property value type (e.g., integer, string, float, etc.) and a mode (which defines whether a property is mandatory and/or readonly) (see Section ▭).
A service offer is the information that is registered in the Trader about a service and the act of registering that information in the Trader is called exporting a service offer. As stated in Section ▭, a service offer consists of the service type name, a reference to the interface that provides the service, and zero or more property values for the service, where those properties correspond to the ones that are listed in the associated service type and specifying a value to them depends on the mode associated to each one of them. A value must be provided for every mandatory property (both
4.3.4. Energy-saving methods
Since energy is a scarce resource in WSNs, performing energy-saving methods is essential to extend the sensor nodes lifetime and thus the WSN lifetime. This section presents some energy-saving approaches that have been implemented in WISeMid
Besides this in-network data aggregation, which is used by most middleware, WISeMid implements an aggregation service which aggregates the last
Reply storage timeout
Considering that some physical aspects sensed by a sensor node, such as temperature, do not present a great variability in terms of second/minute time scale, this approach avoids sending equivalent Request messages (that is, messages asking for the same service with the same parameters) during a short period of time, as the returned data are likely to be the same. Hence, SAGe groups equivalent Request messages and, for a configurable period of time, only one Request is sent to the sensor service provider, and the received Reply message is stored and forwarded as an answer to all the equivalent Request messages that arrive during that period. For the cases where the sensed value changes very often, this procedure may be turned off by setting to null (i.e., 0 seconds) the Reply message storage timeout.
Automatic type conversion
Since the transmission/reception of data is very energy consuming, the more data is sent/received by a sensor, the more energy is spent. With that in mind, SAGe performs an additional step when converting an Internet Request message into a sensor Request message. For each argument in the Request body, it tries to fit the argument value in a smaller type (that is, a compatible type that uses less bytes). For instance, if the argument is a
Asynchronous invocation patterns
Initially, the WISeMid services communicated synchronously. However, synchronous invocation blocks the service user (client) until the result returned from the service provider (server) is received. Thus, when a service user is running in a sensor node, it keeps consuming energy while waiting for the answer without executing any task. For that reason, we extended WISeMid with asynchronous invocation patterns, which enable the client to resume its work immediately after a remote invocation is sent. Four asynchronous invocation patterns, which are presented in
As stated previously, SAGe is an important WISeMid service which performs different tasks to allow the integration of the Internet and WSNs.
SAGe may be considered an advanced version of SerialForwarder
5.1. SAGe architecture
The SAGe architecture, which is illustrated in Figure ▭, comprises three components:
Configuration: provides a user interface (UI) that enables to configure some SAGe attributes, such as: the port number used by Internet clients to connect to SAGe, and the period of time that a sensor Reply message should be considered an up-to-date information (to refrain SAGe from sending unnecessary Request messages to WSN).
Service Proxy: provides one interface per network (WSN and Internet) through which SAGe receives/sends WIOP messages to provide communication between the services.
Message Handling: handles WIOP messages and is divided into three subcomponents:
Grouping: groups equivalent Internet Request messages during a given period of time (set by Configuration) to avoid WSN energy waste;
Conversion: performs the conversion between Internet and WSN WIOP message formats (namely, and );
Storage: stores the messages received from both networks during a given period of time (set by Configuration), in order to enable message grouping.
Those (sub)components cooperate to perform SAGe functions, which are described next.
5.2. SAGe functions
As mentioned above, the main functions of SAGe are acting as a service proxy and participating in the energy-saving mechanisms.
In order to enable the interaction of services of both Internet and WSN in a transparent way while acting as a service proxy, SAGe has an important role in three specific tasks: the binding of a WSN service in the Naming Service, the invocation of a WSN service (provider) by an Internet service (user), and the invocation of an Internet service (provider) by a WSN service (user). Those three tasks as well as SAGe's participation the methods to conserve the WSN nodes energy are described as follows.
5.2.1. Binding of a WSN service
Once a WSN service starts, it sends a message invoking the Bind operation of the Naming Service. When SAGe receives that message, it creates a
5.2.2. Invocation of a WSN service
When the SAGe receives a Request message from the Internet invoking a WSN service, it converts the message to a Request and sends it to the WSN using the
5.2.3. Invocation of an Internet service
When a sensor node service performs a lookup for an Internet service, SAGe checks if this service is already known, i.e., if its reference is cached. If the service is unknown, SAGe converts and forwards the lookup request to the WISeMid Naming Service. When it receives the Reply, it stores the returned
5.2.4. Saving WSN limited resources
As exposed in Section ▭, WISeMid implements some energy-saving mechanisms. SAGe has an essential role in some of these mechanisms, as explained below.
In the Reply Storage Timeout mechanism, SAGe is in charge of everything: allowing the configuration of the period of time the Reply message will be considered up-to-date; recognizing and grouping equivalent Request messages; storing and forwarding the Reply message for every Request message that arrives in the configured period of time.
The Automatic Type Conversion is also performed by SAGe. When converting a Request message into a one, it tries to fit each argument value in the Request body in a compatible type that uses less bytes. The same procedure is performed for the result value of Reply messages when converting them into Reply messages.
Besides its active participation in those mechanisms, SAGe also performs small actions that help saving the sensor nodes energy. An example has already been described in Section ▭: SAGe does not forward to WSN any Internet Request which asks for a sensor service that has not been registered. It would be useless and energy wasting since no sensor announced that service. Another example occurs when a sensor requests an Internet service (Section ▭). It consists in not giving up at the first unsuccessful attempt to connect to the Internet service provider. Considering that it may be a sporadic problem, SAGe tries to connect to the server a configurable number of times before returning an error to the sensor node. This procedure aims to refrain the sensor from sending another Request in case the answer is fundamental for its application. Details of SAGe implementation are given in
Several applications require particular attention to specific parts (regions) of a WSN. For instance, monitoring applications like a security surveillance may define the border region as a critical one to be monitored, whereas forest fire detecting applications may define clearings that resulted from previous fires as the critical regions to be monitored (since they tend to be more propitious for new fires due to their dry vegetation and soil)
Considering the given examples, Region 1 would be defined as the critical area for the security surveillance application and Region 4 would represent a clearing and be the critical area of the forest fire detection application.
|(a) Logical regions in a WSN||(b) Service composition defining regions in a WSN|
Defining logical regions in a WSN
With that in mind, Clever is added to the framework as a tool that allows defining these logical regions by composing Web services available in the Internet. Although the notion of logical regions have already been presented in the literature, to the best of our knowledge this is the first approach that uses web service composition to define logical regions in WSNs.
It is worth mentioning that regions intersection may occur since a single web service (which represents a sensor node) may participate in more than one composition. The next section describes the composition approach used by Clever.
6.1. Composition approach
Besides WISeMid services (that is, Internet's or WSN's services which use WIOP messages to interact with each other), Web services are also supported by WISeMid. In other words, WISeMid enables transparent communication among WISeMid services and Web services. That is possible by using two different kinds of proxy: one that plays the role of a Web service, allowing other Web services to access the WISeMid service it represents, and one that acts as a WISeMid service, to enable the communication between other WISeMid services and the Web service it is related to. Both kinds of proxies are automatically generated by ProxiesGen from WIDL and WSDL files and have the same operations that the services they represent.
Considering that, each WSN node may provide a (WISeMid) service, which may be represented by a Web service that acts as a proxy. Therefore, composing Web services which represent services that are running on sensor nodes can result in the creation of a logical region in the WSN. Figure ▭(b) illustrates two Web service compositions that define two logical regions in a WSN. On both compositions, when an operation (e.g., getTemperature) belonging to the interface of the Web service composition is invoked, the invocation is passed to all sensor nodes belonging to the WSN's logical region and represented by the composition.
As explained above, the Web services depicted in Figure ▭(b) are actually proxies to WISeMid services running in the sensor nodes. Thus, the Web services that constitute the composition (which is itself a Web service) do not access directly the sensor nodes. Rather, they convert and forward the received requests to the associated WISeMid service provided by the nodes.
When many sensors provide the same (WISeMid) service, only one Web service is used as a proxy to them. That happens because the Web service proxy is automatically generated by the ProxiesGen based on the service's WIDL, which is identical for all sensors providing the same service. Hence, to create a logical region with sensors that provide the same service, a user must add that service
To identify to which sensor a request needs to be sent, a parameter is set in the URL of the Web service. For example, if the URL of a temperature Web service is
then the resulting parameterized URL is
where the id parameter is the identifier of the WSN node that provides the service.
The process of defining a WSN logical region by creating a Web service composition comprises three steps: (1) to choose the Web services to be used in the composition; (2) to set the order and the parameters for each Web service invocation; and (3) to set the URL parameter (node id) of each web service invocation. The first two steps are commonly used in Web service composition and are typically performed using BPEL and a modeling and verification tool that supports it. The third step requires modifying the WSDL file that results from the composition to add a partner link for each sensor that is supposed to compose the logical region, as explained in the following.
The BPEL partner links are the Web services used in the composition. Their URLs are static by default and obtained from the respective WSDL file. However, in the case that a Web service represents more than one WSN service, it is necessary to change these URLs updating dynamically the sensor identification number parameter, as there will be only one web service for them. This process is called Dynamic Addressing and an example of code is shown below:
First, the new URL is assigned to an EndPointReference variable (1-7). Then, this variable is copied to a partner link (8-11). Finally, the invocation to the updated partner link is done (12).
The Clever tool is responsible for automating the third step by allowing the user to choose the nodes that should be part of the region and then automatically creating a partner link for each selected sensor node. Clever is implemented as a NetBeans plug-in, being accessed through a button. When that button is pressed, a wizard is opened to guide the user in choosing the nodes that will join the logical region. First, the Web service that represents the desired WSN service must be selected from a list of the services that have been added to the composition. Actually, the listed names are the partner link names of the invokes contained in the composition, with their respective WSDL file location. Once the Web service (partner link) is selected, the next window shows all the invokes to that service, as illustrated in Figure ▭(a). For each invoke, a node ID must be set. To choose the node of interest, the user may search the WSN for all nodes that satisfy certain constraints, which are represented by property values of the offered service. For that purpose, Clever provides an interface that communicates with the Trader, as depicted in Figure ▭(b). Using this window, the user is able to perform a query in the Trader, receiving a list of the nodes that satisfy that query to choose one of them.
|(a) Step 2 for defining a logical region: selecting the nodes||(b) Finding and setting the node ID|
When every invoke has a node associated, Clever automatically updates the BPEL file (of the Web service composition) to change the URL parameter before each partner link invocation. After that, the new (composite) Web service is ready and the related WSN logical region is created. Once the Web service composition is designed and deployed, a new Web service is created representing that composition. An invocation to this service corresponds to invoking each Web service involved in the composition and those Web services in turn request the related WSN service provided by each selected sensor node.
It is worth mentioning that, although the approach focuses on creating compositions with WSN Web services (more specifically, Web services representing WSN services) in order to form the logical regions in the WSN, it is possible to include Internet Web services in the composition, creating heterogeneous compositions. This possibility raises the level of integration since the (composite) service itself is distributed among nodes of both networks.
7. Energy consumption evaluation
This section presents results of experiments that analyze how WISeMid (including SAGe and the energy-saving mechanisms) and Clever affects the energy consumption in a sensor node.
For all scenarios, we use one Iris mote connected to a MTS400 basic environment sensor board, running the application defined in the studied scenario; and one Iris mote connected to a MIB520 USB programming board, working as a base station (BS), i.e., the sink node. The BS is connected to an Internet host that runs SAGe. Also, two other services run on an Internet host: the Naming service and the service/application under evaluation.
To estimate the energy consumption of the sensor node, an oscilloscope (Agilent DSO03202A) has been used. A PC is connected to the oscilloscope that captures the code snippet execution start and end times by monitoring a led of the sensor, which is turned on/off to signalize execution start/end. The PC runs a tool called AMALGHMA
Previous evaluation results have shown that WISeMid infrastructure has an impact over the energy consumption. Comparing an application that uses WISeMid infrastructure to a similar application that uses only TinyOS, the results shows that the service abstraction provided by WISeMid brings an energy consumption increase of 16.11% compared to the TinyOS application version (see
Aggregation: To analyze the energy-saving offered by the Aggregation service, a scenario composed by an Internet service user requesting a WSN service that provides the sensed temperature is studied. When the Aggregation service is off, the Internet service sends 30 requests in a row; when it is on, only one request is sent by the Internet service user, and the WSN service provider returns one value which corresponds to the aggregation (average) of the last 30 sensed values. As Figure ▭(a) shows, the Aggregation service saves 96.57% of energy. That significative rate is due to avoiding the transmission of 58 messages (29 requests and 29 replies), which would be necessary if the Aggregation service was not available.
|(a) Aggregation service and Automatic Type Conversion||(b) Reply Storage Timeout used in Logical Regions||(c) Asynchronous Patterns instead of Synchronous communication||(d) Sensor position estimation method being performed by the WSN or by the Internet|
Energy consumption of energy-saving mechanisms and real application
Automatic Type Conversion: The evaluation scenario for the Automatic Type Conversion comprises a simple WSN service, which has an operation that sets an attribute of type
Reply Storage Timeout in Logical Regions: The next scenario involves the use of a WSN logical region composed by two sensor nodes providing a Temperature service, which may also be invoked as a web service called TemperatureWS. As explained previously, only one proxy represents all sensors that provide the same service, hence TemperatureWS represents both sensors' service. A Web service composition (WSComposition) with the two Temperature services (actually, the TemperatureWS proxy) is created using Clever for selecting the nodes of interest. Finally, a service that runs on the Internet (TempMon) and monitors the temperature in that area calls WSComposition, which actually calls TemperatureWS twice in a row, once for each sensor node. The proxy calls the Temperature service in the sensors and then forwards their replies to the WSComposition, which calculates the mean value of the received results and returns it to the TempMon service.
To evaluate this logical region composition with the Reply Storage feature, the TempMon service requests the Temperature service composition (WSComposition) 25 consecutive times with random interval between messages, and a timeout of 4s. Figure ▭(b) presents the results, which show that the Reply Storage feature saves 91.28% of energy in the studied scenario, which is a very significant energy-saving rate.
Asynchronous invocation patterns: The asynchronous patterns are evaluated in groups according to their type of operations: one-way or request-response. The one-way scenario is composed by a Logging service provided by an Internet host that is used by a WSN service to record log messages. The patterns evaluated here are Fire and Forget and Sync with Server.
The request-response scenario consists of the first distributed application described in Section ▭, with a Surveillance service running in a sensor node, which captures images of any moving target and sends them to a Recognition service running in the Internet.
The results of both scenarios are presented in Figure ▭(c). For one-way operations, a sensor saves 61.27% of energy when Fire and Forget is adopted instead of Sync with Server. That significant difference was expected since the former ends the process the moment the invocation is sent, whereas the latter involves the tasks performed in SAGe (such as message translation) plus the round-trip delay time from SAGe to the server. For response-reply operations, comparing to synchronous communication, the Poll Object pattern saves 43.91% of energy whilst the Result Callback obtains 50.83% of energy-saving. Those results confirm that the asynchronous invocation patterns can be adopted to extend the WSN lifetime.
Requesting Internet Services: One of WISeMid's main characteristics is that it allows sensor nodes to be not only service providers, but also service users. There are several situations in which asking for a node outside the network to perform a task is more suitable than performing it in-network. It may be even less costly in terms of energy consumption to request the service outside the WSN. Next scenario evaluates an environment monitoring application that shows this strategy. This application is composed by a Monitoring service that runs in a mobile sensor node and therefore needs to know the node position before reporting measured data (see
To estimate the node position, we adopted an approach that has been developed with two versions: centralized and distributed. Both versions use measurements of distance between every node and its neighbors. In the centralized version, all sensor nodes send information about their neighbors to a central machine (outside WSN) with plenty of computation power where the nodes position are calculated and sent back to the network. In the distributed version, each node is responsible for calculating its position using information about its neighbors. Details of this localization approach, including implementation description and accuracy evaluation results, can be found in
Considering those information, we were able to estimate the energy consumption for both versions of this approach. The centralized version consumption comprises the energy that a node spends by requesting its location to a service that is provided by the Internet (Positioning service). It is worth mentioning that synchronous communication is being used, therefore this energy consumption includes the time the sensor keeps waiting for the reply. Moreover, to perform the localization algorithm, the Positioning service must have received the neighbor information of all WSN nodes. Hence, we have added to this calculation the energy consumption of all sensor nodes sending a message with their neighbors information.
For the distributed version, the values represent the estimated energy consumption of all messages that have to be exchanged for the position calculation. That value actually comprises the estimation of the number of messages that each node sends during all the localization algorithm execution, which involves several iterations in the optimization process
Figure ▭(d) shows the estimated energy consumption for both versions considering different sizes of network. As one can observe, in some situations, asking for a node outside the network to perform a task is more suitable than performing it in-network. For this specific application which uses this localization algorithm, the centralized version consumes approximately 98% less energy than the distributed version. That huge energy-saving rate is due to the great number of messages that have to be exchanged by the sensor nodes in the distributed version. In a network with 200 nodes, for instance, approximately 22,400 messages are transmitted.
8. Concluding remarks
This chapter introduced a framework for integrating WSNs and the Internet at service level, by allowing the interoperability of their services. The framework is composed by four components: Smart, a service model to describe services from both networks (Internet and WSNs); WISeMid, a middleware that enables the interoperability of WSN's and Internet's services; SAGe, an advanced gateway which is responsible for providing the location and access transparency for the services' communication; and Clever, a service composition tool which enables the creation of logical regions in the WSN by just composing Web services that are available on the Internet.
Some evaluation results concerning the energy consumption of those elements have been presented. Those results lead to the conclusion that by using some WISeMid's energy-saving mechanisms, a sensor node may save significant amount of energy. For instance, using the Aggregation service, a sensor node can save 96.57% of energy, whereas by using the Reply Storage Timeout feature in a logical region, a saving of 91.28% is obtained. Furthermore, a real application which requests an Internet service that estimates the sensor positioning instead of computing it in-network saved approximately 98% of energy, emphasizing the usefulness of the sensor nodes' capability of being service requestors.
In terms of future work, there are a number of possibilities to improve and extend the framework elements. The Smart model may be improved by detailing some elements, such as