An Open and Integrated Management Platform forWireless Sensor Networks

M. Kalochristianakis, v. Gkamas, G. Mylonas, s.Nikoletseas, E. Varvarigos

Research Academic Computer Technology Institute,Department of Computer Engineering and Informatics,

University of Patras, Rio, Greece{kalohr, vgkamas, mylonasg, nikole, manos}@cti.gr

Abstract- We present the conceptual basis and the initialplanning for an open source management architecture forwireless sensor networks (WSN). Although there is an abundanceof open source tools serving the administrative needs of WSNdeployments, there is a lack of tools or platforms for high levelintegrated WSN management. This is because of a variety offactors, including the lack of open source management tools, theimmaturity of tools that offer manageability for WSNs, thelimited high level management capabilities of sensor devices andarchitectures, and the lack of standardization. The current workis, to our knowledge, the first effort to conceptualize, formalizeand design a remote, integrated management platform for thesupport of WSN research laboratories. The platform is based onthe integration and extension of two innovative platforms:jWebDust, a WSN operation and management platform, andOpenRSM, an open source integrated remote systems andnetwork management platform. The proposed systemarchitecture can support several levels of integration(infrastructure management, functionality integration, firmwaremanagement), corresponding to different use-cases andapplication settings.

Keywords- remote management, wireless sensor networks,pervasive communications, open source.

I. INTRODUCTION

Wireless sensor networks typically consist of spatiallydistributed autonomous devices that use sensors tocooperatively monitor physical or environmental conditions,such as temperature, sound, vibration, pressure, motion,acceleration or pollutants, at different locations. They aretypically being used in the scientific, medical, commercial, andmilitary domains in order to perform sensing and monitoring inthe physical world, such as habitat monitoring, object trackingindustrial automation, fire detection, traffic monitoring, etc.The effective and flexible integration of sensory systems withinterconnection networks and grid technologies is a critical steptowards developing major pervasive computing andcommunication services and applications. Because of sensornetwork inherent characteristics such as heterogeneity, limitedbandwidth and energy constraints, WSN management andmonitoring architectures need to:

• provide a wide range of services so as to cover the wholespectrum of supported WSN architectures

J. RolimDepartment of Computer Science,University of Geneva, Switzerland

rolim@cui.unige.ch

• minimize the overall implementation effort and manageWSNs uniformly to the degree possible

• reduce the needs for network administration and sensornode software management

• expose web interfaces for WSNs management

Most management tools for WSNs provide networkmanagement functionality; they primarily support visualizationbased on collecting data from the network of sensors using datalogging on a designated WSN gateway node. The nodes polltheir sensors at a user-configurable sampling rate and sendthem to the gateway using multi-hop protocols; readings fromthe network are typically stored in a relational database forfurther processing. Most tools that rely on mechanisms such asthe above must be considered monitoring or supervisory toolsrather than management tools, since they lack functionality forsensor state change or WSN configuration. Moreover, suchtools are typically installed and configured to monitor a singleWSN installation.

A lot of administrative and management tasks that aretypically supported by standard management tools forworkstations would be valuable to WSNs operators andadministrators. Such tasks are:

• multiple WSNs management and monitoring

• web-based control

• remote command execution or remote configuration

• software / firmware upgrade

• reporting

• grouping

An integrated management platform for WSN mustinclude all the above tasks. The scenery of open source toolsfor WSN management is analogous to the one for remotemanagement of general systems, in terms of product maturityand market fragmentation. There are very few integratedmanagement systems offered with open source licensingschemes and none of them offers WSN interfacing.

This paper presents an architecture that is capable ofdelivering remote management functionality to wireless sensornetworks. The idea is based on the combination of jWebDust

[1], a software environment that allows the implementation ofcustomized applications for wireless sensor networks, andOpenRSM [2], one of the very few open source remotemanagement platforms. In order to bring management to WSN,it is essential to automate routine WSN practice. jWebDustprovides WSN management functionality, including querying,monitoring, data logging and visualization. jWebDust employsan extendable architecture and provides easy interfacing andAPI. OpenRSM provides the implemented distributed logicsuitable to deliver services, such as inventory and assetmanagement, software delivery, remote control and networkmonitoring, all integrated in one environment.

The paper is organized as follows. Section II describes therelated state of the art regarding monitoring and administrationtools for wireless sensor networks. Section III presents anoverview of the jWebDust and OpenRSM architectures. Theproposed integrated architecture and its applicability to relevantuse-case scenarios are presented in Section IV. Finally,conclusions and future work are discussed in Section V.

