A Wireless Sensor Network Framework Based on Light Databases

7/24/2019 A Wireless Sensor Network Framework Based on Light Databases

http://slidepdf.com/reader/full/a-wireless-sensor-network-framework-based-on-light-databases 1/23

SOFTWARE – PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2013; 43:501–523Published online 16 April 2012 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/spe.2119

A wireless sensor network framework based on light databases

Eduardo Cañete*,† , Manuel Díaz and Bartolomé Rubio

University of Málaga, Dpto. Lenguajes y ciencias de la Computación. Calle de Bulevard Louis Pasteur,

s/n. 29071 Málaga, Spain

SUMMARY

The development of wireless sensor and actor network applications is made difficult by the fact that develop-ers have to face up to a set of resource-constrained devices which have to work wirelessly and distributely. Inthis work, we propose a framework to create and integrate light databases within nodes that need to manageand process data. The databases will be designed by means of simple entity-relationship models from whichthe code needed to manage the database will be generated. Basically, this code will be composed of datastructures and the algorithms in charge of managing them. This architecture will help developers avoid dataredundancy to better manage the memory of the nodes and to save time in developing applications. Copyright© 2012 John Wiley & Sons, Ltd.

Received 19 September 2011; Revised 5 March 2012; Accepted 17 March 2012

KEY WORDS: wireless sensor network ; databases ; design ; high-level programming ; framework

1. INTRODUCTION

Wireless sensor and actor networks (WSANs) [1] are promising technology which allows users tomonitor and control any kind of scenario (indoor environment, whole cities, woods, . . . ) [2]. These

networks are composed of tiny devices which are quite resource-constrained because of their smallsize. They are normally characterized by their short-range wireless communication capabilities,short battery-life, small memory, and limited CPU processing capabilities.

One of the main issues during the development of a WSAN application is designing and imple-menting the data structures and algorithms necessary to manage the local information (clustering,routing, sensed data, ...) collected by each node which forms a part of the whole sensor network.For example, in most WSAN applications, each node manages the information of their neighbors(battery level, identifiers, RSSI, LQI, etc.) [3]. If, in addition, the developed application is based onclusters, nodes also have to manage information to know which cluster they belong to, and clusterheads would store information on which nodes are members [4].

In short, nodes have to manage a substantial amount of information, which varies on the basisof the goal of the application. We think it can be very useful to have a framework that, on the onehand, allows developers to design all the data structures needed by the nodes graphically and, on

the other hand, automatically generates the necessary codes to manage all the data structures speci-fied. This framework would facilitate the developers task as any required change in the applicationcan be performed in a graphical way, and the needed new code will be generated automatically.Developers will save a lot of time because they do not have to analyze the code to see which partmust be changed. It could be even worse if the developer who has to change the code is not thesame person who developed the application. Often, this way of working can introduce difficult to

*Correspondence to: Eduardo Cañete, University of Málaga, E.T.S.I Informática, Bulevar Louis Pasteur, 35. CampusTeatinos. Lab 3.3.2, 29071 Málaga, Spain..

†E-mail: [email protected]

Copyright © 2012 John Wiley & Sons, Ltd.



502 E. CAÑETE, M. DÍAZ AND B. RUBIO

detect side effects in the application. However, the framework would also help designers and devel-opers understand much better the behavior of the application, thanks to the graphical design of thedata structures.

In this paper, we present a framework to create light databases in charge of managing all the datastructure needed by the developers. Basically, the framework will allow developers to create a basisentity-relationship model (ERM) from which all the codes needed to manage the data structure will

be generated. This code means that developers can interact with the database information by meansof a set of primitives which will be exposed to them through an API. From the generated code pointof view, we are aware that developers are also able to implement the same code as efficiently asthe framework, but it is also true that the code written by developers is error-prone. In contrast, theframework will not only always generate the code in the same way but also future versions of theframework will be improved to be more and more efficient. Finally, we would like to emphasize thatthis framework is not thought to deal with the distributed nature of a sensor network in a direct way,but it is thought to improve the performance of each individual node which, of course, will improvethe performance of the whole sensor network.

We would like to emphasize the fact that our work is a contribution to the WSAN research fieldin the sense that it effectively provides the following innovations:

1. To the best of our knowledge, our approach is the first one that integrates light database man-

agement systems (DBMS) within sensor nodes in order to efficiently manage and structureinformation. By using light DBMS within the nodes, several advantages are achieved

– The ERM shows us not only the data structure used in the application, but it also shows usthe relationship between them.

– Avoid data redundancy. It is important as the nodes used are devices with little storagecapacity.

– Greater data integrity and independence from applications.– Improved data access to users through the use of primitives.– Reduced data entry, storage, and retrieval costs. It helps to reduce the energy consumption

of the nodes.– Facilitated development of new applications.

2. The proposed framework allows developers to graphically design the database model through

which they want to manage the data used by the nodes.3. The model designed graphically shows in real time the memory space needed by the data struc-

tures and the algorithms used to interact with them. It facilitates users to choose the best designin terms of memory constraint.

4. The code generated offers a friendly interface so that its integration with the whole applicationis easy.

5. Finally, the framework is designed so that it can be easily adapted to any WSAN operatingsystem.

The rest of the paper is structured as follows. Section 2 summarizes related work. Section 3describes the proposed architecture in creating and integrating light databases within the nodes thatcompose WSANs. Section 4 describes a case study where a smart sensor application is designed byusing our approach. In Section 5, the environment set-up used to test the framework is described,and a performance evaluation is presented. Finally, Section 6 concludes the paper.

2. RELATED WORK

Both researchers and companies are realizing that, with the passing of time, the industry and privateclients are increasingly depending on wireless sensor networks (WSN) to solve many problems thatwould be really difficult to tackle with other kinds of technologies. For this and other reasons, animportant research issue is the development of middlewares and frameworks to be able to deal withthe challenges of WSANs [5,6]. Most solutions fit into one of the following categories: tuple spacesand channel approaches, agent-based approaches, macroprogramming approaches, service-oriented

Copyright © 2012 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2013; 43:501–523

