Real-Time Data Dissemination for Wireless Sensor

Networks using XMPP

Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

CISTER/IPP-HURRAY! Research Group, Polytechnic Institute of Porto (ISEP-IPP), Rua Dr.

Antonio Bernardino de Almeida, 431, 4200-072 Porto, Portugal
{vjmg, llf, jich, ffp}@isep.ipp.pt

Abstract. The advances on Wireless Sensor Network (WSN) Technologies

triggered the need to acquire and disseminate the data from these installations to
remote clients on the Internet. Many WSN applications also have real-time
requirements, thus real-time access to this data is also required. In this paper,
we propose an architecture for the dissemination over the Internet of WSN data
in real-time. The proposed solution is based on the XMPP protocol and on its
Jingle extension, for non real-time and for real-time applications, respectively.

1 Introduction

In recent year the continuous development and widespread use of Wireless Sensor
Networks (WSN) has triggered the need for architectures capable of disseminating the
information captured by WSN sensors through the internet to remote clients.
However, some of these applications have real time requirements [1], and require
specific architectures for their particular requirements.
WSNs’ need for information gathering has been handled by well established
protocols, like ZigBee [4] and 6LoWPAN [5], and by some other more experimental
protocols, like Sensor Transmission Control Protocol (STCP) [6] or Congestion
Detection and Avoidance in Sensor Networks (CODA) [7]. WSN data dissemination
over the Internet can also be based on some well established protocols, which operate
over TCP/IP, like HTML web pages which are used on the SenseWeb project [8] or
with web services [2]. In these cases the data source is a database which can be
accessed by a query to retrieve information.
But these end-to-end architectures are not capable of delivering sensor-related data in
real-time, i.e. with predictable and well known delays. Most WSNs have real-time
issues in consideration and there are also protocols that enable soft real-time
performance on the Internet. The main issues against real-time accomplishment are
the use of a database as the source of all information and the use of the Service
Oriented Architecture (SOA) paradigm. The approach is centralized around the
database, its components are very decoupled and message oriented. When a client
makes a data request, it will have to pass through several layers until reaching a
database where the data is stored. After that, a database query is performed and a
result is returned to the client through the inverse path.
2 Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

This kind of transactions increases the round-trip-delay since it causes a high message
overhead and turns the access to the database the bottleneck of the system. It also can
be considered inefficient, since when a client is interested in retrieving the
information continually in real-time it has to make constant requests to receive the
data; another disadvantage is that if several clients are monitoring the same data, each
one has to make its own request and the response is individually delivered. To make
things worse (in terms of real-time performance) a messages are used to communicate
between several modules. Such kind of behavior further increases the overhead of the
system.
To overcome the performance drawbacks of such kind of message-oriented and
centralized database approaches, in this paper we propose an architecture for real-time
delivery of WSN data to a group of applications. Our approach has several differences
from the previous mentioned architecture: i) content delivery oriented to group-
applications, not to a single client; ii) data transmission is supported by protocols
which can give real-time guarantees; iii) uses a reduced number of layers between the
data source and the client; iv) uses streaming approach for content delivery.
This work has been motivated by the requirements of a human motion tracking
application [3], which aims at tracking, in real-time, the movement of the human
body. The information concerning the position and orientation of each body part is
acquired by 15 WSN nodes, each one provided with an inertial system. This
information is then transmitted to a sink node which is responsible for processing
sensor data and for its dissemination to IP-based remote clients. Since we want real-
time tracking the data acquired from the sensor node should be transmitted to the
remotes clients with soft real-time guarantees, which can be provided by the system
proposed in this paper.
This paper is organized as follows. Section 2 provides an overview of the proposed
architecture using a four tiers model. Section 3 describes the proposed architecture
and its implementation for non real-time application and Section 4 for real-time
applications. Section 5 provides scenario for the application of the propsed framework
to a human motion tracking scenario. Finally, on Section 6 we draw some conclusions
and discuss our future work.

2 System Overview