II. RELATED WORK

Software environments that provide the necessary tools andoperations to allow the monitoring and administration of awide range ofWSN's applications are relatively few and to ourbest knowledge, none of them integrates all the desiredmanagement functionality in a single environment.

TinyDB [3] is an example of an application that allowsmultiple concurrent queries, event-based queries and timesynchronization through an extensible framework that supportsadding new sensor types and event types. The central idea ofTinyDB is to provide an SQL-like interface to the programmerthat makes the wireless sensor network look like an RDBMS(Relational Database Management System). Tiny ApplicationSensor Kit (TASK) [4] is built on top of TinyDB in order tofurther simplify application deployment and development, andto provide additional management capabilities. TinyDB isdistributed with TinyOS [5], the de-facto operating systemused in WSNs so far.

MoteWorks [6] is a commercial WSN management productoffered by Crossbow. MoteWorks is built on n-tier architecturemodel and offers a number of standard WSN functionalities,along with APIs for easy interfacing and integration with othersoftware. It also supports numerous sensor node hardwareplatforms. Mote-VIEW [7], a part of MoteWorks, is a platformthat provides visualization tools to the user, combined with adata logger that runs on the sensor network gateway. Thelogger listens to readings arriving from the network through acontrol center attached to the gateway and stores them in arelational database.

ArchRock [8] is an another example of a company whichproduces products that offer WSN management capabilities.Like MoteWorks, it offers sensing functionalities, and APIs tointerface with. It also offers integration of the sensor networkwith IP networks, using a 6LoWPAN network stack inside thesensor network, making it easier to interface with the nodes.

TWIST [9] and MoteLab [10] are examples of testbeddeployment management environments, targeted toward

research teams. They provide capabilities as job scheduling(i.e., binary code updates from different users), networkactivity sniffmg, etc. However, these tools are designed forspecific-purpose environments that focus on the testingmethods ofWSN applications. Moreover, special hardware andnetwork topologies are required, making TWIST and MoteLabnot well-suited for general network management.

MANA [11] is an example of a other managementarchitecture for WSNs. It provides functional, information, andphysical management architectures that take into accountspecific characteristics of a WSN network. Some of themrestrict physical resources such as energy and computingpower, frequent reconfiguration and adaptation, and faultscaused by unavailable nodes.

GSN [12] is another middleware architecture (extendiblesoftware infrastructure) for rapid deployment and integration ofheterogeneous wireless sensor networks. GSN is tested withMica2, Mica2Dot, TinyNodes, Wisenode, Wired & Wirelesscameras, several RFID readers.

Finally, Hourglass [13] is an Internet-based infrastructurefor connecting a wide range of sensors, services, andapplications in a robust fashion. In Hourglass, streams of dataelements generated from sensor networks are routed to one ormore applications. The Hourglass infrastructure consists of anoverlay network of well-connected dedicated machines thatprovides service registration, discovery, and routing of datastreams from sensors to client applications.

The above platforms and tools provide specificadministrative functionality, mostly in terms of development,and do not give an integrated remote management WSNenvironment, under which the overall administration andmonitoring of the wireless sensor network can performed bothin low and high level.

III. OVERVIEW OF JWEBDUST AND OPENRSM

In this section an overview ofthejWebDust and OpenRSMplatforms is given. Subsection A describes the jWebDustplatform, while subsection B describes the OpenRSM platform.

A. jWebdust overview

jWebDust [1] differentiates the system into two maingroups: the networked sensor devices that operate usingTinyOS [5], and the rest of the network (e.g. control centers,database server, etc.) that is capable of executing Java code.Both system groups use an open architecture implementing acomponent-based architecture. The component interface andthe exchange of data over broadly used protocols provideincreased portability. This implies that the system can be usedover different machine architectures as well as operatingsystem and server technologies.

From a high-level perspective, the components that makeup jWebDust are organized using the n-tier application model.We distinguish the following five tiers:

• the Sensor Tier that consists of one or more wirelesssensor networks deployed to areas of interest,

OpenRSMIntegration Server

~NAT

JPI

~QOpenRSM

Pro~y

The components of the OpenRSM platform are the agentthat makes target stations manageable, the graphicalmanagement console presented to the user and the server whereprocessing logic is implemented. The OpenRSM agents areabstract, multiplatform, manageable entities that conveyadministrative actions coming from the OpenRSM server.Administrative actions originate from user actions on theOpenRSM management console, the component exposed to theend-users and the administrators of the service. Managementcommands are conveyed to the OpenRSM server and then tothe agents. The architecture of the OpenRSM system ispresented in Figure 2.