DOI: 10.1002/spe



A WIRELESS SENSOR NETWORK FRAMEWORK 503

approaches, and database-inspired approaches. As the last category is the closest approach to ourproposal, the related work is divided into two different sections: the first includes all approaches thatare not based on databases, and the second includes those that are based on databases.

2.1. Approaches not based on databases

The coordination needed in WSNs and WSANs has attracted the attention of the coordinationparadigm community. More specifically, different coordination models and middleware based onthe Linda abstract model [7] have appeared in the area of sensor networks. Linda can be con-sidered the most representative coordination language. It is based on a shared memory modelwhere data is represented by elementary data structures called tuples, and the memory is a mul-tiset of tuples called a tuple space. Examples of this type of middleware are TinyLime [8] andTeenyLime [9].

An alternative to tuple spaces is the proposal, based on the use of tuple channels, to carry out com-munication and synchronization between the nodes involved. Several advantages can be obtainedfrom the use of channels with respect to shared memory models (architectural expressiveness, datastreams in a natural and suitable way, definition of complex and dynamic interaction protocols, etc.).A example of this category is tuple channel (TC)-WSANs [10]. An agent-based model makes migra-tion decisions autonomously. The key to this approach is to make the application as modular aspossible to facilitate its injection and distribution throughout the network. One of the most impor-tant publications that follows this approach is Agilla [11]. The idea behind Agilla is to initiallydeploy a network without the need for a previously installed application. Agents that implement theapplication behavior can later be injected, effectively reprogramming the network. Because eachagent is executed autonomously and multiple agents can simultaneously run on a node, multipleapplications can coexist. Agilla presents a compromise between flexibility and power consumptionbecause of the transmission of agents by the network.

Traditional applications are composed of different programs, each of which is located in a node of the network. Applications are therefore programmed by specifying the local behavior of all nodes inour network. Proposals such as those by Kairos [12] and Regiment [13] have a different approach.Applications can be created by specifying the global behavior of the network. This behavior will be

then be translated into different pieces of code which will be used in the nodes. The programmingtasks are therefore at a higher level of abstraction.In the service-oriented paradigm category, functionality in the network is accessible as a service,

and it is in this way that communication is achieved between nodes. The programmer can specify theexecution flow by compacting these services together. The use of services provides a high level of abstraction because programmers specify behavior by creating a program that makes use of differ-ent services, but the programmers do not have to worry about the communication or protocols tasksused for this goal. These approaches can be classified in two big groups. There is a group where theservices act like real web services; one of the current approaches we can find is Tiny web services[14] and TinyWS [15]. However, the rest of the service approaches deal with the service concept ina different way. Some approaches are Oasis [16], TinySOA [17], Open Sensor-Rich Environments[18], and USEME [4]

2.2. Approaches based on databases

To the best of our knowledge, there only exists one group of approaches that make use of databaseconcepts in the area of WSANs, but in a way different than our proposal. In such approaches(TinyDB [19], SINA [20], COUGAR [21], MaD-WiSe [22], etc.), a WSAN is abstracted as a wholedatabase, which can be queried by the users to extract information.

TinyDB is a query-processing system that extracts information from the data collected by theWSAN by using the underlying operating system, TinyOS, and a controlled flooding approach todisseminate the queries throughout the network. SINA is a more complex database approach than


DOI: 10.1002/spe




TinyDB, as it not only permits SQL-like language for expressing queries but also provides otherfunctions that are beyond the scope of traditional database systems. SINA incorporates two robustmechanisms: hierarchical clustering, allowing scalability, and an attribute-based naming schemebased on an associative broadcast to manage the spreadsheets. The COUGAR system is a platformfor testing query-processing techniques over ad hoc sensor networks. COUGAR has a three-tierarchitecture: the QueryProxy, a small database component that runs on sensor nodes to interpret and

execute queries, a Frontend component, which is a more powerful QueryProxy that permits con-nections to the world outside of the sensor network, and a graphical user interface through whichusers can pose ad hoc and long-running queries on the sensor network. In MaD-WiSe [22], authorspropose a query language based on SQL to extract data from the sensor network. Unlike traditionaldatabases, MaD-Wise is not designed to process a query as fast as possible but to maximize thelifetime of the WSN, which implies minimization of the energy consumption of the queries. In[23], a model in executing optimized and efficient queries is presented. In other words, the authorshave developed an optimized spanning tree able to transport a robust estimated value reported byeach sensor node, depending on the accuracy and confidence parameters provided by the user.The main idea behind this approach is the combination of two models: an efficient Gaussian-based compression scheme that is geared towards minimizing erroneous reporting of value, anda model used to know and select which are the most appropriate data on the basis of two parame-ters provided by the user to execute a concrete query. In [24], authors combine the concept of data

moving average with the increase of the data sampling rate when a possible alarm is detected.Only in the case where the averaged value (after increasing the sampling rate) is still over thealarm threshold, actions are carried out. It helps avoid taking unnecessary actions, which couldresult in a huge waste of money. In [25], authors propose a model to mitigate the negative effectof the enrichment process needed to express and execute complex queries on a sensor networkin terms of energy and response time. This is achieved by using a transformation from the stan-dard XML extension, used to express queries on sensor data, to lower level primitives that executeon raw sensor streams. This way, the interoperability between the system program and the sensornetwork is maintained, and on the other hand, the packet size used to transport the query acrossthe sensor network is reduced. Finally, in [26], authors see the sensor network as a database. Inorder to avoid that, all sensor data are directly sent to the sink; authors propose a model to opti-mize the transport of these stream data (database queries). To achieve this, they have developed

an efficient distributed implementation to join the multiple data stream generated by the sensornodes by using a perpendicular approach (PA) which is communication-efficient and load-balancedand, in addition, incurs near-optimal communication for binary joins. According to the authors, thisis the first work to address distributed implementation of multitable join in sensor networks withmemory constraints.

