Load Migrating for the Hot Spots in WirelessSensor Networks using CTP

Jing Zhao, Lei Wang, Wenlong Yue, Zhengquan Qin, Ming ZhuSchool of Software, Dalian University of Technology, China

jing.john.zhao@gmail.com, lei.wang@dlut.edu.cn, yue.wenlong@gmail.com, qzq@dlut.edu.cn, zhuming@dlut.edu.cn

Abstract—To suit the needs of data collection, routing protocolsin WSN are normally required to form a collection tree wheredata flows from the source nodes to the sink nodes. Theseprotocols, such as CTP and Multihop LQI, generally targetat reducing the packet delivery cost without considering loadbalancing issues. We argue that load balancing is crucial forWSNs because load imbalance may cause certain nodes, whichwe call hot spots, to run out of energy faster than expected. Theload imbalance may lead to holes and prominently degrade theperformance of the network. In this paper, we propose BCTP(Balanced Collection Tree Protocol), which enhances CTP byenabling the network to migrate the load of the node underheavy traffic. BCTP uses the average transmission rate as themetric to measure a node’s long term traffic load. Once a node isfound heavily loaded, BCTP adopts a stochastic routing strategyto balance the load. BCTP is evaluated by testbed experimentswith 9 Telosb motes. Experiment result shows that BCTP canreduce the load of the hot spot by up to 61.9% in a denselydeployed network.

Index Terms—Wireless sensor Networks, Hot Spot, StochasticRouting

I. INTRODUCTION

Wireless sensor networks (WSNs) prove to be a powerful

tool for prolonged surveillance of large scale phenomena [1].

A wireless sensor network is typically composed of large

quantities of densely deployed low-cost wireless sensor nodes

which are constrained both in computational ability and en-

ergy. Due to the limited transmission range of the senor nodes,

WSNs usually adopt a multi-hop many-to-one routing pattern

to transmit the data collected from the phenomenon area to

the sink node. To suit the needs of WSNs, a number of many-

to-one routing protocols are proposed and of these protocols,

CTP (Collection Tree Protocol) [2] is a commonly used and

thoroughly tested one. CTP uses ETX [3] as its routing metric

to avoid lossy links. ETX stands for the expected total number

of transmissions required to successfully deliver a packet. The

greater the ETX of a path is , the lossier the path is. However,

ETX doesn’t address the problem of load balancing. Therefore,

CTP is prone to the hot spot problem: certain nodes carry much

heavier transmission load than other nodes. These nodes are

likely to run out of battery faster than the ordinary nodes,

which may create holes and undermine the performance of

the whole system.

We conducted several experiments of CTP on 9 nodes.

Figure 1 shows the collection tree built by CTP in one of these

experiments. The routing table of node 4 is shown in Table

I. We can find that though the route 4 → 1 → 0 is not as

good as 4 → 2 → 0, it is still usable. Other experiments yield

similar results. This phenomenon implies that CTP by itself

won’t provide load balancing service even if there is sufficient

network redundancy. In the sensor networks deployed in the

wild, there are also reports of similar problems [4]. Our Design

of BCTP is based on this observation.

0

5 4

8

6

73

21

Fig. 1. A collection tree built by CTP. We can see from the figure that thetree is highly imbalanced.

TABLE IROUTING TABLE OF NODE 4

Neighbors Route ETX Link ETX0 4.6 4.62 2 13 4.7 1.71 3.2 2.26 4.3 2.2

Balanced Collection Tree Protocol (BCTP), a protocol based

on CTP, aims to solve the problem of hot spot in CTP. BCTP

modifies CTP in two aspects: First, BCTP adds a transmission

recorder component to measure a node’s load and to determine

whether a node is a hot spot or not; Second, BCTP modifies

the routing strategy of the hot spot’s children to migrate the

load of the hot spot.

To solve the problem of hot spots, we must first answer

the following questions: how do we quantitatively define a

hot spot? What metric should we use to measure the load

of a sensor node? The motivation of solving the problem of

hot spots is that we want to guarantee that all the nodes of

the network can work unattended for a given period of time.

