Dison Adhoc2012

8/14/2019 Dison Adhoc2012

1/15

DISON: A Self-organizing Network Management

Framework for Wireless Sensor Networks

Trang Cao Minh, Boris Bellalta, and Miquel Oliver

Universitat Pompeu Fabra, Barcelona, Spain{trang.cao,boris.bellalta,miquel.oliver}@upf.edu

Abstract. Wireless sensor networks have wide applications in many ar-eas from detecting enemy targets in the military to monitoring patienthealth or water/gas usage in the civil. However sensor devices are usuallyequipped with a limited power battery and deployed at a very high den-sity in inaccessible environments. Therefore, it is impractical to changeor maintain manually these sensor networks. In this paper, we have de-signed and implemented a general and extendable management frame-work called DIstributed Self-Organizing NEtwork management (DISON)

framework to provide an autonomous management mechanism for WSNs.In DISON, sensor nodes exploit local knowledge or cooperate with othernodes to coordinate and adapt management and application tasks ef-fectively according to their capabilities. To verify the efficiency of theproposed framework, we have evaluated DISON in a data collection ap-plication scenario, where DISON is used to optimize the number of activenodes. The simulation results show that running DISON reduces the en-ergy consumption up to 30%, and also improves other key parameterssuch as the packet delivery rate and the end-to-end delay.

Key words: network management, wireless sensor networks, self orga-nizing

1 Introduction

With the rapid development of technologies in IC (Integrated Circuit) andMEMS (Microelectromechanical systems), Wireless Sensor Networks (WSNs),networks of tiny sensor devices, have been extensively used nowadays in variousapplications such as target tracking, habitat monitoring and many others. How-ever, sensor nodes have very limited power and resource constraints. Thereforethey are prone to fail. The sensor failure may cause changes in network topologyand affect the quality of offered services. Moreover, sensor nodes can be deployedin a large number of nodes and in inaccessible environments depending on theapplication. Thus, the manual replacement of failed sensor nodes is impossibleor expensive. To cope with these challenges, the development of self-organizingmanagement functionalities in WSNs is desirable.

Due to the limited resource nature of sensor nodes, a management systemfor WSNs needs to be lightweight, autonomous and scalable. In addition, therequirements of WSN applications are expected to evolve over time. Therefore a


2/15

2 Trang et al.

WSN management system should be able to adapt the network operations notonly to the network state, but also to the changes in application requirements.Moreover, it is complex and not efficient to develop an adaptive managementsystem for each application or each hardware platform. Hence, it is required to

develop a management system that supports various applications and platforms.Many network management architectures for WSNs have been designed. Ruiz

et al. [7] describes MANA, a generic architecture for managing WSNS. In MANA,management services are distributed to some manager nodes and agents. There-fore it is required to have a specific mechanism to distribute efficiently theseagents. The delay when performing a management task is also an issue in largescale networks since manager nodes need to wait agents visit sensor nodes. Somepolicy based management approaches are introduced in [2], [5]. In [2], Cha etal. proposed a hierarchical framework in which the base station is responsiblefor interpreting high level management policies and distributing them to sensornodes. These policies are applied locally on sensor nodes as soon as the nodestate matches the policy condition. Therefore their approach requires the basestation to maintain the up-to-date global view of the network which is not al-

ways available, especially in large scale networks. Le et al. [5] proposes threelevel management policies to distribute management tasks to the base station,cluster heads and sensor nodes. However, in their approach management poli-cies are represented in the high level XML language [1] at the base station, andinterpreted to the machine code at sensor nodes.

In [9], the authors divided the network into multiple clusters in which eachcluster has a gateway node that organizes and manages network operations basedon application requirements and the available energy in sensor nodes. However,their approach mainly focus on finding data relay routes and arbitrating mediumaccess. A hybrid management solution is presented in [6]. WinMS [6] allows in-dividual sensor nodes to perform management functions locally based on thenetwork state of their neighbors. In addition, the base station works as a centralmanager to store, analyze the global state of the network and execute manage-

