Middleware Model for TinyOS and Contiki-Based

Wireless Sensor Networks

Basem Y. Alkazemi
College of Computer Science and Information Systems
Umm al Qura University
Makkah, Kingdom of Saudi Arabia
[email protected]

Abstract— Heterogeneous Wireless Sensor Network (WSN) their respective data exchange model. In another paper [3], we
contains different types of sensor nodes. These nodes can proposed a general purpose middleware model that allows an
communicate with their base station and the corresponding application to communicate with different types of nodes. The
application. WSN requires a well-defined middleware for literature proposed many middleware models for WSNs, but
maintaining system independence. In this paper we discuss a most of them can communicate with the same types of nodes.
general purpose middleware with multiple services that can
communicate with heterogeneous nodes of multiple networks. In this paper we are implementing our proposed
This middleware can identify the types of heterogeneous nodes middleware model. This middleware initially works with
connected to a network. The proposed middleware can TinyOS and Contiki-based networks. It allows the application
communicate with these nodes by interpreting the application’s to identify the node types, configure the sensor nodes and allow
requests into underlying network signatures. To test the data communication. This paper discusses some scenarios and
proposed middleware, we select two different types of network functionality of the proposed middleware. In the remainder of
based on TinyOS and Contiki. The middleware receives the the paper, section II discusses the middleware role in WSNs,
request from the application, interprets the message signature section III describes the TinyOS and Contiki programming
according to the underlying network, sends the message to the models, section IV details the proposed middleware model, and
nodes, receives the message from the nodes and sends the request finally section V draws conclusions and offers suggestions for
back to the application.
future work.
Keywords— Wireless Sensor Network; Middleware; TinyOS;
Contiki; Interoperability II. MIDDLEWARE ROLE IN WIRELESS SENSOR
NETWORK
I. INTRODUCTION Middleware always plays a vital role in WSNs. A business
Wireless Sensor Networks (WSNs) are composed of sensor application is unable to retrieve or send data to an underlying
nodes, actuators and sensing radios designed to sense the network due to incompatibilities between their protocol,
physical environment. Despite the increase in hardware and message signature and communication model. Due to this
sensing capabilities, WSNs are still limited in resources and mismatch, every network should have a separate application,
complex in nature [1]. Due to this complex nature, most of the and every application can only send/receive data to a specified
applications are built according to the specific need of the underlying network. So middleware plays an important role in
underlying network. The application always integrates with the communicating with two different types of network. This type
lower layer of WSNs to understand the underlying network of middleware identifies the network and modifies the request
requirement. As WSNs consists of a large number of sensor from an application according to the underlying network [3].
nodes and these nodes can vary in their architecture, so the In literature, people present many types of middleware, but
application built on top of WSNs should be able to most of them are application-specific. Hermann et al. presented
communicate with heterogeneous nodes. Senceive [4], a middleware for WSNs that bridges the
All the nodes in WSNs use an operating system to application layer and network layer. This middleware provides
communicate. These operating systems remain same in all services to configure the topology of WSN. Another form of
sensor nodes within the same network and can vary from one web-based middleware from WSNs was proposed by Jeon et
WSN to another. While deploying a network, first all the nodes al. [5]. This middleware analyzes a GSM network using ad-hoc
should be programmed according to the application’s needs. protocols. MiLAN [6] is a form of application-based
Here we consider only TinyOS and Contiki-based nodes. An middleware used for multiple applications such as home and
application without a middleware cannot communicate with office security, environmental surveillance and medical patient
both these types of nodes in different networks. To monitoring. It uses some service discovery protocols to access
communicate with these nodes, the middleware needs to send new nodes and communicate with them.
different messages according to their predefined structure [2]. Li et al. [7] proposed middleware for environment
In our previous paper [2], we identified the difference monitoring, military and health applications. This middleware
between the Contiki and TinyOS operating systems in terms of is application-based and uses Hypertext Transfer Protocol
(HTTP) and Java Message Service (JMS) protocols for

978-1-5090-5306-3/16/$31.00 ©2016 IEEE