Since wireless transmissions account for a large proportion of

2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks

978-0-7695-4610-0/11 $26.00 © 2011 IEEE

DOI 10.1109/MSN.2011.42

167

2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks

978-0-7695-4610-0/11 $26.00 © 2011 IEEE

DOI 10.1109/MSN.2011.42

167

2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks

978-0-7695-4610-0/11 $26.00 © 2011 IEEE

DOI 10.1109/MSN.2011.42

167

the energy consumption [5], this goal lays an upper bound for

the overall transmissions of a sensor node during its lifetime.

Thus, the hot spots should be those whose transmissions

exceed the bound. However, we can’t use overall transmissions

directly as the metric to define hot spot for it will be too late to

make any change if a node’s transmissions already exceed the

bound. Instead, we use the average transmission rate, which is

measured by the number of transmissions per unit time, as the

metric to measure the load of a node and to set the threshold of

hot spot. This will achieve the following benefits. First, this

metric is directly connected with the overall transmissions.

Second, this metric allows a node to detect an overload node

at early stage by calculating its average transmission every

unit time, which is much shorter than the total lifetime.

The second phase of solving the problem is to migrate the

load of the hot spot. BCTP requires the children of a hot spot

to find a suitable alternate route. When a packet arrives, it

will choose a route opportunistically from the original route

and the alternate route. We use opportunistic routing to avoid

frequent changes of the topology and to keep the children from

becoming hot spot themselves. We will elaborate this part in

Section III. Besides, the selection of alternate route in BCTP

insures that no routing loops will occur and the alternate route

won’t traverse a hot spot itself. Last but not least, our scheme

only uses one bit of the option field of the original CTP control

message. It relies solely on the CTP beacon mechanism to

deliver necessary information and thus doesn’t introduce any

network overhead.

The contribution of this paper is as follows. First, we

introduce average transmission rate as the metric to measure a

node’s long term load. Second we design a localized scheme to

migrate the load of the hot spots. Third, we implement BCTP

in CTP and evaluate the performance of BCTP in a 9-node

testbed.

Section II describes related work. Section III describes the

design of BCTP. Section IV demonstrates the implementation

of BCTP and Section V evaluates BCTP through experiments.

Section VI concludes the paper.

II. RELATED WORK

A. Many to One Routing Protocols

Collection Tree Protocol (CTP) is a multi-hop protocol

which computes the route from non-sink nodes to a single or a

number of sinks in WSN. CTP Noe is a recent implementation

of CTP. It uses two distinctive techniques which are called

data path validation and adaptive beaconing. Data path vali-

dation can detect loops and validate the routing topology by

examining the received data packets while adaptive beaconing

adapts the rate of control messages dynamically. These two

techniques enable CTP Noe to detect a routing inconsistency

quickly using a low rate of control messages. CTP Noe is

thoroughly tested in 12 different testbeds and 6 different

link layers. Muhammad Hamad Alizai et al. proposed BRE

(Bursty Routing Extensions) [6] based on the observations

that routing protocols like CTP tend to use long term stable

route rather than unstable links. They argue that bursty links,

whose link quality changes dramatically over time, should be

exploited in routing. BRE uses a metric called STLE to detect

immediate good quality links and uses it as the parent. BRE

falls back to traditional routing if a single delivered packet is

not acknowledged.

These routing protocols, from CTP to BRE, put their

emphasis on reducing total transmissions. However, we argue

that balancing the transmissions of individual nodes is also

very important. The imbalance of network load may put some

nodes out of service faster than required and thus degrade the

performance of the entire network.

B. Rate Control Schemes

Rate control schemes, such as Fusion [7], CODA [8], ESRT

[9] and IFRC [10], also try to reduce the load of certain node

in the network. The main purpose of these protocols is to

eliminate congestion in the network. Fusion uses the queue

length to measure levels of congestion and when a congestion

is detected, it applies hop-by-hop backpressure to regulate the

data rate of the sources. CODA measures both the channel and

buffer to detect congestion. Other than open loop backpressure,

CODA also adopts an end-to-end acknowledgement strategy