ment maintenance operations if it detects any interesting event. Thus, WinMSalso has the issue similar to [2] when the number of nodes increases. Some policy-based management systems are also presented in [12], [8]. However, there aresome issues which are not covered by the existing approaches. First, there is nowork on defining in detail management data models or management mechanismsused in sensor nodes. Second, the capability to adapt to the changes in applica-tion requirements is not completely taken into account in current managementapproaches.

In this paper, we propose a DIstributed Self-Organizing NEtwork manage-ment (DISON) framework that provides the autonomous management mecha-nism to allow sensor nodes to self configure and adapt to the changes in applica-tion requirements, resources and network state. In DISON, sensor nodes performmanagement tasks at different level according to their resources. Sensor nodeswith limited resources exploit their local knowledge to reconfigure their opera-tions and provide management information for other nodes. In case of nodes that


3/15

DISON: A Self-organizing Network Management Framework for WSNs 3

have more resources (ex. more powerful battery or larger memory etc.), morecomplex management tasks can be performed by them. Some examples are co-ordinating application tasks among a set of nodes and collecting managementdata from a set of nodes to detect if there is any problem and reconfigure them

if needed. Sink nodes or base stations which are normally connected to largepower suppliers and have strong computing capacity are responsible for globalmanagement tasks such as topology management and disseminating new codeto support new management tasks.

We have implemented and evaluated DISON framework in SENSE simulator[3] to organize active sensor nodes in a data collection application. Our simulationresults show that DISON can reduce the energy consumption, up to 30%, andimprove other network performance metrics such as the packet delivery rate andthe end-to-end delay.

The rest of the paper is organized as follows. In Section 2, we describe theDISON system overall. Section 3 presents the detail of the DISON Manage-ment components. Section 4 presents the scenario in which DISON is evaluated.In Section 5 we show and discuss the simulation results. The conclusions are

presented in Section 6.

2 DISON Framework

Since wireless sensor networks can be deployed with a large number of nodes,central management systems are not suitable for WSNs due to the delay to takemanagement decisions and distribute them, and the traffic congestion at nodeswhich are close to the central manager. The distributed management solutionsalso have drawbacks. Due to the limited energy battery and resources, sensornodes can not do complicated processing. Therefore it is essential to use a hybridsolution for management in WSNs. Every sensor node should have the ability todo simple local management tasks while complex management decisions should

be only performed by some powerful nodes.In this article, we have developed a hybrid self-organizing management frame-

work for WSNs. Nodes in the network can have different roles in performingmanagement tasks based on theirs capabilities. In our framework, we definethree types of management roles: Self Manager (SM), Group Manager (GM)and Network Manager (NM). A SM role contains abilities to control, regulateand adapt the nodes behavior in accord with the changes in application re-quirements, the nodes resources and the neighborhood information. The GMrole is used to achieve an effective utilization of the resources in a set of nodesby coordinating nodes capability. The GM role is normally performed by nodesthat have rich resources and energy. The NM role is used to manage the wholenetwork. For example, it stores the network topology or decides the nodes thathave the GM and the SM role. Therefore the NM role should be performed bythe base station. The GM role is normally assigned to some sensor nodes whichhave rich resources while the SM role should be performed by every node. Beaware that a sensor node can have more than one management role (e.g SM and


4/15

4 Trang et al.

Fig. 1. DISON System Overview

GM) if it has enough resources. Figure 1 depicts our proposed framework. Thenetwork is divided into multiple sets of nodes. Each set of nodes are managed bya node with the GM role, called Manager node. The whole network is managedby Base station with the NM role. Every nodes are assigned SM role. If the nodeonly has SM role, it is called Normal node.

Only the GM role needs to be distributed through the WSN in an efficientway. One distributing approach is using central servers (base stations) to assignthe GM role to a certain group of nodes based on the network topology. Thisapproach is efficient for networks which have a fixed topology and a small numberof nodes. Another approach is the use of clustering algorithms [4][10]. The chosencluster heads, which are elected by using a clustering algorithm, are suitableto role as Manager nodes. Since the clustering algorithms do not make any