The approaches mentioned are thought to help programmers in the development of WSAN appli-cations in different ways, but as a trade-off, they can only interact with the deployed sensor networksas the design of the approach used dictates. On the one hand, these kinds of approaches save thedevelopers time, but on the other hand, they have to adapt to the restrictions imposed. In contrast,our approach does not abstract the sensor networks as a database, but it allows a programmer touse light databases within the nodes that form the whole sensor network. So, developers are ableto structure the information efficiently, and in addition, they have total control over the applicationthey are developing.

3. WSAN-DATABASE FRAMEWORK ARCHITECTURE

Figure 1 depicts the proposed architecture for the WSAN-database framework. It is formed by fourmain components:

1. WSAN application types2. WSAN-ERM3. primitive selector4. code generator


DOI: 10.1002/spe




Figure 1. Wireless sensor and actor networks-database framework architecture.

Throughout the following subsections, each one of the four components will be explained in moredetail, together with a practical example based on the Contiki operating system [27].

3.1. WSAN application types

Because the goal of the framework will be to facilitate the management of data structures within aWSAN application, it is essential that the framework knows all predefined types. Obviously, thesetypes will be different depending on the chosen operating system (Contiki, TinyOS, Squawk JavaVirtual Machine, etc.) to develop the WSAN application. To deal with this issue, the different typesare organized in XML files called Contiki-Types.xml, TinyOS-Types.xml, Squawk-Types.xml, and so

on. It helps us to achieve a platform-independent framework. Within an XML file, each type isrepresented with the following structure:

The name field stores the name of the type to be modeled. The size field stores the number of bytes needed to store the information assigned to a variable, declared with the type indicated in the

name field. Finally, the format field will be used to distinguish between two kinds of types: singleand structured types. This distinction is necessary as the code used to represent each type is differ-ent, depending on its format. In the following, it is shown how two different and predefined Contikitypes are represented:


DOI: 10.1002/spe




The mentioned piece of XML code represents an integer type without a sign, whose size is 2 bytes.

On the other hand, this piece of code represents a data structure of 4 bytes which are used in Contikyto store the addresses of the nodes.

Users can also define their own types by using the predefined types and/or the other user typespreviously defined. These types will be stored in a file called OperatingSystem-UserTypes.xml, forexample, Contiki-UserTypes.xml.

3.2. The WSAN-ERM

This part of the system allows developers to graphically represent the data structures they have inmind by using a reduced ERM. Basically, the model is represented through three concepts:

1. Entity. It represents a data structure. Developers can define as many entities as they want.Each entity is composed of a name and a set of tuples which will represent the fields of thedata structure. Each tuple is composed of the following fields:

– Type. Within this field, developers can chose one of the types defined in the XML filecommented in the previous section.

– Name. In this field, developers write the desired name for the data field.– Pointer. Here, it is indicated if the data field is a pointer or not.– Unique key (UK). It indicates that there will not be two or more tuples with the same

value in the data field marked as unique key. It admits null values.– Primary key (PK). It is a special case of unique keys. The data fields (one or several)

marked as primary key will uniquely identify a tuple. It does not admit null values.2. Mote. It represents the node in charge of managing the defined data structures. This concept

can only be defined once.3. Relations. Through them, developers can specify what entities interact with other entities andwhat entities interact with the mote. Thus, the kinds of relations are– Mote-entity. It represents data structures that directly depend on the nodes. For example, if

we want to model that a node manages the information of five neighbors as MAXIMUM,we have to create the entity ‘neighbor’ and create a relationship between the mote and thisentity with a cardinality of one to five.

– Entity–entity. This kind of relationship is useful when an entity depends on other entities(nested structures).

In order to better understand the concepts explained previously, let us suppose that a WSANapplication based on groups/clusters has to be developed. So, all nodes are going to be organized ingroups where there will be nodes in charge of managing these groups. These nodes will be knownas ‘leader nodes’. Normally, these kinds of nodes are more powerful, and apart from managing thegroups, they are also in charge of receiving the data sensed by the sensor nodes that form part of their groups. Therefore, this kind of application has two kinds of nodes: leader and sensor nodes.Let us focus on the data structures the leader nodes would need in this application and how they aremodeled by using a WSAN-ERM. On the one hand, a ‘leader node’ needs to store the informationof the groups where it leads. Concretely, it needs a data structure to store the ID of the group, the IDof the place where the group is located, and information about the list of the member nodes. On theother hand, it also needs to save and manage the information sent by the sensor nodes (members).Let us suppose sensor nodes send temperature, humidity, and light data periodically at a set timeinterval. This information has to be saved in another data structure which will facilitate its analysis(data aggregation, higher values, lower values, etc.).


DOI: 10.1002/spe




Figure 2. The wireless sensor and actor networks (WSAN)-entity-relationship model (ERM).

Figure 2 shows how the data structures mentioned previously are modeled by using the WSAN-ERM in the developed framework. From the application requirements, we can identify three differ-ent entities: groups, members, and sensed data. Once these entities have been added to the model, thefollowing step is to identify the data fields associated with each one of the entities. In our example,for each entity, its data fields are

1. Group entity.

– groupId. ID of the group where the node is the leader. Furthermore, this field will be theprimary key used to uniquely identify a group entity tuple because a node can not be theleader of two or more equal groups.

– locationId. ID of the physical place where the node is located.2. Member entity.

– memberId. It is a single value used as the primary key. The following data field (memberAd-dress) could be used as the primary key instead of this field, but it is not advisable becausethe size of the ‘memberAddress’ data field is bigger than the size of the ‘memberId’. Inaddition, it is a data structure instead of a single value. Therefore, whenever possible, wewill use single values as the primary key because they might be used in auxiliary structuresto establish relationships between different entities. Furthermore, primary keys are mainlyused to find information within many tuples; so, the simpler they are, the less complex thealgorithms used to find information are.

– memberAddress. Data field used to save the address of the member node.– batteryLevel. It stores the current battery level of the member node.– registerTime. Data field used to know how recent the data of a member entity tuple is.

3. Sensor data entity.– sourceNodeId. The address of the node that the information of a ‘sensor data’ entity tuple

belongs to.– registerTime. The data field used to know how recent the data of the ‘sensor data’ entity tuple