to deal with consistent congestion. IFRC, which monitors the

queue length to detect incipient congestion, introduces a novel

low-overhead congestion sharing mechanism. It converges to

a fair and efficient rate allocation using an AIMD control law.

ESRT is quite different from the above schemes by using a

centric rate control mechanism. It computes the appropriate

rate for each node at the base station and broadcasts the rate

to every node in the network.

The rate control schemes are different from BCTP in two

aspects. First, they work in different time scales. The former

try to solve transient congestion while the latter tries to

solve long term load imbalance. Second, they use completely

different methods to reduce a node’s transmission load. Rate

control schemes usually reside on top of routing protocols and

rely on explicit rate control to reduce a node’s transmission

load. BCTP, on the other hand, tries to exploit the redundancy

of the network to migrate the transmission load of the hot spot.

C. Stochastic Routing

S. Keshav [11] compared the pros and cons of stochastic

and deterministic routing. He argues that stochastic routing

eliminates the problem of load oscillation but suffers from

varying delays, which may cause some connections out of

order. However, as most WSN applications are not connection

oriented, the ordering problem is not so important in the WSN

context. Alejandro Ribeiro et al. [12] provide a series of

theoretical study of stochastic routing in multi-hop wireless

networks. It establishes a model where packets are randomly

routed to neighboring nodes. In this model, the duty of routing

protocol is to search for a matrix of routing probabilities

according to a properly defined optimality criteria. The trans-

mission mitigation algorithm of BCTP is inspired by this

model.

168168168

D. Energy Aware Routing

The Energy Aware Routing (EAR) [13] proposed by Rahul

C. Shah et al. has much in common with our scheme. EAR

also maintains a set of good paths instead of a single optimal

path. It requires a node to choose one path from those paths

probabilistically. EAR introduces an energy metric which is

determined by both the cost to deliver a packet and the residual

power of the intermediate node. The probability assigned to

each path is determined by the energy metric of the path. Our

scheme is different from EAR in several aspects. First, EAR’s

routing decision is based on the residual energy of paths while

BCTP’s is based on the residual energy of individual nodes.

From our perspective, EAR ignores the energy differences of

the nodes on the same path. A path is abundant in residual

energy doesn’t mean all the nodes on the path is abundant

in residual energy. Second, EAR’s energy cost metric is

based on the assumption that the accurate residual energy and

transmission cost of energy can be obtained by sensor nodes.

However, this is not true for some sensor platforms.

Sequential Assignment Routing (SAR) [14] takes the energy

resources into consideration when it tries to set up a route.

The routing decision of SAR is mainly based on three factors:

residual energy, QoS of the paths and the priority level of

the packets. SAR forms trees rooted from the source nodes

to the destination nodes. These trees avoid nodes that are

low in energy. The problem of SAR is that it relies on the

global information of the whole network and can’t handle the

dynamic of networks.

E. Structured Networks with Load Migration Abilities

Some researchers try to solve the problem of hot spots by

modifying the architecture of WSNs. They add some special

nodes to the network and form multi-layered hierarchical

networks. These special nodes usually process special abilities

like mobility or multi-radio transmission ability. They can

carry the load that cannot be handled by the ordinary nodes.

Wan et al. [15] tries to solve the problem of hot pots

by placing some virtual sinks. These virtual sinks have two

kinds of radios: long ranged radios based on IEEE 802.11

to communicate with the physical sinks and short ranged

radios to communicate with the sensors. In addition, they

proposed Siphon, a set of distributed algorithms, to instruct

the network to use these virtual sinks efficiently. Siphon is

mainly composed of three parts: virtual sink discovery and

selection, congestion detection and traffic redirection. Virtual

sink discovery mainly exploit the routing protocols’ control

messages to locate the virtual sinks in the network. Congestion

discovery is either initiated by sensor nodes or physical sink

nodes. The former is mainly based on CODA’s congestion

discovery and the latter mainly exploits the smart monitoring

ability of physical sinks.

Another way to migrate the high traffic load of WSNs is

to introduce mobile nodes into the network. Shah et al. [16]

introduces data mules into the network. These data mules can