assumptions about the presence of infrastructure, they are useful for networksthat do not have a fixed and stable topology, a common case in wireless sensornetworks.

In this article, we focus on the design of a WSN architecture that have GMand SM roles. We propose a new protocol stack for the sensor nodes as illustratedin Figure 2. The first element, Hardware APIs, provides access interfaces tothe controller, communication devices, storage resources, sensors and the powersupply of the sensor node. Examples of these interfaces are switch on/off thenode, read/write the memory, switch on/off the radio. The second element ofthe DISON node is the Communication Protocols that govern data transmissionthrough wireless channel by using the Hardware APIs interfaces. In the Commu-nication Protocols, several protocols are implemented: MAC, routing, locationand time synchronization. The MAC protocols provide nodes a way to transfer

data packets with neighbors and make wakeup/sleep schedules. The routing pro-tocols specify how packets are transmitted to the sink or the base station. Thelocation protocols supply absolute or relative positions of node by using attached


5/15


Fig. 2. Protocol Stack of a sensor node in DISON framework

GPS devices or location algorithms. The time synchronization protocols providelow power methods of synchronizing clocks among nodes in network. The third

element is Application. It is responsible for sending sensor data and receivinguser requests by using communication protocols. It can also access the inter-faces in Hardware APIs component to trigger sensors and receive sensing data.The last element is DISON Management. This element provides mechanisms toanalyze the changes in application requirements, nodes resources, and networkstate to reconfigure the communication protocols and the application if neededto ensure the required quality of service or to prolong network lifetime.

3 DISON Management Components

This section presents further details on the DISON Management part of the pro-

posed protocol stack. As illustrated in Figure 3 there are three main components:Context Establishment, Policy based Reasoning and Controlling Response. TheContext Establishment component is responsible for extracting meaningful con-texts from the raw data such as application requirements, the nodes residualenergy or the packet error rate. In our framework, a meaningful context is theinformation that affects nodes operations. Based on the meaningful context ex-tracted by the Context Establishment component, the Policy based Reasoningcomponent selects a set of policies that govern node behaviors or network op-erations. The Controlling Response component is responsible for executing theactions indicated in those policies. It is important to note that only the basicfunctions of the DISON architecture are implemented in each node at the ini-tialization. When there is a change on a nodes resources or in the network state,a node can request to the base station or other nodes to provide it with new

functions to ensure that it can complete the management tasks it has assigned.


6/15

6 Trang et al.

Fig. 3. DISON Components and Process

3.1 Context Establishment

The main goal of the Context Establishment (CE) component is to form themeaningful context from the given current raw data. In order to accomplish thisgoal, the CE component predefined context formats are stored in the ContextDatabase. Using these formats, the sub component Context Interpreter recog-nizes the context values, handles missing values, removes redundant data andfinally forms the requested context. Then the resulting context is transmitted tothe Policy based Reasoning component.

As shown in Figure 3 there are three sources that produce context informa-tion: Node Information which is the information about sensing capabilities,the residual energy, the memory status, the node location and the radio state;

Application Requirementswhich include the query information such as whattypes of sensing data are needed, when it needs to collect data, the data samplerates, and how long data is collected; Network State which includes some net-work performance metrics such as the transmission delay and the packet errorrate and the neighborhood information such as the number of neighbors andtheir information. Due to the limited resources of sensor nodes, the context rep-resentation scheme and the context interpreter mechanism need to be simple butefficient. To achieve this, we model the context which are stored in the ContextDatabase as follows

[CONTEXT ID] [INFORMATION TYPE] [INFORMATION ID] [INFOR-MATION VALUE]

where CONTEXT ID is the unique identifier of the context, INFORMA-TION TYPE describes the source of the raw information; INFORMATION ID

represents the identifier of each specific information such as the sensing capabil-ities, the residual energy, etc; and INFORMATION VALUE is the value of thatspecific information in bits. This model ensures that the context is stored and