communication. Agilla [8] is a type of mobile agent overcome these changes and send the specific message
middleware. It is used for self-adaptive WSNs. The agents of signatures to an underlying network.
this middleware can enter into WSN to identify the problems
and rectify them accordingly. This middleware is not used for
IV. PROPOSED MIDDLEWARE MODEL
data collection and communication.
In our previous paper [3], we proposed a general purpose
SensorsMW [9] is a type of middleware that allows middleware model. This middleware model consists of an
applications to collect data from the network through web
Application interface layer, Service layer, and Hardware
services. This middleware helps application with data
collection, generating notification for events and network interface layer. Figure 1 shows the layers of the proposed
maintenance. Khedo et al. [10] proposed a component-based, middleware. The application interface layer binds itself to the
service-oriented middleware program. This middleware application of system. It is responsible for providing the
provides applications with numerous services related to interface to user applications. This layer binds the middleware
communication and management of nodes. service layer and user application to send and receive the
messages. The service layer contains the number of services of
TinySOA [11] is middleware that uses an API to middleware like identification, configuration and data
communicate with WSN. This API can communicate with communication. This layer receives the request from the
nodes, gateway and servers. ubiSOAP [12] middleware application interface layer, interprets the message into network
provides services to multiple mobile devices. SStreaMWare
signatures and invokes the desired service. The hardware
[13] is a middleware program that provides applications with a
interface layer binds itself to the underlying network. This
number of services including querying, discovering and
binding layer has various protocols that help to manage heterogeneous
nodes. Read, write, open and close are the major services of
this layer.
III. THE TINYOS AND CONTIKI PROGRAMMING
MODELS
The middleware programs discussed above have several
applications and are very useful in real environments. Every
type of middleware deals with sensor nodes of an underlying
network. Some operating systems (OS) running on these nodes
help in network establishment and data communication. Most
of the middleware approaches that do not deal with
heterogeneous networks contain a different OS. Two of the
most commonly used OS in WSN are TinyOS and Contiki, so
we limited our investigations to these two OS.
TinyOS has a component-based, event-driven programming
model [14]. These components are the basic building blocks of
this OS. nesC [15] programming language is used to write
these components. Two major types of components are Module
and Configuration. The Module components are used for
implementation of component interfaces, while Configuration
components are used to accumulate all components together
and connect all the interfaces of the components. A component
Figure 1 Proposed Middleware model
consists of a set of tasks, events and command handlers.
Commands are used to invoke the requests, and events are the
notification messages sent to the caller. A. Network Model Scenario
The middleware works with two different types of
Contiki OS [16] has a modular architecture. The modules of networks. Both of these networks contains TinyOS or Contiki
Contiki are written in threads. The communication model uses nodes. Figure 2 shows a scenario of the network model. The
messages that are passed through multiple events. The Contiki model consists of an application, middleware, multiple sink
architecture consists of a Contiki kernel, libraries, a program and remote nodes in a network. There can be multiple sink
loader and processes [17]. The programs in Contiki are called nodes connected with the system, and these nodes act as a
Processes. Every process is like a component that has certain gateway between application and WSN. There are multiple
interfaces to interact with other components. A Process is a remotes nodes in a network that can sense and transmit data.
simple C function with some variables. Contiki OS executes The application requests the data from any node of the
these processes based on certain events. underlying network through the middleware. The middleware
Atif et al. [2] characterized TinyOS and Contiki in a translates the requested message into the required signature
component-based model. Both of them have different format of the underlying network node and transmits the
architectures and programming models. The message message to the sink node. The middleware interacts with these
signatures of both of these OS varies in their numbers and networks using its hardware interface layer.
types of attributes. The middleware plays an important role to
 4) Identification of remote nodes connected in the network
