uniﬁed service access for wireless sensor networks service access for wireless... · uniﬁed...

Unified Service Access for Wireless Sensor Networks

Jukka Suhonen, Olli Kivelä, Teemu Laukkarinen, and Marko HännikäinenDepartment of Computer SystemsTampere University of Technology

Tampere, Finland{jukka.suhonen, olli.kivela, teemu.laukkarinen, marko.hannikainen}@tut.fi

Abstract—Sensor networks enable large scale and fine reso-lution monitoring via interconnected sensor devices that rangefrom home appliances and mobile phones to dedicated sensingplatforms. While new wireless technologies are emerging, thechallenge is in the interpretation and utilization of heteroge-neous data received through varying types of interfaces. Thispaper presents a unified service access architecture, interfaces,and message formats for Wireless Sensor Networks (WSNs) col-lectively referred to as WSN OpenAPI. It supports sensor datacollection, actuator control, real-time alerts based on sensorvalues, and querying measurement and alert history. Comparedto the related work, WSN OpenAPI allows efficient machine-to-machine (M2M) communications with low complexity messageformats and avoiding extensive queries with publish/subscribeparadigm.

Keywords-wireless sensor networks; web services; sensorsystems; information management

I. INTRODUCTION

Sensor networks enable large scale and fine resolutionmonitoring of physical world via interconnected sensor de-vices. The devices include computers, mobile phones, homeappliances, and dedicated sensing platforms. A WirelessSensor Network (WSN) is a specific case where the mainpurpose of the network is in sensing and actuation. AWSN combines environmental sensing, data processing, andwireless multihop ad-hoc networking with low cost and low-energy hardware [1]. In general, sensor networks enablea vast amount of applications in various areas such asmilitary surveillance, interactive games, security and assetmanagement, environment monitoring, health care, buildingand home automation, and industrial control.

The key challenge is the utilization of heterogeneoussensor values to allow collaboration and data fusion be-tween sensor networks. Sensor devices use various protocols,different interfaces for accessing sensors, and incompatiblesensor data formats, which makes combining data fromdifferent sources hard. For example, WSNs alone comprisemyriad of different network technologies [2], such as IEEE802.15.4/ZigBee, IEEE 1902.1 RuBee, WirelessHART, Z-Wave, and proprietary protocols. As the technologies havedifferent capabilities, e.g. in throughput, communicationrange, and energy-efficiency, it might be beneficial to com-bine different technologies even on the same installation site.

This paper presents the design and reference implementa-tion of WSN OpenAPI, which is our proposal for a unifiedservice architecture for WSNs1. It is a set of specificationsthat define interfaces and data formats for accessing sensorsand actuators (transducers). WSN OpenAPI supports com-mon sensor tasks comprising sensor data collection, actuatorcontrol, real-time alerts based on sensor values, and queryingmeasurement and alert history. Unlike the related proposals,WSN OpenAPI is targeted at efficient machine-to-machine(M2M) communications. Small message formats enable theuse of resource constrained hardware and limited bandwidth.The design has been industry-driven. In addition to thesensing functionality, the developed specifications supportmaintenance and the life cycle management of WSNs.

WSN OpenAPI has been verified in deployments witha prototype low-energy WSN called Tampere Universityof Technology Wireless Sensor Network (TUTWSN), andAndroid and Nokia N900 mobile phones. As a practical usecase, this paper presents a greenhouse pilot study.

The rest of this paper is organized as follows. SectionII lists related work on WSN interfaces and data gathering.Section III describes WSN OpenAPI in detail. A referenceimplementation and experimental results are described in IV.Section IV concludes the paper.

II. RELATED WORK

IEEE 1451 describes a set of standards for connect-ing transducers to microprocessors via different networktechnologies. The standards share a common TransducerElectronic Data Sheet (TEDS) specification that describestransducer identification, calibration, and manufacturer re-lated information. The standards define only methods toaccess to transducers directly, while e.g. data collection andalert services must be implemented as separate services [3].

To guarantee compatibility between products from differ-ent manufacturers, several communication standards, suchas ZigBee and Bluetooth, define application profiles. Theprofiles describe the procedures and data formats supportedby a device. However, the profiles are generally technologydependent, and to exchange data between technologies itneeds to be converted to shared data formats and messages.

1Openapi specification is available with reference applications at http://www.tut.fi/dcs/downloads/