7/15


Sensor Type Bits Meaning

NO SENSOR 0000000 No sensor is enabled

TEMPERATURE 0000001 Temperature sensor is enabled

LIGHT 0000010 Light sensor is enabled

HUMIDITY 0000100 Humidity sensor is enabled

ACCELEROMETER 0001000 Accelerometer sensor is enabled

MAGNETOMETER 0010000 Magnetometer sensor is enabled

MICROPHONE 0100000 Microphone sensor is enabled

SOUNDER 1000000 Sounder sensor is enabled

Table 1. Sensing Capability Value

queried efficiently based on the characteristic of each source of raw informationand the information itself. For example, assume that we use 2 bits to representthe information type, 3 bits for the information identifier in case of the Node

Information source, 7 bits for representing which type of sensors in a node areactive (referring to Table 1), the temperature sensor is on context is rep-resented as 01 001 0000001. From the Table 1, it is easy to see that each positionin 7 bits corresponds to one sensing ability. Therefore, to enable a sensing abil-ity, we just need to turn on the bit at the corresponding position. For example,01 001 0000011 means temperature and light sensors are on.

In case of complex contexts, the Context Interpreter analyzes and extractsthe meaningful context from the input data. For example, let us consider thatthe node receives a query that requests to collect temperature during 10 secondswith a frequency of 2 seconds. After analyzing the query, the above context isrepresented as 10 001 0000001101010 where 10 indicates that the informationis an Application Requirement, 001 indicates that the application is a query,the array of bits 0000001101010 contains the sensing type, the query period and

the sampling frequency. In order to prevent any waste of memory resources, welimit the number of contexts each node can have according to its managementrole. Nodes with the SM role will have less contexts than nodes with the GMrole. The Context Manager in the CE component is responsible for adding newcontexts or removing old contexts if the number of contexts reaches a predefinedthreshold.

3.2 Policy-based Reasoning

The second component of DISON Management, Policy-based Reasoning (PBR),is responsible for determining whether, or which respectively, actions should betaken referring to the changes in nodes state, network conditions or applicationrequirements. It is essential to see that in this scenario the rule based policysolution appears naturally. In general, a rule based policy system is to decidethe set of actions to be executed in a given situation based on rules. The advan-tage of rule-based solutions is their flexibility. Rules can be modified and added


8/15

8 Trang et al.

at application runtime with no need for code recompilation. Due to the hetero-geneous characteristics of sensor networks, it is beneficial to use a mechanismthat offers such flexibility for the reasoning process. Therefore we have built ourreasoning mechanism based on a rule-based system. We form a rule based policy

in the Policy Database as the following formula:[SET OF CONTEXTS] [SET OF ACTIONS]The left hand side of a policy includes identifiers of contexts (CONTEXT ID)

which is combined by conditional elements such as AND, OR, NOT, etc. Theright hand side is the set of actions to be executed when the policy is applied.Each action is represented by a couple (ActionID, Parameters) where ActionIDis the identifier of the action (e.g. reconfiguring networks, route discovery ...) andParameters is the list of the parameters used by the action. For example, whena node receives a query that requests to collect temperature, it needs to turn onthe temperature sensor to collect data and start the communication protocolsto transmit the data to the sink. To support that scenario, a policy is definedas 0001 0001 1 0000001 in which, the first 0001 is the identifier of the contextTEMPERATURE IS ON, the second 0001 indicates the hardware function that

needs to execute is the switching sensor, 1 0000001 are parameters providedto the switching sensor function (e.g 1 means switch on and 0000001 meanstemperature sensor).

When receiving the context from the Context Establishing component, theReasoning System queries the list of policies in Policy Database that matches tothe context. Utilizing the query results, it chooses which policies have to be ac-tivated. If one of the existing policies satisfies completely the context, it extractsthe list of actions in the policy and sends them to the Controlling Response.Otherwise, it gets the default policy that includes actions such as ignoring thiscontext or asking support from other nodes. Similar to the CE component, thePBR component also limits the number of policies and the complexity of thereasoning system according to the node management roles. Nodes with the GMrole have more policies and more powerful reasoning systems.