walk randomly or move along parallel straight lines in the

field. They can pick up data and drop them off to a wired

access point. This way the cost is shifted from the node to

the data mules. Ma and Yang [17] introduces a path planning

algorithm, which add some turning point to the parallel lines.

The path of the mobile data collector can be adjusted according

to the distribution of the network. Zhao and Yang [18] propose

a three-layer framework, which includes the sensor layer, the

cluster head layer and the mobile collector layer. The cluster

heads collect data from the sensor nodes and forward them to

mobile data collectors.

These multi-layer frameworks and BCTP try to solve the

same problem. However, these frameworks introduce “super

nodes” into the network and thus increase the complexity and

cost of the network. We believe the ordinary sensor nodes

possess enough transmission ability to solve the hot spot

problem by themselves.

III. DESIGN

A. Design Goals and Challenges

Our aim is to detect hot spots, the nodes that run out of

battery faster than expected due to heavy transmission load,

and to reduce the load of the hot spot using stochastic routing.

However, we don’t want to undermine the reliability and

stability of the original CTP or to introduce more overhead.

As a result, BCTP faces the following crucial challenges.

First, as BCTP aims to solve the hot spot problem, it should

first introduce a metric which can define a hot spot. Further,

a hot spot should be correctly detected at early stage to leave

enough time for the protocol to solve the problem. Thus, the

metric should be both correct and agile in reflecting a node’s

transmission load.

Second, after a hot spot is discovered, BCTP should exploit

the network’s transmission ability to reduce the hot spot’s

transmission load. The transmission migration scheme should

ensure the migrated load won’t burden the node which is

already overloaded. Besides, the load migration scheme should

do its best not to enlarge the number of hot spots.

Third, CTP, which reacts quickly to routing inconsistencies

but sends very few beacons, proves to be reliable and stable

in a number of experiments. These feathers should be retained

as much as possible. Hence, BCTP should only act as a

supplement of CTP, which deals with the special case that

a hot spot emerges. What’s more, as CTP’s rate of beacons is

highly relative to the frequency of network topology changes,

BCTP’s load migration scheme should change the network’s

topology as little as possible.

Based on the discussions above, the design of BCTP is

mainly composed of three parts: hot spot detection, load

migration and integration with original CTP.

B. Hot Spot Detection

The hot spot is detected by continuously monitoring the

transmission load which is measured by the average transmis-

sion rate. A node will consider itself overloaded if its average

transmission load is above a preset threshold.

169169169

1) The Average Transmission Rate Metric: By our defini-

tion, a hot spot is a node whose long term transmission load is

much higher than expected. We use the average transmission

rate to measure a node’s current load. After a node turns

on BCTP, it counts every transmission it issues. Every xsecond, BCTP calculate a node’s average transmission rate by

Tavg = Tt/Ct where Tavg denotes the average transmission

rate, Tt denotes a node’s total transmissions, CT denotes a

node’s total measurements. If x is too large, the metric can’t

agilely reflect the changes of a node’s load. If x is too small,

it will impose a heavy computation burden on a node. A

compromise scheme is that x should be smaller than the steady

beacon interval of CTP.

2) Threshold for Hot Spots: Threshold for hot spots is

highly application-specific, i.e. it’s related to the node’s bat-

tery, transmission energy cost and how long the node is

expected to work. This threshold reflects the energy constraint

on the number of transmissions i.e. the battery allows how

many transmissions to be made in a node’s life time. We expect

the threshold for the average transmission to be obtained in

the training period.

It should be noted that BCTP only deems a node as a hot

spot if its average transmission is above the threshold for

consecutive N measurements. This requirement is aimed to

avoid a frequent transition of a node’s status.The default value

of N is 5.

C. Transmission Load Migration

After a hot spot is detected in the network, the load

migration scheme will try to reduce the load of the hot spot.

This is done in two phrases: First the downstream node of the

hot spot will try to find an alternate route; if such route exists,

BCTP will allocate the routing probabilities to the original

route and the new found route.

1) Alternate Route Selection: The children of a hot spot is

required to find an alternate route. The alternate route should