Suhonen, J.; Kivela, O.; Laukkarinen, T.; Hann kainen, M., "Unified service access for wireless sensor networks," Software Engineering for Sensor Network Applications (SESENA), 2012 Third International Workshop on , vol., no., pp.49,55, 2-2 June 2012

Sensor query languages gather data from the networkbased on complex requests [4]. However, they usually re-quire that data is stored at nodes [5] and expect certaincapabilities from the sensor devices. Thus, their applicabilityis limited as the interoperability between different networksis not considered.

Open Geospatial Consortium (OGC) has developed sensorrelated eXtensible Markup Language (XML) encodings re-ferred to as Sensor Web Enablement (SWE) [6]. Two meta-data formats have been defined. Sensor Model Language(SensorML) describes sensors and their capabilities, whileObservations & Measurements (O&M) describes sensormeasurements. These formats may be used separately ortogether with other OGC standards.

SWE defines several services for practical utilizationof sensors. Sensor Observation Service (SOS) defines aninterface for requesting simple observations from sensornetworks and observation repositories (e.g. a measurementdatabase). Sensor Planning Service (SPS) extends SOS byallowing complex sensor queries that require time consum-ing computation or waiting for future data. Sensor AlertService (SAS) defines an interface for publishing and sub-scribing to sensor alerts. Alerts can be delivered to the clientwith Web Notification Services (WNS), which is intended todeliver messages with various methods, e.g. e-mail, HTTPto other services, and SMS. WNS is not tied to alerts, butcan be used generally with other services and protocols e.g.to indicate client the completion of SPS query.

Sensor measurements in SWE are encoded with Trans-ducer Markup Language (TML). It can be used for real-timestreaming or carrying SOS or SPS results. For convenience,TML includes additional transducer information such ascharacteristics (accuracy, coordinates, ...), calibration, opera-tional conditions, and the relationships of transducers. Thus,TML can be used independently from O&M and SensorML.

OGC SWE has been implemented in Open Sensor WebArchitecture (OSWA) [7], PULSENet [8], and WSN Appli-cation Service Platform (WASP) [9]. The common goal ofthese platforms is to ease the development of applicationsthat utilize sensor data by defining a middleware layerfor SWE. Additionally, WASP extends SWE with userauthentication, WSN hardware configuration management,and application management for inserting, updating, anddiscovering sensor services.

SenseWeb [10] aims to provide an open infrastructurefor registering and utilizing sensors. It uses a centralizedarchitecture where sensors connect to a coordinator viagateways. The gateways hide network technology detailsand determine which data is available publicly. Compared toSWE, SensorWeb has less features. It supports only storingand querying sensor data, whereas alerts and other sensorrelated services are not specified. Furthermore, the platformdoes not support real-time streaming of sensor data makingit mostly suitable for infrequent queries.

IrisNet [11] and Hourglass [12] are frameworks that allowcomplex queries over distributed Internet-connected sensors.Their goal is to reduce bandwidth usage to allow highbandwidth sensing, e.g video streams, with data filtering,smart query routing, and data caching. As a drawback, theseframeworks expects significant computing power and storagefor the routing devices.

WSN OpenAPI act as an abstraction layer for sensornetwork services. Thus, it can be used to connect networkspecific standards such as IEEE 1451 to data query frame-works. Compared to SenseWeb, WSN OpenAPI supportsseveral sensor related services and historical data queries.WSN OpenAPI does not mandate a specific communi-cation protocol. This relaxes implementation requirementsand allows using it e.g. over TCP/IP, SOAP, SIP, or othercommunication protocols in WSNs such as 6LoWPAN.

Unlike SWE that pulls data from passive services [13]thus causing query overhead to the sensor network, WSNOpenAPI uses an active publishing mechanism. In addition,data collection can be adjusted based on client requirementsthus reducing sensor network overhead. WSN OpenAPIallows implementation on very resource constrained devicesby defining simple data formats. Still, it can be used in con-junction with the SWE interfaces and services. Specifically,SensorML that has been adopted as meta-data format.

III. WSN OPENAPI

WSN OpenAPI defines a unified access to sensor networkservices as shown in Fig. 1. This way, clients (e.g. applica-tions or M2M systems) that connect to the gateway functionsimilarly regardless of sensor network technology. A sensornetwork may comprise multiple nodes, or consist of onlyone node e.g. a personal computer or a mobile phone thatpublish their sensors.