The data dissemination process can be divided into 4 different phases: data
acquisition, presentation, tranmission and consumption. The four tiers model (Fig 1.)
proposed in this paper separate these four phases into four different layers: WSN
Layer, Data Layer, Transport Layer and Client Layer. Separating the implementation
into these layers provide the means for ease of deployment and adaptability to
different application requirements.
The WSN Layer is composed by a set of wireless sensor nodes that measure a
physical phenomenon and converts its data into a digital format. These nodes are
usually designed for specific applications; thus the type of information transmitted
varies according their sensory capabilities. To solve this problem the data encoding
specification must be known by the Data Layer. Due to the low processing capacities
of the nodes, we assume that data might be transmitted in a raw format or with low
 Real-Time Data Dissemination for Wireless Sensor Networks using XMPP 3

level processment and further processed at the Data Layer. This sink node operates as
a kind of gateway interconnecting the WSN to other networks (Data Layer).
On the Data Layer the data encoding is performed and it might also be subjected to
further processing. The data comes from the WSN Layer and is properly encoded in a
convenient form, e.g. XML. After the encoding, it’s critical to immediately deliver the
data to the clients in order to minimize the delay. To accomplish that, one data
transport channel is established with the Transport Layer.
The Transport Layer forwards data from the Data Layer to the Client Layer. By
isolating the data transport from data retrieval and encoding/decoding, optimized
procedures can be taken to answer specific needs. Defining the transport protocol,
service discovery, network backbone and routing paths are some of the aspects of the
implementation that must be considered. This layer delivers the data to the Client
Layer by creating single or multiple data transport channels with entities from the
Client Layer.
Finally, the Client Layer receives the packets from the Transport Layer. Algorithms
for encoding to a specific format, recovering lost packets and jitter compensation can
be present to provide compatibility and improved service experience.
In our system’s design when an application changes, the WSN layer might require
modifications, the remaining layers only need to be properly reconfigured.
The main contribution of this paper is to propose an architecture to the Transport
Layer, which can use has its transport protocol Extensible Messaging and Presence
Protocol (XMPP) or the Real-Time Protocol (RTP), these approaches are discussed in
the Sections 3 and 4. The first is oriented towards non real-time applications and the
second is oriented for applications requiring real-time performance.

Fig. 1. System architecture

3 XMPP Transport Layer Architecture

In this work the Extensible Messaging and Presence Protocol (XMPP) [9], a well
established and open source technology, was the first approach to transport data. This
technology was originally developed for instant messaging applications, and it has
been extended to support other applications, like voice and video communications.
But in fact, it can serve our purpose of delivering WSN data to a large number of
clients. This section describes the approach based on XMPP, while Section 4
describes the Jingle approach.
4 Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

3.1 XMPP Overview

XMPP technology is based on the client/server paradigm where clients are

interconnected through servers. Therefore, when two clients want to communicate
they connect to a XMPP server and start exchanging XMPP messages. Messages
exchanged between clients are always relayed by a server. Such kind of
communications can be encrypted and the clients are also able to run an
authentication protocol to connect with the server(s). The XMMP clients are
identified by a unique identifier called Jabber Identification (JID).
XMPP servers are also capable of connecting between each other for scalability
proposes. In this protocol all communications are coded using the XML protocol so
all its content is text based and easily understandable in every platform.
Additionally, the use Multi-User Chat (MUC) functionalities [15] offers the means of
sending the same message to several clients breaking the one-o-one model. This
technology resembles the IRC’s chat rooms where an authorized user can post a
message in the virtual room and its content can be “heard” by all present. It is
supported by most of the open-source server implementations. Its major drawback is
that the implementations available of these technologies use unicast to deliver the
messages, instead of multicast.

3.2 Communication Between Entities

This implementation was developed using XMPP and the MUC protocol. There are
two main flows of information: the communication channel between the Data Server
to the Transport Server and from the Transport Server to the Clients.
Although they use the same protocol to transport data, their end points have different
characteristics. The connection from the Data to the Transport Layer is a one-to-one
relation to reduce traffic overhead. The communication from the Transport to Client
layer is a one-to-many relation, as seen in Fig.2 by the cister.ipp.pt Transport Server;
that connects directly to two clients.
 Real-Time Data Dissemination for Wireless Sensor Networks using XMPP 5

Fig. 2. System overview