satisfy the following requirements: (1) The alternate route

should be loop-free, which is a basic requirement of a routing

protocol; (2) the alternate route should not traverse another

hot spot or the migration scheme will be meaningless; (3) the

alternate route should avoid the extremely lossy links which

proves to be unstable.

To avoid loops, BCTP requires that node i can only choose

node j as its next hop if the following constraint is satisfied

ETX(j) < ETX(p) + 1,

where node p is node i’s parent. Since the ETX of a link is at

least one, this requirement ensures node j won’t transmit the

packet to node i’s current next hop p, let alone transmit the

packet back to node j.

To prevent the alternate route from traversing a hot spot

itself, BCTP requires all the children of a hot spot to broadcast

themselves as a hot spots.

2) Routing Probability Allocation: If the children of a

hot spot found a suitable next hop, it will forward packets

stochastically to the original next hop and the alternate next

hop. The reason we use stochastic routing is to prevent the

children themselves from becoming hot spots. There are some

considerations in designing the load migration scheme.

First, the alternate route is generally lossier than the original

route. Thus, the children of the hot spot have to conduct more

transmissions to deliver a packet through the alternate route.

The increased transmissions may cause the children to get

overloaded. To prevent this situation, the probability should

be allocated such that the anticipated average transmission rate

should not surpass the threshold.

Let Ttres denote the threshold for hot spots, Tavg denote the

node’s current average transmission rate, Ep denote the ETX

of the node’s original route, Ea denote the ETX of the alternate

route, P denote the number of packets expected to be delivered

in x seconds. All these variables can be easily obtained by a

node locally. Suppose α is the probability allocated for the

original route. The constraint on α is set by

(α× Ep + (1− α)× Ea)× P − Ea × P ≤ Ttres − Tavg,

which yields

α ≥ 1− Ttres − Tavg

(Ea − Ep)× P.

The left of the inequality indicates the expected additional

transmissions incurred by adopting a alternate route. The

right indicates the number of increased transmissions a node

tolerates. In the implementation of BCTP, we set α to the

minimum value. This inequality shows that the probability

allocated to the original route is related to three factors:

(1) the gap between the threshold and the node’s current

average transmission rate, (2) the ETX gap between the node’s

alternate route and its original route, (3) the number of packets

to deliver by the node. The higher α is, the more a node relies

on its original route. α is negatively related to the first factor

but positively related to the other factors. This agrees with the

intuition.

There are two extreme cases: α = 0 and α = 100. The

former means the node doesn’t rely on the original route at all

while the latter means the node doesn’t use the alternate route

at all. In the former case, the node doesn’t need to broadcast

itself as a hot spot as is described in Section III-C since it

doesn’t use the original route at all.

0

1 2

9654 7

3

8

Fig. 2. A situation that traffic is migrated from node 1 to node 3

Second, the migrated load may cause the nodes on the

alternate route to become overloaded. We tolerate this scene

170170170

as it is beneficial in some situations. As is shown in Figure

2, suppose node 1 is deemed under heavy load, node 6 will

choose node 2 as its alternate route. The migrated load in turn

causes node 2 to become heavily loaded, which will cause

node 8 to choose node 3 as its alternate route. The load is

virtually transferred from node 1 to node 3.

Third, if a hot spot declares it’s not overloaded as soon as

the load of the hot spot is reduced below the threshold, it’s

likely that it will soon get overloaded again as its children

get back to their original route. We don’t want a node status

to change too frequently. So a hot spot can only declare it is

not overloaded after its average transmission rate is below the

Ttres−M for consecutive N measurements.The default value

of M is 2.

D. Integration with CTP

As we have discussed above, we want to change the

behavior the original CTP as little as possible. So BCTP

completely acts as the original CTP when there is no hot spot

in the network. After a hot spot is declared, BCTP still tries to

maintain the original CTP tree as much as possible. A node

still broadcasts the original next hop as its parent and the

original route cost even if it is using the alternate route. The

node is somehow cheating the other nodes. However as long

as it doesn’t harm the stability and reliability of the protocol,

BCTP is fine with it.