OpenRSM utilizes the power of third party tools that havebeen enhanced and integrated in order to deliver the followingservices:

Figure 2. The OpenRSM system architecture

open source EMS tool can be developed by extending existingrated components offered by the open source community [16],[17].

In principle, OpenRSM needs to be simple and lightweight[18] so that it can be used by naive end users, not specialized inthe use of management tools or asset reporting tools.OpenRSM was designed for fast and automated deployment, inorder to cover the needs of administrators who manage verydynamic environments. The development model adopted forthe OpenRSM system is open source development, in order toexploit the dynamics of projects that relate to managementtechnologies [19], [20], [21], [22] and gain value fromintegration. The open source community has been put underscrutiny [23] in order to recover the open source managementinitiatives suitable for the purposes of OpenRSM [24], [25].The architecture of the OpenRSM platform has been chosen tobe modular in order to follow the logical categorization ofentities involved [16] and to provide integration with otheropen source management tools. The implemented frameworkwas based on the agent-server model [26], [27].

Figure 1. Management of multiple WSNs from a single, unified, virtualsensor network usingjWebDust

• the Control Tier that corresponds to the control centerswhere the wireless sensor networks report the realizationof events,

• the Data Tier responsible for storing the informationextracted from the wireless sensor network(s),

• the Middle Tier that is responsible for processing the datato generate statistics and other meaningful information and

• the Presentation Tier that interfaces the information withthe final user in an easy way based on the capabilities ofthe user's machine.

The component-based architecture enables the jWebDustsystem to gain control over all critical resources, required bythe implemented functionality (connection to database,communication with a server, code execution). The autonomyof the components makes the system independent of themachine architecture, allowing it to be executed over anyfavored machine architectures using best-of-breed servertechnologies.

jWebDust uses a simple Discovery Service [I] in order tokeep track of the sensor nodes that participate in the wirelesssensor network and their technical characteristics (e.g., type ofsensors attached to each device, available power, etc) [14].

A distinct feature of jWebDust is its ability to managemultiple wireless sensor networks, each with a different controlcenter, under a common installation (Figure I). This is done byintroducing virtual sensor networks that hide the actualtopology and allow users to control the sensor nodes as if theywere deployed under a single, unified, sensor network. Thisabstraction significantly reduces the overhead of administeringmultiple networks. Furthermore, the idea of a unified, virtualsensor network allows the integration of totally heterogeneoussensor networks, i.e. not only regarding different kinds ofsensors attached to the sensor nodes of the network, but alsodifferent kinds of CPU architectures.

~ -- -- - - - -- -- - - -- -- -- - - , .. --- - - - - --- - - - --- - - - --,IIIIIIIIIIIIIIII,I

~.:! ! !~~ (:<___ ___ ___ ___________ _ L___ __ _______ _________ ~II

Area of Interesl 1 Area of Interest 2 jWebDust server

B. OpenRSM overview

The Open Source Remote System Management(OpenRSM) [2] is a pioneering initiative in the lightweightmanagement software area of open source enterprisemanagement (EMS) tools [15]. The initiative has been basedon the observation that most of the components comprising an

• inventory and asset management

• software delivery

• remote desktop control

• network monitoring

Figure 3. The proposed system architecture

forward them to the agent running at WSN's server/gatewaywhere jobs will be executed as jWebDust procedures. Thearchitecture of the integrated system is presented in Figure 3.

C. Firmware level management

In order to cover advanced needs for WSN managementsuch as firmware development and deployment, a higher levelof integration is required. In order to enable firmwareconstruction, deployment and discovery of individual sensornodes the integration must reach the firmware level. This willenable the management platform to deliver identifiable sensornodes, capable to dynamically change their state and runtimeenvironment in order to test new ideas, protocols andimplementations. In order to achieve the above it is necessaryfor the management platform to:

• support the underlying development environment.

• design a framework for firmware construction that willsupport the desired functionality and integrationcharacteristics.

l.---<SJMilnil gcma nl

ClJn~clc

O;>unRSMIflltf!JrSIi:)1'1 St"..1;!l'

rou terI

Jj)

