- Email: [email protected]
A Framework for Integrating WSNs and External Environments
2010 Management and Control of Production Logistics University of Coimbra, Portugal September 8-10, 2010
A Framework for Integrating WSNs and External Environments Thanh-Dien Tran*, Jorge Sa Silva** Department of Informatics Engineering, University of Coimbra, Polo II - Pinhal de Marrocos, 3030-290 Coimbra, PORTUGAL Email: *[email protected], **[email protected] Abstract: Wireless Sensor Networks (WSNs) offer a diversity of applications in most of the fields, including healthcare, environmental monitoring, military and smart homes. However, most of the important applications of WSNs cannot operate in complete isolation and therefore it is necessary to have an infrastructure for integrating WSNs with external environments (e.g., IP networks and virtual worlds). In this paper, we survey the current approaches on interconnecting WSNs with the IP networks and analyze their advantages as well as their limitations. Based on the analysis, we propose a new approach for interoperability between WSNs and external environments. Our proposed framework takes the advantages of current approaches as well as it takes into account the idea of service-orientation and application-independence. Our aim is to create a generic framework that is able to adapt with the multitude of applications running on sensor nodes and exposes WSNs as a set of web services to external environments. This paper also presents an implemented use-case for integrating WSNs with Second Life virtual world. 1. INTRODUCTION Wireless Sensor Networks (WSNs) are networks that comprise a large number of small and low-cost devices with limited capability in processing, memory, communication and power. The most important factors of WSNs are their sensing and actuation abilities. WSNs work under information gathering paradigm based on the cooperation of a multitude of sensor nodes. Because of its low-cost and ability to collaboratively sense the surrounding physical environments, WSNs are promising unlimited applications in most of the areas. The major applications of WSNs are aim at monitoring the ambient environments or internal conditions of the targets as well as actuation. In most of the cases, WSNs cannot operate in complete isolation, but they need to be connected with external environments. As TCP/IP protocol suit has become the de-facto standard for the Internet and used in most of the local and intra-net networks, interconnecting WSNs with TCP/IP networks will offer the opportunity to integrate WSNs in the future Internet. WSNs are envisioned as an integral part of our life. Therefore, integrating WSNs with the IP networks is desirable. Furthermore, by integrating with the IP-based networks, we can expose WSNs as a set of services in the Internet environment for increasing the applicability of WSNs. However, the limitations of sensor nodes such as memory, computation, communication and energy make it difficult or inefficient to deploy the full TCP/IP protocol stack into all sensor nodes. Furthermore, special characteristics of WSNs such as data-flow patterns, application-specific, and data-centric routing make them also difficult for integrating WSNs with IP networks and external environments. Therefore, our aim is to provide a solution for some of the
978-3-902661-81-4/10/$20.00 © 2010 IFAC
383
above challenges when integrating WSNs with external environments. In this paper, we survey and analyze the current research and present our proposal for integrating WSNs with external environments. The main contribution of our work is a generic service-oriented and applicationindependent framework for integrating WSNs and external environments (IP networks, Virtual Worlds, web 2.0, etc). To prove the applicability of the proposed framework, we implement a use case for integrating WSNs with Second Life virtual world. The rest of this paper is organized as follows. Section 2 presents a survey of different approaches for interconnecting WSNs with IP networks. Section 3 details our proposed framework. Then, Section 4 illustrates a use case that we implemented for the localization service of the framework with Second Life virtual world environment. In Section 5, we outline a real application scenario for applying the proposed framework. Finally, Section 6 presents some conclusions and outlooks for future work. 2. RELATED WORK There are several studies and proposals for interconnecting WSNs with IP networks. The approaches for interoperability between WSNs and external networks can be divided into two main categories: gateway-based and IP-enabled sensor networks. The first approach uses one or more powerful nodes acting as gateway between two types of networks to translate and forward packets between them. The second approach directly deploys IP protocol stack into sensor nodes. 2.1 Gateway-based approaches In gateway-based approaches, one or more gateways are deployed between the two dissimilar networks. Several 10.3182/20100908-3-PT-3007.00085
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 gateway-based approaches have been proposed for interconnecting WSNs with IP-based networks. This section discusses the advantages as well as the drawbacks of them. The first and simplest one is the application-level gateway or proxy (Dunkels et al., 2004b; Z. and Krishnamachari, 2003). In this approach, the gateway translates and forwards the packets between the two types of networks. The gateway or proxy can act as a relay or as a front-end (Dunkels et al., 2004b). In the relay mode, the gateway simply translates and relays the data from the WSN to the clients on the TCP/IP network and the clients must register the particular data interest with the proxy or gateway. On the other hand, in the front-end mode the gateway proactively collects the data from the sensor networks and stores it in a database. The gateway serves as the interface to a distributed database (WSNs), and the clients then query the gateway for the required information. The main advantage of this second approach is that it is simpler to implement and transparent to both networks. However, the application-level gateway is usually used for specific tasks or for a set of specific protocols, and it requires a specific gateway for each application (Dunkels et al., 2004b; Emara et al., 2009). Another gateway-based approach, which can be applied for interconnecting WSNs and IP networks, is Delay Tolerant Network (DTN) (Fall, 2003). DTN was designed for critical environments (i.e high bit-error rates, long and variable delays, frequent network partitioning and asymmetrical data rates) (Dunkels et al., 2004b) where end-to-end connection is almost impossible. A DTN consists of a set of regions that share a common layer called bundle layer that resides on the top of transport protocols used in the local region networks. The bundle message contains information that allows DTN gateway to route packets between regions and to deliver them to local hosts within their local region (Fall, 2003). DTN gateway stores packets persistently until they can be sent to the next hop. DTN approach is different from the ordinary applicationlevel gateway approach, but it still needs one or more gateways for operation. DTN architecture can be used to interconnect WSNs with IP networks as DTN gateway is similar to a relay proxy. Furthermore, DTN approach can provide reliable end-to-end communication between nodes in different regions by using the bundle layer and storeand-forward mechanisms. However, it requires deploying the bundle layer into all nodes in both networks and the gateways. Some recent studies propose a low layer (network layer) gateway-based approach for the interoperability between WSNs and IP networks. VIP Bridge (Shu et al., 2007) proposed an approach for integrating several isolated WSNs with IP-based networks to form a virtual sensor network. VIP Bridge is based on the node-centric or locationcentric communication paradigm to map node IDs to IP addresses. In this model, IP addresses of sensor nodes are stored in the VIP Bridge as virtual IP addresses. The packets that come from one network are translated into the corresponding format and sent to the other side by the bridge. However, this approach is based on a networklevel Gateway instead of an application-level Gateway.
384
This means that the VIP Bridge does not translate the content of the packets. With this approach, Internet users can directly access to the sensor node using IP addresses. Another advantage of this method is that the WSNs can freely choose their communication protocols. In fact the communication protocols of WSN are transparent to the Internet users. However, the VIP Bridge approach has some limitations. Firstly, it requires modifying the application of sensor nodes to register their IDs or location addresses and the format of the sensed data. Furthermore, client applications are WSN-specific; it means that these applications must have the ability to understand and analyse the traffic from WSNs. Another drawback is that the packet analysis and translation are based on a specific field to categorize the packets into operation or query commands. Finally, only using a node ID to find the corresponding requesting packets will, in some cases, not determine unique packets if there are multiple requests to the same node at the same time. Another study based on VIP Bridge is presented in (Emara et al., 2009), which proposes two main improvements compared to VIP Bridge. Firstly, it does not require sensor nodes register their information with the gateway. Therefore, it does not require modifications in protocols and applications of the sensor nodes. Secondly, it does not use specific fields to identify the type of commands (operation or query), and consequently, it also does not require any modification of user applications. However, like VIP Bridge, the main drawback of network-level gateways is that it assumes that application protocols are the same on both sides. The network-level gateways only do the mapping between sensor nodes’ IDs and virtual IP addresses, translate the messages up to network layer; and do some non-data filtration. In both approaches (Shu et al., 2007; Emara et al., 2009), the gateway publishes virtual IP addresses assigned to sensor nodes to IP hosts. However, the IP hosts cannot be known in advances as they may change. Moreover, the network-level gateway approach requires that the user application have ability to analyze the packets from the WSNs to get the useful data. This makes the WSNs not totally transparent to the client applications. 2.2 IP-enabled WSNs Since WSNs are resource-constraint, application-specific, data-centric, and support many-to-one and one-to-many data flows, deploying IP over WSNs presents some problems. Some of the most limitations of deploying an IP stack in sensor nodes are: the large header overhead, global addressing schema, limited bandwidth, limited node energy, transport protocol, and high bit-error rates. Because of these problems, many researchers believe that IP-enabled sensor networks are infeasible and inefficient (Z. and Krishnamachari, 2003). However, recent studies have proved that it is possible to deploy IP protocol in WSNs (Dunkels, 2003; Dunkels et al., 2004a; Montenegro et al., 2007; Hui et al., 2009; Zimmermann et al., 2008). 6LoWPAN (Hui et al., 2009; Montenegro et al., 2007) introduces an adaptation layer, between link layer and network layer, that aims to enable efficient IPv6 communication over 802.15.4 links. 6LoWPAN applies cross-layer optimization with three primary
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 elements (Hui et al., 2009): header compression, fragmentation and layer-two forwarding. Although IP can be deployed directly into sensor nodes, its efficiency in terms of energy and usefulness still need to be more studied. On the other hand 6LoWPAN introduces an adaptation layer between the link layer and the network layer, so it is not totally compatible with conventional IP networks and it still requires a bridge/router/gateway between WSNs and IP networks. Based on the above analysis, we believe there should be a novel solution for interoperability of WSNs and external environments allowing IP client-applications and other environments (e.g., web 2.0, P2P, and Virtual World) to easily communicate with WSNs. In addition, the proposed solution should be independent of WSNs, i.e., it can be adapted to new applications and protocols of WSNs. It means that the new solution will make the WSNs as the plug-and-play component of the Future Internet. In the next section, we will formalize our framework toward this aim. 3. THE PROPOSED FRAMEWORK 3.1 Overview Our main objective is to propose and create a transparent infrastructure for integrating WSNs and external environments. Besides the interconnecting functionalities, the infrastructure also comprises a set of supporting services for WSNs such as mobility, localization and authentication. The proposed framework allows client-applications and other environments to communicate with the WSNs using web services. The novelty of this framework is that it is designed to be independent of the applications running on sensor networks, i.e, it can be adapted to new applications and protocols of WSNs without the need of reprogramming. With the proposed framework, WSNs can be used as plug-and-play components of the future Internet. Furthermore, it also allows external environments to access individual sensor nodes using virtual IPv6. The proposed framework takes advantages of VIP Bridge (Shu et al., 2007) in mapping IP addresses and in integrating several isolated WSNs with IP-based networks to form a virtual sensor network. However, as in (Emara et al., 2009) our framework does not require that sensor nodes register their identifications and data information with the gateway component. Our approach for interoperability between WSNs and external environments is based on service-oriented approach in which WSNs are exposed to the external environments as a set of web services. The abstract model of the framework is depicted in Fig. 1. The proposed framework interacts with WSNs and exposes their information and functionalities in form of web services to other environments. The main benefits of this framework are: • Application-independence: The proposed framework can be used for different applications running in WSNs. Therefore, it is easy to add new sensor nodes with different applications to existing WSNs as well as to deploy the framework for new WSNs.
385
Fig. 1. The generic Framework for interoperability between WSNs and external environments • Unified programming interface: Since the framework exposes the data and functionalities of WSNs as set of web services, it provides a unified and standardized interface for other environments to interact with WSNs. • Transparency: The interoperability between WSNs and external environments is via web services. External environments can communicate with WSNs easily and transparently without knowing any details. The developers only need to concentrate on data manipulation without worrying about network details. • Reusability: The framework can be used for deploying different types of WSNs without reprogramming. • Easy integration with other environments: Exposing WSNs as a set of web services makes the integration of WSNs with other environments easier. • Direct access to sensor nodes: The sensor nodes can be directly accessed from the Internet via the services of the framework. In the following sections we will present a more detailed structure of our proposed framework and its operations. 3.2 Framework Architecture This framework adopts the gateway-based architecture with proxy components to provide interoperability. The proxy components of the framework are responsible for interacting with WSNs in order to compose and to provide services for other environments. The framework has also ability to dissect multiple protocols of WSNs as well to analyze the aggregated data. These components make WSNs transparent to external environments. As depicted in Fig. 1 the proposed framework comprises six main components: Web service interfaces, Task Scheduler and Execution, Message Composer and Forwarder, Packet Analyzer, Virtual IP mapper, and a set of services. The web service interfaces are the entry point where other environments can access the data. The Task Scheduler and Execution is the module where the requests are scheduled and executed. The Message Composer and Forwarder is responsible for translating the request messages into the WSN messages and forwarding them to the WSN. The Packet Analyzer inspects the packets from the WSNs in order to extract the sensing data. The Virtual IP Mapper
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 will assign a unique virtual IP for every sensor node based on the information it receives from the Packet Analyzer. Virtual IP addresses are stored in the IP mapping table of the framework. The information from the Packet Analyzer is also used by other services of the framework such as localization and mobility. To realize the framework, the following methods and techniques are used: • Service-Oriented Architecture (SOA): SOA is used to expose the data, functionalities and services of WSNs as a set of web services. The web service interfaces are used to offer a language independent platform. • Traffic Description Language: The sensor network traffic will be described by XML so that it is possible to adapt the framework for new protocols of WSNs. The framework includes a mechanism for analysing traffic of the WSN and for composing the packets based on the traffic description. In fact, the traffic description language is the mechanism used by the framework to adapt to new applications and protocols by adding the new traffic descriptions instead of reprogramming the framework’s components. • Virtual IP Mapping: Mapping mechanisms are used to assign virtual IPv6 addresses to sensor nodes. The mapping information depends on the protocols of the sensor networks. This virtual IPv6 mapping allows the external environments to access sensor nodes using their IP addresses as unique identifications. • Extensible architecture: The framework is designed as a flexible architecture which allows to easily add new or existing components. 3.3 Operations of the Framework In our approach, external environments access the data and functionalities of the WSN via a gateway using a set of web services. When receiving a request from the external environment, the Web services engine will parse the request and forward the requested information to the Task Scheduler and Execution component. The Task Scheduler and Execution component will put the request into the Task list and process it. Depending on the request, it can be scheduled to execute one or more times. After that the information may be forwarded to the Message Composer and Forwarder where it will be translated into the internal format and sent to the WSN. How the Message Composer and Forwarder composes the message depends on the packet formats that are described in the Sensor Traffic Description. The Sensor Traffic Description is one of the factors that make the framework flexible to new applications and protocols. The Packet Analyzer also uses the information in Sensor Traffic Description in order to dissect the packets from WSNs. It will store the data into the database and provide the information for the Virtual IP mapper to build the virtual IP mapping table. At the same time, it provides other necessary information for other services such as localization and mobility (if required). The current model allows Internet users to access individual node (using virtual IP) via web services. This also
386
offers a secure environment by providing authentication and authorization services at the gateway. Furthermore, the encryption services can be easily integrated into the gateway to secure the data. Exposing WSNs as a set of services There are two types of services that WSNs can provide for external environment: data and operations. Data is sensed by sensor nodes and consumed by the external environments for visualization and monitoring. The operation services allow client applications and other tools to control the operations of individual sensor nodes and to actuate other systems. To provide data services, the Packet Analyzer captures and analyzes the traffic from sensor nodes and stores these data in a temporary buffer. The data web services of the framework will provide these data to the clients. The Packet Analyzer has ability to analyze multiple protocols of WSNs (e.g., Active Message, 802.15.4, 6loWPAN). It dissects the sensor traffic from the sensor nodes and passes the identification to the IP Mapper to associate an IP address to the sensor node if it does not exist. In order to provide the application-independence for the framework, the traffic description language is used to describe the structure of application’s data. Based on these descriptions the packet analyzer extracts the correct data. The applications’ data and related information is, then, stored in the data buffer for further processing. The functionalities of the sensor nodes are also provided via a common set of web services. These services allow directly access to individual sensor nodes or group of nodes. The parameters of the services include the identification of the node(s) (ID or IP), and the command. The Message Composer & Forwarder component is responsible for composing and forwarding the command to the corresponding sensor node(s). Virtual IP Mapper The virtual IP mapper is responsible for assigning a unique virtual IPv6 address for each sensor node. The mapping information corresponding to virtual IP depends on the WSN. This functionality allows sensor nodes to be exposed as normal IP nodes to external environments. The list of virtual IPs is provided by the IP mapping table service which can be accessed via the web service interfaces. Mobility, localization, and authentication and authorization services To support mobility and localization services in our architecture, we assume multi-sink environments. The area may be covered by several sink nodes. Therefore, mobile nodes would be able to connect to the best sink in each specific moment, guaranteeing the connectivity anywhere and anytime. In our testbed, we performed a study based on the received signal strength indication (RSSI) value in order to detect the movement of sensor nodes. Although RSSI value is inaccurate, it gives the relative useful information deciding which proxy will be responsible for the mobile node (Silva et al., 2009). Localization is the process that calculates the location of devices. The relative position of the sensor nodes is very important in many types of applications. The RSSI value can be used to estimate the distance between two sensor
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010
Fig. 3. Interaction between sensor node and SL object
Fig. 2. Interaction between sensor node and SL object nodes. Therefore, it is possible to calculate the relative position of a sensor node in a WSN if we can collect the RSSI value of that sensor node by at least three fixed reference sensor nodes. In WSNs, RSSI value is usually available and it is one of the simplest parameters for ranging and location estimation. The next section describes an example process that was implemented in our lab for the communication between a sensor node and an object in Second Life (SL) virtual world using the proposed framework. In this example, we will explain how to use the localization service to illustrate the mobility of a sensor node in SL environment. 4. MOBILITY OF SENSOR NODE IN SECOND LIFE VIRTUAL WORLD In this section, we present a simplified workflow of using the proposed service-oriented framework for mapping a sensor node to an object in Second Life. We illustrate how to visualize mobile sensor nodes in SL. In this scenario, the localization service of the framework is used to calculate the location of the sensor node and the mobile sensor node is visualized by making the avatar in SL with the ability to move. To realize this, we attach a SL object to the avatar and that object is scripted to be connected to the Web Service Interface of the framework. So it gets the position of the corresponding sensor node. Fig. 2 describes the process of mapping and the communication protocol of the SL object with the sensor node. The first step to implement this use-case is to script the SL object and map it to the sensor node that it will get the information from. This mapping can be based on any information that uniquely identifies the sensor node. According to our framework, we can use the virtual IPv6 address to uniquely identify the sensor node. Currently, there are two methods to implement this scenario in SL. The first one is to program the SL object to periodically send requests to the web services of the framework in order to get the latest location of corresponding sensor node
387
and update the position of the corresponding avatar in SL. The second method is to include a function in the framework that sends the updated position of the sensor node to the corresponding SL object whenever the sensor node changes its position. The second method seems more appropriate. However, the current method for interacting with SL objects from outside is via SL XML-RPC gateway and this gateway has some limitations that should be solved in order for this method works smoothly. Firstly, the XML-RPC gateway of SL only allows one message per channel to be queued at any time. Furthermore, each message has at least three-second delay. Therefore, it takes a long time (at least three seconds) for sending data from a sensor node to the SL object. Because these limitations, we implemented our scenario using the first method. In our implementation, the SL object is scripted to send a location request to web services interface of the framework every second. In order to provide the relative position of the sensor node, the localization service employs the trilateration technique that needs the RSSI values from three or more fixed reference sensor nodes. Therefore, to support this service, the architecture of WSNs must be carefully designed. In our testbed environment, four sensor nodes at fixed positions is used as beacons that collect the RSSI information from mobile sensor nodes and send it to the localization service of the framework. In our framework, the Packet Analyzer component is responsible for collecting the RSSI information from beacon nodes and providing them to the localization service. In our prototype, we implemented a proxy component that collects RSSI values from the sensor node and calculates the location of sensor node. The location of sensor node, then, is visualized in the Second Life by making the avatar to which the SL object is attached moving when the sensor node changes its position. This system is depicted Fig. 3. The next section will describe a real application scenario that we are implementing using our proposed framework. 5. APPLICATION SCENARIO We are applying our framework in the employees’ health monitoring scenario in an oil refinery in the context of the
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 transparent to external environments as well as preserve the specific characteristics of WSNs. The interconnecting infrastructure should also include supporting services for WSNs such as mobility, localization and security.
Fig. 4. Model for realizing the employee’s health monitoring using the proposed framework with Second Life FP7 GINSENG project (GINSENG, 2008). The overall goal of GINSENG is to provide a wireless sensor network that will meet specific performance targets, that will integrate with industry resource management systems, and that will be proven in a real industry setting where performance is critical. One of the selected scenarios of GINGSENG is monitoring safety and pollution supervision in the oil industry. Oil refinement is a complex and dangerous process, during which any small failure can lead to disaster, with serious consequences on human lives, on the environment as well as on the economy. Since oil refinement is a hazardous working environment, it is necessary to monitor the current heath status of the workers (e.g., heart rates, body orientation, and locations) as well as the environment conditions (e.g., temperature, light). In order to realizing this real application scenario, Second Life (Linden-Research, 2010) virtual world is used as a tool for visualizing the employees’ health and environment conditions. Each worker is equipped with one or more sensors and a special smart-shirt (Pandian et al., 2008). In this scenario, the services of the proposed framework collect information about the employees’ location, their health status and surrounding environment condition. The collected information is transmitted to the SL for displaying. We are using the proxy-based WSN architecture proposed in (Silva et al., 2010) for monitoring the mobility and the location of the employees. The model for deployment this scenario is depicted in Fig. 4. As depicted in Fig. 4, each worker is equipped with at least one sensor node called mobile node (MN) and its mobility is managed by a set of Sensor Mobility Proxies (SMPs) which are all connected via a shared SMP backbone. In order to determine the location of the worker, the WSNs also include a set of fixed sensor nodes called reference points (anchor or beacon nodes). These reference fixed sensor nodes provide the necessary information for the location service of the framework so that it can calculate the positions of mobile nodes (workers). The location information as well as other sensed data from the sensor network is visualized in the Second Life so that other people can continuously monitor the workers’ heath, location, and environment conditions. This helps the systems to create warning and to act timely. 6. CONCLUSION WSNs will be an integral part of our daily life and they will become important components of the Future Internet. Interconnecting WSNs and external environments is a deniable requirement. However, it is crucial to make WSNs
388
This paper proposed a framework for interconnecting WSNs and external environments. The framework exposes data and functionalities of the WSNs as a set of web services, making WSNs transparent to other environments. Furthermore, the framework has ability to be adapted to new applications and protocols as it assumes a WSN as a plug-and-play component of the Future Internet. In this paper, we present how to integrate WSNs with Second Life virtual world using the proposed framework. we also present a real application scenario that is being implemented. As a future work we intend to evaluate the performance and the reliability of the framework. Furthermore, our current location service for WSNs is based on RSSI measurement, but these values are unstable because of noise, obstacles and anisotropy of antenna. Therefore, in the future we will investigate and design a more stable method for estimating the ranging and location based on RSSI value. ACKNOWLEDGEMENTS The research leading to these results has received funding from the EU Seventh Framework Programme (FP7/20072013) under grant agreement n 224282, Project GINSENG and from PULSE ”Inteligencia de Negocio em Tempo Real”, 5354 QREN. REFERENCES A. Dunkels. Full tcp/ip for 8-bit architectures. In MOBISYS’03, 2003. A. Dunkels, J. Alonso, and T. Voigt. Making tcp/ip viable for wireless sensor networks. http://www.sics.se/ adam/ewsn2004.pdf, 2004a. A. Dunkels, J. Alonso, T. Voigt, H. Ritter, and J. Schiller. Connecting wireless sensornets with tcp/ip networks. In WWIC 2004, volume 2957, pages 143–152. LNCS, 2004b. K. A. Emara, M. Abdeen, and M. Hashem. A gatewaybased framework for transparent interconnection between wsn and ip network. In Fourth International Conference on Intelligent Computing and Information Systems, 2009. K. Fall. A delay-tolerant network architecture for challenged internets. In Proceeding of the SIGCOMM 2003 conference, 2003. GINSENG. Ginseng - performance control in wireless sensor networks. http://www.ict-ginseng.eu/ documents/md_1_necs-ginseng.pdf, 2008. J. Hui, D. Culler, and S. Chakrabarti. Internet protocol for smart object (ipso) alliance. white paper 3, 2009. Linden-Research. Second life. http://secondlife.com/, 2010. G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler. Rfc 4944: Transmission of ipv6 packets over ieee 802.15.4 networks. http://tools.ietf.org/search/rfc4944, 2007. K. Pandian, K. Mohanavelu, T. Safeer, D. Kotresh, P. Shakunthala, and V. Padaki Gopal. Smart vest:
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 Wearable multi-parameter remote physiological monitoring system. Medical Engineering & Physics, 30(4): 466–477, 2008. L. Shu, J. Cho, S. Lee, M. Hauswirth, and L. Zhang. Vip bridge: Leading ubiquitous sensor networks to the next generation. Journal of Internet Technology, 8(3), 2007. R. Silva, J. Sa Silva, M. Simek, and F. Boavida. A new approach for multi-sink environments in wsns. In IM’09: Proceedings of the 11th IFIP/IEEE international conference on Symposium on Integrated Network Management., 2009.
389
Ricardo Silva, Jorge Sa Silva, and Fernando Boavida. A proxy-based mobility solution for critical wsn applications. In In the proceedings of Second International Workshop on Medical Applications Networking, 2010. M. Zuniga Z. and B. Krishnamachari. Integrating future large-scale wireless sensor networks with the internet. Technical report, Department of Electrical Engineering, University of Southern California, 2003. A. Zimmermann, J. Sa Silva, J. Sobral, and F. Boavida. 6glad: Ipv6 global to link-layer address translation for 6lowpan overhead reducing. In Next Generation Internet Networks (NGI 2008), pages 209–214, 2008.
A Framework for Integrating WSNs and External Environments Thanh-Dien Tran*, Jorge Sa Silva** Department of Informatics Engineering, University of Coimbra, Polo II - Pinhal de Marrocos, 3030-290 Coimbra, PORTUGAL Email: *[email protected], **[email protected] Abstract: Wireless Sensor Networks (WSNs) offer a diversity of applications in most of the fields, including healthcare, environmental monitoring, military and smart homes. However, most of the important applications of WSNs cannot operate in complete isolation and therefore it is necessary to have an infrastructure for integrating WSNs with external environments (e.g., IP networks and virtual worlds). In this paper, we survey the current approaches on interconnecting WSNs with the IP networks and analyze their advantages as well as their limitations. Based on the analysis, we propose a new approach for interoperability between WSNs and external environments. Our proposed framework takes the advantages of current approaches as well as it takes into account the idea of service-orientation and application-independence. Our aim is to create a generic framework that is able to adapt with the multitude of applications running on sensor nodes and exposes WSNs as a set of web services to external environments. This paper also presents an implemented use-case for integrating WSNs with Second Life virtual world. 1. INTRODUCTION Wireless Sensor Networks (WSNs) are networks that comprise a large number of small and low-cost devices with limited capability in processing, memory, communication and power. The most important factors of WSNs are their sensing and actuation abilities. WSNs work under information gathering paradigm based on the cooperation of a multitude of sensor nodes. Because of its low-cost and ability to collaboratively sense the surrounding physical environments, WSNs are promising unlimited applications in most of the areas. The major applications of WSNs are aim at monitoring the ambient environments or internal conditions of the targets as well as actuation. In most of the cases, WSNs cannot operate in complete isolation, but they need to be connected with external environments. As TCP/IP protocol suit has become the de-facto standard for the Internet and used in most of the local and intra-net networks, interconnecting WSNs with TCP/IP networks will offer the opportunity to integrate WSNs in the future Internet. WSNs are envisioned as an integral part of our life. Therefore, integrating WSNs with the IP networks is desirable. Furthermore, by integrating with the IP-based networks, we can expose WSNs as a set of services in the Internet environment for increasing the applicability of WSNs. However, the limitations of sensor nodes such as memory, computation, communication and energy make it difficult or inefficient to deploy the full TCP/IP protocol stack into all sensor nodes. Furthermore, special characteristics of WSNs such as data-flow patterns, application-specific, and data-centric routing make them also difficult for integrating WSNs with IP networks and external environments. Therefore, our aim is to provide a solution for some of the
978-3-902661-81-4/10/$20.00 © 2010 IFAC
383
above challenges when integrating WSNs with external environments. In this paper, we survey and analyze the current research and present our proposal for integrating WSNs with external environments. The main contribution of our work is a generic service-oriented and applicationindependent framework for integrating WSNs and external environments (IP networks, Virtual Worlds, web 2.0, etc). To prove the applicability of the proposed framework, we implement a use case for integrating WSNs with Second Life virtual world. The rest of this paper is organized as follows. Section 2 presents a survey of different approaches for interconnecting WSNs with IP networks. Section 3 details our proposed framework. Then, Section 4 illustrates a use case that we implemented for the localization service of the framework with Second Life virtual world environment. In Section 5, we outline a real application scenario for applying the proposed framework. Finally, Section 6 presents some conclusions and outlooks for future work. 2. RELATED WORK There are several studies and proposals for interconnecting WSNs with IP networks. The approaches for interoperability between WSNs and external networks can be divided into two main categories: gateway-based and IP-enabled sensor networks. The first approach uses one or more powerful nodes acting as gateway between two types of networks to translate and forward packets between them. The second approach directly deploys IP protocol stack into sensor nodes. 2.1 Gateway-based approaches In gateway-based approaches, one or more gateways are deployed between the two dissimilar networks. Several 10.3182/20100908-3-PT-3007.00085
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 gateway-based approaches have been proposed for interconnecting WSNs with IP-based networks. This section discusses the advantages as well as the drawbacks of them. The first and simplest one is the application-level gateway or proxy (Dunkels et al., 2004b; Z. and Krishnamachari, 2003). In this approach, the gateway translates and forwards the packets between the two types of networks. The gateway or proxy can act as a relay or as a front-end (Dunkels et al., 2004b). In the relay mode, the gateway simply translates and relays the data from the WSN to the clients on the TCP/IP network and the clients must register the particular data interest with the proxy or gateway. On the other hand, in the front-end mode the gateway proactively collects the data from the sensor networks and stores it in a database. The gateway serves as the interface to a distributed database (WSNs), and the clients then query the gateway for the required information. The main advantage of this second approach is that it is simpler to implement and transparent to both networks. However, the application-level gateway is usually used for specific tasks or for a set of specific protocols, and it requires a specific gateway for each application (Dunkels et al., 2004b; Emara et al., 2009). Another gateway-based approach, which can be applied for interconnecting WSNs and IP networks, is Delay Tolerant Network (DTN) (Fall, 2003). DTN was designed for critical environments (i.e high bit-error rates, long and variable delays, frequent network partitioning and asymmetrical data rates) (Dunkels et al., 2004b) where end-to-end connection is almost impossible. A DTN consists of a set of regions that share a common layer called bundle layer that resides on the top of transport protocols used in the local region networks. The bundle message contains information that allows DTN gateway to route packets between regions and to deliver them to local hosts within their local region (Fall, 2003). DTN gateway stores packets persistently until they can be sent to the next hop. DTN approach is different from the ordinary applicationlevel gateway approach, but it still needs one or more gateways for operation. DTN architecture can be used to interconnect WSNs with IP networks as DTN gateway is similar to a relay proxy. Furthermore, DTN approach can provide reliable end-to-end communication between nodes in different regions by using the bundle layer and storeand-forward mechanisms. However, it requires deploying the bundle layer into all nodes in both networks and the gateways. Some recent studies propose a low layer (network layer) gateway-based approach for the interoperability between WSNs and IP networks. VIP Bridge (Shu et al., 2007) proposed an approach for integrating several isolated WSNs with IP-based networks to form a virtual sensor network. VIP Bridge is based on the node-centric or locationcentric communication paradigm to map node IDs to IP addresses. In this model, IP addresses of sensor nodes are stored in the VIP Bridge as virtual IP addresses. The packets that come from one network are translated into the corresponding format and sent to the other side by the bridge. However, this approach is based on a networklevel Gateway instead of an application-level Gateway.
384
This means that the VIP Bridge does not translate the content of the packets. With this approach, Internet users can directly access to the sensor node using IP addresses. Another advantage of this method is that the WSNs can freely choose their communication protocols. In fact the communication protocols of WSN are transparent to the Internet users. However, the VIP Bridge approach has some limitations. Firstly, it requires modifying the application of sensor nodes to register their IDs or location addresses and the format of the sensed data. Furthermore, client applications are WSN-specific; it means that these applications must have the ability to understand and analyse the traffic from WSNs. Another drawback is that the packet analysis and translation are based on a specific field to categorize the packets into operation or query commands. Finally, only using a node ID to find the corresponding requesting packets will, in some cases, not determine unique packets if there are multiple requests to the same node at the same time. Another study based on VIP Bridge is presented in (Emara et al., 2009), which proposes two main improvements compared to VIP Bridge. Firstly, it does not require sensor nodes register their information with the gateway. Therefore, it does not require modifications in protocols and applications of the sensor nodes. Secondly, it does not use specific fields to identify the type of commands (operation or query), and consequently, it also does not require any modification of user applications. However, like VIP Bridge, the main drawback of network-level gateways is that it assumes that application protocols are the same on both sides. The network-level gateways only do the mapping between sensor nodes’ IDs and virtual IP addresses, translate the messages up to network layer; and do some non-data filtration. In both approaches (Shu et al., 2007; Emara et al., 2009), the gateway publishes virtual IP addresses assigned to sensor nodes to IP hosts. However, the IP hosts cannot be known in advances as they may change. Moreover, the network-level gateway approach requires that the user application have ability to analyze the packets from the WSNs to get the useful data. This makes the WSNs not totally transparent to the client applications. 2.2 IP-enabled WSNs Since WSNs are resource-constraint, application-specific, data-centric, and support many-to-one and one-to-many data flows, deploying IP over WSNs presents some problems. Some of the most limitations of deploying an IP stack in sensor nodes are: the large header overhead, global addressing schema, limited bandwidth, limited node energy, transport protocol, and high bit-error rates. Because of these problems, many researchers believe that IP-enabled sensor networks are infeasible and inefficient (Z. and Krishnamachari, 2003). However, recent studies have proved that it is possible to deploy IP protocol in WSNs (Dunkels, 2003; Dunkels et al., 2004a; Montenegro et al., 2007; Hui et al., 2009; Zimmermann et al., 2008). 6LoWPAN (Hui et al., 2009; Montenegro et al., 2007) introduces an adaptation layer, between link layer and network layer, that aims to enable efficient IPv6 communication over 802.15.4 links. 6LoWPAN applies cross-layer optimization with three primary
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 elements (Hui et al., 2009): header compression, fragmentation and layer-two forwarding. Although IP can be deployed directly into sensor nodes, its efficiency in terms of energy and usefulness still need to be more studied. On the other hand 6LoWPAN introduces an adaptation layer between the link layer and the network layer, so it is not totally compatible with conventional IP networks and it still requires a bridge/router/gateway between WSNs and IP networks. Based on the above analysis, we believe there should be a novel solution for interoperability of WSNs and external environments allowing IP client-applications and other environments (e.g., web 2.0, P2P, and Virtual World) to easily communicate with WSNs. In addition, the proposed solution should be independent of WSNs, i.e., it can be adapted to new applications and protocols of WSNs. It means that the new solution will make the WSNs as the plug-and-play component of the Future Internet. In the next section, we will formalize our framework toward this aim. 3. THE PROPOSED FRAMEWORK 3.1 Overview Our main objective is to propose and create a transparent infrastructure for integrating WSNs and external environments. Besides the interconnecting functionalities, the infrastructure also comprises a set of supporting services for WSNs such as mobility, localization and authentication. The proposed framework allows client-applications and other environments to communicate with the WSNs using web services. The novelty of this framework is that it is designed to be independent of the applications running on sensor networks, i.e, it can be adapted to new applications and protocols of WSNs without the need of reprogramming. With the proposed framework, WSNs can be used as plug-and-play components of the future Internet. Furthermore, it also allows external environments to access individual sensor nodes using virtual IPv6. The proposed framework takes advantages of VIP Bridge (Shu et al., 2007) in mapping IP addresses and in integrating several isolated WSNs with IP-based networks to form a virtual sensor network. However, as in (Emara et al., 2009) our framework does not require that sensor nodes register their identifications and data information with the gateway component. Our approach for interoperability between WSNs and external environments is based on service-oriented approach in which WSNs are exposed to the external environments as a set of web services. The abstract model of the framework is depicted in Fig. 1. The proposed framework interacts with WSNs and exposes their information and functionalities in form of web services to other environments. The main benefits of this framework are: • Application-independence: The proposed framework can be used for different applications running in WSNs. Therefore, it is easy to add new sensor nodes with different applications to existing WSNs as well as to deploy the framework for new WSNs.
385
Fig. 1. The generic Framework for interoperability between WSNs and external environments • Unified programming interface: Since the framework exposes the data and functionalities of WSNs as set of web services, it provides a unified and standardized interface for other environments to interact with WSNs. • Transparency: The interoperability between WSNs and external environments is via web services. External environments can communicate with WSNs easily and transparently without knowing any details. The developers only need to concentrate on data manipulation without worrying about network details. • Reusability: The framework can be used for deploying different types of WSNs without reprogramming. • Easy integration with other environments: Exposing WSNs as a set of web services makes the integration of WSNs with other environments easier. • Direct access to sensor nodes: The sensor nodes can be directly accessed from the Internet via the services of the framework. In the following sections we will present a more detailed structure of our proposed framework and its operations. 3.2 Framework Architecture This framework adopts the gateway-based architecture with proxy components to provide interoperability. The proxy components of the framework are responsible for interacting with WSNs in order to compose and to provide services for other environments. The framework has also ability to dissect multiple protocols of WSNs as well to analyze the aggregated data. These components make WSNs transparent to external environments. As depicted in Fig. 1 the proposed framework comprises six main components: Web service interfaces, Task Scheduler and Execution, Message Composer and Forwarder, Packet Analyzer, Virtual IP mapper, and a set of services. The web service interfaces are the entry point where other environments can access the data. The Task Scheduler and Execution is the module where the requests are scheduled and executed. The Message Composer and Forwarder is responsible for translating the request messages into the WSN messages and forwarding them to the WSN. The Packet Analyzer inspects the packets from the WSNs in order to extract the sensing data. The Virtual IP Mapper
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 will assign a unique virtual IP for every sensor node based on the information it receives from the Packet Analyzer. Virtual IP addresses are stored in the IP mapping table of the framework. The information from the Packet Analyzer is also used by other services of the framework such as localization and mobility. To realize the framework, the following methods and techniques are used: • Service-Oriented Architecture (SOA): SOA is used to expose the data, functionalities and services of WSNs as a set of web services. The web service interfaces are used to offer a language independent platform. • Traffic Description Language: The sensor network traffic will be described by XML so that it is possible to adapt the framework for new protocols of WSNs. The framework includes a mechanism for analysing traffic of the WSN and for composing the packets based on the traffic description. In fact, the traffic description language is the mechanism used by the framework to adapt to new applications and protocols by adding the new traffic descriptions instead of reprogramming the framework’s components. • Virtual IP Mapping: Mapping mechanisms are used to assign virtual IPv6 addresses to sensor nodes. The mapping information depends on the protocols of the sensor networks. This virtual IPv6 mapping allows the external environments to access sensor nodes using their IP addresses as unique identifications. • Extensible architecture: The framework is designed as a flexible architecture which allows to easily add new or existing components. 3.3 Operations of the Framework In our approach, external environments access the data and functionalities of the WSN via a gateway using a set of web services. When receiving a request from the external environment, the Web services engine will parse the request and forward the requested information to the Task Scheduler and Execution component. The Task Scheduler and Execution component will put the request into the Task list and process it. Depending on the request, it can be scheduled to execute one or more times. After that the information may be forwarded to the Message Composer and Forwarder where it will be translated into the internal format and sent to the WSN. How the Message Composer and Forwarder composes the message depends on the packet formats that are described in the Sensor Traffic Description. The Sensor Traffic Description is one of the factors that make the framework flexible to new applications and protocols. The Packet Analyzer also uses the information in Sensor Traffic Description in order to dissect the packets from WSNs. It will store the data into the database and provide the information for the Virtual IP mapper to build the virtual IP mapping table. At the same time, it provides other necessary information for other services such as localization and mobility (if required). The current model allows Internet users to access individual node (using virtual IP) via web services. This also
386
offers a secure environment by providing authentication and authorization services at the gateway. Furthermore, the encryption services can be easily integrated into the gateway to secure the data. Exposing WSNs as a set of services There are two types of services that WSNs can provide for external environment: data and operations. Data is sensed by sensor nodes and consumed by the external environments for visualization and monitoring. The operation services allow client applications and other tools to control the operations of individual sensor nodes and to actuate other systems. To provide data services, the Packet Analyzer captures and analyzes the traffic from sensor nodes and stores these data in a temporary buffer. The data web services of the framework will provide these data to the clients. The Packet Analyzer has ability to analyze multiple protocols of WSNs (e.g., Active Message, 802.15.4, 6loWPAN). It dissects the sensor traffic from the sensor nodes and passes the identification to the IP Mapper to associate an IP address to the sensor node if it does not exist. In order to provide the application-independence for the framework, the traffic description language is used to describe the structure of application’s data. Based on these descriptions the packet analyzer extracts the correct data. The applications’ data and related information is, then, stored in the data buffer for further processing. The functionalities of the sensor nodes are also provided via a common set of web services. These services allow directly access to individual sensor nodes or group of nodes. The parameters of the services include the identification of the node(s) (ID or IP), and the command. The Message Composer & Forwarder component is responsible for composing and forwarding the command to the corresponding sensor node(s). Virtual IP Mapper The virtual IP mapper is responsible for assigning a unique virtual IPv6 address for each sensor node. The mapping information corresponding to virtual IP depends on the WSN. This functionality allows sensor nodes to be exposed as normal IP nodes to external environments. The list of virtual IPs is provided by the IP mapping table service which can be accessed via the web service interfaces. Mobility, localization, and authentication and authorization services To support mobility and localization services in our architecture, we assume multi-sink environments. The area may be covered by several sink nodes. Therefore, mobile nodes would be able to connect to the best sink in each specific moment, guaranteeing the connectivity anywhere and anytime. In our testbed, we performed a study based on the received signal strength indication (RSSI) value in order to detect the movement of sensor nodes. Although RSSI value is inaccurate, it gives the relative useful information deciding which proxy will be responsible for the mobile node (Silva et al., 2009). Localization is the process that calculates the location of devices. The relative position of the sensor nodes is very important in many types of applications. The RSSI value can be used to estimate the distance between two sensor
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010
Fig. 3. Interaction between sensor node and SL object
Fig. 2. Interaction between sensor node and SL object nodes. Therefore, it is possible to calculate the relative position of a sensor node in a WSN if we can collect the RSSI value of that sensor node by at least three fixed reference sensor nodes. In WSNs, RSSI value is usually available and it is one of the simplest parameters for ranging and location estimation. The next section describes an example process that was implemented in our lab for the communication between a sensor node and an object in Second Life (SL) virtual world using the proposed framework. In this example, we will explain how to use the localization service to illustrate the mobility of a sensor node in SL environment. 4. MOBILITY OF SENSOR NODE IN SECOND LIFE VIRTUAL WORLD In this section, we present a simplified workflow of using the proposed service-oriented framework for mapping a sensor node to an object in Second Life. We illustrate how to visualize mobile sensor nodes in SL. In this scenario, the localization service of the framework is used to calculate the location of the sensor node and the mobile sensor node is visualized by making the avatar in SL with the ability to move. To realize this, we attach a SL object to the avatar and that object is scripted to be connected to the Web Service Interface of the framework. So it gets the position of the corresponding sensor node. Fig. 2 describes the process of mapping and the communication protocol of the SL object with the sensor node. The first step to implement this use-case is to script the SL object and map it to the sensor node that it will get the information from. This mapping can be based on any information that uniquely identifies the sensor node. According to our framework, we can use the virtual IPv6 address to uniquely identify the sensor node. Currently, there are two methods to implement this scenario in SL. The first one is to program the SL object to periodically send requests to the web services of the framework in order to get the latest location of corresponding sensor node
387
and update the position of the corresponding avatar in SL. The second method is to include a function in the framework that sends the updated position of the sensor node to the corresponding SL object whenever the sensor node changes its position. The second method seems more appropriate. However, the current method for interacting with SL objects from outside is via SL XML-RPC gateway and this gateway has some limitations that should be solved in order for this method works smoothly. Firstly, the XML-RPC gateway of SL only allows one message per channel to be queued at any time. Furthermore, each message has at least three-second delay. Therefore, it takes a long time (at least three seconds) for sending data from a sensor node to the SL object. Because these limitations, we implemented our scenario using the first method. In our implementation, the SL object is scripted to send a location request to web services interface of the framework every second. In order to provide the relative position of the sensor node, the localization service employs the trilateration technique that needs the RSSI values from three or more fixed reference sensor nodes. Therefore, to support this service, the architecture of WSNs must be carefully designed. In our testbed environment, four sensor nodes at fixed positions is used as beacons that collect the RSSI information from mobile sensor nodes and send it to the localization service of the framework. In our framework, the Packet Analyzer component is responsible for collecting the RSSI information from beacon nodes and providing them to the localization service. In our prototype, we implemented a proxy component that collects RSSI values from the sensor node and calculates the location of sensor node. The location of sensor node, then, is visualized in the Second Life by making the avatar to which the SL object is attached moving when the sensor node changes its position. This system is depicted Fig. 3. The next section will describe a real application scenario that we are implementing using our proposed framework. 5. APPLICATION SCENARIO We are applying our framework in the employees’ health monitoring scenario in an oil refinery in the context of the
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 transparent to external environments as well as preserve the specific characteristics of WSNs. The interconnecting infrastructure should also include supporting services for WSNs such as mobility, localization and security.
Fig. 4. Model for realizing the employee’s health monitoring using the proposed framework with Second Life FP7 GINSENG project (GINSENG, 2008). The overall goal of GINSENG is to provide a wireless sensor network that will meet specific performance targets, that will integrate with industry resource management systems, and that will be proven in a real industry setting where performance is critical. One of the selected scenarios of GINGSENG is monitoring safety and pollution supervision in the oil industry. Oil refinement is a complex and dangerous process, during which any small failure can lead to disaster, with serious consequences on human lives, on the environment as well as on the economy. Since oil refinement is a hazardous working environment, it is necessary to monitor the current heath status of the workers (e.g., heart rates, body orientation, and locations) as well as the environment conditions (e.g., temperature, light). In order to realizing this real application scenario, Second Life (Linden-Research, 2010) virtual world is used as a tool for visualizing the employees’ health and environment conditions. Each worker is equipped with one or more sensors and a special smart-shirt (Pandian et al., 2008). In this scenario, the services of the proposed framework collect information about the employees’ location, their health status and surrounding environment condition. The collected information is transmitted to the SL for displaying. We are using the proxy-based WSN architecture proposed in (Silva et al., 2010) for monitoring the mobility and the location of the employees. The model for deployment this scenario is depicted in Fig. 4. As depicted in Fig. 4, each worker is equipped with at least one sensor node called mobile node (MN) and its mobility is managed by a set of Sensor Mobility Proxies (SMPs) which are all connected via a shared SMP backbone. In order to determine the location of the worker, the WSNs also include a set of fixed sensor nodes called reference points (anchor or beacon nodes). These reference fixed sensor nodes provide the necessary information for the location service of the framework so that it can calculate the positions of mobile nodes (workers). The location information as well as other sensed data from the sensor network is visualized in the Second Life so that other people can continuously monitor the workers’ heath, location, and environment conditions. This helps the systems to create warning and to act timely. 6. CONCLUSION WSNs will be an integral part of our daily life and they will become important components of the Future Internet. Interconnecting WSNs and external environments is a deniable requirement. However, it is crucial to make WSNs
388
This paper proposed a framework for interconnecting WSNs and external environments. The framework exposes data and functionalities of the WSNs as a set of web services, making WSNs transparent to other environments. Furthermore, the framework has ability to be adapted to new applications and protocols as it assumes a WSN as a plug-and-play component of the Future Internet. In this paper, we present how to integrate WSNs with Second Life virtual world using the proposed framework. we also present a real application scenario that is being implemented. As a future work we intend to evaluate the performance and the reliability of the framework. Furthermore, our current location service for WSNs is based on RSSI measurement, but these values are unstable because of noise, obstacles and anisotropy of antenna. Therefore, in the future we will investigate and design a more stable method for estimating the ranging and location based on RSSI value. ACKNOWLEDGEMENTS The research leading to these results has received funding from the EU Seventh Framework Programme (FP7/20072013) under grant agreement n 224282, Project GINSENG and from PULSE ”Inteligencia de Negocio em Tempo Real”, 5354 QREN. REFERENCES A. Dunkels. Full tcp/ip for 8-bit architectures. In MOBISYS’03, 2003. A. Dunkels, J. Alonso, and T. Voigt. Making tcp/ip viable for wireless sensor networks. http://www.sics.se/ adam/ewsn2004.pdf, 2004a. A. Dunkels, J. Alonso, T. Voigt, H. Ritter, and J. Schiller. Connecting wireless sensornets with tcp/ip networks. In WWIC 2004, volume 2957, pages 143–152. LNCS, 2004b. K. A. Emara, M. Abdeen, and M. Hashem. A gatewaybased framework for transparent interconnection between wsn and ip network. In Fourth International Conference on Intelligent Computing and Information Systems, 2009. K. Fall. A delay-tolerant network architecture for challenged internets. In Proceeding of the SIGCOMM 2003 conference, 2003. GINSENG. Ginseng - performance control in wireless sensor networks. http://www.ict-ginseng.eu/ documents/md_1_necs-ginseng.pdf, 2008. J. Hui, D. Culler, and S. Chakrabarti. Internet protocol for smart object (ipso) alliance. white paper 3, 2009. Linden-Research. Second life. http://secondlife.com/, 2010. G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler. Rfc 4944: Transmission of ipv6 packets over ieee 802.15.4 networks. http://tools.ietf.org/search/rfc4944, 2007. K. Pandian, K. Mohanavelu, T. Safeer, D. Kotresh, P. Shakunthala, and V. Padaki Gopal. Smart vest:
MCPL 2010 Coimbra, Portugal, Sept 8-10, 2010 Wearable multi-parameter remote physiological monitoring system. Medical Engineering & Physics, 30(4): 466–477, 2008. L. Shu, J. Cho, S. Lee, M. Hauswirth, and L. Zhang. Vip bridge: Leading ubiquitous sensor networks to the next generation. Journal of Internet Technology, 8(3), 2007. R. Silva, J. Sa Silva, M. Simek, and F. Boavida. A new approach for multi-sink environments in wsns. In IM’09: Proceedings of the 11th IFIP/IEEE international conference on Symposium on Integrated Network Management., 2009.
389
Ricardo Silva, Jorge Sa Silva, and Fernando Boavida. A proxy-based mobility solution for critical wsn applications. In In the proceedings of Second International Workshop on Medical Applications Networking, 2010. M. Zuniga Z. and B. Krishnamachari. Integrating future large-scale wireless sensor networks with the internet. Technical report, Department of Electrical Engineering, University of Southern California, 2003. A. Zimmermann, J. Sa Silva, J. Sobral, and F. Boavida. 6glad: Ipv6 global to link-layer address translation for 6lowpan overhead reducing. In Next Generation Internet Networks (NGI 2008), pages 209–214, 2008.