1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

Wireless Sensor Knowledge Archive

Sanat Sarangi

Bharti School of Telecommunication Technology

And Management, IIT Delhi,

Hauz Khas, New Delhi - 110016, INDIA

sanat.sarangi@ieee.org

Subrat Kar

Bharti School of Telecommunication Technology

And Management, IIT Delhi,

Hauz Khas, New Delhi - 110016, INDIA

subrat@ee.iitd.ac.in

Abstract—Wisekar - the WIreless SEnsor Knowledge ARchiveis presented. It is a centralized web repository for collection,management and distribution of events from sensor-enableddevices towards realization of the Internet of Things (IOT).Wisekar offers flexible multimodal event contribution methodsadapted to a variety of user skill and requirement levels. Alongwith rich visualization capabilities, it is versatile in terms of itsability to extend and decorate events with XML based meta-data and images. This allows enforcement of rigorous standards-compliant formats like the Open Geospatial Consortium (OGC)defined SensorML and TransducerML.

Keywords: Wisekar, Internet of Things, Sensor Networks,REST, Web Service

I. INTRODUCTION

A web-based repository Wisekar (Wireless Sensor Knowl-edge Archive) - hosted at http://wisekar.iitd.ac.in - for archiv-ing sensor derived information is presented. Rapid growthof Wireless Sensor Networks and increasing proliferation ofsensor enabled mobile phones have created a new wave on theInternet - The Internet of Things. For massive volumes of datagenerated from heterogeneous sources to be meaningful, theymust be systematically and coherently stored and catalogued.This has fuelled the development of large web sensor archives[1], [2]. Globally accessible web repositories on the Internetusually communicate over HTTP which is permitted by fire-walls. Two rugged architectures, SOAP [3], [4] and REST [5]are suitable to realize such systems.

Simple Object Access Protocol (SOAP) involves the trans-mission of information in the form of XML encoded messageswhere each message consists of an envelope containing aheader and a body. SOAP became W3C recommendation inversion 1.2 of the standard and its services are defined ina W3C compliant XML document called a Web ServicesDescription Language (WSDL) file [6]. HTTP is the mostcommon transport layer for SOAP although extensions areavailable to allow it to bind to a different transport layer suchas Java Message Service (JMS) [4]. In comparison, REST(Representational State Transfer) uses a URI associated with anHTTP defined method like GET, POST, PUT and DELETE totransmit data. URI identifies the resource and method identifiesthe operation on the resource. The structured XML basedSOAP requires strict type checking which is not needed forthe lightweight REST making it relatively convenient for clientapplications to inter-work with RESTful services.

Storing events in proprietary formats makes it difficult forsystems to easily interoperate, to build super-archives or search

for information using platform independent query standards.SPARQL [7] is a W3C recommended query language forinformation expressed in the Resource Description Frame-work (RDF) format and the Web Ontology Language (OWL)built over RDF. The Open Geospatial Consortium (OGC)has developed the Sensor Web Enablement (SWE) framework[8] consisting of XML based standards like Observation andMeasurements (O&M) schema, SensorML to describe sensorsystems and TransducerML to describe transducers and sup-port realtime streaming of information. Such standards areindispensable for building ontologies and specifications likeSensor Web Resources Ontology for Atmospheric Observation(SWRO-AO) [9] or Semantic Sensor Observation Service(SemSOS) [10]. For data interchange, JavaScript Object No-tation (JSON) and XML are the two popular formats. WhileXML is an appropriate document interchange format, JSON isfaster for data interchange [11] due to its relatively lower datarepresentation space overheads.

Wisekar combines the flexibility of REST with the ex-pressiveness of XML to accept and manage heterogeneoussensor derived information with support for parameter basedfiltering and visualization. It consolidates all information intoa single homogeneous system for archival and analysis, andacts as potential bridge between dissimilar networks. This canbe used to realize smart pervasive applications with focusedobjectives such as generation of SMS or Email based onspecific conditions or data characteristics.

II. RELATED WORK