are. In this entity, the primary key is a combination between the above field and this field.The ‘sourceNodeId’ cannot bet used as a primary because there could be several tuples withthe same ‘sourceNodeId’ but with different ‘registerTime’.


DOI: 10.1002/spe




– Temperature. The field used to store the temperature value sent by the node whose addressis the ‘sourceNodeId’.

– Humidity. It stores the humidity value.– Light. It stores the light value.

4. Relationships between entities.– Relationship mote-group. It indicates that each leader mote will be able to manage 10

different groups.– Relationship group-member. It indicates that each group will have information on 20different members, and each will be able to belong to the 10 different groups.

– Relationship Mote-sensordata. Finally, this relation is used to indicate that a leader mote willbe able to store information (humidity, temperature, etc.) of 20 different nodes.

3.3. Primitives selector

Once developers have designed the desired data model to satisfy the application requirements, thefollowing step is to create the algorithms necessary to interact with the generated data structures.Basically, the information stored in the data structures need to be created, updated or modified,and consulted or deleted. In order to facilitate the generation of these algorithms, a visual systemis proposed. It takes developers through a simple and guided process with the purpose of helping

them design the API that will be used to interact with the designed data structures. Figure 3 showswhich steps are necessary to create the API primitives. In the following, each one of these steps isexplained in detail:

1. First, the developer has to indicate what kind of primitive he or she wants to create. There arefour kinds of primitives:

– Primitives to store new data in the data structures.– Primitives to modify data already stored in the data structures.– Primitives to consult the data already stored.– Primitives to remove data.

Figure 3. Primitive-generating flow diagram.


DOI: 10.1002/spe




2. Second, a name must be assigned to the new primitive. It will be used to identify the primitivewithin the API.

3. In the third step, developers have to select those entities related with the kind of primitive theywant to create. If two or more entities are selected, they have to be related to each other as itdoes not make sense to create a primitive from two independent entities.

4. Once the previous step has been carried out, all data fields that belong to the selected entities

are revealed to the developer in order for them to select only those that are necessary to createthe primitive.5. In the fifth step, developers can either ignore it and proceed onto the next step or can carry

out two different actions: either to define the grouping fields or to define the filtering fields.This step can be repeated as many times as the user desires, thereby allowing developers todefine data filtering on data already grouped or vice versa. Let us describe what the goal of each action is

Data grouping It is useful when developers need to group data registers that have commonvalues within the same data field. For example, let us imagine we have the following tuples(1,33), (1,31), (1,29), (2,28), and (2,30), where the first value is the ID of a sensor node, andthe second one is the temperature registered by this node. A developer may wish to knowwhat the maximum temperature sensed by each node is ((1,31), (2,30)). To achieve this, he

or she has to indicate that the first field will be the grouping field and the second one mustgroup the data by choosing the highest value. Therefore, one of the data fields has to bemarked as the grouping field, and the rest of the fields have to be marked with one of thefollowing labels: MAX, MIN, SUM, . . . depending on the desired primitive.

Data filtering In this case, the developer has to select a set of constraints on the data fieldsselected in the previous step. Through these constraints, the criteria in selecting the desireddata registers are established. They are modeled by associating one of the followings ruleswith each one of the selected data fields:

Lower than (data < X ). Greater than (data > X ). Equal to (data D X ). Lower than or equal to (data <D X ). Greater than or equal to (data >D X ). Greater and lower than (X < data < Y ). Greater than and lower or equal than (X < data <D Y ). Greater or equal than and lower than (X <D data < Y ). Greater or equal than and lower or equal than (X <D data <D Y ).

6. Finally, the developers have to select the ‘action data fields’. Namely, they must indicate thedata fields they want to consult, remove, update, or add as the kind of primitive selected in thefirst step. Because the generated primitive can only return a data structure, all selected datafields must belong to the same entity. In the case when the chosen primitive is a consult , userswill have two options: the previously given option where the ‘action data fields’ are indicatedor a new option to achieve data aggregation. To achieve this, users must indicate in the fields

selected the kind of aggregation (minimum, maximum, mode, sum, etc.) they desire. In thefollowing, these two possible options are explained.

Following our example (Figure 2), let us suppose we want to create the following fourprimitives:

1. A primitive to consult those member nodes whose ‘groupId’ is X and their battery level isgreater than or equal to Y .

2. A primitive to update the ‘registerTime’ of the member node whose ID is X .3. A primitive to remove member nodes whose battery level is lower than X .4. A primitive to insert a new register with the data received from the node X .


DOI: 10.1002/spe




Figure 4 shows the steps followed in creating the first primitive in a graphical way (Figure 5 alsoshows how some of these steps are carried out using the application). As ‘memberId’ was the actiondata field selected, the primitive will return the number of members that satisfy the selection cri-terion defined in Step 4. In addition, in an external array called DATA_RESULT, a list of pointerswith the memory references to the corresponding ‘member_t’ data structures (for member entities)will be stored. We consider it is much more efficient to return a pointer list than to return a list with

the ID of the members because, through a pointer, the developer can consult any of its data fields(not only the data stores in the ‘memberId’ data field). In addition, independent of the number of different ‘consult primitives’ created and the kind of data they return, the system will only need toallocate memory in managing a pointer list. Listing 1 shows the code generated by the frameworkin creating the primitive defined in Figure 4 (data structures used are described in Section 3.4).

The signature of the primitives 2, 3, and 4 would be

int UpdateRegisterTimeMembers(long newRegisterTime, uint16_t batteryLevel) int RemoveMember(uint16_t batteryLevel)

Figure 4. Steps followed to create a consult primitive.

(a) Step 3 (b) Step 4 (c) Step 5

Figure 5. Consult primitive.


DOI: 10.1002/spe




int InsertSensedData(rimeaddr_t sourceNodeId, long registerTime, uint16_t temperature,uint16_t humidity, uint16_t light)

As mentioned before, in the case of the ‘consult primitive’, developers also have the possibilityof specifying aggregation data such as the maximum, minimum, average, sum, or mode value. Letus imagine a developer needs to know the temperature average value from the data values sent by aparticular node. He or she would have to follow these steps:

