LiteOS based Extended Service Oriented Architecture for Wireless by bestt571

Service-Oriented Architecture (SOA) is a component model, which the application of different functional units (called services) between these services through well-defined interfaces and contracts linked. Interface is defined in a neutral manner, it should be independent of implementation services, hardware platforms, operating systems and programming languages. This makes such a system built on a variety of services can a uniform and common way to interact.

International Journal of Computer and Electrical Engineering, Vol. 2, No. 3, June, 2010
1793-8163
LiteOS based Extended Service Oriented
Architecture for Wireless Sensor Networks
V.Vanitha, Dr.V.Palanisamy, N.Johnson and G.Aravindhbabu
integrating data and computation required in the processing
Abstract-Over the last decade, embedded sensing systems of information. The communication elements consist of a
have been successfully deployed in a range of application areas, receiver, a transmitter, and an amplifier if needed (see Fig.
from education and science to military, healthcare and 1). Basically, all individual sensor nodes are operated by a
industry. These systems are becoming more robust, capable
limited battery, but a base station node as a final data
and widely adopted. However, every particular applications
requires complex integration work and therefore technical collecting center can be modeled with an unlimited energy
expertise, effort and time which prevents users from creating source. Nodes communicate wirelessly. Each node
small tactical, ad-hoc applications using sensor networks. communicates directly (i.e., single hop) with a few other
These limitations are already addressed by implementing nodes within its radio communication range. A node may
service oriented architecture in the wireless sensor networks. also transmit to distant nodes through multi-hop
In addition to that, many real time applications are very time
communication.
critical and demand richer set of applications. To address this
issue, we propose an extended service oriented architecture For years, wireless sensor network has been closed
(ESOA) that provides customizable sensor network, network deployed for a specific application with a specific
consolidates services and manages applications. set of characteristics. Typically, a single party (e.g., a
government agency, a research institution, a private
Index Terms—ESOA, WSN, SANET, LiteOS, Service company) owns, maintains, and uses the sensor-actuator
oriented architecture network (SANET). Most early SANET deployments have
adopted ad-hoc, application-specific architectures. In recent
years, the need to decouple SANETs from the applications
I. INTRODUCTION
using them led to the emergence of generic SANETs, an
A Wireless sensor network (WSN) is composed of a large alternative design model where an application-independent
number of sensor nodes that are densely deployed either query system is deployed on the SANET. In this model, the
inside the phenomenon or very close to it. The main query system is designed to answer queries from any
objective of the wireless sensor networks is to observe an application. As SANETs evolve, they are expected to
environment, collect information about the observed become open, ubiquitous, interoperable, multi-purpose
phenomena or events and deliver this information to the infrastructures. This would translate into new requirements
application. that existing architectures do not support. We argue that the
next-generation SANETs require customizable architectures
that would provide developers the ability to select individual
software components from several SANETs and integrate
them in new applications that achieve higher levels of
efficiency and scalability.
Recently, the Service Oriented Architecture (SOA) has
been considered as a good candidate to develop open,
efficient, inter-operable, scalable and customizable WSN
applications. In Service Oriented WSNs, node’s sensing
Fig. 1 Wireless Micro-node model. Each node has sensing unit, porcessing
unit, power unit, and communication modules capability is exposed in the form of in-network services.
The wireless micro sensor node consists of a sensing Application development is simplified by providing
module, a processing element, and communication elements. standards for data representation, service interface
The sensing module is an electrical part detecting physical description, and service discovery facilitation. By wrapping
variable from the environment. The processing unit (a tiny application functionality into a set of modular services, a
microprocessor) performs signal processing functions, i.e. programmer can then specify execution flow by simply
connecting the appropriate services together. Some
approaches are TinySOA [7], OASiS [5] and TinyWS [6].
Manuscript received Augest 11,2009. In TinySOA, services are lightweight code units deployed
V.Vanitha, N.Johnson, G.Aravindhbabu are with department of
directly on top of the operating system of nodes.
Computer Science and Engineering, Kumaraguru college of Technology,
Coimbatore, Tamilnadu, India. (vanithajayaprakash@yahoo.com) Applications invoke services using a service-oriented query
Dr.V.Palanisamy, Principal, Info Institute of Engineering, Coimbatore, model. Queries are submitted to one of the established base
Tamilnadu, India stations or directly to individual nodes. OASiS also uses a
passive discovery mechanism, but it is combined with an
432
International Journal of Computer and Electrical Engineering, Vol. 2, No. 3, June, 2010
1793-8163
object migration approach instead of using remote query only when a user is present. Therefore, LiteShell and LiteFS
mechanisms. Finally, TinyWS is a small web service are connected with a dashed line in this figure. LiteOS
platform that resides on the sensor nodes. It hosts the web provides a wireless node mounting mechanism (to use a
services and has SOAP processing engine. The sensor nodes UNIX term) through a file system called LiteFS. Much like
are service providers, the application devices are service connecting a USB drive, a LiteOS node mounts itself
requestors and a distributed UDDI acts as an overlay entity. wirelessly to the root filesystem of a nearby base station.
We introduce ESOA, Extended SOA model, which inserts Moreover, analogously to connecting a USB device (which
at the top of the typical SOA model two layers that provides implies that the device has to be less than an USB cable -
the service consolidation and management. length away), the wireless mount works only for devices
TinyOS adopts NesC and the event-based programming within wireless range. The mount mechanism comes handy,
model, which introduces a learning curve for the most for example, in the lab, when a developer might want to
traditional programmers. In our work we use LiteOS [2], a interact temporarily with a set of nodes on a table-top before
new operating system for sensor networks developed by deployment. While not part of the current version, it is not
UIUC. LiteOS supports C programming and provides Unix- conceptually difficult to extend this mechanism to a “remote
like abstraction for wireless sensor networks, which greatly mount service” to allow a network mount. Ideally, a
improved their compatibility with other development network mount would allow mounting a device as long as a
platforms and simplified the sensor network programming. network path existed either via the Internet or via multi-hop
The rest of the paper is organized as follows. In section 2, wireless communication through the sensor network. Once
we discuss about LITE OS. In section 3, we discuss the mounted, a LiteOS node looks like a file directory from the
limitations of the current wsn architecture. In Section 4 we base station. The shell, called LiteShell, supports UNIX
discuss the basic service oriented architecture and its commands, such as copy and move, executed on such
advantages in wsn. In section 5 we present our extended directories. The external presentation of LiteShell is
service oriented middleware architecture. In section 6 we versatile. While the current version resembles closely a
present the overview of research literature related to our UNIX terminal in appearance, it can be wrapped in a
work. The paper ends with the conclusion in section 7. graphical user interface (GUI), appearing as a “sensor
network drive” under Windows or Linux.
B. Advantages of LiteOS model
II. INTRODUCTION TO LITEOS
It is an interactive and reliable model which provides the
LiteOS provides a UNIX-like environment for sensor
benefits like robustness, integrity, availability. It helps to
networks, networked embedded devices, and cyber physical
provide the simple operations for services when
systems. It provides a thread-based run-time execution
compared to TinyOS model. LiteOS provides the
environment for applications. This paper introduces the
environment for Object-oriented languages which helps to
UNIX-like operating system, called LiteOS that fits on
have the advantages like reusability, modularity,
memory-constrained motes such as MicaZ. This operating
extensibility.
system is multithreaded and comes bundled with a UNIX-
like file system and a C++ compiler. While TinyOS and its
extensions have significantly improved programmability of
mote-class embedded devices via a robust, modular III. LIMITATIONS OF CURRENT WSN ARCHITECTURES
environment, NesC and the event-based programming Current architectures for WSN have inherent limitations
model introduce a learning curve for the most developers that may be summarized as follows:
outside the sensor networks circle. The purpose of LiteOS is
A. Tight coupling between WSNs and applications
to significantly reduce such a learning curve.
A tight network–application coupling characterizes most
current sensor network and WSN architectures. This
coupling usually takes one of two forms:
• Network-dependent application development: Most
current sensor applications are designed and
implemented to be used on a specific sensor network or
a specific type of sensor networks with specific
characteristics and a specific querying interface. Often,
application developers need to know network-specific
information such as network topology, nodes’
transmission range and processing/memory capabilities,
Fig. 2 LiteOS Architecture etc.
• Application-dependent network design and deployment:
A. Architectural Overview In some cases, a decision is first made to use a specific
Fig.2 shows the overall architecture of the LiteOS software system to build a sensor application. The
operating system, partitioned into three subsystems: requirements of the software system must then be taken
LiteShell, LiteFS, and the kernel. Implemented on a base into consideration when designing and deploying the
station, the LiteShell subsystem interacts with sensor nodes sensor network supporting that system.
433
International Journal of Computer and Electrical Engineering, Vol. 2, No. 3, June, 2010
1793-8163
B. Costly optimization or suboptimal efficiency provide services to either end-user applications or other
In current WSNs, application-dependent optimization services distributed in a network through published and
makes the sensor network unable to provide the same levels discoverable interfaces. The basic SOA defines an
of performance to other applications. Also, several rounds interaction between software agents as an exchange of
of optimization may be needed as the application evolves or messages between service requesters (clients) and service
is replaced. The alternative of application independent providers. Clients are software agents that request the
optimization is often too generic and does not exploit execution of a service. Providers are software agents that
optimization opportunities that a specific class of provide the service. Agents can be simultaneously both
applications may offer. Typically, this leads to suboptimal service clients and providers. Providers are responsible for
efficiency. publishing a description of the service(s) they provide.
Clients must able to find the description(s) of the services
C. Limited reusability they require and must be able to bind to them. The basic
Ideally, for a WSN to be cost effective, it would be SOA is not an architecture only about services, it is a
necessary to amortize its deployment and maintenance cost relationship of three kinds of participants: the service
by sharing its functionalities amongst a large group of users provider, the service discovery agency, and the service
and applications. This reusability is generally not easily requestor (client). The interactions involve the publish, find
achievable in current sensor infrastructures due to the tight and bind operations (see Fig.3). These roles and operations
coupling between networks and applications. act upon the service artifacts: the service description and the
D. Low return on investment service implementation. In a typical service based scenario a
service provider hosts a network accessible software module
This drawback follows from the previous one. The (an implementation of a given service). The service provider
monolithic, application-specific design of current WSN defines a service description of the service and publishes it
makes it difficult to reuse most of an application’s modules to a client or service discovery agency through which a
in developing another application. Often, intensive service description is published and made discoverable. The
programming is required each time a new application has to service requestor uses a find operation to retrieve the service
be developed. description typically from a discovery agency, i.e., a registry
E. Non-scalability or repository like UDDI, and uses the service description to
Most of today’s WSN applications are designed and bind with the service provider and invoke the service or
optimized for light loads, i.e., destined to be used by a small interact with service implementation. Service provider and
group of users. As a result, current WSNs often do not scale service requestor roles are logical constructs and a service
to support large numbers of simultaneous users. may exhibit characteristics of both.
This architectural approach is particularly applicable to
IV. EXTENDED SERVICE ORIENTED ARCHITECTURE (ESOA) heterogeneous wsn where multiple applications running on
varied technologies and platforms need to communicate
Our proposed service oriented Architecture consists of
with each other. In this way, users can mix and match
service composition layer on top of basic service oriented
services to develop new applications with minimal
architecture. Fig.3 depicts the architecture of extended
programming effort.
service oriented architecture.
B. Service composition layer
Service Composition Layer The service composition layer in the ESOA encompasses
[ Coordination ] [Monitoring] necessary roles and functionality for the consolidation of
[ Conformance] [ QoS] multiple services into a single composite service. Resulting
composite services may be used by service aggregators as
Basic SOA
components (i.e., basic services) in further service
compositions or may be utilized as applications/solutions by
service clients. Service aggregators thus become service
Fig. 3 ESOA Architecture
providers by publishing the service descriptions of the
composite service created by them. A service aggregator is a
A. Basic SOA service provider that consolidates services that are provided
by other service providers into a distinct value added service.
Service aggregators develop specifications and/or code that
permit the composite service to perform functions that
include the following:
1) Coordination: controls the execution of the component
services, and manages dataflow among them and to the
output of the component service (e.g., by specifying
workflow processes and using a workflow engine for
run-time control of service execution).
Fig. 4 Basic SOA 2) Monitoring: allows subscribing to events or
information produced by the component services, and
SOA is a logical way of designing a software system to publishes higher-level composite events (e.g., by
434
International Journal of Computer and Electrical Engineering, Vol. 2, No. 3, June, 2010
1793-8163
filtering, summarizing, and correlating component need continuous monitoring to handle the critical situation
events). effectively. For this purpose, we have proposed ESOA
3) Conformance: ensures the integrity of the composite concept in which the service composition layer helps to
service by matching its parameter types with those of handle all the operations related to this critical patient
its components, imposes constraints on the component monitoring system.
services (e.g., to ensure enforcement of business rules), Under our implementation, the application mainly
and performs data fusion activities. consists of three types of sensors which used to extract the
4) QoS composition: leverages, aggregates, and bundles data for pulse, blood pressure and oxygen saturation level.
the component’s QoS to derive the composite QoS, The data is considered to be either critical or non-critical
including the composite service’s overall cost, based on the readings of each. For example, blood pressure
performance, security, authentication, privacy, monitors measure the pressure flowing through the blood
(transactional) integrity, reliability, scalability, and vessels against the walls of the arteries. If blood flow is
availability normal, then blood pressure is normal (average 120/80). If
blood flow becomes restricted in some way, blood pressure
C. Advantages
goes up. If increased blood pressure goes undetected, the
It is realized that many leading organizations are moving person is at risk of severe medical problems.
towards a service-oriented architecture (SOA), an approach According to the readings, the response is given as a
to architecting the IT infrastructure that eliminates feedback in monitor either to alert a patient or nurse/doctors.
redundancy and accelerates project delivery via The data should be transmitted at faster rate and the events
consolidation and reuse of services (these services are often should be handled immediately.
referred to as Web services). SOA allows an organization to Feedback data includes patient profile, accident response,
effectively leverage existing assets rather than forcing them and medical care information and so on. Here we have
to create yet another redundant silo for each business need. proposed to use service provider which is a basic layer in
This, in turn, also makes IT more efficient, allowing for ESOA to build service composition layer. Services included
shorter cycle times and quicker project delivery – further in this layer for chronic disease monitoring are:
helping IT align with business. 1) Coordination: Data is extracted from each sensors
By implementing a service oriented approach at all levels and the workflow process is identified for proper data
of WSN, the rapid development of applications as well as flow.
the thorough testing of sensor networks will be possible. 2) Monitoring: According to the filtered data, it is
This service oriented approach will allow for the summarized and service is executed and the events
development of a WSN management system that will be (response) are handled either periodically/non-
able to handle the dynamic addition and removal of periodically. Correlation from each sensor’s data might
different sensors and applications as interoperable services.
be found.
D. Scenario 3) Conformance: Actual business rules are implemented
Based on the above SOA architecture, we proposed to under this service and it might be based on ECA(Event,
develop the health care application (as shown in Fig. 5) for Control & Action). Example: For pressure>190 medical
patient monitoring system. The healthcare domain presents care should be handled immediately. Object oriented
opportunities for a significant number of applications of approach will be used to ensure integrity.
wireless sensor technology 4) QoS: There are potential opportunities for WSN in
The following scenario explains the problem definition healthcare, but they are still in infancy. Due to
and the forthcoming explanation gives the implementation monitoring gap and cost of wired diagnostic equipment
details regarding the service coordination layer operations. it is difficult to monitor all patients. WSN helps to have
reduced cost, faster data transmission and data
processing. Reusability, modularity and configurability
are of greater benefits. Privacy is achieved through
password mechanisms.
V. RELATED WORK
One of the earlier works in taking the service-oriented
approach in the design of a middleware system for wireless
sensor networks was presented by Golatowski et al. [8]. In
Fig. 5 Patient Monitoring System their work they introduce (at a very high level) a simple
service-oriented model in which the responsibility for
Consider a patient who is admitted in hospital having handling the services requests is assigned to an external
chronic disease. It encompasses wide range of health entity. This external server works as a bridge between the
problems including diabetes, asthma, heart diseases and requests received from the exterior and the internal network
sleep disorders. In many cases, chronic diseases require functionality. Nevertheless, no details on how the
some kind of health monitoring, especially in the later components interact between them, its characteristics or the
stages of the disease progression. So, on later stages, we
435
International Journal of Computer and Electrical Engineering, Vol. 2, No. 3, June, 2010
1793-8163
protocols used, are explained. protocols as most application devices and provide data
These are high-level programming abstractions that the access via frameworks that can be used by general
service-oriented sensor and actuator (SOSANET) exposes to application developers. To achieve this we have proposed
applications as a middleware layer. Typically, a middleware ESOA. We are currently implementing this on a LiteOS, a
service is implemented as a module that runs off-network new operating system for wsn.
and that interacts with one or several nodes to provide its
functionality. Most existing SOSANETs provide only REFERENCES
middleware services. Examples include Atlas [9], and [1] Wang MM, cao JN, Li J et al, Middleware for wireless sensor
Sensation [10]. networks: A survey, Journal of computer science and technology
23(3): 305-326 May 2008.
Atlas is a service-oriented sensor and actuator platform [2] Qing Cao and Tarek Abdelzaher and John Stankovic and Tian He,
that enables programmable pervasive spaces. This platform The LiteOS Operating System: Towards Unix-Like Abstractions for
is focused primarily on an OSGi-based service framework. Wireless Sensor Networks, In Proceedings of ACM/IEEE IPSN,
Sensation is an open and generic service-oriented platform pages 233-244, 2008.
[3] M.P.Papazoglou D.Georgakopoulos, Service oriented computing ,
that enables standardized communication within individual Communications of the ACM, October- 2003.
infrastructures, between infrastructures and their sensors, [4] Flavia Coimbra Delicato, P.F. Pires, L. Pirmez, L.F.R.D.C. Carmo,
but also among distributed infrastructures. Sensation allows “A Flexible Web Service based Architecture for Wireless Sensor
Networks”, in proceeding of the 23rd International Conference on
developers to concentrate on the semantics of their Distributed Computing Systems workshops (ICDCSW2003), p. 730,
infrastructure and to develop innovative concepts and 2003.
implementations of context-aware systems. [5] M. Kushwaha, I. Amundson, X. Koutsoukos, S. Neema, and J.
Sztipanovits. OASiS: A Programming Framewor for Service-
In [11], the authors present WISE, a Web-Services Oriented Sensor Networks. In Proceedings of the 2nd IEEE/Create-
framework for publishing, browsing, and analyzing real Net/ICST International Conference on COMmunication System
time sensor data. Providers register their sensors with a softWAre and MiddlewaRE (COMSWARE’ 07), Bangalore, India,
January 2007. IEEE Computer Society Press.
UDDI registry where any user can discover them over the [6] N. Y. Othman, R. H. Glitho, and F. Khendek. The Design and
Internet. Once the desired sensors are located, the user can Implementation of a Web Service Framework for Individual Nodes in
employ two new communication protocols, namely SSCP Sinkless Wireless Sensor Networks. In Proceedings of the IEEE
International Conference on Computers and Communications
and SSTP, to control the incoming sensor streams. As the (ISCC’07), pages 941–947, Aveiro, Portugal, July 2007. IEEE
data arrive at the user browser software, a corresponding Computer Society Press.
plug-in such as a data animation module is activated to [7] A. Rezgui and M. Eltoweissy. Service-oriented sensor actuator
allow the user to ‘‘see’’ the data stream presented in an networks: Promises, challenges, and the road ahead. Computer
Communications, 30:2627–2648, 2007.
intelligible way. [8] Golatowski F, Blumenthal J, Handy M, Haase M (2003) Service
ZigBee will play an important role in the adoption of oriented software architecture for sensor networks. Intl.Workshop on
Assistive Technology by enabling wireless low-power Mobile Computing (IMC 2003),Rockstock,Germany, pp 93–98
[9] J. King, R. Bose, Y. Hen-I, S. Pickles, A. Helal, Atlas: a
communication between devices and services that foster serviceoriented sensor platform: hardware and middleware to enable
safe, healthy and independent living conditions for the programmable pervasive spaces, in: Proceedings of the 31st IEEE
disabled or elderly. In addition to Assistive Technology, Conference on Local Computer Networks, November 2006, pp. 630–
638.
ZigBee applications in the health and fitness domains can [10] T. Gross, T. Egla, N. Marquardt, Sens-ation: a service-oriented
address several other market segments and needs. platform for developing sensor-based infrastructures, Int. J. Internet
Honeywell offers the 26PC SMT (Surface Mount Protocol Technol. 1 (3) (2006) 159–167.
[11] K.A. Hua, R. Peng, G.L. Hamza-Lup, WISE: a Web-based intelligent
Technology) Series pressure sensor. This small, low-cost, sensor explorer framework for publishing, browsing, and analyzing
high-value pressure sensing solution takes the place of the sensor data over the Internet, in: Proceedings of the Fourth
health care professional having to place a stethoscope under International Conference on Web Engineering (ICWE), July 2004, pp.
568–572.
the pressure cuff to hear the noise of the rushing blood. The [12] F. Golatowski, J. Blumenthal, M. Handy, M. Haase, H. Burchardt, D.
sensor measures blood pressure faster and more accurately Timmermann, Service-oriented software architecture for sensor
than manual devices, and is used directly with printed networks, in: Proceedings of the International Workshop on Mobile
circuit boards (PCBs). The blood pressure monitor has an Computing, 2003, pp. 93–98.
[13] ZigBee Wireless Sensor Applications for Health, Wellness and
on-board processor to cycle through the test, record results Fitness - March 2009. www.zigbee.org
and output the results to a digital read-out screen. Instead of [14] Blood Pressure Monitoring Using the 26PC SMT.
watching the mercury fall in the manometer, the pressure www.honeywell.com/sensing, info.sc@honeywell.com
sensor acts as the mechanism to provide a visual aid and
noise monitor of the pulse of blood flowing through the
arteries.
VI. CONCLUSION
Today, the Wireless Sensor Networks use proprietary
mechanisms in providing data access. They use non
standard protocols and require gateways as a bridge between
application devices and the sensor networks. To facilitate a
wider use of sensor data and motivate more innovative
applications, WSN should use common and standard
436