3.3 Controlling Response

As soon as receiving the list of actions to be executed from the PBR component,the subcomponent Execution Engine maps the actions with the managementfunctions it supports and executes them. The Management functions elementincludes the local functions that control hardware devices and protocols thatimplement the cooperative management tasks. The Management Database isused to store buffers and variables used in management tasks.

4 A Data Collection Scenario

In this section we apply the proposed DISON framework to resolve a populardata collection application scenario in WSNs. In this scenario we consider a


9/15


WSN in which sensor nodes are randomly deployed in a square or rectanglearea. We assume that sensor nodes have different energy and sensing capabilities.For example, some nodes can have both the temperature and the light sensorwhile other nodes only have the temperature sensor. A sink node (base station)

broadcasts a query to network at specific times to collect sensing data. A queryincludes three parameters: types of sensing data, the sampling frequency andthe collecting period. The types of sensing data is encoded based on the Table1. For example, a query to collect light and temperature every 10 seconds for1000 seconds is represented by a triple (3, 10, 1000).

Since sensor nodes are densely deployed, there might have more than twonodes at each sensing area unit. It results in the data redundancy and nonefficient resources usage if all nodes collect data and transmit it to the sink.Therefore it is necessary to choose some active nodes to collect and transmitdata while other nodes are switched to sleeping state to save energy if they donot affect the network connectivity and the full sensing coverage. There are someapproaches to handle this issue as in [11]. However their solutions are based onthe assumption that sensor nodes know their geographical location. This assump-

tion is not practical and expensive even though we can use location algorithmsto find approximately locations of sensor nodes. In our proposal, we divide thenetwork area into a grid of multiple adjacent cells. The grid is symmetric orasymmetric. Nodes are deployed randomly in each cell of the grid. We assumethat each node can know the identifier of the cell where it is located and itssensing radius covers that cell. This assumption is different to the assumptionin which the node knows its geographic location. First of all, the network gridis built based on the structure of the deployment area. For example, if sensornodes are deployed in a building, the network grid will be the room structureof the building and each cell is corresponding to a room. In case sensor nodesare deployed on streets, we can use the GOOGLE map application to build thenetwork grid. Second, the process of building the network grid is performed atthe base station before deployment. Therefore, it is not constrained by the en-

ergy or resources. After building the network grid, each cell in the network gridis assigned a unique identifier. These identifiers can be assigned to sensor nodesmanually before deployment or automatically in run time. For example, we canhave a special device moving around the network area. This device has the GPSmodule and the WIFI/3G connection that allows it to detect its geographic po-sition and communicate with the base station to determine the cell where it iscurrently located. Then it broadcasts beacons that include the cell identifier tonearby nodes. As soon as sensor nodes receive a beacon, they assign their cellidentifier to the one indicated in the beacon.

After deployment, every node broadcasts its presence to neighbor nodes.Then, some random nodes calculate the capability function based on the noderesources and decide to start the manager election round. After the round ends,the network is divided into sets of nodes. In each set of nodes there is a Managernode with the GM role. The sink roles as Network Manager. We assume that it


10/15

10 Trang et al.

knows the cell identifier of every node in network. This assumption is used tocalculate performance metrics.

When receiving a query from the sink, each sensor node needs to considerwhether or not it performs that task. First of all, it checks the context of the

query. If the node has the required sensing capabilities, it executes the corre-sponding action, the task registering by transmitting a Task Register Message(TREG) to its Manager node. The TREG message includes the unique identi-fier of the request query, the node capability, the identifier of the cell where thenode is located and the cell code. The node capability is calculated based onthe battery information, the number of hops to the sink, the number of internallinks which are links to nodes in the same cell and the number of external linkswhich are links to nodes in other cells as in the Equation 1.

capability =1BL +2HC +3IL +4EL (1)