1. Create a ‘consult primitive’.2. Introduce the name of the primitive.3. Select the ‘sensor data’ entity.4. Select the data fields: sourceNodeId and temperature.5. Add to the sourceNodeId data field the value ‘equal to’.6. Associate the aggregation value AVERAGE with the temperature data field.

These steps generate a primitive that return a single value (temperature average value) instead of a set of registers. This value is not returned through the primitive but is stored in an auxiliary datastructure called DATA_RESULT, which has to be consulted by the user as long as the primitive isexecuted successfully. It is indicated through an integer returned by the primitive (see Table IV).

Another option could be to obtain the node that sent the higher temperature value. To obtain aprimitive able to obtain this information, the developer would have to follow the same steps men-tioned previously. But in this case, the ‘sourceNodeId’ data field must be selected as the action datafield, and the aggregation value must be the maximum.

The update, remove, insert, and consult primitives will return an integer that will give developersinformation about the execution of the primitive. Tables I–IV show the meaning of the code returnedby the update, remove, and insert primitives, respectively.


DOI: 10.1002/spe




Table I. Information code returned by an update primitive.

Update Primitive

Code Information-1 There was an error during the execution of

the primitive0 Number of registers that have been updated

successfully

3.4. Code generator

Once it has been shown how to define the WSAN-ERM model and how to select the API primitives,let us see how the model is translated in the source code so that it can be understood by a concreteWSAN operating system. Listing 2 shows the code generated from the model defined in Figure 2.


DOI: 10.1002/spe




Table II. Information code returned by a remove primitive.

Remove Primitive

Code Information-1 There was an error during the execution of

the primitive0 Number of registers that have been removed

successfully

Table III. Information code returned by an insert primitive.

Insert Primitive

Code Information0 The data has been inserted successfully-1 It indicates that a data tuple already exists

with the same primary key-2 Unique key error-3 There is insufficient memory

Table IV. Information code returned by a consult primitive.Consult primitive

Code Information0 The data has been selected successfully-1 There was an error during the execution of

the primitive

On one hand, a code, where three data structures similar to the entities defined in the WSAN-ERM has been generated, but an auxiliary data structure called ‘group_members_t’ has also beengenerated. These structures are needed when a WSAN-ERM contains many-to-many relations, and

thanks to them, not only the data redundancy is reduced but they also make the algorithms moreefficient. On the other hand, array structures have been also created. Through these, the cardinalitiesspecified in the relations established between the entities of the WSAN-ERM are represented.

In the generated code, we can appreciate that the size of the ‘group_members_t’ data structure is2 bytes; thus, the array structure called ‘groupMembers’ will need to allocate 2 200 bytes. Letus suppose that, in the ‘member entity’, we had selected the ‘memberAddress’ data field as the pri-mary key instead of the ‘memberId’ data field. In this case, the size of the ‘group_members_t’ datastructure would be 5 bytes, and the array structure would need to allocate 5 200 bytes, which is2.5 times more memory. Thus, developers or designers need to pay close attention when they arecreating the WSAN-ERM of their application because a bad design can have a negative impact interms of memory.

As shown in Figure 2, the framework is able to indicate in real time the memory space neededby the leader node to store the data structures generated from the WSAN-ERM. In our particularexample, the memory needed is calculated in the following way:

The size of ‘group_t’ data structure is 2 bytes. The size of ‘member_t’ data structure is 13 bytes. The size of ‘group_members_t’ data structure is 2 bytes. The size of ‘sensorData_t’ data structure is 16 bytes. ‘groups’ array needs 10 2 bytes (20 bytes). ‘members’ array needs 20 10 bytes (200 bytes). ‘groupMembers’ array needs 200 2 bytes (400 bytes). ‘sensorData’ array needs 20 12 bytes (240 bytes).


DOI: 10.1002/spe




As four arrays have been generated, four variables are needed to control the last position wherethe data was stored. These variables need 8 bytes because the size of each one of them is2 bytes.

From the mentioned information, we can conclude that 20 C 200 C 400 C 240 C 8 bytes(868 bytes) need to be allocated.

4. CASE STUDY

In order to show how this approach is able to save time for the developers, a smart sensor networkapplication that detects mildew in a vineyard is going to be modeled. Mildew is one of the mostserious and costly diseases grape growers face, and the cost-per-day of protection is a significantmeasure of fungicide performance and overall value. Mildew destroys large areas of crops in manygrowing seasons, and poor control of this disease can result in the rejection of entire grape crops bywineries. Furthermore, mildew also increases the susceptibility bunches of grapes to Botrytis andother rots. During spring, the risk increases considerably when the temperature fall within the rangeof 20 to 25 °C, and the relative humidity is higher than 80%. The detection of these parameters canbe used to send an alarm to the vineyard owner in order for them to take the necessary measures.

Both parameters, temperature and humidity, will be controlled through a set of sensor nodes

which will send the sensed values to the sink node located in the farmhouse. The sink is the nodein charge of analyzing all the data sent by the sensor nodes. Its mission is to generate the necessaryalarms which are sent to the owner of the farmland via GPRS or e-mail. As the deployment will havetwo different nodes (sensor and sink node), two different designs will be necessary. On one hand,Figure 6(a) shows the database design of the sensor nodes. This design is thought to facilitate thedevelopment of the routing protocol. Through the entity ‘NEIGHBOR NODES’, each sensor willstore information from the neighbor nodes in order to know which are located in the upper, same,and lower level (number of hops need to reach the sink). This information allows us to send thepackets from the sink to the sensor nodes and vice versa through the shortest paths. Together withthis information, parameters such as Received Signal Strength Indication (RSSI), battery level, andat what time a node registered their neighbors’ information will also be stored. The RSSI and batterylevel are used in order to have two different routing protocols: (i) routing sensitive to the RSSI and