Cosm (earlier Pachube) [12] offers a REST based WebService that allows a user to store, share, control and analyzerealtime sensor data from devices in Extended EnvironmentsMarkup Language (EEML). SensorBase.org [13] designed tolog sensor information provides support for data contributionin Environmental Markup Language (EML). A SOAP basedWeb Service API is used to contribute data to SenseWeb [14].SensorMap is a SenseWeb based application which providesthe user a graphical user interface to query, visualize andanalyze sensor data. UCI Machine Learning Repository [15]and CRAWDAD [16] host data and supporting meta-data suchas citations in the form of datasets. Wisekar is designed tofoster collaborative scientific research across a wide profileof users and systems with heterogeneous data contributioncapabilities. It accepts both pre-packaged and live-streamedinformation through a RESTful API, while supporting evolu-tion paths for preservation of relevant data. Wisekar providesa flexible yet rigorous standards enforcement strategy to meetdifferent application and inference requirements. It allows a

IEEE CONECCT2013 1569685245

1

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

custom XML schema to be defined for each dataset permittingdata for multiple XML derived standards to co-exist.

III. WISEKAR

We describe the organization and behaviour of Wisekar inthe following sections.

A. Data Organization

Wisekar effectively addresses the storage and interactionrequirements expected of an IOT repository that include main-taining citable research data, and providing manual and auto-mated interfaces for collecting information from distributeddata generation points. Information is stored two kinds ofdatasets - passive sets and active sets - with slightly differentobjectives as discussed below.

1) Passive Sets: Passive sets are stored in compressedarchive files and have a user-defined data format. XML, CSVand JSON are the recommended formats for textual content.In addition to the data itself, each dataset contains meta-dataexplaining the structure, source, citations and applications ofthe dataset. A passive set is created after all data for the set isavailable. Once created, only some sections of the meta-datasuch as citations are meant to be updated. Passive sets offerthe simplest way to contribute meaningful data and are similarto datasets in [15] and [16].

2) Active Sets: There may be situations where data is tem-poral in nature, is generated from a geographically distributedset of locations, and needs to be analyzed by a heterogeneousgroup of people. Moreover, it may be difficult to ascertainthe volume of relevant data before hand. An example couldbe analyzing pollution levels or temperature trends across theglobe. Such situations call for more flexibility in contribution,update and collaboration at all levels of data management.Wisekar active sets are appropriate for such situations. Unlikepassive sets, data in active sets is structured. The creation ofan active set is similar to a passive set, however a (privateor shared) mode needs to be assigned to the set. The datacontributor has the option to specify an XML schema thatextends the structure definition of the dataset contents. Activeset modes are discussed in more detail later. Contributionto active sets is made through client applications using theWisekar REST API.

In order to allow heterogeneous events from a variety ofdomains to co-exist, a flexible representation format is usedfor active set events. Every event has a standard and a vari-able component. Important fields in the standard componentinclude- a unique Wisekar assigned event ID, event type and anassociated set of compulsory status values. Wisekar maintainsa glossary of event types that help define the interpretationof the standard component e.g. a temperature type eventrequires a status field to store the temperature in Celsius. Thevariable part includes the provision of supplying an imageand an XML Fragment where the event contributor mayspecify additional information not captured by the standardfields. For a temperature event, XML Fragment may containspecific details of the event source. However, the fragmentmust comply with the XML schema defined for the datasetto preserve the structure of events across the dataset. Thestandard component helps offset the storage overheads of XML

by capturing common information across events in a fixed setof fields with a predefined interpretation format.

Sensor nodes and their events are entered, updated anddeleted by applications using the Wisekar API. The APIdeveloped so far is summarized in Tab.I. The first column hasthe HTTP method - GET, POST, PUT and DELETE that isused send a request to the server to Retrieve, Create, Updateand Delete the resource(s) defined in the second column.POST node creates a unique Wisekar node ID in a specifieddataset using the node details specified in the request. POSTevent uses the associated details (optionally including theXML Fragment) to create an event with a unique event IDcorresponding to a Wisekar node ID. Each event has an eventtype from a glossary of events obtained using GET eventtypes.The glossary of event types is conveniently extendable bythe administrator as per requirement. GET datasets returnsthe details of datasets filtered on the basis of access rightsavailable to users. An image co-tagged with each event canbe inserted and retrieved with POST eventimage and GETeventimage respectively.

TABLE I: Wisekar REST API

HTTP Method Resource

GET datasets

nodes

events

userdetails

eventtypes

eventimage

POST node

event

eventimage

PUT node

event

DELETE node

event

Fig. 1: Life Cycle of an Active Set