The architecture of WSN OpenAPI presented in Fig.2 comprises sensing, actuation, data storage, and meta-data services. An WSN OpenAPI gateway connects sensornetworks to clients. A sensor device can interact with the

Figure 1. Unified access to sensor network services.


gateway directly with WSN OpenAPI, but for compatibility,an adapter may be used to convert between WSN OpenAPIand proprietary data formats. Data archive service storesmeasurement values for later examination and can be real-ized e.g with a file or database. Meta-data archive is a datastorage that holds node and sensor related information suchas sensing accuracy, manufacturer, and model. The archi-tecture allows the distribution of these services to separatemachines to increase performance when interfacing largenetworks, or they can be co-located in a single machine.

WSN OpenAPI uses a hierarchical structure to addressnodes and transducers: a sensor network comprises nodes,which contain one or more transducers. As a physical sensormay measure several related quantities e.g. temperature andhumidity, a transducer is further divided into components.For example, an acceleration transducer comprises compo-nents for acceleration on each axis. The network hierarchyfits naturally to WSNs but can also be applied to singledevices such as satellites or mobile phones. In that case,each device forms a virtual network.

A. Network Interfaces

WSN OpenAPI consists of several interfaces that canbe used separately. Thus, an WSN OpenAPI client needto implement only the interfaces that are required for itsfunctionality. The interfaces are:• Authentication and Capability Format (ACF) – defines

message formats for authenticating to the gateway andquerying the list of supported interfaces. Thus, this isthe only mandatory interface for an implementation.

• Network Management Format (NMF) – describes mes-sage formats for querying network structure and status,configuring measurement collection, and setting alerts.

• Meta-Data Format (MEDF) – defines an interface forquerying node capabilities and sensors.

Figure 2. WSN OpenAPI service architecture comprising a gateway, anoptional technology specific gateway adapter, data archives, and networkelements.

• Sensor Information Data Format (SIDF) – describes theformat to present measurement data.

• Sensor Archive Data Format (SADF) – defines requestand response data formats for accessing values storedin a WSN data archive.

• Node Actuator and Sensor Control (NASC) – presentsan interface for sending actuator commands to sensors.

If a sensor network/device does not natively support thefeatures specified in certain interface, such as alerts, it isexpected that these features are emulated in the gateway. Therelations between the interfaces and their connectivity to thegateway, data archive, and meta-data archive are presentedin Fig. 3. The interfaces utilize publish/subscribe paradigmwhere data consumers register themselves to the data sourcesto receive the data they are interested in.

WSN OpenAPI messages are defined both in XML andComma Separated Value (CSV) formats. Using textual pre-sentation for data instead of binary format increases compat-ibility between different machine architectures. XML formatis being adopted as a common language between softwaresystems, and benefits from the common availability of parserlibraries and language support. Also, as the defined XMLmessages define the data types and interface part in WSDL,allowing describing the service easily in WSDL. CSV ismore compact allowing its use in M2M communicationswhere bandwidth is limited and data compression wouldrequire too much processing power.

B. Network Structure and Status

In addition to the sensor measurements, WSNs have oftenindustry-driven requirements for system integration. Theserequire the knowledge of network structure, the status ofdevices, e.g. their location and whether their are workingcorrectly or being replaced.

The hierarchical model of the WSN OpenAPI supportsstoring and querying the maintenance information in net-work, node, and sensor levels. In addition, the knowledge ofnetwork structure allows efficient targeting of requests andcommands to individual sensors. For example, a gatewaycan return error message immediately when trying to sendan actuator command to a non-existing actuator.

Figure 3. Relations between the WSN OpenAPI interfaces. Arrows denotethe direction in which messages are forwarded.


C. Configuration of Measurements

Measurement requests control real-time data collectionof sensor values. This way, a client does not need topoll gateway continuously. Instead, a client requests certainsensor readings by defining the measured quantity (sensortype) and how often a sensor is sampled. The gateway sendsthe measurements periodically to the client. By default, arequest is directed to the whole network but can be limitedto certain nodes. An example request is presented in Fig. 4.

The data collection depends on implementation. Ideally,a gateway adjusts sensing based on the measurement re-quests. Thus, sensors are sampled only when required whichreduces overhead in the sensor network. If the run-timemodification of data collection intervals is not possible, e.g.due to the lack of support in WSN protocols, the sensorscan be sampled at fixed intervals. Then, the gateway cangenerate measurements at specified intervals from the latestmeasurement values.