(ii) routing sensitive to the battery level. The goal of the former is to achieve a more reliable rout-ing, and the goal of the latter is to achieve a uniform distribution of the energy consumption. Theentity ‘CONTROL INFORMATION’ will store the kind of routing that it is going to be executedand the level (distance to the sink) where the node is located. On the other hand, Figure 6(b) showsthe database design used for the sink node. Through this design, the sink will be able to store andcontrol the information of 20 sensor nodes. The sink will know the level (distance) where each nodeis located, its address, and the timestamp when the information of the sensor node was updated forthe last time. The relation SENSOR NODES, SENSED DATA, allows the sink node to store up to15 data tuples for each one of the 20 sensor nodes.

(a) Software design of the sensor nodes (b) Software design of the sink node

Figure 6. Software design as a kind of node.


DOI: 10.1002/spe




These graphical designs not only allow us to understand what information is going to be managedby the nodes at first sight, but also all the necessary codes to manage the information represented bythem will be automatically generated.

In the following, the code generated by the framework from the data structures previously com-mented on is shown in Listings 3 and 4. From another point of view, this is the code developers donot have to worry about, as it will be automatically generated by the framework.

Let us see what the difference would be in terms of code if developers had to write the code forthe sink (see the code shown in Listing 5).

In this code, it can be clearly seen that in contrast to the code generated by the framework, the datafields ‘sensorNodeId’ and ‘sensedDataId’ have not been used because both entities (data structures)are related using a nested structure. Although it is possibly the most intuitive way to represent thesedata structures, it is also the most inefficient way because the memory allocation for the data tupleof a sensor node evolves into the memory allocation to manage 15 data tuples of the sensed data bythe node.

The code mentioned is not only clearer, but also the memory allocation problem is avoided. Itis achieved by relating the data structures through the primary keys. As we can see in the code,the primary key of the ‘sensorNode_t’ data structure has been migrated to the ‘sensedData_t’ data

structure.Of course, developers will also have to write the necessary algorithms to obtain, store, update,or remove information from the data structures. Let us suppose that developers need the followingalgorithms:

1. An algorithm for the sensor nodes to register a new neighbor node located in the upper level.2. An algorithm for the sensor nodes to update the information of the neighbor nodes located in

an upper level.3. An algorithm for the sensor nodes to know where the neighbor node with the higher battery

level located in the upper levels of a particular node is. This operation will be used by therouting protocol.


DOI: 10.1002/spe





DOI: 10.1002/spe




4. An algorithm for the sensor nodes to delete a specific neighbor node located in the upper level.5. An algorithm for the sink node to register the sensor nodes of the wireless sensor network.6. An algorithm for the sink node to register the sensed data received from a particular

sensor node.7. An algorithm for the sink node to obtain the average temperature from all sensed data.8. An algorithm for the sink node to obtain the average temperature from all sensed data by a

particular sensor node.9. An algorithm for the sink node to know the average temperature sensed by the sensor nodes byusing the most up to date values. It will help the developers know if the average temperaturefalls within the range of 20–25°C.

10. An algorithm for the sink node to obtain those network nodes with a battery level higher thana given threshold.

Table V shows the signature of the primitive previously described.In the following, the process to generate some of the primitives previously mentioned is described

step by step:

For primitive 3,1. Create a ‘consult primitive’;

2. Primitive name, ‘upperLevelNodeWithHigherBattery’;3. Select ‘NEIGHBOR NODES’. As there are three different relationships between the moteand the entity, it is necessary to select the correct one. In this case, the relation called‘upperLevelNodes’ will be selected;

4. Select ‘batteryLevel’ data field;5. Do not select any selection criteria;6. Select ‘nodeAddress’ as the action data field;7. Associate with the ‘batteryLevel’ data field the aggregation value MAXIMUM.8. Generated primitive: int GetUpperLevelNodeWithHigherBattery().

For primitive 9,1. Create a ‘consult primitive’;2. Primitive name: ‘AverageTemperatureAsTime’;3. Select ‘SENSOR NODES’ and ‘SENSED DATA’ entities;4. Select ‘sensorNodeId’, ‘temperature’, and ‘measureTime’ data fields;5. Select as grouping data, the ‘sensorNodeId’ data field, and to obtain the most up to date

value, the ‘measureTime’ data field must be marked with the label MAX;6. Associate with the ‘temperture’ data field the aggregation value AVERAGE;7. Generated primitive: int GetAverageTemperatureAsTime().

And so on.

Listings 6 and 7 show the code generated by the framework used to add to the API the twoprimitives mentioned previously.

Table V. Signature of the generated primitives.

ID Primitive

1 int insertNodeUpperLevel(const rimeaddr_t *node, uint16_t rssi, uint16_t batteryLevel)2 int updateNodeUpperLevel(const rimeaddr_t *node, uint16_t rssi, uint16_t batteryLevel)3 int GetUpperLevelNodeWithHigherBattery()4 int deleteNodeUpperLevel(const rimeaddr_t *node)5 int insertNetworkNode(const rimeaddr_t *node, int dist, long lastUpdate, uint16_t batLevel)6 int insertDataSensedByNetworkNode(const rimeaddr_t *n, uint16_t t, uint16_t h, long mTime)7 int GetAverageTemperature()8 int GetAverageTemperatureAsNode(const rimeaddr_t *node)9 int GetAverageTemperatureAsTime()10 int GetNetworkNodesWithBatteryLevelHigherThan(uint16_t batteryLevel)


DOI: 10.1002/spe





DOI: 10.1002/spe




5. EVALUATION

In order to analyze and study the performance of the framework presented in this article, both datastructures obtained from the database model represented in Figure 6 and their respective primitivesgenerated in an automatic way (see Table V) are evaluated in terms of memory occupation, compiledcode footprint, energy consumption, and CPU activity time.

5.1. Environment set-up

The COOJA sensor network simulator [28] has been used to carry out all the experiments. COOJAis a power profiling tool that enables accurate network-scale energy measurements in a simulatedenvironment. The COOJA simulator offers the possibility of carrying out the simulation in differentplatforms. We selected the TelosB motes because they are one of the most used by the sensor netcommunity. In order to carry out the simulations, we used Contiki [27] which is an open source,highly portable, multitasking operating system for memory-efficient networked embedded systemsand wireless sensor networks. In the following sections, each one of the experiments carried out areexplained in more detail.