XMPP was design for one-to-one communication, so for the Transport-Client relation
we used Multi-User Chat (MUC) protocol. Consequently, transmitting data from the
WSN Layer to a large set of clients only requires the transmission of a message from
the Data Layer to a MUC entity.
The implementation details of the Transport, Data and Client Layer are detailed in
sections 3.4, 3.5 and 3.6 respectively. Meanwhile it’s important to describe the initial
state of the system.

3.3 Initialization

The initialization processes are all actions concerning service discovery or WSN
information retrieval. This approach allows the prior to run-time configuration of the
Data Server, thus allowing its adaptation to many different situation without code
changes. As an example, in our motivational application we can specify that the
attitude of each body part should be mapped into 15 independent MUCs. As is
described on Section 5 these configuration choices can have a different impacts on the
system performance. Such information is managed by the Service Discovery Manager
that resides in the Transport Layer.
During initialization the Data Server starts by retrieving from the Service Discovery
Manager its Service File. This file, coded in XML, contains a description and the
number of MUCs to be used, as well as its mapping to the sensor data acquired by the
WSN Layer.
Also the Client has to request the Service File to know the location of the required or
available Transport Servers. It also retrieves the Content File which contains an XML
Schema that allows the validation of the received data and its mapping into data
objects (using the Java Architecture for XML Bidding (JaxB) API [12]). Fig 3 depicts
an example of the initialization procedure. If the services and WSN are somehow
static these proceedings can be skipped when the entities already posses all
information about the service.

3.4 Transport Layer

This layer interface provides mechanisms for the registration, authorization and data
transfer, ensuring that data is delivered to authorized clients only. These mechanisms
are supported by XMPP servers.
Also for service discovery, a Service Discovery Manager should be present to provide
information about services and the location of servers, information about WSN
configuration, sensor node capabilities and description. However, in the present
implementation status the Service Discovery Manager has not been implemented, the
service and description file are locally available the Client and Data Layers.
The Transport Servers (Fig. 2) are the main elements present in this layer and they
provide the interface between the Data Layer and the Client Layer. In order to use the
MUC protocol, first a XMPP server supporting such technology must be installed. We
are using the Openfire 3.6.4 [13] XMPP server. This implementation uses the MUC
6 Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

protocol to easily deliver content to clients. The Transport Server allows MUC rooms
creation by Data Servers as well as data post actions. The clients are only allowed to
receive messages after authentication with the Transport Layer.
When the Data Server terminates, it is the responsibility of the Transport Server to
destroy MUCs created by the application and send a message notifying the Clients.

3.5 Data Layer

After the first phase, showed in Fig 3, the Data Server interaction with the Transport
Layer can be resumed in phases 2 and 3: the transport server’s configuration and the
data transmission.
Using the Service File the Data Server saves, in a data structure, the MUCs room
scheme. Then it requests the Transport Server to create such MUC structures. After
creating those structures, the Data Server starts the dissemination of data to the
MUCs. When the Data Server leaves the room, the service ends.

Fig. 3. Initialization and run-time operation

3.6 Client Layer

After consult the Service File and the Content File the client starts by joining the
MUCs based on its interests, as showed in Fig 3, phase 4. It is important to note that a
client might only be interested in receiving specific parts of the data produced on the
WSN Layer. As an example considering our motivational human body motion
tracking application, a client application might only be interested on the movement of
an arm and hand for gesture recognition. Another application might be interested on
the movement of the legs for the monitoring of an athlete.
After joining the room no more requests are needed to retrieve information. As long
as the client remains in the room it is continually feed (Fig 3, phase 5) with the newest
data. The data received was encoded with JAXB API to Java objects for easier data
manipulation. In our main motivational application context, the Client provided
information to a rendering program in order to see the sensor’s movement.
 Real-Time Data Dissemination for Wireless Sensor Networks using XMPP 7

4 Jingle/RTP Transport Layer Architecture