The underlying development environment for sensor nodefirmware, TinyOS, offers development tools that can beintegrated into custom OpenRSM jobs. TinyOS functionalitycan be used by OpenRSM via TinyOS job templates,disposable to users for customization or immediate usage. Itcan be disputed whether TinyOS jobs can be generic, orspecialized; generic jobs offer users the freedom to ful1yexploit the underlying functionality, while specialized ones canbe formalized and their operation can be guaranteed. For thepurposes of remotely managing sensor nodes a conservativeapproach must be followed. The compilation and deploymenttasks can be formalized to produce accurate and safe results.The more generic the supported TinyOS functionality, thewider the space of cases the overlying firmware frameworkmust support. The management system will thus supportselected TinyOS functionality. It will formalize thedevelopment and the deployment tasks so as to allow specificchanges disallowing the creation of modules that may result tofundamental malfunction of the WSN, such as incompatibilitiesin the discovery or firmware update services. The output of theTinyOS jobs will be registered and stored.

The jWebDust layer uses the underlying TinyOSinfrastructure and provides the higher layers of the sensornodes protocol stack. The integrated management platform can

IV. THECONCEPT OF INTEGRATED WSN MANAGEMENT

jWebDust and OpenRSM can complement each other inorder to deliver integrated management to WSNs. With respectto the level of integration we distinguish the fol1owingmanagement layers:

• WSN server / gateway infrastructure management

• WSN server functionality support, applicationprogramming interface (API) integration

• firmware management

B. Functionality integration

OpenRSM can be further integrated with jWebDust. Inparticular, we propose an extension that allows to supportjWebDust services, APls and tools and to expose them asspecial-purpose remote management services. The OpenRSMwill then be capable to schedule and synchronize the executionof jWebDust-specific jobs and provide users with the capabilityto define custom jWebDust-specific jobs. In OpenRSMterminology , jobs are entities abstracted in accordance to objectoriented design principles. They are designed to be abstractsystem tasks (e.g., inventory, remote control, remote command,etc) or reusable user-created objects and playa central role interms of usability, design efficiency and system scalability.Jobs can themselves be managed by administrators/users,decoupling their creation and execution stages. They can begrouped or dynamically created based on the attributes ofmanaged systems. Each jWebDust-specific job will correspondto a distinct administrative task manageable within thejWebDust platform. OpenRSM will embody typical jWebDusttemplate jobs. Users can utilize the template jobs to createcustom ones. Jobs can be correlated with machines and then besubmitted to the OpenRSM integration server; the server will

A. Infrastructure-level management

OpenRSM can be primarily used to delivery infrastructuremanagement to WSN servers that is, bring inventory and assetsmanagement, network monitoring, software delivery, andremote desktop control to laboratory servers. This level ofintegration is achieved by incorporating the OpenRSM agentwithin ajWebDust installation.

Emphasis was given to system integration, extending fromdatabase backend migration, server and web content porting,and agent logic concatenation. The combined subsystems havebeen modified so that information can be shared among them.At the same time, the overall system has been designed so thatit is subject to the minimum possible set of limitations. Itscapabilities extend to managing any stations reachable throughstandard IP connectivity in a secure manner. The architecture atthe server tier has been kept open and thus adaptable to anyspecific needs and business models [17]. Care has been takenso that OpenRSM can manage stations hidden behind theNetwork Address Translation (NAT) protocol, using a proxyserver developed for that reason. The system also supportsmultiplatform systems management, and provides amultilingual user interface. The server has been put understress and performance tests [2].

support a safe and formalized subset of the API, tools andfunctionality provided by jWebDust in the same manner asTinyOS jobs. The challenge is to create an OpenRSM­compatible branch of jWebDust firmware, considering therestrictions in terms of sensor node memory and processingpower, so as to include minimal implementations of OpenRSMinventory and discovery modules.

Currently jWebDust supports sensor networks based onTinyOS. In order to provide heterogeneous sensor networksmanagement, as in the case where individual managednetworks are based on other architectures (eg ContikiOS [28]),the platform can be extended in order to support the additionalinfrastructures. Firstly, firmware management functionality caneasily be mapped to OpenRSM jobs using the graphicalinterface of the OpenRSM. jWebDust must then interface withthe sensor architecture communication API in order to establishconnection with the sensors. In the case where the sensorarchitecture supports IP-enabled networks, customized sensormanagement can be achieved by incorporating the OpenRSMagent in the code executed on the sensor.

D. Use-case scenarios