D. Sensor Alerts

Some of the collected sensor values may indicate criticalconditions that could cause loss of property, information,or lives, e.g. machine malfunction, intruder, or fire. Alertsprovide a method to identify these situations and send real-time message to the client.

Alert service is configured via NMF interface. An alertdefines a sensor type and value range that triggers a noti-fication. An alert can be targeted to the whole network orspecific sensors. An alert is delivered to the client as SIDFmessage. High level actions, such as generating an emailor SMS message, are outside the scope of the specification.However, high level messages can be generated by anotheralert service, e.g. SAS in OGC SWE, which has subscribedto the WSN OpenAPI alerts. A configuration example isshown in Fig. 5.

<SetMeasurements xmlns="urn:wsn-openapi:xml:ns:nmf" ><Measurement quantity="Temperature" interval="2"

time_unit="minute"/><Measurement quantity="Luminance" interval="1"

time_unit="minute"><Network id="1"><Node id="2"/></Network>

</Measurement></SetMeasurements>

Figure 4. Measurement request example comprising a generic temperaturerequest and luminance request targeted at a specific node.

<Alerts network="13"><Alert id="1" quantity="Humidity" min="50" max="70"/><Alert id="2" quantity="Acceleration" min="20" max="30"inclusive="false"><Node id="2"/>

</Alert></Alerts>

Figure 5. Alert configuration example. Inclusive parameter means that analert is generated when sensor value is within the defined bounds.

E. Sensor Data Collection

An example of data collection is shown in Fig. 6. Gatewayassociates the measured raw sensor values with time andquantity and forwards measurements to clients. To completethe understanding about the measurement, a client mayrequest related information from data archives, such as thecurrent sensor location and measurement unit and margin oferror.

The SIDF and SADF interfaces are used to deliver mea-surements to the client. SIDF is targeted as streaming real-time data directly from nodes, whereas SADF is designed forarchived sensor data queries. Figure 7 presents an example ofSIDF measurement in XML and CSV formats. Compared toSIDF, SADF message may include data from several nodes.A SADF request contains a time frame and can be limited tocertain measurement type, nodes, or sensors. SADF reply isgrouped based on measurement type as Network: {Time

frame, Measurement: {Node, Sensor}}} to ease re-sult handling.

Figure 8 shows an example of subscription to real-timemeasurements generated by another client. A data consumerclient defines in its request the measurements it wants toreceive. The request can be limited to specific networks,nodes, or sensors.

Figure 6. Composition of measurement related information.

<SIDF version="1.0" xmlns="urn:wsn-openapi:xml:ns:sidf"><Network id="13"><Node id="2"><Sensor id="Acceleration"><Measurement quantity="Acceleration"

unit="mg" time="2010-09-25T14:24:46+00:00"><Component id="x">142</Component><Component id="y">46</Component><Component id="z">895</Component><Component id="roll" unit="degree">8</Component><Component id="pitch" unit="degree">2</Component><Component id="total">907.36</Component></Measurement></Sensor>

</Node></Network></SIDF>

SIDF;1.0;1"13";"2";"Acceleration";2010-09-25T14:24:46+00:00;;142,46,↪→895,8,2,907.36

Figure 7. Example of sensor measurement in XML and CSV formats.The first row of CSV denotes the message type, version, and the numberof data lines.


Figure 8. Subscription to real-time measurements.

F. Actuator and Sensor Control

NASC interface controls sensor network actuators andconfigures node specific operational parameters, e.g., howsensors should collect their data. Figure 9 presents anexample of an actuator command to turn on lights.

IV. IMPLEMENTATION AND EXPERIMENTS

The interface has been verified with several practicaldeployments. In this paper, we consider two distinct usecases. In the first use case, mobile phones represent anetwork comprising only one sensor device that interactsdirectly with the WSN OpenAPI gateway. The seconduse case presents a multihop mesh network with severalTUTWSN [14] sensor nodes. The basic operation principleof TUTWSN is comparable e.g. to ZigBee as it uses similarmulti-hop low duty cycle operation.