As for control messages, BCTP relies on the beacon control

scheme of CTP. BCTP uses only 1 bit of the beacon message.

It is used to inform other nodes when a node become a hot

spot.

IV. IMPLEMENTATION

We implement BCTP in nesC for TinyOS 2.1.1. The orig-

inal CTP is mainly consisted of three parts: routing engine,

forwarding engine and link estimator. CTP uses the Four Bit

Link Estimator (4bitle) as its link estimator. To suit the needs

of CTP, we add the transmission monitor componen.Their

relationship is illustrated in Figure 3.

The transmission monitor component provides the

RecordTx interface to interact with other components. The

start command instructs the monitor to record transmissions

and periodically compute the average transmission rate of the

node. The stop command stops the monitor. The addTxcommand increases the monitor’s transmission counters.

The addPkt command increases the monitor’s packet

counter. The Packet counter is usually smaller than the

transmission counter as a node may retransmit a packet

several times to successfully deliver it. The getAvgTxand getAvgPkt command return the average transmission

rate and average packet delivery rate respectively. Similarly,

the getTx command and the getPkt command return

the transmissions of the last measure interval and the

delivered packets of the last measure interval respectively.

The getState command reports whether the node is a

hot spot. The isRecordOn command returns wether the

monitor has been turned on. If a normal node turns into a hot

spot or a hot spot returns to the normal state, it will notify

other components of the state change by the stateChangeevent. The parameter tells other components which state the

node is in.

interface RecordTx {command void start();command void stop();command void addTx();command void addPkt();command uint16_t getAvgTx();command uint16_t getAvgkt();command uint16_t getTx();command uint16_t getPkt();command bool getState();command bool isRecordOn();event void stateChange(state_t state);

}

The BCTP also modifies the routing engine part of CTP.

BCTP adds the constrained item to the routing table entry,

which indicates whether a neighbor is a hot spot. Every time

a node updates its routing table, it will check if its parent is a

hot spot. If its parent is a hot spot, the node will try to select

an alternative route and determine the probability assigned to

each route.

Forwarding Engine

Next HopRouting Engine

Link Estimator

Transmission Recorder

Fig. 3. The architecture of BCTP. Forwarding Engine, Routing Engine andLink estimator are the original components of CTP. We add a TransmissionRecorder component and modify the RoutingEngine component.

V. EVALUATION

We tested BCTP on 9 GF100 Motes, which is designed

according to Telosb specifications. A standard mote includes

a mini-USB port for programming and data transfer, an IEEE

802.15.4 radio TI CC2420, a low power MCU MSP430 F1611

with 10K RAM, an external fash chip up to 1MB. The

9 motes are densely deployed within an area of 2 square

meters. The CC2420 power is set to 2 to insure a multi-hop

communication. In our experiment, node 0 is selected as the

sink node. Figure 4 shows an example of the GF100 node. The

transmissions of the sink node are not studied as sink nodes

usually have external power supplies in WSN applications.

171171171

Fig. 4. GF100 Mote

We run both BCTP and CTP consecutively for 3 hours and

record the packets received at the base station. For BCTP, we

set the transmission measure interval x to 30 seconds, average

transmission threshold Ttres to 20 pkts per 30 seconds. Each

node is required to send a packet every 5 seconds.

A. Comparison with CTP

Figure 6 compares the overall transmissions of each node

between CTP and BCTP in three hours. It’s obvious that BCTP

is much more balanced than CTP. In BCTP, the highest load

of a node is 7755 while the highest load in CTP is 20498.

BCTP reports a reduction of 61.9% transmissions on the most

heavily loaded node. To quantitatively compare the fairness

of BCTP and CTP, we compute the fairness index of the

nodes’ transmissions in each experiment. Jain’s fairness index

is computed as follows:

f(y1, y2, ..., yn) =(

n∑i=1

yi)2

nn∑

i=1

y2i

, yi ≥ 0 and

n∑

i=1

yi > 0.

We can see from Figure 5 that the BCTP achieves a much

better fairness than CTP.

0

0.2

0.4

0.6

0.8

1

CTP BCTP