We mention here some use-case scenarios, in order to showthe conceptual similarity of usual management tasks inintegrated WSN management tools, and further justify ourconceptual approach. As WSNs tend to come closer to IPnetworks (e.g., 6LoWPAN), it is our belief that suchsimilarities will only become more. In the case of IP-basedsensor networks where the sensors are individually addressed,they can also be managed by remote management systems suchas OpenRSM. Management can be achieved by integrating thelightweight agent version in the sensor firmware. In that casethe OpenRSM will have to extend its server functionality inorder to support sensor agents.

Regarding inventory and asset management, which is astandard feature in OpenRSM and similar management tools, itis also a necessary feature in WSN as well. Although the initialconcept for WSN was that they should be data-centric, i.e.,only the information matters and not the source (node) it camefrom, this trend has shifted to more node-centric approaches.Very-large-scale WSNs, at least on a single location, are yetextremely rare, and with new standards and interoperabilitybetween different WSN hardware, heterogeneous WSNs arethe current and future trend. The administrator of a WSN mustbe able to see at any instance the capabilities of the nodes, thehardware and software associated with each one of them. Adynamic directory of such "services" is necessary to take fulladvantage ofWSN's capabilities.

Also, software delivery is important in WSNs, even moreso than in regular networks. This is because even moderate-sizeWSNs include more than 50 nodes, each one usually runningthe same software and difficult to interface with and program.This is a feature that has attracted much attention (e.g.[26]) inWSNs and we plan to take advantage of such previous work.For example, a research lab should be able to schedule jobsrelated to the software executed in its WSN and reprogram itdynamically and on-the-air (as opposed to manualreprogramming).

Regarding remote control, this is an inherent feature ofmost WSN software, since the resources of such a network areits sensors, actuators, communication subsystems, and, ifavailable, file storage. WSN administrators need a way tocontrol these resources in a way that resembles themanagement of regular networks, i.e., on groups of resources,that are built based on the dynamic directory mentioned above.

Finally, network monitoring is also an important activity inWSN. In general, such networks are prone to failures andtopologies change quite often. Statistics like the energyavailable, package failures and retransmissions are useful inevaluating the overall performance of the network and thesoftware used, e.g., of the routing protocol used, and directlylinked to the overall functionality offered by the WSN.

E. Integration Methodology

The integration of the two platforms will be done inaccordance with the integration levels, mentioned previously.

The first objective is to set the jWebDust under OpenRSMmanagement by producing an agent module for WSNgateways. The agent module can be integrated into thecodebase of the jWebDust platform or it can be deployed as anexternal module.

The next milestone is the development of high level systemmanagement functionality for the specific needs of WSNgateways, such as customized reports and assets management,into the agent module. Integration will proceed further intoproducing connectors for the jWebDust API interface. At thispoint the remote management agent will be capable to providefor the execution of all WSN management functionalitiessupported by the jWebDust API.

After this point the integration will affect all OpenRSMlevels and will reach the management console where the userwill be presented with visual representations of the managedboards and even sensors. After this point the integration ofjWebDust and OpenRSM may even consider branching fromOpenRSM and jWebDust, since it will have the potentialneeded for building end-user services for WSN management.

One of the most interesting and challenging services will bethe support of TinyOS jobs that will foster development andmaintenance actions for jWebDust managed laboratories. Thecornerstone of these services will be the frrmware managementservice that will formulate and support the remote firmwareupdate.

V. CONCLUSIONS AND FUTURE WORK

This paper presents the conceptual design of an integratedmanagement environment enhanced with WSN managementfunctionality. The design is based on the integration of theWSN monitoring platform jWebDust with the OpenRSMsystems and network management system. The derivedplatform is an integrated remote management WSNenvironment, under which the overall administration andmonitoring of the wireless sensor network can performed bothin low and high level. Future work includes the gradualintegration of the two platforms in accordance with theintegration levels, as mentioned in Section IV, and the

evaluation of its feasibility and performance (implementationoverhead, evaluation ofperformance metrics).

ACKNOWLEGMENT

This work has been partially supported by the 1STProgramme of the European Union under contract number IST­2005-15964 (AEOLUS).

REFERENCES