We would like to lay stress on COOJA which allows us to carry out very realistic simulationsbecause of the fact that through COOJA, the sensor node software can be run in a sensor node

emulator that emulates an actual sensor node at the hardware level.

5.2. Evaluation of the generated data structures

Table VI shows the memory occupation and the compiled code footprint of the data structures usedas examples throughout of the paper. One of the advantages of this framework is that the users seein real time the memory occupation of the generated data structures. If the data structures are ana-lyzed, we observe that both memory occupation and compiled code footprint values are normal. Inother words, in spite of the fact that the code is automatically generated, the table shows the frame-work only generates the code when strictly necessary. This is well reflected in the last two rows of the table where the penultimate and ultimate rows show the memory occupation and compiled codefootprint of the same data structure (see Figure 6(b)) generated in an automatic and customized way,respectively. These data show three positive things:

1. The memory occupation of the data structure generated by the user in a customized way is36 bytes higher than the structure generated by the framework. This shows that this valuedepends on the cardinality defined between the entities specified in the data structure, so thatthe bigger the cardinalities are, the bigger the difference between the memory occupationneeded by the data structure generated in a customized and automatic way.

2. The compiled code footprint is practically the same, and unlike the memory occupation, it isindependent of the cardinalities defined between the entities specified in the data structure.

3. The compiled code footprint of both structures also show that the framework does not generateunnecessary code.

5.3. Primitives compiled code footprint

Figure 7 shows the compiled code footprint used by each one of the primitives described in Table V.All footprints are within normal limits. In the case of primitives 4, 5, and 6, we think the code

Table VI. Data structure evaluation.

Memory occupation Compile code footprint(bytes) (bytes)

Data structure (Figure 2) 868 712Data structure (Figure 6(a)) 608 528Data structure (Figure 6(b)) 3890 424Data structure (Figure 6(b)) (custom) 3926 408


DOI: 10.1002/spe




generated uses an instruction that depends on a Contiki external library, so that the final footprint isthe sum of the external library and the primitive footprint. In the case when creating these primitivesin a customized way, the instructions dependent on external libraries would also be necessary.

5.4. CPU activity time and energy consumption

Figures 8 and 9 show the CPU activity time and the energy consumption of the primitives shown inTable V when they are executed. Obviously, the energy consumption is directly related to the time a

Figure 7. Compiled code footprint.

Figure 8. CPU activity time.

Figure 9. Energy consumption.


DOI: 10.1002/spe




primitive needs to be executed. Both figures present the evaluation of the primitives in the best andworst case. In terms of code, best and worst case means the execution of a primitive where an arrayof size N has to process one or N elements, respectively. Several conclusions can be drawn fromFigure 8:

Primitives generate for the sensor nodes

For primitives 1 and 2 (insert and update), it is logical that they take the same time to beexecuted because in both cases, they process the array in the same way. The only differencebetween primitive 1 and 2 is that one inserts an element and the other updates it.

In spite of the fact that primitive 3 has to process the same array as primitives 1 and 2, it needsa little less time because it only has to find an element and return it instead of updating orinserting all their attributes (RSSI, batteryLevel, lastUpdate, . . . ).

For the worst case, primitive 4 takes more time than primitives 1, 2, and 3 because when anelement is removed, all the elements stored in the next positions of the array have to be movedone position to the left.

Primitives generated for the sink

Primitive 6 inserts a data tuple in the ‘sensed data’ entity, which is related to the ‘sensor nodes’entity. Thus, before inserting this tuple, the foreign key that relates the data tuple with the sen-sor that generated them must be found within the ‘sensor nodes’ entity. In contrast, primitive5 directly inserts the data tuples in the ‘sensor nodes’ entity. For this reason, primitive 6 takesmore time than primitive 5 in both the best and worst cases.

Primitives 7, 8, and 9 obtain the average temperature in three different ways. Primitive 7 cal-culates it by analyzing all the sensed data tuples generated by all the sensors nodes. Thiscalculation is quick as it is not necessary to apply any data filter. For this reason, the bestand worst cases of this primitive are better than the times of primitives 8 and 9. In the caseof primitive 8, the difference of these times is because the average temperature is calculated

depending on a particular node. It means that the system has to look for the primary key of thedesired node within the ‘sensor nodes’ entity and then filter the data tuples of the ‘sensed data’entity, depending on this primary key. Primitive 9 is quite special in terms of execution. In spiteof the fact that it only needs to look for information within a data structure, it takes more timethan the other primitives. This is because to obtain the average temperature from the most upto date data, all data tuples have to be compared with each other.

Although the primitives 10 and 3 are executed over different data structures, their executionsare similar. For this reason, their CPU activity times are equal.

6. CONCLUSIONS

In this article, we have proposed an architecture that allows developers to create and integrate lightdatabases within the nodes that form part of a WSAN. A framework based on this architecture canhelp developers of WSAN applications in many ways. It will require less development time, appli-cations will be more energy-efficient, and developers will be able to easily adapt to any requirementchanges of the data model. Furthermore, the architecture permits the creation of a framework inde-pendent of the platform; thus, a design could generate code for nodes based in different operatingsystems. Also, a smart application that detects mildew disease in vineyards has been designed byusing this framework approach. It highlights the benefits of using this framework approach to designsmart sensor network applications. Finally, the performance evaluation of the framework shows thatthe generated code in terms of memory occupation, compiled code footprint, CPU activity time, andenergy consumption is efficient.


DOI: 10.1002/spe




7. ACKNOWLEDGEMENTS

This work was partially supported by European Project SEEDS FP7-285250 and Spanish ProjectsP07-TIC-03184, TIN2008-03107, TIN2011-23795 and TIC-03085.

REFERENCES1. Akyildiz IF, Kasimoglu IH. Wireless sensor and actor networks: research challenges. Ad Hoc Networks 2004;

2(4):351–367.2. Gehrke J, Liu L. Sensor-network applications. IEEE Internet Computing 2006; 10(2):16–17.3. Wenning BL, Pesch D, Timm-Giel A, Görg C. Environmental monitoring aware routing: making environmental