The RTP protocol [11] has been designed for the delivery of streaming media,
particularly audio and video over the Internet. It allows a receiver end point to
compensate for the communication Jitter, provides the means for a transmitter to
adapt its transmission rate and allows the re-ordering of packets on a receiver. It
usually operates on top of the UDP protocol, therefore packet delivery is not
guaranteed, contrarily to TCP.
The Jingle is a XMPP extension for establishing sessions. It has been primarily
designed for supporting the signaling on VoIP communications, but it can be used for
other kind of aplications, as is our case. The Jingle itself is just used for signaling,
configure and maintain the transport channel. In this alternative the Real-Time
Protocol (RTP) is used for communications between the Data Server and the
Transport Server and between the Transport Server and the Clients.
The use of RTP is mainly due to its improved performance which results from the
smaller overhead of the UDP protocol. In relation it exhibits lower communication
delays, but it has the drawback of not guaranteeing the delivery of packets
In section 4.2 the initialization process is described as well as the Jingle protocol
phases. Sections 4.3 to 4.5 detail the implementation on each layer focusing mostly on
the differences between this implementation and the XMPP-based implementation.

4.1 Initialization

To initiate the data dissemination process the Data Layer and Client Layer use the
Service File to know the JID from the Transport Server. Therefore, the Jingle
negotiation process requires the use of a XMPP client bot, running on the Transport
Server to answer the requests.
As depicted in Fig. 4, when using the RTP protocol the Initiator (in our case the
Client or the Data Server) always takes the initiative and contacts the Responder (the
Transport Server) by delivering a session initiate request containing, among other
information, the IP address, port and data encoding (XML, binary, etc) supported. The
Transport Server answers with an acknowledge, and a session accepted follows
containing its own IP address, port and the data encoding chosen. The initiator accepts
the terms, it sends an acknowledgement and both end points can start an RTP data
transport channel. Notice that the RTP channel does not pass information through the
XMPP server, it is a peer-to-peer channel between the Initiator and the Transport
Server.
In our architecture the Responder is always a Transport Server and the Initiator could
be a Client or a Data Server. Further details are explained in Sections 4.2, 4.3 and 4.4.

4.2 Transport Layer

In this implementation, there are 3 main elements: the Service Discovery Manager,
the XMPP Server and the Transport Server. The role of the Service Discovery
Manager is the same as in the XMPP-based solution. The new approach here is to
8 Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

clearly separate the XMPP Server from the Transport Server. This isolation is related
to the fact that XMPP is no longer our transport method.

Initiator XMPP Server Responder

(Client or Data Server) (Transport Server)

Initiate (IP, Port, Enconding)

Ack
Responder(IP, Port, Chosen Encoding)
Ack

MEDIA CHANNEL

Responder(IP,Port,Media Encode)
Ack

Fig. 4. Jingle initialization procedure

The Initiator needs to know the XMPP address (JID) of the Transport Server, which
can be obtained from the Service File. The Initiator uses this JID to make contact with
the Transport Server and uses the Jingle protocol to negotiate the connection.
The Transport Server, is more complex than on the XMPP approach. It can be divided
in two main components: the XMPP client bot and the RTP Session.
The service JID is the XMPP client bot, running on a Transport Server; hence
Transport Servers are always Responders in the Jingle negotiation process. If the
Transport Server is available for delivering the data to the Initiator and supports the
Initiator encoding format, a response is send with the Transport Server IP address,
port and encoding format, otherwise it cancels the session establishment.
After accepting the terms both entities can setup a RTP channel, which is supported
by the RTP Session component. The session data source is always a Data Server and
the deliverers are always Clients.
In our implementation we used the JLIBRTP API for managing the RTP protocol. It
creates a session with a pre-defined UDP sockets and, as needed, Clients can be added
to the session’s participant list. The participants are a combination of IP and port
address of the other end-point, thus when data is send using a RTP session the
participants list is consulted for data delivery.
Such approach helps the management of the Transport Server. When a session is
established using Jingle then the Initiator is added to the participants list, while when
a session is terminated the respective participant is deleted.

4.3 Data and Client Layer

After knowing the service JID, the Data Server negotiates with the Transport Server
in order to obtain its IP and Port. The Media encoding is assumed to be XML in this
implementation. When the Data Server wants to finalize, a session, a terminate
message must be send to the Transport Server.
 Real-Time Data Dissemination for Wireless Sensor Networks using XMPP 9

