«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
as to create a single (logical) network. More specifically, there are reasons that can be enumerated in favor of using IP in WSNs in terms of interoperability .
• IP is open and freely available. It can reach a larger audience than a proprietary protocol , which favors interoperability.
• IP is a universal protocol in terms of the variety of applications, devices, operating systems and underlying networking technologies that it supports. In fact, IP accommodates a wide range of applications with significantly different QoS requirements, such as e-mail, bulk data transfers, high definition television or voice over IP (VoIP).
• IP successfully runs on high-end servers, desktops, mobile phones and severely constrained devices like sensors. On the other hand, IP was designed for connecting physical networks with different characteristics. The Internet is a good example of the success of IP in this regard.
• IP offers end-to-end communication between devices, which does not require PTGs. Fig. 13.4 represents the end-to-end IP vision for connecting WSNs to the Internet.
13.3.2. Benefits of IPv6 In addition to the benefits of IP in terms of interoperability between networks, IP version 6 (IPv6)  is particularly suitable for WSNs. First, it defines a large address space, where the size of addresses is 128 bits, that satisfies the requirements of WSNs in terms of their potentially large number of devices. Second, it has many auto-configuration and discovery mechanisms, which match the unattended operation required by WSNs. Finally, it uses compact headers that allow the definition of new options when new functionality is needed. However, IPv6 does require an adaptation for optimized performance on top of WSNs. This work has been carried out by the IETF 6LoWPAN WG. For a detailed description of how IPv6 is used in WSNs, the reader may refer to Chapter 11 (section 11.1.2).
13.3.3. Adoption of IP for WSNs
In the last years, relevant industry alliances in the area of WSNs, such as
Z-Wave and ZigBee, have announced their intention to adopt IP technology:
• In May 2007, the Z-Wave Alliance announced the Z/IP program to drive convergence of Z-Wave and TCP/IP and “to take Z-Wave to the next level of worldwide adoption” . In May 2009, the IP-Wave single chip solution, which runs an IP stack on a Z-Wave chip, was announced. The manufacturer recognized that interoperability between IP and Z-Wave was “a crucial step in the process” because “it is [...] imperative that home control networks be able to interface with the Internet” .
• On the other hand, in April 2009, ZigBee announced that “it will incorporate global IT standards from the Internet Engineering Task Force (IETF) into its specification portfolio of low-power wireless networking standards” . Further information from the ZigBee Alliance confirms the ZigBee plans with regard to IP protocols . Previously, an adaptation of the ZigBee Application Protocol called Compact Application Protocol (CAP) had been proposed for its use on top of UDP/IP  (see Fig. 13.5). These announcements and activities show a tendency in the WSN industry to adopt IP and take advantage of its benefits.
Chapter 13. Interoperability between wireless sensor networks and other networks Fig. 13.5. ZigBee adaptation to IETF 6LoWPAN protocol stack 13.3.4. IETF work in progress and future work While the IETF 6LoWPAN WG has developed mechanisms for the transmission of IPv6 packets on top of IEEE 802.15.4 networks (see Chapter 11) and the IETF ROLL WG is currently developing a routing protocol for LLNs (see Chapter 7), upper layer functionality for these environments has only started to attract the attention of the IETF community very recently . For this reason, although it is feasible to run full IP stacks in typical embedded devices using standard Internet protocols , many implementers are currently using special, ad-hoc, transport and application layer protocols within the WSN. This approach currently limits the interoperability between WSNs and the Internet. Work within the IETF in this area is only in a preliminary stage. Hence, the study, development or adaptation of transport and application layer protocols based on IP for WSNs is an open area as of the writing of this book.
13.3.5. Usage of existing session/application protocols for WSN This section discusses the use of various session or application protocols for the interconnection of WSNs with external TCP/IP based networks like
the Internet; such as SIP, XMPP, MQTT-S, HTTP or web services. Note that it may be difficult to distinguish session and application protocols due to the terminology used or the protocols themselves that implement session and application functionalities.
The Session Initiation Protocols (SIP) was originally created to control multicast conferences and later evolved as a control protocol for multimedia communications like voice and video. In fact, SIP has become the standard protocol to support voice over IP by the IETF and also by the 3GPP. SIP offers the possibility to register an IP address with an identification known as a uniform resource identifier (URI) and to establish a session for the continuous exchange of information. SIP has been extended to be used as an instant messaging protocol and also to exchange status information also known as presence information. SIP has defined the role of the user that provides information when a change is produced using the PUBLISH or the NOTIFY command when another user is interested in the information. The user can express its interest in a status variation with the SUBSCRIBE command. Information about the status (including location) is coded using an XML format. Also SIP defines mechanisms to send a command to a group of users with the forking function48 or merging different replies. All these facilities are quite in line with the requirements of high level communication of a WSN. The possibility of using SIP has been analysed , but the complexity of the protocol suggested the using of a simplified version called TinySIP .
The eXtensible Messaging and Presence Protocol (XMPP)  is an alternative to SIP as a presence protocol and it has been proposed as WSN communication protocol [24, 25]. XMPP has been developed by the Jabber open The forking request of SIP means that multiple dialogs can be established from a single request Chapter 13. Interoperability between wireless sensor networks and other networks source community and has been accepted by the IETF (see RFC 3920 ).
XMPP uses as a core transport protocol layer an eXtensible Markup Language (XML) streaming protocol49 (see chapter 12). This permits two entities to exchange XML elements over the network. The protocol is based in three stanza types: presence/, message/ and iq/. The first stanza is used as a publish/subscribe mechanism for subscribing to a status event and receive information about it. The second one is used as a push mechanism for real time delivery and the last one is used to make request and receive responses. Jabber uses a naming approach that allows identifying a sensor node or the sensor itself. One of the main distinction characteristics of XMPP is the federation that allows communication between different domains quite easily.
The usage of XML based protocols has received certain criticism due to the verbosity and the processing requirements, but it has proven the feasibility of the solution using simplified approaches such the mXMPP  or compressing the XML with EXI (Efficient XML Interchange)50.
XMPP has been used in solutions such as OpenSpime , a proposal from WideTag to support data collection and encrypted messaging between entities.
The publish/subscribe mechanism is also used in the protocol MQTT-S of IBM [30, 35]. This protocol is a light weight implementation or extension of the Message Queueing Telemetry Transport (MQTT) protocol for WSNs. The MQTT is a protocol used in resource-constrained devices. The implementation in the client side is very simple. Most of the complexity resides in the server side (the broker side according to MQTT terminology). The protocol XML is used on top of a persistent connection such as the one provided by TCP. It is possible to transport the XML messages using HTTP but this requires the usage of an XMPP Enhancement Proposal (XEP). One example is the XEP 0124 “Bidirectional-streams Over Synchronous HTTP (BOSH)”, which is suitable for WSN.
EXI is a proposal from the EXI Working Group of the W3C to optimise the usage of XML.
The proposal includes a more compact coding for XML structures.
assumes an underlying network providing point-to-point connection, session oriented and in-order delivery. MQTT-S, opposed to MQTT does not assume any functionality from the network and requires an MQTT-S gateway to support the connectivity with the broker. A sensor node publishes its data to the broker and an entity interested in the data registers its interest in the broker by means of a subscription. Any published data that matches with the existing subscriptions will be propagated by the broker to the interested entities.
MQTT-S uses streaming of binary data at higher level protocol (instead of streaming of XML data).
Due to the popularity of the web, the usage of HTTP has a significant acceptance in WSNs. HTTP can be used to get data from a sensor, in a similar manner data is obtained by a web browser from a web server .
Also, web service techniques can be used for interacting with a sensor node. This last option has two implementations . The first one is the classical one  and implies the usage of SOAP (Simple Object Access Protocol) to define the format of the messages exchanged when invoking a service and Web Services Description Language (WSDL) to describe the syntaxes of the interfaces. SOAP and WSDL are based on XML instances.
Handling this implementation of a web service can be considered complex for a limited resource sensor node and an alternative has been developed based on the Representational State Transfer (REST) principle . According to this model, four commands can be used (GET, PUT, POST and DELETE), the web service is stateless so commands result to be idempotent. Information exchanged can be encoded using XML, but other formats are possible. One example is Java Script Object Notation (JSON), which allows the exchanging and serializing of data structures.
Although JSON is quite common, XML or HTML can also be used. The format used in data exchange should be used by both sides of the communications since no mechanism similar to WDSL is available. REST additionally allows leveraging all the features intended for HTTP such as caching, authoring, encryption and compression.
Chapter 13. Interoperability between wireless sensor networks and other networks
With REST, a GET is used to obtain data from a sensor or a PUT to send data from a sensor. This approach is followed by Pachube . With this system, a sensor can feed information to the Pachube web server (making an input) or collect information from the web server (making an output). The data exchanged is coded with Extended Environments Markup Language (EEML)  or using Comma-Separated Values (CSVs). The first one is intended to describe data collected from a device, building, system or space in a structured form. EEML is similar to SensorML, but it extends its capability describing the environment of the sensor node (see chapter 12). The CSV is more simple but less flexible than EEML.
The IETF CoRE working group, which is intended to standardise session and application protocols for constrained networks51 using IP, proposes the use of RESTful solutions . There are implementations of RESTful solutions for different wireless sensor plataforms , .
Another HTTP-based alternative is the use of web feeds such as Really Simple Syndication (RSS) or Atom to publish the information from a sensor.
13.4. SCADA for WSN applications
Supervisor networks or control networks such as Supervisory Control And Data Acquisition (SCADA) systems are intended to be used for industrial control, infrastructure usage or large facility control. A SCADA system is built with a human machine interface to interact with an operator, a supervisory system (a computer) for gathering data and sending commands, Remote Terminal Units (RTUs) to support the data acquisition and control, Programmable Logic Controllers (PLCs) to distribute the control functions and a communication infrastructure. This type of networks shares some aspects with wireless sensor and actuator networks. In fact, a SCADA system can be used as a replacement of a WSN, since they include all the elements and functionalities of a WSN, but the cost of elements and complexity of installation of a SCADA system do not fulfil the requirements of a WSN. A WSNs are an example of such considered constrained networks.
SCADA system offers guaranties related to the delay and availability, in particular in the control of actuators, more restrictive than the ones offered by present WSNs. Even though, WSNs are being used to complement a SCADA system [31, 32] or even to replace it .
SCADA systems use their own specific communication protocols with the intention to provide the required reliability and availability. The protocols used include Modbus, RP-570, Profibus or Conitel. IEC 60870-5-101, IEC 60870-5-104 or DNP3 are standard SCADA protocols. Most of the protocols have extensions to work over IP, but control applications refuse to use the public Internet. Modbus is used in some WSN deployments due to the fact that it is royalty-free, it is publicly available and it is simple. Modbus can transport data in binary format and in ASCII. In addition, there are Modbus gateways able to use SMS or GPRS.
13.5. Integration of WSNs into IMS