In the implementations, the mobile phones transmit datain WSN OpenAPI format, whereas the second use case usesan adapter on the WSN OpenAPI gateway to convert nativeWSN message format to WSN OpenAPI as presented inFig. 10. In addition to the sensor devices, a user interfacewas implemented for viewing sensor data and controllingthe networks. Both the gateway and the user interface wereimplemented in Java for ease of portability.

The implementation used TCP/IP as a transport protocol.In the used approach, a TCP connection acts as a ses-sion which is initialized by sending an ACF authenticationmessage. The user privileges were stored in PostgreSQLdatabase on the gateway, and detailed users and their rightsto read sensors, control actuators, and configure networksettings. For example, when a client program requests the

<Network id="1"><Node id="2"><Commands><Actuator id="light_switch">ON</Actuator></Commands>

</Node></Network>

Figure 9. Actuator command to turn on lights on a target node.

reception of all sensor data, it only receives measurementsfrom networks, nodes, and sensors to which it has accessrights.

As message handling performance is of concern in theresource constrained devices, message parsing times wererecorded on the test setup. On test computer (Java 1.6.0_26,Windows 7, and Intel i5 M540 processor) XML parsing took0.27 ms while CSV message was decoded in 0.024 ms. Asa comparison, the same implementation on mobile phone(Android 2.2.1, 800 MHz Scorpion processor) parsed XMLand CSV messages in 10.1 ms and 0.41 ms, respectively.Thus, CSV format is especially suitable when processingpower is limited but is beneficial also in PC class deviceswhen large quantities of data need to be handled.

A. Use Case: Mobile Phone as a Sensor

Modern mobile phones are equipped with several sensors,thus allowing many sensing applications. As users almostalways carry a phone, phones can act as personal alertdevices, and allow large scale distributed sensing.

A WSN OpenAPI client for Nokia N900 mobile phonewas implemented as a Python script. The client uses CSVformat, allowing a low complexity implementation withonly 200 lines of code (LOC). The actual WSN OpenAPImessage calls took only 50 LOC while the remaining ofthe code comprised polling sensor values. This indicates thesuitability of the proposed interface for resource constraineddevices. The N900 client publishes acceleration, luminance,and GPS location information to the gateway with SIDF in-terface. Similar client was implemented in Java for Androidplatform.

From the application point of view, the WSN OpenAPI ar-chitecture allows seamless convergence of different networktechnologies: the mobile phone can be viewed as just anothernode in the sensor network. Based on the GPS information,the user interface co-located mobile phones on the same mapwith nodes from other networks as show in Fig. 11.

B. Use Case: Greenhouse Monitoring

In the greenhouse monitoring, a sensor network allowsfine grained control in environmental conditions, thus poten-tially increasing crops and saving resources as unnecessary

Figure 10. WSN OpenAPI implementation including gateway software,mobile phone sensor devices, connection to WSN, and an user interface.


Figure 11. User interface showing both dedicated TUTWSN nodes and amobile phone with current sensor values.

heating and watering are avoided. The greenhouse monitor-ing network comprised two data collecting nodes that wereconnected to the WSN OpenAPI gateway, and 28 TUTWSNnodes as shown in Fig. 12. The other data collecting nodewas used for load balancing. Nodes were equipped withtemperature, humidity, and luminance sensors that weresampled once per two minutes. The use case presented theinteroperability with an existing technology. The messagebetween the TUTWSN gateway (data collectors) and theWSN OpenAPI gateway used a proprietary binary messageformat as shown in Fig. 13.

Table I shows the typical amount of samples per daycollected from the sensor network and the amount of traffic

Figure 12. Multihop network topology in the greenhouse use case showingthe typical routes toward data collecting nodes.

Figure 13. Connectivity and the message formats in the greenhouse usecase.

required to encode the samples with different data formats. Atypical SIDF message for a sensor sample consumed 258 Bin XML and 54 B in CSV format. As a comparison, the samedata in TUTWSN binary format required 18 B. Requestinghistorical data with SADF requires 48% less space than thereal-time reception of the same data with SIDF, assumingthat the sensor data is requested in one query. Compared tothe XML messages, CSV format requires 79% and 55% lessbandwidth in SIDF and SADF, respectively.

V. CONCLUSIONS

This paper presents a sensor network architecture thatdefines a unified access for sensor data collection, actuatorcontrol, real-time alerts, and querying measurement history.Compared to binary formats, the used XML and CSV for-mats increase overhead but improve interoperability betweensystems. The structured XML messages allow applicationspecific extensions, while the more compact CSV enableefficient M2M communications.