Finally, the Client, similarly to the Data Server operation, after obtaining the service
JID, and the Transport Server IP negotiates the establishment of an RTP channel with
the Transport Server. The difference between the Client and the Data Server is that
the first one only consumes data while the second just posts data to the Transport
Server. The mediator in such process is the Transport Server. At some point if the
Client wants to leave the service a session terminate request should be send.

5 Human Motion Tracking Application

This section describes an application of the architecture described in this paper. This
application is a rendering 3D program where a human is represented and replicates
the human movement in real-time. Fig. 5 represents the main components of our
application.
5
4

rvi ces
Web Se

Client
1
ML
Service Discovery gle/X
1 Jin
Manager We
bS
erv
ice
s
3
L
M
/X

2
PP
XM

Jingle/XML

USB Jingle/XML

Base Station RT
Data Server P/
XM
XMPP Server
XM L Jingle/XML
L
PP RTP/XM
/X Client 2
M
L

Transport Server

Fig. 5. Human motion tracking application

The 15 sensor nodes are strategically positioned over a human body (1). The motion
is tracked by groups of 3 sensors (accelerometer, gyroscope, magnetometer) and
transmitted to the base station (2) which delivers the data to the data server (3) using a
USB interface.
In this phase the data is processed using data fusion algorithms (e.g. based on Kalman
filter) to obtain roll, pitch and yaw coordinates of each sensor. The data server
establishes connections with the XMPP server and Transport Server.
On (4) we can see the main elements of the Transport Layer, the Service Discovery
Manager, the XMPP Server and the Transport Server.
Fig. 5 also exposes applications consuming the information (5): Client 1 is consuming
the information on a secure and reliable transport method like XMPP while the Client
2 is using the RTP for real-time motion tracking.
10 Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

5.1 System Initialization

In order to start data dissemination there are several steps to be taken before actually
starting the process.
First we must define the message format used to transmit the information. That is
defined on a XSD file, Fig. 6 depicts an extract of that file and can be obtained from
the Service Discovery Manager.
Another type of information is concerning the user interaction with the system.
Simple information to define would be a simple description of the services, a name,
the transport methods for disseminating data and the JID to establish the session.
In the Data Server Layer it must first establish the USB connection. To enter the
system it must first login and establish the sessions for the transport methods that will
be used for the dissemination.
Finally in the Transport Layer it must be placed the application to handle the different
channels and assign it to handle session request from the service JID.

5.2 Client Layer & Application

The first step that the client application must do is to login into the system. In order to
do that, it needs to send its credentials to a XMPP server over a SSL channel.
Then it contacts the Service Discovery Manager, which provides information about
the available services and their configuration. This information includes the JID, a
text description, message formats, and sensors descriptions, which can be used by
generic applications to provide simple access to any system, or used by a developer to
fine-tune one particular application.
After choosing the desired service the application uses the XMPP server to establish a
session. In this phase the client can choose to join a MUC or use the RTP protocol.
When the negotiation concludes, the client is able to connect directly to the Transport
Server using the selected method and it can start receiving the data.
In our application the motion information is consumed and presented to the end user
as a 3D human shape that moves accordingly. This visualization was done using Java
3D.

<xs:element name="WSN_INFO"> <xs:element name="Contents">

<xs:complexType> <xs:complexType>

<xs:sequence> <xs:sequence>

<xs:element ref="Message"/> <xs:element ref="Content" maxOccurs="unbounded"/>

<xs:element ref="Nodes"/> </xs:sequence>

</xs:sequence> </xs:complexType>

</xs:complexType> </xs:element>

</xs:element> <xs:element name="Content">

<xs:element name="Message"> <xs:complexType>

<xs:complexType> <xs:sequence>

<xs:sequence> <xs:element name="idContent" type="xs:int"/>

<xs:element ref="Header"/> <xs:element name="roll" type="xs:float"/>

<xs:element ref="Contents"/> <xs:element name="pitch" type="xs:float"/>

</xs:sequence> <xs:element name="yaw" type="xs:float"/>

 Real-Time Data Dissemination for Wireless Sensor Networks using XMPP 11