in which BL is the battery level, HC is the number of hops to the sink, ILis the number of internal links, EL is the number of external links, 1, 2, 3,4 are the priorities of the battery level, the number of hops to the sink, thenumber of internal links and the number of external links correspondingly. It itimportant to note that these parameters are normalized before they are used bydividing for the corresponding maximum value. In our scenario, the priorities ofthe battery level and the number of external links are setup higher than otherones in order to ensure that if nodes have higher power and more connectionsto other cells, they will have higher probability of being selected. The cell codeis a special value to encode adjacent cells that a node can connect. Figure 4illustrates how to calculate the 8-bit cell code on the two plane area. The nodemaps the relative location of the connected cell to a corresponding bit in the cellcode. For example, if the node has a link to the north west cell, the bit 1 of thecell code is ON. A cell code 01001001 indicates that the node can connect to thecells: north west, west, and south. Node A has a better cell code than node B if

all ON bits of cell code B is ON on cell code A and there is at least a ON bit incell code A that is not ON in cell code B. For example, if cell code A is 01001001and cell code B is 00001001, we can infer that the node A has a better cell codethan node B. In other words, node A covers all links to other cells of node B,that is, if node B switches to sleeping state, node A can ensure the connectivityof adjacency nodes are not affected.

When the Manager node receives TREG messages from nodes in its managedset, it groups all nodes that have same query request and same cell identifiertogether. In each group it chooses nodes which have the highest capability andthe best cell code as active nodes. Other nodes are considered as redundantnodes. Then, the Manager node broadcasts a Task Response Message (TREP)message to inform nodes in its managed set. As receiving TREP, the node checksif it is a redundant node. If yes, the node broadcast a SLP (Sleep) beacon to

its neighbors to inform it will go to the sleeping state, then it waits a period oftime T before going to the sleeping state. Otherwise, it starts performing therequested query task. If a neighbor node receives an SLP beacon and detects


11/15


Fig. 4. Cell code illustration

that the sleeping node is the unique connection to other cells, it sends a Active

Request (AR) beacon to the sleeping node. During the period T, if the sleepingnode receives any AR beacon from its neighbor, it ignores the query task butstill works as a forwarding node. Otherwise, it changes to the sleeping state tosave energy.

5 Evaluation

We have implemented the above scenario in SENSE [3]. For comparison, we haveimplemented a data collection application where all sensor nodes transmit datato the sink as soon as receiving the query as the baseline, and refer to it asBDC. In BDC, the data relay path is built on the query broadcasting process.Each node setups the node from which it receives the query as the next node

to forward data. We also have built the forwarding mechanism in DISON basedon the query request similarly to BDC. However, DISON stores the identifier ofthe cell from which it receives the query instead of the node identifier becauseDISON could switch off some nodes which can be on the data relay route to saveenergy. When the node need to send or forward data to the sink, it added thecell identifier to the data packet and broadcast to its neighbors. If the neighbornodes are in the indicated cell, they forward the packet. Otherwise, they dropthe packet.

In our experiments, we consider one symmetric scenario and one asymmetricscenario. In the symmetric scenario, the network is deployed in a 10x10 grid,in which each cell has a radius of 40m. In the asymmetric one, we use a 10x2grid, that could be similar to the room structure of an office building floor.Sensor nodes are randomly placed in each cell of the grid with a density from 2

to 4 nodes. Moreover, in order to ensure the reality of the performance resultswe have also placed sensor nodes randomly through all the area and vary thenumber of nodes in case of the asymmetric grid. The transmitting radius of a


12/15

12 Trang et al.

Table 2. Network Settings

Parameters Value

Tx Power 24, 75103J

Rx Power 13,

5

103

JChannel Error-free

Tx Rate 125 kbps

MAC layer IEEE 802.11 (DCF)

Transmitting Radius 50 m

Simulation Time 3000s

Threshold 0.8