The middleware can easily identify the number of
remote nodes connected in a sensor network. It sends the
request to the middleware to identify the remote nodes
connected in their underlying network. The middleware
invokes its service and calculates the number of remote
nodes connected in each network
V. CONCLUSION AND FUTURE WORK
A WSN has a number of nodes that can sense and
communicate data. We designed a scenario with two different
networks based on TinyOS and Contiki nodes. To
communicate with these two types of network simultaneously
we proposed middleware that can communicate with these
networks. The middleware can identify the node, communicate
data and identify the remote nodes in a network.
Figure 2 Designed Network Scenario In future, we will build a real-time network of TinyOS and
Contiki-based sensor nodes, run some experiments on these
B. Functionality of the proposed middleware networks and extract the actual results of our proposed
middleware. We will identify the nodes of this network and test
The proposed model is implemented for TinyOS and data communication from the application.
Contiki-based nodes. The major functions of this middleware
are:
ACKNOWLEDGMENT
• Nodes identification
This work was funded by grant number 11-INF1674-10
• Find the types of nodes connected
from the Long-Term National Plan for Science, Technology
• Communication between application and nodes. and Innovation (LT-NPSTI), the King Abdul-Aziz City for
• Identification of remote nodes connected in the Science and Technology (KACST), Kingdom of Saudi Arabia.
network. We thank the Science and Technology Unit at Umm A-Qura
1) Nodes identification University for their continued logistical support.
There can be multiple types of sink nodes connected
with the system on different ports. The first step is to REFERENCES
identify the ports on which those nodes are connected. The
middleware has the functionality to check every port of the [1] K. L. Man, D. Hughes, S. U. Guan and P. W. H. Wong, "Middleware
Support for Dynamic Sensing Applications," 2016 International
system and identify the ports on which the nodes are Conference on Platform Technology and Service (PlatCon), Jeju, 2016.
connected. [2] A. Naseer, B. Y. Alkazemi and H. I. Aldoobi, "Component-Based
Model for Heterogeneous Nodes in Wireless Sensor Networks," Lecture
2) Find the types of nodes connected Notes on Information Theory, Vol. 3, No. 1, pp. 25-30, June 2015. doi:
Once the ports have been identified, the next step is 10.18178/lnit.3.1.25-30.
to find the type of node connected. This middleware can [3] Basem Y. Alkazemi, Atif Naseer, Emad A. Felemban, “Towards a
only identify the TinyOS or Contiki types of nodes. The general purpose Middleware model for WSNs: A literature survey”,
International Journal of Computer and Information Technology (ISSN:
middleware stores the information of every node 2279 – 0764) Vol. 04 – Issue 01, January 2015.
connected to the system. [4] C. Hermann and J. Dargie. Senceive: A Middleware for a Wireless
Sensor In Advanced Information Networking and Applications, pp. 612-
3) Communication between application and nodes 619, Gino-wan, Okinawa, Japan, 2008, IEEE.
The major function of this middleware is to [5] Y.J. Jeon, S.H. Park, J.S. Park. Sensor Node Middleware to Support
communicate with a heterogeneous network. The Web-Based Applications over Wireless Sensor Networks, The 2nd IEEE
Workshop on Wireless and Internet Services (WISe 2009) Zurich,
application sends a message to the middleware, the Switzerland; 20-23 October 2009.
middleware gathers the information about the connected [6] W. Heinzelman, A. Murphy, H. Carvalho, and M. Perillo, Middleware to
sink nodes, so it translates the message into their Support Sensor Network Applications, IEEE Network, 2004.
signatures and transmits the message to the sink node. The [7] Qingfeng Li, Chen Li, Jifang Shi. Research and Application on
sink node directs the message to the underlying network Application-oriented Event-Based Middleware of WSNs, In 2010
and collects the data from the network. The middleware is Second International Conference on Networks Security, Wireless
Communications and Trusted Computing, pp. 498-501, Wuhan, Hubei
able to receive the information from the sink node. Once 24-25 April 2010.
the data is in the middleware, the application can easily [8] Fok, C.-L., Roman, G.-C., and Lu, C. 2009. “Agilla: A mobile agent
access the data. Hence the complexity of the underlying middleware for self-adaptive wireless sensor networks”. ACM Trans
network is encapsulated by the application. Autonom. Adapt. Syst. 4, 3, Article 16 (July 2009), 26 pages. DOI =
10.1145/1552297.1552299.
[9] G.F. Anastasi, E. Bini, A. Romano and G. Lipari, “A service-oriented [14] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,
architecture for QoS configuration and management of Wireless Sensor D. Gay, J. Hill, M. Welsh, E. Brewer. TinyOS: An operating system for
Networks”, 2010 IEEE Conference on Emerging Technologies and sensor networks In Ambient intelligence, pp. 115-148, Springer, Berlin,
Factory Automation (ETFA), pp.1-8, 13-16 Sept. 2010. 2005.
[10] K.K. Khedo and R.K. Subramanian, “A Service-Oriented Component [15] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler
Based Middleware Architecture for Wireless Sensor Networks”, in The nesC language: A holistic approach to networked embedded
International Journal of Computer Science and Network Security, Vol. systems In Proceedings of the ACM SIGPLAN 2003 Conference on
9, No.3, pp. 174-182, March 2009. Programming Language Design and Implementation (PLDI), ACM,
[11] E. Avils-Lpez and J. Garca-Macas, “TinySOA: a service-oriented 2003.
architecture for wireless sensor networks”, in Service Oriented [16] Adam Dunkels, Bjorn Gronvall, Thiemo Voigt, Contiki - A Lightweight
Computing and Applications, Vol. 3, No. 2, June 2009, pp. 99-108(10). and Flexible Operating System for Tiny Networked Sensors in
[12] M. Caporuscio, P.G. Raverdy, H. Moungla and V. Issarny. “ubiSOAP: Proceedings of the 29th Annual IEEE International Conference on Local
A service oriented middleware for seamless networking”, in Proc. 6th Computer Networks.
ICSOC, 2008. [17] Beginner's Guide to Crossbow Motes. Available from:
[13] G. Levent, R. Claudia, L. Cyril, B. Andre and O. Vincent, http://www.pages.drexel.edu/~kws23/tutorials/motes/ motes.html. [5
“SStreaMWare: a Service Oriented Middleware for Heterogeneous Nov 2014].
Sensor Data Management”, in Proc. ICPS, Italy, July 2008.