Fairness Index

protocol

Fairness

Fig. 5. This figure compares the fairness index of CTP and BCTP

What we don’t expect is that compared with CTP, BCTP

achieves a reduction of total transmissions by 29.1%. BCTP

allows some nodes to use lossier routes as their alternate

routes. Theoretically, there should be a slight increase of the

total transmissions of the network. To make sure that the

reduction of the total transmissions is not due to packet losses,

we compare the delivery ratio for each node in Figure 7. We

can see that BCTP and CTP achieve similar delivery ratio. So

why does the total transmissions of all nodes reduce?

To answer this question, we record how the average trans-

mission rate of each node changes in the first hour in Figure

8. In the first fifteen minutes, the protocol goes exactly as we

expected. Node 2 and Node 3 are deemed as hot spots and

their load decreases rapidly. This is at the cost of a increased

load in node 5. However, what happens after the first fifteen

minutes is quite beyond our expectation. The figure shows a

general decrease trend of transmissions for the whole network.

Other experiments we conduct report similar trends.

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

22000

0 1 2 3 4 5 6 7 8

Overall Transmissions

Node

BCTPCTP

Fig. 6. A comparison of the overall transmissions of each node in CTP andBCTP. BCTP achieve a more balanced network load than CTP.

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7 8

Delivery Ratio

Node

BCTPCTP

Fig. 7. This figure describes the delivery ratio of each node in CTP andBCTP. We can see from the figure that the delivery ratio is similar in CTPthan BCTP.

An explanation to this phenomenon is that the original CTP

relies too heavily on its setup period to determine a node’s

routing table. In CTP, the link quality information can be

updated by both data messages and beacon messages. As a

node only receives data messages from its children and sends

data messages to its parents, data messages only guarantee that

a node is sensitive to the change of the link to its parent and

children. The problem is that a node solely relies on beacon

messages to update the link information of its other neighbors.

In the setup period of CTP, each node broadcasts its beacon

messages frequently and a node can get relatively accurate

link quality information of all its neighbors. However as the

beacon interval grows longer, the node is insensitive to the

changes of the links to other nodes and thus its routing table

172172172

is inaccurate. It may miss a route which is even better than

current one. In BCTP, however, when a hot spot is detected,

a node is required to find an alternate route. The chance is

that it will try several routes, and the data messages it send

will help to adjust the routing table. In the end it may find an

alternate route is even better than the original one.

0

5

10

15

20

25

30

0 10 20 30 40 50 60

Transmissions/30 secs

Time(minutes)

node 1node 2node 3node 4node 5node 6node 7node 8

Fig. 8. This figure displays how the nodes’ average transmission rateschange in the first hour. Each line of the figure represents a node’s averagetransmission rate.

B. Limits

In order to check how BCTP works in harsh conditions,

we set the RF power of CC2420 to 1 and repeat the above

experiments. Figure 9 shows how the average transmission

rate of each node changes in the first hour. We can see that

there are three nodes above the threshold and BCTP did little

to migrate the load of these nodes. We checked the routing

table of all the participated nodes and found that there are

no suitable alternate route for hot spots’ children. This is the

nodes in the network are less connected due to the RF power

constraints. As we have illustrated in pervious sections, only

under the circumstance that one or more alternate routes exist,

can BCTP migrate well the load of the hot spots.

0

5

10

15

20

25

30

35

40

45

50

0 10 20 30 40 50 60

Transmissions/30 secs

Time(minutes)

node 1node 2node 3node 4node 5node 6node 7node 8

Fig. 9. This figure displays how the nodes’ average transmission rates changein the first hour when the RF power is set to 1. The load of node 1, 3 and 6cannot be efficiently migrated.

VI. CONCLUSIONS AND FUTURE WORK

This paper describes the design and implementation of

BCTP, an enhanced version of the CTP protocol, which con-

siders both transmission cost and load balancing. Evaluations

in testbed show that BCTP can significantly decrease the

number of transmissions of the hot spots given that there are

sufficient redundant nodes in the network.

Currently we are still using the beacon scheme of CTP.

However, we feel that the beacon scheme of CTP is flawed in