sensor node is 50m. The battery level of each node is generated randomly in therange of [0, 106]J. We define one special node as the sink and put it randomly inthe grid. The sink node is responsible for broadcasting a query at a specific time

to collect data from the network. The time to start querying is set randomlyin the range [80, 90] seconds. We set the sampling frequency to 10 seconds. Theperiod of collecting sensing data is chosen randomly in the range [1000 , 1200]seconds. Every random number in the simulator is generated by using a linearcongruential algorithm and 48-bit integer arithmetic. The simulation results arecalculated based on the results from running each scenario with 10 different seednumbers. The other parameters are set as in Table 2.

2 3 40

20

40

60

80

100

PDR(%)

Node Density

2 3 40

0.2

0.4

0.6

0.8

EndT

oEndDelay(s)

Node Density

2 3 40

4

8

12

16

20

AverageNodeUsedEnergy(J)

Node Density2 3 4

0

30

60

90

120

CoveragePercentage(%)

Node Density

BDC DISON

Fig. 5. Grid 10x10


13/15


In order to calculate the coverage ratio, we calculate the number of packetsincluding sensing data from each cell at the sink node. We denote recvi as thenumber of received packets including the sensing data from ith cell. Assumethat each sensor node transmits sensing data to the base station in the interval

T seconds with a rate APP RATE. To make it clearly, T is the query periodand APP RATE is the sensing data sampling frequency. If the condition shownin the Equation 2 is satisfied, the ith cell is considered as transmitting enoughdata to the sink. In other words, ith cell is covered. The simulation area is fullycovered if every cell in the simulation area is covered.

recvi= Threshold

T

APP RATE

(2)

We use the following metrics to evaluate our proposal:

Average Node Used Energy. The average used energy of each node. Packet Delivery Rate (PDR). The percentage of packets generated at the

sensor nodes that are successfully delivered to the sink.

Coverage Percentage. The percentage of the number of covered cells pertotal cells in the grid.

End-to-End Delay. The average time taken for a packet to be transmittedacross the network from the node to the sink.

In case of the 10x10 grid scenario (Figure 5), the packet delivery rate isimproved significantly for all node density values, up to 30% at node density 4.The end-to-end delay of the DISON solution is higher than BDC because thereare more successfull received packets in DISON, and these packets can be sentfrom nodes which are far from the sink. Therefore it results in an increase of theaverage delay. It is important that the used energy is reduced significantly, upto 23% at node density 4.

As shown in Figure 6(a), DISON solution does not improve the used energy

comparing to BDC if there are only two nodes in each cell. However it increasesthe packet delivery rate slightly and reduces the end-to-end delay significantly. Itis because the energy that saves from switching off some nodes is approximatelythe same as the required management overhead in DISON. In addition, as thenumber of nodes that transmit data to the sink decreases, it results in lesstraffic in the network. Therefore the packet delivery rate and the end-to-enddelay are improved. When the node density increases to 3 and 4, we can seethat DISON reduces the power consumption from 18% to 29% because thereare more redundant nodes that can be switched off without compromising thenetwork operation. Moreover, it also improves significantly the packet deliveryrate and the end-to-end delay. In case of nodes are randomply placed in all thearea, DISON still achieve better performance than BDC (Figure 6(b)). The usedenergy and the end to end delay of DISON is much lower than BDC while the

packet delivery rate is also slightly higher. In addition, it is easy to see that thesensing coverage is ensured in all scenarios.


14/15

14 Trang et al.

2 3 40

20

40

60

80

100

PDR(%)

Node Density

2 3 40

0.05

0.1

0.15

0.2

0.25

0.3

E

ndToEndDelay(s)

Node Density

2 3 40

4

8

12

16

20


Node Density2 3 4

0

30

60

90

120


Node Density

BDC DISON

(a)

50 60 70 80 90 1000

20

40

60

80

100

PDR(%

)

Number of nodes

50 60 70 80 90 1000

0.05

0.1

0.150.2

0.25

0.3

EndToEndD

elay(s)

Number of nodes

50 60 70 80 90 1000

4

8

12