The current interface design concentrates on the firstphase sensor networks comprising sensing and actuation.As a future work, the interface will be extended with dataprocessing components to support distributed computing insmart and autonomous sensor networks.

REFERENCES

[1] I. F. Akyildiz, S. Weilian, Y. Sankarasubramaniam, andE. Cayirci, “A survey on sensor networks,” IEEE Commu-nications Magazine, vol. 40, no. 8, pp. 102–114, Aug. 2002.

[2] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensornetwork survey,” Elsevier Computer Networks, vol. 52, no. 12,pp. 2292–2330, Aug. 2008.

Raw SIDF SADFData data XML CSV XML CSV

Temperature / node 0.012 0.167 0.035 0.085 0.038All sensors / node 0.035 0.497 0.104 0.255 0.114All sensors / network 44300 11.44 2.395 5.854 2.617

Table ITRAFFIC REQUIREMENTS OF THE WSN OPENAPI FORMATS PER DAY IN

THE GREENHOUSE USE CASE (VALUES AS MBS).


[3] E. Song and Kang Lee, “Smart transducer web servicesbased on the IEEE 1451.0 standard,” in Instrumentation andMeasurement Technology Conference (IMTC), May 1-3, 2007,pp. 1–6.

[4] P. Bonnet, J. Gehrke, and P. Seshadri, “Querying the physicalworld,” IEEE Personal Communications, vol. 7, no. 5, pp.10–15, Oct. 2000.

[5] R. Sugihara and R. K. Gupta, “Programming modelsfor sensor networks: A survey,” ACM Trans. Sen. Netw.,vol. 4, pp. 8:1–8:29, Apr. 2008. [Online]. Available:http://doi.acm.org/10.1145/1340771.1340774

[6] M. Botts, G. Percivall, C. Reed, and J. Davidson,“OGC R©sensor web enablement: Overview and high levelarchitecture,” in Second Int’l Conf., GSN 2006, Boston, MA,USA, October 1-3, 2006, Revised Selected and Invited Papers,S. Nittel, A. Labrinidis, and A. Stefanidis, Eds. Springer,2008, pp. 175–190.

[7] X. Chu and R. Buyya, “Service oriented sensor web,” in Sen-sor Networks and Configuration Fundamentals, Standards,Platforms, and Applications, N. P. Mahalik, Ed. Springer,2007, ch. 3, pp. 51–74.

[8] S. M. Fairgrieve, J. A. Makuch, and S. R. Falke, “PulsenetTM:An implementation of sensor web standards,” in Int’l Sympo-sium on Collaborative Technologies and Systems (CTS ’09),May 2009, pp. 64–75.

[9] J.-C. Liu and K.-Y. Chuang, “WASP: An innovative sensorobservation service with web-/GIS-based architecture,” in17th Int’l Conf. on Geoinformatics, Aug. 2009, pp. 1–6.

[10] J. L. Aman Kansal, Suman Nath and F. Zhao, “Senseweb: Aninfrastructure for shared sensing,” IEEE Multimedia, vol. 14,no. 4, pp. 8–13, Oct.-Dec. 2007.

[11] S. Nath, A. Deshpande, Y. Ke, P. B. Gibbons, B. Karp,and S. Seshan, “Irisnet: an architecture for internet-scalesensing services,” in VLDB ’2003: Proceedings of the 29thinternational conference on Very large data bases. VLDBEndowment, 2003, pp. 1137–1140.

[12] J. Shneidman, P. Pietzuch, J. Ledlie, M. Roussopoulos,M. Seltzer, and M. Welsh, “Hourglass: An infrastructurefor connecting sensor networks and applications,” HarvardUniversity, Tech. Rep., 2004, harvard Technical Report TR-21-04.

[13] D. Moodley and I. Simonis, “A new architecture for thesensor web: The SWAP framework,” in 5th Int’l SemanticWeb Conference (ISWC), Nov., 5–9 2006, p. 17.

[14] M. Kohvakka, J. Suhonen, T. D. Hämäläinen, and M. Hän-nikäinen, “Energy-efficient reservation-based medium accesscontrol protocol for wireless sensor networks,” EURASIPJournal on Wireless Communications and Networking, 2010,article ID 878412.


uniﬁed service access for wireless sensor networks service access for wireless... · uniﬁed...

Documents