</xs:complexType> <xs:element name="timestamp" type="xs:long"/>

</xs:element> </xs:sequence>

<xs:element name="Header"> </xs:complexType>

<xs:complexType> </xs:element>

<xs:sequence>

<xs:element name="idWSN" type="xs:int"/>

<xs:element name="idNode" type="xs:float"/>

<xs:element name="idContent" type="xs:float"/>

</xs:sequence>

</xs:complexType>

</xs:element>

Fig. 7. XSD Content file

6 Conclusions and Future Work

In this paper we proposed an innovative architecture for real-time WSN data

dissemination over the Internet. Our architecture is based on a 4 tiers model, where
the first tier takes care of WSN applications. The second tier, the Data Layer, is
responsible for data coding. The third tier, the Transport Layer, which is deeply
analyzed in this paper, provides the means to connect the sources in the Data Layer
with the sinks in the Client Layer.
Our solution to the Transport Layer is based on XMPP protocol for non real-time
applications and for real-time application we propose the use of Jingle XMPP
extension, which supports connections using the RTP protocol.
We had shown how our architecture can be used on a human motion tracking
application, which acquires the attitude of 15 sensors placed on the human body.
In our future work we intend to perform experiments regarding the system
performance in several scenarios, particularly to determine the system performance in
terms of delay and on the processing capabilities of the Transport Server.

Acknowledgements

This work was partially funded by the Portuguese Science and Technology
Foundation (Fundacão para a Ciência e a Tecnologia - FCT).

References
[1] Alves, M., Koubaa, A.: A Two-Tiered Architecture for Real-Time Communications in
Large-Scale Wireless Sensor Networks: Research Challenges. WIP Proceeding of the 17th
Euromicro Conference on Real-Time System, Palma de Mallorca, Spain, pp 33-36 (2005).
[2] Shi, J., Lui, W.: A Service-oriented Model for Wireless Sensor Networks with Internet. In
Procedings of The Fifth International Conference on Computer and Information Technology
(2005).
12 Joel Gonçalves, Luis Lino Ferreira, Jianxin Chen, Filipe Pacheco

[3] Chen, J., Ferreira, L.: Human Motion Tracking using Wireless Sensor Networks. Technical
Report HURRAY-TR-090407, available online from www.cister.isep.ipp.pt, (2009).
[4] ZigBee Specification Download Request from
http://www.zigbee.org/en/specdownload/download/request.asp, (2008).
[5] Montenegro, G., Kushalnagar, N., Hui, J., Culler, D.: Transmission of IPv6 Packets over
IEEE 802.15.4 Networks. Available online from http://www.ietf.org/rfc/rfc4944.txt (2007).
[6] Han, C.-C., Kumar, R., Shea, R., Kohler, E., Srivastava, M.: A Dynamic Operating System
for Sensor Nodes. In Proceedings of the 3rd international conference on Mobile systems,
applications, and services, pages 163–176, Seattle, Washington, USA, June 2005.
[7] Wan, C.-Y., Eisenman, S., Campbell, A.: Coda: Congestion Detection and Avoidance in
Sensor Networks. In Proceedings of the 1st International Conference on Embedded
Networked Sensor Systems, Los Angeles, California, USA, October. (2003).
[8] Nath, S., Liu, J., Zhao, F.: Challenges in Building a Portal for Sensors WorldWide. In
World-Sensor-Web (2006).
[9] XMPP Organization, http://xmpp.org/protocols/.
[10] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., Hildebrand, J, “XEP-0166
Jingle”, XMPP Standards Foundation (2009).
[11] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.: RTP: A Transport Protocol for
Real-Time Applications. http://tools.ietf.org/html/rfc3550, (2003).
[12] Laun, W.: A Jaxb Tutorial. https://jaxb.dev.java.net/tutorial/.
[13] Openfire XMPP Server. http://www.igniterealtime.org/projects/openfire/.
[14] Schulzrinne, H., et al., “RTP: A Transport Protocol for Real-Time Applications – RFC
3550”, Network Working Group (2003).
[15] Saint-Andre, P., “XEP-0045: Multi-User Chat”, XMPP Standards Foundation (2008).