sensor networks more robust. Telecommunication Systems 2010; 43(1):3–11.4. Cañete E, Chen J, Díaz M, Llopis L, Rubio B. A service-oriented approach to facilitate WSAN application

development. Ad Hoc Networks 2011; 9(3):430–452.5. Wang M, Cao J, Li J, Das SK. Middleware for wireless sensor networks: a survey. Journal of Computer Science and

Technology 2008; 23(3):305–326.6. Rubio B, Diaz M, Troya JM. Programming approaches and challenges for wireless sensor networks. In ICSNC ’07:

Proceedings of the Second International Conference on Systems and Networks Communications . IEEE ComputerSociety: Washington, DC, USA, 2007; 36–43. DOI: 10.1109/ICSNC.2007.63.

7. Gelernter D. Generative communication in linda. ACM Transactions on Programming Languages and Systems 1985;7(1):80–112.

8. Curino C, Giani M, Giorgetta M, Giusti A, Murphy AL, Picco GP. TinyLime: bridging mobile and sensor net-works through middleware. In Proceedings of the 3rd IEEE International Conference on Pervasive Computing and

Communications (PerCom 2005). IEEE Computer Society Press: Kauai Island (Hawaii, USA), 2005; 61–72.9. Costa P, Mottola L, Murphy AL, Picco GP. TeenyLIME: transiently shared tuple space middleware for wireless sen-

sor networks. In Proceedings of the 1st International Workshop on Middleware for Wireless Sensor Networks (Mid-

Sens 2006), co-located with the 7th International Middleware Conference (Middleware’06). ACM Press: Melbourne,Australia, 2006; 43–48.

10. Barbarán J, Díaz M, Iñaki E, Garrido D, Llopis L, Rubio B, Troya JM. Programming wireless sensor and actornetworks with TC-WSANS. In IEEE International Conference on Pervasive Services, ICPS’07 . IEEE ComputerSociety: Istanbul, Turkey, 2007; 196–203.

11. Herbert J, Ling G, Fei K. Mobile agent architecture integration for a wireless sensor medical application, 2006.12. Gummadi R, Gnawali O, Govindan R. Macro-programming wireless sensor networks using kairos, 2005.13. Newton R, Morrisett G, Welsh M. The regiment macroprogramming system. In IPSN ’07: Proceedings of the

6th International Conference on Information Processing in Sensor Networks. ACM: New York, NY, USA, 2007;489–498. DOI: 10.1145/1236360.1236422.

14. Priyantha NB, Kansal A, Goraczko M, Zhao F. Tiny web services: design and implementation of interoperable andevolvable sensor networks. In SenSys ’08: Proceedings of the 6th ACM Conference on Embedded Network Sensor

Systems. ACM: New York, NY, USA, 2008; 253–266. DOI: 10.1145/1460412.1460438.15. Othman NY, Glitho RH, Khendek F. The design and implementation of a web service framework for individual

nodes in sinkless wireless sensor networks. In Proceedings of the IEEE International Conference on Computers and

Communications (ISCC’07). IEEE Computer Society Press: Aveiro, Portugal, 2007; 941–947.16. Kushwaha M, Amundson I, Koutsoukos X, Neema E, Sztipanovits J. Oasis: A programming framework for service-

oriented sensor networks. In Proceedings of the 2nd International Conference on Communication Systems Software

and Middleware: Bangalore, India, 2007; 941–947.17. Rezgui A, Eltoweissy M. Service-oriented sensor-actuator networks: promises, challenges, and the road ahead.

Computer Communications 2007; 30:2627–2648.18. Liu J, Zhao F. Composing semantic services in open sensor-rich environments. IEEE Network 2008; 22(4):44–49.19. Madden SR, Franklin MJ, Hellerstein JM, Hong W. Tinydb: an acquisitional query processing system for sensor

networks. ACM Transactions on Database Systems 2005; 30:122–173. DOI: 10.1145/1061318.1061322.20. Shen C-C, Srisathapornphat C, Jaikaeo C. Sensor information networking architecture and applications. IEEE

Personal Communications 2001; 8(4):52–59. DOI: 10.1109/98.944004.21. Yao Y, Gehrke J. The cougar approach to in-network query processing in sensor networks. SIGMOD Record 2002;

31:9–18. DOI: 10.1145/601858.601861.22. Amato G, Chessa S, Vairo C. Mad-wise: a distributed stream management system for wireless sensor networks.

Software: Practice and Experience 2010; 40:431–451.23. Meliou A, Guestrin C, Hellerstein JM. Approximating sensor network queries with in-network summaries. Technical

Report UCB/EECS-2008-137 , EECS Department, University of California, Berkeley, 2008.24. Liu K, Chen L, Liu Y, Li M. Robust and efficient aggregate query processing in wireless sensor networks. Mobile

Networks and Applications 2008; 13:212–227.25. McCann D, Roantree M. A query service for raw sensor data. In Proceedings of the 4th European Confer-

ence on Smart Sensing and Context (EuroSSC’09). Springer-Verlag: Berlin, Heidelberg, 2009; 38–50. DOI:1813042.1813048.


DOI: 10.1002/spe




26. Zhu X, Gupta H, Tang B. Join of multiple data streams in sensor networks. IEEE Transactions on Knowledge and

Data Engineering 2009; 21(12):1722–1736.27. Dunkels A, Gronvall B, Voigt T. Contiki—a lightweight and flexible operating system for tiny networked sensors.

In Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN ’04) . IEEEComputer Society: Washington, DC, USA, 2004; 455–462.

28. Eriksson J, Österlind F, Finne N, Dunkels A, Tsiftes N, Voigt T. Accurate network-scale power profiling for sensornetwork simulators. In Wireless Sensor Networks, Vol. 5432, Roedig U, Sreenan C (eds), Lecture Notes in Computer

Science. Springer: Berlin / Heidelberg, 2009; 312–326.

A Wireless Sensor Network Framework Based on Light Databases

Documents

Transcript of A Wireless Sensor Network Framework Based on Light Databases