3) Relationship between Active and Passive Sets: Evolutionof active sets is shown in Fig.1. They have three operativemodes - private, shared and published. An active set is createdin private or shared mode. Private mode set allows only thecreator to have all (view, update and delete) rights on the set.In shared mode, creator has all rights while other Wisekarmembers only have view rights. Therefore, a collaborativepollution monitoring activity at two places would typicallyinvolve creation of two shared datasets, one for each place.Shared mode would be made more granular to allow multipleusers to exercise finer control on a single dataset. After it isdetermined that an active set needs no further updates, its status

2

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

is changed to published. A published active set is equivalent toa passive set and long term data archival measures are adoptedfor it.

B. Enforcement of Standards

The XML Fragment associated with each event iscustom-defined by the contributor. This fragment can bestructured on one or more standards and markup languagesdiscussed earlier. However, to achieve consistency acrossXML information of events in a dataset, a Document TypeDefinition (DTD) or XSD based schema needs to be definedduring creation of the dataset. Each active-set stores a set ofnodes and the events generated from them. This hierarchicalorganization may be viewed as a generic structure that isusable for applications other than sensor networks. We planto add additional levels of granularity like a per-node schemagoverning the structure of events from each node. A sampleDTD and the corresponding XML Fragment are given below.They are used in our experimental Case Study discussed inSec.IV.