16

20


Node Density50 60 70 80 90 100

0

30

60

90

120


Node Density

BDC DISON

(b)

Fig. 6. Grid 10x2: (a) Variable Node density, (b) Variable Number of Nodes

6 Conclusion

This article presents a decentralized, self-organizing management framework forwireless sensor networks. In the proposed framework, sensor nodes participatein the self-organizing management process at different levels depending on theirresources and the relationship with their neighbors and to the network at large.We have presented a new protocol stack for wireless sensor nodes to supportmanagement functions. This protocol stack allows each sensor node to recon-figure its operations according to the application requirements, resources andnetwork state. We have analyzed and have implemented the management frame-work in a data collection application scenario. The simulation results show thatthe proposed framework not only reduces the nodes energy consumption but


15/15


also improves other network performance metrics such as the packet deliveryrate and the end-to-end delay. In the near future, we are going to implementand evaluate the proposed framework in dynamic scenarios where, for instance,the network topology changes rapidly due to the node mobility and in multi-

services WSNs where there are multiple sinks with different types of requests aswell.

References

1. Paul V. Biron and Ashok Malhotra, editors.XML Schema Part 2: Datatypes. W3CRecommendation. W3C, second edition, October 2004.

2. Si-Ho Cha, Jong-Eon Lee, Minho Jo, Hee Yong Youn, Seokjoong Kang, and Kuk-Hyun Cho. Policy-based management for self-managing wireless sensor networks.IEICE Transactions, pages 30243033, 2007.

3. Gilbert Chen, Joel Branch, Michael Pflug, Lijuan Zhu, and Boleslaw Szymanski.SENSE: A Sensor Network Simulator. Advances in Pervasive Computing and Net-working, pages 249267, 2004.

4. Yuanzhu Peter Chen, Arthur L. Liestman, and Jiangchuan Liu. Clustering Al-gorithms for Ad Hoc Wireless Networks. InAd Hoc and Sensor Networks. NovaScience Publishers, 2004.

5. T.D. Le, Wen Hu, S. Jha, and P. Corke. Design and implementation of a policy-based management system for data reliability in wireless sensor networks. InLocalComputer Networks, 2008. LCN 2008. 33rd IEEE Conference on, pages 762 769,oct. 2008.

6. Winnie Louis Lee, Amitava Datta, and Rachel Cardell Oliver. WinMS: WirelessSensor Network-Management System, An Adaptive Policy-Based Management forWireless Sensor Networks. Technical report, School of Computer Science & Soft-ware Engineering, The University of Western Australia, 2006.

7. L. B. Ruiz, J. M. Nogueira, and A. A. F. Loureiro. MANNA: A ManagementArchitecture for Wireless Sensor Networks. Communications Magazine, IEEE,

41(2):116125, 2003.8. Zhang Wenbo and Xu Haifeng. A Policy Based Wireless Sensor Network Man-agement Architecture. In Intelligent Networks and Intelligent Systems (ICINIS),2010 3rd International Conference on, pages 552 555, nov. 2010.

9. Mohamed Younis, Moustafa Youssef, and Khaled Arisha. Energy-aware manage-ment for cluster-based sensor networks.Computer Networks, pages 649668, 2003.

10. O. Younis and S. Fahmy. HEED: A Hybrid, Energy-Efficient, Distributed Cluster-ing Approach for Ad Hoc Sensor Networks. Mobile Computing, IEEE Transactionson, 3(4):366 379, oct.-dec. 2004.

11. H. Zhang and J. Hou. Maintaining Sensing Coverage and Connectivity in LargeSensor Networks. Ad Hoc & Sensor Wireless Networks, 1(1-2), 2005.

12. Yanmin Zhu, Sye Loong Keoh, M. Sloman, and E.C. Lupu. A Lightweight Pol-icy System for Body Sensor Networks. Network and Service Management, IEEETransactions on, 6(3):137 148, september 2009.

Dison Adhoc2012

Documents

Transcript of Dison Adhoc2012