terms that it cannot loyally reflect a node’s network conditions.

Besides, the threshold for hot spots is set manually in BCTP. In

the future, this threshold should be set automatically according

to the network’s traffic conditions.

VII. ACKNOWLEDGE

This work is partially supported by Natural Science Founda-

tion of China under Grant No. 61070181, the Fundamental Re-

search Funds for the Central Universities No. DUT10ZD110,

and Natural Science Foundation of Liaoning Province under

Grant No. 20102021.

REFERENCES

[1] Y. I.F.Akyildiz, W.Su and E.Cayirci, “Wireless sensor networks: asurvey,” in Computer networks, 2002.

[2] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis, “Collectiontree protocol,” in SenSys, 2009.

[3] D. S. Couto, D. Aguayo, J. Bicket, and R. Morris, “A high-throughputpath metric for multihop wireless routing,” in MobiCom, 2003.

[4] K. Liu, Q. Ma, X. Zhao, and Y. Liu, “Self-diagnosis for large scalewireless sensor networks,” in IEEE INFOCOM, 2011.

[5] L. Hoesel and P.J.M.Havinga, “A lightweight medium access proto-col(lmac)for wireless sensor networks:,” in SenSys, 2004.

[6] M. H. Alizai, O. Landsiedel, J. A. B. Link, S. Gotz, and K. Wehrle,“Bursty traffic over bursty links,” in SenSys, 2009.

[7] B. Hull, K. Jamieson, and H. Balakrishnan, “Mitigating congestion inwireless sensor networks,” in SynSys, 2004.

[8] C.-Y. Wan, S. B. Eisenman, and A. T. Campbell, “Coda: congestiondetection and avoidance in sensor networks,” in SynSys, 2003.

[9] I. F. A. Yogesh Sankarasubramaniam, Ozgur B. Akan, “Esrt: event-to-sink reliable transport in wireless sensor networks,” in ACM interna-tional symposium on Mobile ad hoc networking & computing, 2003.

[10] S. Rangwala, R. Gummadi, R. Govindan, and K. Psounis, “Interference-aware fair rate control in wireless sensor networks,” in SIGCOMM, 2006.

[11] S. Keshav, An Engineering Approach To Computer Networking.Addison-Wesley Professional, 1997.

[12] A. Ribeiro, G. B. Giannakis, Z.-Q. Luo, Nikolaos, and D. Sidiropoulos,“Modelling and optimization of stochastic routing for wireless multihopnetworks,” in IEEE INFOCOM, 2007.

[13] R. C. Shah and J. M. Rabaey, “Energy aware routing for low energy adhoc sensor networks,” in WCNC, 2002.

[14] K. Sohrabi and J. Pottie, “Protocols for self-organization of a wirelesssensor network,” in Personal Communications, 2000.

[15] C.-Y. Wan, S. B. Eisenman, A. T. Campbell, and J. Crowcroft, “Overloadtraffic management for sensor networks,” in ACM Transactions onSensor Networks, 2007.

[16] R. C. Shah, S. Roy, S. Jain, and W. Brunette, “Data mules: modelingand analysis of a three-tier architecture for sparse sensor networks,” inAd Hoc Networks, 2003.

[17] M. Ma and Y. Yang, “Sencar: an energy-efficient data gathering mech-anism for large-scale multihop sensor networks,” in IEEE Transactionson Parallel and Distributed Systems, 2007.

[18] M. Zhao and Y. Yang, “A framework for mobile data gathering withload balanced clustering and mimo uploading,” in INFOCOM, 2011.

[19] A. Woo, T. Tong, and D. Culler, “Taming the underlying challenges ofreliable multihop routing in sensor networks,” in SenSys, 2003.

[20] A. Ribeiro, N. D.Sidiropoulos, and Georgios.B.Giannakis, “Optimal dis-tributed stochastic routing algorithms for wireless multihop networks,”in IEEE TRANSACTIONS, 2008.

[21] S. Biswas and R. Morris, “Exor: Opportunistic multihop routing forwireless networks,” in SIGCOMM, 2005.

173173173