[1] I. Chatzigiannakis, G. Mylonas, and S. Nikoletseas, jWebDust : A java­based generic application environment for wireless sensor networks, Inthe proceedings of the first International Conference on DistributedComputing in Sensor Systems (DCOSS '05), 2005, pp. 376-386. Also,in the International Journal of Distributed Sensor Networks (IJDSN),Taylor and Francis, accepted, to appear in 2008.

[2] I. Karalis, M. Kalochristianakis, P. Kokkinos, E. Varvarigos ­OpenRSM: a lightweight integrated open source remote managementsolution, Intl Journal of Network Management 2008

[3] TinyDB: A declarative database for sensor networks,http://telegraph.cs.berkeley.edu/tinydb/

[4] P. Buonadonna, D. Gay, 1. Hellerstein, W. Hong, and S. Madden,TASK: Sensor network in a box, In the Proceedings of the 2nd EuropeanWorkshop on Sensor Networks, 2005.

[5] P Levis, S Madden, J Polastre, R Szewczyk, K Whitehouse, A Woo,D Gay, J Hill, M Welsh, E Brewer, D Culler - TinyOS: An OperatingSystem for Sensor Networks. In Ambient Intelligence, Springer BerlinHeidelberg, (2005), pp. 115-148

[6] Mote-Works monitoring software, Crossbow Technology Inc.,http://www.xbow.com/

[7] Mote-VIEW monitoring software, Crossbow Technology Inc.,http://www.xbow.com/

[8] ArchRock, http://www.archrock.com/

[9] TWIST Community Web Site, http://www.twist.tu-berlin.de/wiki

[10] MoteLab, Harvard Experimental Wireless Sensor Network Testbed,http://motelab.eecs.harvard.edu/.

[11] L. Ruiz, 1. Nogueira, A. Loureiro - MANNA, a managementarchitecutre for wireless sensor networks. In Communications Magazine,IEEE, vol 41, issue 2, Feb 2003

[12] K. Aberer, M. Hauswirth, A. Salehi - A middleware for fast and flexiblesensor network deployment. Proceedings of the 32nd internationalconference on Very large data base, p1199-1202, 2006

[13] J. Shneidman, P. Pietzuch, 1. Ledlie, M. Roussopoulos, M. Seltzer, M.Welsh - Hourglass: An Infrastructure for Connecting Sensor Networksand Applications Harvard Technical Report TR-21-04

[14] I. Chatzigiannakis, A. Kinalis, and S. Nikoletseas, Power conservationschemes for energy efficient data propagation in heterogeneous wirelesssensor networks, 38th Annual ACMlIEEE Simulation Symposium(ANSS 2005), IEEE Computer Society Press, pp. 60-71,2005.

[15] D Kakadia, T. Thomas, S. Vembu, 1. Ramasamy, "Enterprisemanagement systems part I: architectures and standards", SunMicrosustems, Inc.

[16] A, Westerinen, W Bumpus, "The continuing evolution of distributedsystems management", IEICE Trans. Inf & Syst., vol. E86-D, no. 11,November 2003.

[17] M. Sale, "IT service management and IT governance: review,comparative analysis and their impact on utility computing", HP inventresearch labs, 2004

[18] M. Dekhil, V. Machiraju, K. Wurster, M. Griss, Remote managementservices over the web, Software Technology Lab, HP, May 2000

[19] OpenAudit: http://sourceforge.net/projects/openaudit/

[20] UltraVNCm http://www.uvnc.com/

[21] Windows-get: http://windows-get.sourceforge.net/

[22] Nino network management system: http://sourceforge.net/projects/nino/

[23] A. Hochstein, R. Zarnekow, W. Brenner, Evaluation of service-orientedIT management in practice, In Proceedings of the InternationalConference on Services Systems and Services Management, 2005, Vol.1, pp. 80-84.

[24] S. Lee, M. Choi, S. Yoo, 1. Hong, H. Cho, C. Ahn, S. Jung, Design ofawbem-based management system for ubiquitous computing servers,http://www.dmtforgjeducation/academicalliance/, accessed on January2008.

[25] K. Carey, F. Reilly, Integrating CIMlWBEM with the Java enterprisemodel, http://www.dmtforgjeducation/academicalliance/, accessed onJanuary 2008.

[26] M Wren, 1. Gutierrez, Agent and web-based technologies in networkmanagement, In Proceedings of the Global TelecommunicationsConfernece (GLOBECOM), 1999, Vol. 3, pp. 1877-1881.

[27] I. Bailey, A simple guide to enterprise architecture, Model Futures TMwhite paper, 2006,http://www.modelfutures.com/file_download/4/SimpleGuideToEA.pdf,accessed on January 2008.

[28] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight andflexible operating system for tiny networked sensors. In Workshop onEmbedded Networked Sensors, Tampa, Florida, USA, Nov. 2004.