XML Fragment DTD:<!ELEMENT info (name, sensor, source)><!ELEMENT name (#PCDATA)><!ELEMENT sensor (#PCDATA)><!ELEMENT source (#PCDATA)>

XML Fragment:<?xml version=”1.0”?><info><name>WisekarNode1</name><sensor>Temperature</sensor><source>DataCentreA</source></info>

C. Visualization and Interaction

Wisekar is designed to handle and visualize large volumesof data. Nodes and Events in each active set are distributed intomultiple pages for ease of visualization and faster retrieval.Selective viewing of sensor events and nodes is possible byfiltering information with start and end time, nodes and eventtypes. Event information requested is both updated in tablesand presented on Google maps. The information is exportablein both comma separated values (CSV) and XML to allow it tobe conveniently used by both document processors and customapplications. A discussion forum for members to interact andplan joint research exercises is also available.

D. Development Platform and Third Party Applications

The evolution of web application development with ref-erence to languages, frameworks and software engineeringprinciples is discussed in [17]. The movement towards richerbrowser-based applications and an improved semantic web isnoted. Wisekar is developed and hosted in a LAMP (Linux,Apache, MySQL, PHP) environment. The API has been eval-uated with heterogeneous client platforms. PHP examples areavailable as a part of the documentation. Android based SmartPhone applications and general purpose Java based Nativeapplications as REST clients for Wisekar have been developed.The Case Study in Sec.IV discusses a complete deployment.

E. Performance Evaluation

Wisekar API performance for data retrieval and update isevaluated by load testing it using Apache JMeter [18]. Theparameters and methods used to characterize performance aregiven in Tab.II. Testing involved making simultaneous GET orPUT requests to Wisekar with a specified number of threadsgiven by Number of Threads and repeating the experimentLoop Count times. The results are used to compute Average(mean) Response Time and Standard Deviation, Throughputand the Median Response Time. Ramp-up Time indicates thetime at the end of which all threads used for testing are active.For each of the two request types - GET nodes and PUT node- two data sizes are used for evaluation as indicated. GETnodes (38.07 KB) returns a page of node details. GET nodes(7.81 KB) returns a fraction of the page. PUT node (0.72 KB)updates only one node parameter and PUT node (1.18 KB)updates three node parameters including the node description.These values are chosen to demonstrate the performance ofWisekar over a large variation in data size and also illustratethe order of data sizes that updates (PUT) and retrievals (GET)usually work with.

Fig.2 shows that the Average Response Time increases bothwith the data size associated with the methods and over numberof threads. The minimum and maximum Average ResponseTimes are 44 ms and 1603 ms with PUT node (0.72 KB) at25 threads and GET nodes (38.51 KB) at 100 threads respec-tively. The corresponding minimum and maximum standarddeviations in response time given in Fig.3 are 28.33 ms and618.66 ms. We note that this standard deviation increases withincrease in number of threads, although at a relatively slowerrate. Median values shown in Fig.4 are close to the meanvalues indicating Response Time is evenly distributed aboutthe mean with less outliers. Throughput (requests/sec) variesinversely with Response Time as expected. PUT node (0.72KB) and GET nodes (38.07 KB) have the highest and lowestthroughput levels respectively.

TABLE II: Performance Evaluation Parameters and Methods

JMeter Parameters

Parameter Value

Ramp-up Time 10 seconds

Loop Count 100

Number of Threads 25, 50, 75, 100

Wisekar Methods

Method Data Size

GET nodes 38.07 KB

GET nodes 7.81 KB

PUT node 1.18 KB

PUT node 0.72 KB

IV. CASE STUDY

In this section we discuss Wisekar in the context of ex-perimental sensor network setup to summarize our discussionwith a concrete example and delineate Wisekar’s position androle in sensor network applications.

A. Deployment Scenario

Wisekar is assumed to be the central repository for atemperature monitoring application spanning a distributed set

3

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

25 50 75 1000

200

400

600

800

1000

1200

1400

1600

1800

2000

Number of Threads

Ave

rag

e R

esp

on

se

Tim

e (

ms)

GET nodes (38.51 KB)

GET nodes (7.81 KB)

PUT node (1.18 KB)

PUT node (0.72 KB)

Fig. 2: Average Response Time Vs Number of Threads

25 50 75 1000

200

400

600

800

1000

1200

1400

1600

1800

2000

Number of Threads

De

via

tio

n (

ms)

GET nodes (38.51 KB)

GET nodes (7.81 KB)

PUT node (1.18 KB)

PUT node (0.72 KB)

Fig. 3: Standard Deviation of Response Time Vs Number ofThreads

25 50 75 1000

200

400

600

800

1000

1200

1400

1600

1800

2000

Number of Threads

Me

dia

n R

esp

on

se

Tim

e (

ms)

GET nodes (38.51 KB)

GET nodes (7.81 KB)

PUT node (1.18 KB)

PUT node (0.72 KB)

Fig. 4: Median Response Time Vs Number of Threads

25 50 75 1000

50

100

150

200

250

300

Number of Threads

Th

rou

gh

pu

t (r

eq

ue

sts

/se

co

nd

)

GET nodes (38.51 KB)

GET nodes (7.81 KB)

PUT node (1.18 KB)

PUT node (0.72 KB)

Fig. 5: Throughput Vs Number of Threads

of data centres. Each data centre has some site-specific infor-mation that needs to be included with the data to allow Wisekarto distinguish between the heterogeneous data sources. Also,for security reasons, one of the sensor events needs to beaccompanied with an image and an XML Fragment sharingmore details about the node and the data centre. We realize therequirements of such an application by logging events from anode that senses ambient temperature of a room, in Wisekar.

Fig. 6: Case Study Experimental Setup

B. Experimental Setup

Fig.6 shows a block diagram of the experimental setup.The sensor node measures and sends temperature events toa Decision Support System (DSS) responsible for monitoringand logging all data from the sensor network deployed in theroom. The responsibility of converting the raw measurementinto a Wisekar temperature event in Celsius lies with the DSS.This allows Wisekar to archive, serve and analyze only mean-ingful data. This however does not imply that Wisekar imposesany restrictions on the kind of data it accepts. The DSS canlog the unprocessed temperature in Wisekar using a Customevent type. The Java based (Wisekar REST client) Interfaceris used by the DSS to log relevant information in Wisekar.For one of the temperature events, the XML Fragment given

4

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

in Sec.III-B containing the required additional information islogged. Thereafter an image of the node available to the DSSis updated for the event.

Fig. 7: Communication between Interfacer and Wisekar

Fig. 8: Standard Event Information with Dataset Location onGoogle Maps

C. Communication between Interfacer and Wisekar

A private active set named WisekarTestSetIITDelhi is cre-ated by filling in all the attribute information in a form togenerate a unique datasetId. Attribute information includesthe DTD defined in Sec.III-B. The methods used for logging

an image and XML Fragment tagged event are captured bythe sequence diagram in Fig.7. GET userdetails allows theInterfacer to obtain the API Key by supplying user credentialsused for logging into Wisekar. POST node and POST eventare used to create a node with a global unique node ID andsubmit events for it respectively. Parameter localId with POSTnode refers to an ID assigned to the node by the contributorfor easy recall. Other node details include its name, descriptionand GPS location. Parameter status with POST event containsthe temperature. The XML Fragment of Sec.III-B is insertedas a parameter to POST event. POST eventimage method isused to update an image for the logged event, that can besubsequently retrieved with GET eventimage.

Fig.8 shows the logged temperature events along with theDataset position on Google map. Latest Events table indicatesthe standard information associated with each event. Event‘1912’ is tagged with an XML Fragment and an Image.

V. CONCLUSION

This paper presents the design and implementation ofWireless Sensor Knowledge Archive (Wisekar), a commoncentral Internet of Things repository for systematic collection,archival and dissemination of sensor and related data. Wisekaris already an operational system that is being used by us andother institutions for a wide variety of distributed applica-tions starting with E-Health and E-Agriculture. Some areasare pollution monitoring, emergency notification for healthapplications and image acquisition, analysis and reporting withheterogeneous systems.

We are developing effective strategies for tasking sensornetworks through Wisekar. Wisekar is expected to play a keyrole in development of applications with specific ontologicalobjectives for seamless integration with the semantic web.Intelligent caching mechanisms and distributed databases areplanned for improved response times with large volumes ofdata. Cloud environments would help address rapid growth instorage space requirements.

VI. ACKNOWLEDGEMENTS

The work in this paper is supported by India UK AdvancedTechnology Centre (IU-ATC) grant by EPSRC, UK and DST,Government of India. We thank Vikas Chawla, IIT Delhi, forhis contribution to the implementation of Wisekar.

REFERENCES

[1] L. Coetzee and G. Olivrin, “The internet of things - promise for thefuture? an introduction,” in IST-Africa Conf. Proc., Pretoria, SouthAfrica, May 2011, pp. 1–9.

[2] Y. Huang and G. Li, “A semantic analysis for internet of things,” inProc. of the 2010 Intl Conf. on Intelligent Comp. Tech. and Automation

(ICICTA ’10), Washington DC, USA, 2010, pp. 336–339.

[3] “SOAP Specification.” [Online]. Available: http://www.w3.org/TR/soap/

[4] “SOAP over Java Message Service 1.0.” [Online]. Available:http://www.w3.org/TR/2012/REC-soapjms-20120216/

[5] R. Fielding, “Architectural styles and the design of network-basedsoftware architectures,” Ph.D. dissertation, University of California,2000.

[6] V. De Luca, I. Epicoco, D. Lezzi, and G. Aloisioa, “GRB WAPI,a RESTful framework for grid portals,” Procedia Computer Science,vol. 9, pp. 459–468, 2012.

5

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

[7] “SPARQL query language for RDF.” [Online]. Available: http://www.w3.org/TR/rdf-sparql-query/

[8] A. Sheth, C. Henson, and S. Sahoo, “Semantic sensor web,” IEEE

Internet Computing, vol. 12, no. 4, pp. 78–83, July-Aug. 2008.

[9] C. Wang, N. Chen, C. Hu, S. Yan, and W. Wang, “A general sensorweb resource ontology for atmospheric observation,” in IEEE Intl

Geoscience and Remote Sensing Symp. (IGARSS), Vancouver, Canada,July 2011, pp. 3436–3439.

[10] C. Henson, J. Pschorr, A. Sheth, and K. Thirunarayan, “Semsos:Semantic sensor observation service,” in Intl Symp. on Collaborative

Technologies and Sys. (CTS) ’09., Baltimore, Maryland, USA, May2009, pp. 44–53.

[11] N. Nurseitov, M. Paulson, R. Reynolds, and C. Izurieta, “Comparison ofjson and xml data interchange formats: A case study,” in ISCA 22nd Intl

Conf. on Comp. and their App. in Industry and Engg, San Francisco,California, 2009, pp. 157–62.

[12] “Cosm.” [Online]. Available: https://cosm.com/

[13] K. Chang, N. Yau, M. Hansen, and D. Estrin, “A centralized repositoryto slog sensor network data,” in Proc. of Intl Conf. on Dist. Comp. in

Sensor Sys., San Francisco, CA, USA, Jun. 2006.

[14] W. Grosky, A. Kansal, S. Nath, J. Liu, and F. Zhao, “Senseweb: Aninfrastructure for shared sensing,” IEEE Multimedia, vol. 14, no. 4, pp.8–13, 2007.

[15] A. Frank and A. Asuncion, “UCI machine learning repository,” 2010.[Online]. Available: http://archive.ics.uci.edu/ml

[16] D. Kotz and T. Henderson, “Crawdad: A community resource forarchiving wireless data at dartmouth,” IEEE Pervasive Computing,vol. 4, no. 4, pp. 12–14, 2005.

[17] M. Jazayeri, “Some trends in web application development,” in Future

of Software Engineering, 2007 (FOSE’07), Minneapolis, MN, USA,2007, pp. 199–213.

[18] “Apache JMeter.” [Online]. Available: http://jmeter.apache.org/

6