ARTICLE IN PRESS - Download-Paper€¦ · Content centric routing in IoT networks and its...

ARTICLE IN PRESS

JID: COMCOM [m5G; March 18, 2016;20:58 ]

Computer Communications xxx (2016) xxx–xxx

Contents lists available at ScienceDirect

Computer Communications

journal homepage: www.elsevier.com/locate/comcom

Content centric routing in IoT networks and its integration in RPL

Yichao Jin

a , ∗, Sedat Gormus b , 1 , Parag Kulkarni a , Mahesh Sooriyabandara

a Q1

a Toshiba Telecommunications Research Laboratory, 32 Queen Square, Bristol BS1 4ND, United Kingdom

b Karadeniz Technical University, Trabzon, Turkey

a r t i c l e i n f o

Article history:

Available online xxx

Keywords:

IoT

Routing

Content centric

Data aggregation

Implementation

a b s t r a c t

Internet of Things (IoT) networks can be used for many applications across different industry domains in-

cluding infrastructure monitoring, civil service, security and surveillance applications etc. However, gath-

ering large amounts of data from such networks including images and videos often cause traffic con-

gestion in the central network area. In order to solve this problem, we proposed the content centric

routing (CCR) technology, where routing paths are determined by content. By routing the correlated data

to intermediate relay nodes for processing, a higher data aggregation ratio can be obtained, hence ef-

fectively reducing the traffic in the network. As a result, significant latency reduction can be achieved.

Moreover, redundant data transmissions can also be eliminated after data aggregation which reduces the

energy consumption spent predominantly on wireless communication thereby conserving limited battery.

CCR was further integrated with the IETF RPL protocol and implemented in Contiki OS using the TelosB

platform. Finally, both simulation and implementation results prove the superior performance of CCR in

terms of low network latency, high energy efficiency, and high reliability.

© 2016 Published by Elsevier B.V.

1. Introduction 1

Distributed computing in wireless networks has recently been 2

attracting a lot of attention, especially in the emerging paradigm 3

of the Internet of Things (IoT) communications where IoT devices 4

are equipped with independent processing, communication, and 5

storage capabilities [1] . The key idea is that rather than sending 6

all raw data directly across an expensive (multi-hop) wireless net- 7

work which is usually correlated with high energy consumption 8

and time delays, a more cost-effective way is to first reduce the 9

data volume locally via in-network processing and subsequently 10

forward only the processed result. Therefore, we can save band- 11

width and energy, reduce latency and extend the network life in 12

resource constrained IoT network [2] . 13

In many cases, data collected for the same application tends to 14

be highly correlated [3] and therefore can be combined or jointly 15

processed while forwarding to the sink. For example, fusing to- 16

gether multiple sensor readings related to the same physical event. 17

Such data aggregation process can reduce the total amount of 18

∗ Corresponding author. Tel.: +44 1179060780. Q2

E-mail addresses: [email protected] , [email protected] (Y. Jin),

[email protected] (S. Gormus), [email protected] (P. Kulkarni),

[email protected] (M. Sooriyabandara). 1 This work was carried out when the author was with Toshiba Research Europe

Ltd.

messages to be sent over expensive wireless links, which has a 19

significant impact on energy consumption as well as overall net- 20

work efficiency. On the other hand, uncorrelated packets might not 21

be simply aggregated from the processing point of view, e.g. it is 22

not meaningful to calculate an average of a temperature and a hu- 23

midity reading. Therefore, one critical issue in data aggregation is 24

to determine an optimized information flow and communication 25

topology in order to efficiently route the correlated data to the 26

intended processing nodes in the network. Let’s take the tunnel 27

monitoring system as an example to give more insight. As shown 28

in Fig. 1 , a variety of sensor nodes and cameras are installed to 29

monitor two key tunnel assessments: tunnel structure safety and 30

traffic management, where a huge amount of real-time sensory 31

data including images and video streams needs to be delivered to 32

a remote control cente e. Traditionally, the server first collects all 33

the data via the same routing topology regardless of whether the 34

data is used for tunnel safety or traffic management. This case is 35

illustrated in Fig. 1 (A). Take Node 1 for example, it sends both Tun- 36

nel safety data A and traffic data B to node 5 as they are treated 37

as the same. Once all data reaches the destination, the final results 38

are computed at the server side. However, this is very likely to cre- 39

ate a ‘hot-spot’ problem, where heavy network traffic in the cen- 40

tral area results in higher energy consumption on the neck nodes 41

and is also prone to traffic congestion events. This is due to the 42

fact that the neck nodes are geographically closer to the access 43

point/server, thus they have to forward messages coming from the 44

outer regions ( Fig. 1 (A)). 45

http://dx.doi.org/10.1016/j.comcom.2016.03.005

0140-3664/© 2016 Published by Elsevier B.V.

Please cite this article as: Y. Jin et al., Content centric routing in IoT networks and its integration in RPL, Computer Communications

(2016), http://dx.doi.org/10.1016/j.comcom.2016.03.005


http://www.ScienceDirect.com

http://www.elsevier.com/locate/comcom

mailto:[email protected]







2 Y. Jin et al. / Computer Communications xxx (2016) xxx–xxx

ARTICLE IN PRESS


Fig. 1. Conventional routing vs. CCR.

To overcome such problem, we proposed a content centric 46

r outing (CCR) protocol in [4] for efficient data aggregation in multi- 47

hop IoT networks. We differentiate data by its content while rout- 48

ing information, and correlated data are termed as the data of the 49

same content. As shown in Fig. 1 (B), since both Node 1 and Node 3 50

provide information for traffic conditions, rather than sending con- 51

tent B to Node 5 as shown in Fig. 1 (A), Node 1 sends it to Node 52

3 where they can be combined or aggregated while forwarding to 53

the server. Intermediate results such as heavy traffic warnings can 54

be computed within the network. As a result, two distinctive rout- 55

ing topologies based on content A and B are created in CCR. This 56

can help to reduce the amount of redundant data sent over the 57

network and also the time lag in the communication system, sav- 58

ing limited node energy and extending the network lifetime. 59

CCR provides a paradigm shift from traditional ways of data 60

collection to content oriented data aggregation and retrieval. This 61

change could bring several attractive advantages such as energy ef- 62

ficiency, fast system response, long network lifetime etc. and pro- 63

vides a way to solve the data explosion problem [5] for the fu- 64

ture IoT network. In [4] , we proposed a multi-objective function 65

to provide optimized in-network data aggregation with the aim of 66

reducing latency, load balancing and extending the network life- 67

time. Using which, each node can refine its routing strategy ac- 68

cording to neighbo ring traffic patterns and the energy availability 69

of the neighbo ring nodes. In addition, a routing candidate selection 70

mechanism was developed in order to avoid communication loops, 71

and the signa ling cost of local message gossiping is controlled to 72

conserve limited node energy and resources. With respect to our 73

previous work, in this paper, we further extend the analysis and 74

protocol explanations in [4] , including updated frameworks, sig- 75

naling and control message details, and trigger function flows etc. 76

Furthermore, we presented a possible integration of CCR in a real 77

industrial standard (the IETF RPL protocol [6] ). The implementa- 78

tion is based on the Contiki OS 2 and TelosB platform. Last but 79

not least, CCR is evaluated by both simulation and implementation 80

experiments. To the best of our knowledge, this paper is the first 81

to present how to implement a content based routing protocol for 82

in-network data aggregation. 83

The rest of the paper is organized as follows. Section 2 covers 84

the related work. In Section 3 , we present our models and assump- 85

2 Contiki is an operating system to network embedded devices. It is highly

portable and can be ported to more than 12 different microprocessor and micro-

controller architectures. [7]

tions following which we present the CCR protocol in Section 4 . 86

The CCR implementation and integration with RPL is illustrated in 87

Section 5 . The efficacy of the design is illustrated in Section 6 with 88

both simulation and emulation results. The paper finally concludes 89

in Section 7 highlighting some of the key findings. 90

2. Related work 91

Different from recent popular notion of Content-Centric Net- 92

working (CCN) or Named Data Networks (NDN) [8] –[10] which 93

has a aim of caching and subscribing data based on con- 94

tent rather than the host. The main focus of the proposed 95

CCR technology is to provide optimized routing topology to fa- 96

cilitate in-network data aggregation and reduce the network 97

traffic. 98

Routing and data aggregation mechanisms have received con- 99

siderable attention in the literature [3] , [11] in the context of wire- 100

less sensor networks. The existing body of work can be broadly 101

classified into two categories – centrali zed and distributed ap- 102

proaches. Centralized approaches [12] –[17] usually pre-compute 103

and construct the optimal appropriate routing structure before the 104

network starts to operate. In [13] , a network lifetime maximum ag- 105

gregation tree solution is proposed. Load balancing is considered 106

in [15] , and authors in [17] further took the aggregation computa- 107

tional cost into account. However, global network information is 108

often required for above literatures which can introduce signifi- 109

cant control overhead. In order to reduce control overhead, dis- 110

tributed clustering approaches such as [18] –[24] resort to forming 111

hierarchical routing topologies via local message gossiping. How- 112

ever, only a simple shortest path tree topology is adopted in [22] . 113

In [23] , a dynamic clustering based approach is proposed. How- 114

ever, the clustering process is triggered per event or application, 115

resulting in large transmission cost in forming the clusters. In ad- 116

dition, similar to the clustering approach, tree ( [13] , [14] , [25] ) or 117

Direct Acyclic Graph (DAG) [26] based approaches also require a 118

specific routing topology to operate, and hence limits their abil- 119

ities to cope with dynamic network conditions. This is because 120

each time a network change happens such as link breakage or 121

early energy depletion of some critical routing nodes, the network 122

topology information needs to be updated to reflect the prevail- 123

ing conditions. This, however, has the cost of introducing addi- 124

tional control traffic to the network as well as incurs additional 125

delays. 126




Y. Jin et al. / Computer Communications xxx (2016) xxx–xxx 3

ARTICLE IN PRESS


Fig. 2. Hop distance based ring topology [4] .

A key shortcoming of existing solutions is that they often as- 127

sume homogeneous network conditions, for example: homogenous 128

traffic or universal node processing capability. However, traffic is 129

dynamic in nature. Each time the traffic of an application changes 130

or a new application arrives, the optimized network structure 131

should, ideally, also be re-formed. In a dynamic environment with 132

multiple applications co-existing, different data aggregation paths 133

are required for efficient delivery of different types of data and 134

better organization of heterogeneous traffic flows. A pre-optimized 135

static structure cannot satisfy the requirements in such a scenario. 136

O 137

r 138

m 139

p140

141

s 142

w 143

a 144

t 145

d 146

c 147

i 148

c 149

o 150

t 151

n152

153

[ 154

o155

t156

d157

w158

w159

I160

w161

d162

M163

t164

w165

o166

3. System models and assumptions 167

3.1. Network model 168

We assume that nodes send data to a gateway node residing at 169

the centre of the topology. The gateway node is much more capa- 170

ble (e.g. in terms of processing power, memory etc.) than the indi- 171

vidual nodes themselves and has access to mains power. Nodes are 172

battery powered and have a finite and heterogeneous initial energy 173

supply E ( i ). Transmission power control is not enabled and there- 174

f 175

h 176

c 177

t 178

p 179

w 180

n 181

g 182

I 183

n 184

t 185

t 186

t 187

3 188

189

p 190

n the other hand, it is not computationally efficient to frequently

econstruct a global network topology or to compute and build

ultiple overlaid topologies because such approach would be ex-

ensive to maintain in lossy environments.

On a related note, a perfect channel condition is also usually as-

umed [4] , [21] , [27] , which may not always be the case in the real

orld as communication link quality can vary over time. Such an

ssumption can jeopardize the delivery of a message and can po-

entially result in re-transmissions which result in further energy

epletion. Routing packets based on link quality and connectivity

an improve communication reliability [6] but it does not necessar-

ly lead to energy efficient routing. Thus, in addition to improving

ommunication reliability, conserving the limited on-board energy

f the battery powered nodes is an important requirement in order

o keep the nodes alive and running in such resource constrained

etworks.

To overcome some of the problems above, the CCR algorithm

4] was introduced to provide content based information flow and

ptimized in-network data aggregation with the aim of avoiding

he transmission of redundant network traffic, reducing network

elay, conserving limited energy resource and extending the net-

ork lifetime. Furthermore, compared with our previous work [4] ,

e provide analysis on a possible integration of CCR in a real

oT protocol stack. CCR is modified such that it can be integrated

ith the RPL protocol and show its compatibility with a stan-

ard based protocol stack. Its effectiveness is evaluated via both

atlab simulation and more practical Contiki Cooja based emula-

ion. A small scale CCR implementation Demo based on real hard-

are (TelosB mote) was developed and demonstrated on various

ccasions.

p 191

j 192

c 193

p 194

i 195

t 196

e 197

c 198

n

p

T

R

Please cite this article as: Y. Jin et al., Content centric routing in IoT


ore all nodes have a fixed communication range. We also assume

eterogeneous node processing capability, e.g., a node may only be

apable of processing one or a few particular types of content due

o hardware or software constraints. In case a node receives a data

acket that it cannot process, it simply relays the packet. To begin

ith, the gateway broadcasts a radio ranging message to help the

odes ascertain how many hops away are they located from the

ateway. Nodes that receive this message are assigned with a layer

D. This layer ID represents the minimum hop distance between a

ode and the gateway. Subsequent to assignment of the layer ID,

he node forwards this message with its own layer ID included in

his message. Such a wave like propagation, results in the forma-

ion of a ring type of topology as shown in Fig. 2 .

.2. Application and aggregation mode

We mainly consider monitoring applications (multi-point to

oint data collection scenario) in this paper for data aggregation

urpose. All data packets associated to the same processing ob-

ective are termed as the packet of the same content, which then

an be processed by a corresponding processing node. For exam-

le, same type of data (temperature readings) gathered in a build-

ng can be treated as the same content if an application requires

he average building temperature. For simplicity, we assume that

ach application running in the network only has a single pro-

essing objective, but multiple applications can co-exist. A total

umber of K applications A = { a k | k = 1 , 2 , 3 , . . . } have the same 199

oisson arrival rate of λ, but with different running duration of 200

= { t k | k = 1 , 2 , 3 , . . . } and heterogeneous traffic traffic data rates 201

k . Depending on the accuracy requirement of an application, 202

networks and its integration in RPL, Computer Communications



ARTICLE IN PRESS


xampl

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

a 232

i 233

F 234

n 235

h 236

n 237

u 238

S 239

i 240

b 241

t 242

n 243

t 244

r 245

o 246

u 247

f 248

n 249

s 250

t 251

n 252

t 253

254

o 255

t 256

f 257

t 258

w 259

a 260

t 261

Fig. 3. Aggregation model e

different data aggregation functions can be applied considering

lossy or lossless aggregation processes [28] . For each node i with

processing function s , a generic data aggregation model is defined

below:

R

out i = ω s × R

in i

0 < ω s ≤ 1

(1)

where R in i

and R out i

represent the incoming and outgoing traffic

rate, respectively. ω s is the data aggregation or compression rate

depends on the processing function s . If ω s = 1 , it means that the

current content cannot be processed by s . ω s can also be a variable

depending on the processing function. For example, there may be

considerable correlation of data streams comprising data reports of

AVERAGE or MAX readings for monitoring applications, which can

aggregate multiple incoming messages into a single outgoing mes-

sage. In such cases, depending on the total received message num-

ber (assuming M ) on an aggregation node, ω s could be 1 M

. Never-

theless, we assume only messages from the same application can

be aggregated. For reasons, different data types may not be easily

processed or just not possible to do so in some cases. For example,

it is not meaningful to calculate the average value of a tempera-

ture and a humidity reading. An example of data aggregation can

be found in Fig. 3 .

In order to have a good data aggregation opportunity, it is as-

sumed that aggregation is carried out in a periodic manner at each

hop, i.e. each node waits for a pre-defined period of time to gather

information [29] and then performs the aggregation. A timeout

clock is used in case some packets get lost during transmission.

4. The proposed CCR protocol

CCR is a distributed process, when an application arrives at the

gateway following which a default routing structure is first used

to initiate data collection. The focus of the subsequent phases is

t 262

a 263

t 264

p 265



es for different applications.

bout optimi zing this routing structure. Each node has a probabil-

ty p t to refine its next hop relay by executing an objective function

. The node that intends to execute F (referred to as an objective

ode hereafter), first broadcasts a local query message to its one-

op neighbo ring nodes. The query message comprises the objective

ode’s outgoing traffic content types and corresponding traffic vol-

me, and the candidate selection criterion (TTGF bits described in

ection 4.3 ). The qualified next hop candidate will then respond to

t with an ACK message, which consists the information required

y F such as the responder’s ID and the estimated node lifetime of

he responder if the designated traffic was sent to that candidate

ode. Using this information as the input of the objective func-

ion, candidate rankings are produced and the one with the highest

anking is selected to relay the corresponding traffic. Finally, the

bjective node updates the routing table and broadcasts a route

pdate announcement message containing new next hop node ID

or corresponding traffic content. Subsequently, the new next hop

odes reply with JOIN ACK messages and the previous relay nodes

end LEAVE ACK messages. As a result of this process, an overlaid

ree topology for multiple traffic content types can be updated dy-

amically. Details of the message sequence signa ling involved in

his process is illustrated in Fig. 4 .

CCR’s operation includes three main functions: trigger function,

bjective function, and routing updates with loop detection func-

ion, and its system architecture is shown in Fig. 5 . The trigger

unction decides how frequently to execute the CCR objective func-

ion. It ensures a high execution frequency under dynamic net-

ork conditions in order to keep the routing table up-to-date, and

low execution frequency when the network stabilizes to reduce

he cost of local signa ling. Once the objective function is triggered,

he node queries its neighbo rs to provide some information such

s data traffic status, remaining battery power level and the con-

ent in their own routing tables. Using this information as the in-

ut of the objective function, candidate rankings are produced and




ARTICLE IN PRESS


Fig. 4. CCR signal ing messages.

the one with the highest ranking is selected to route the corre- 266

sponding content. Hence, the objective function constructs a sepa- 267

rate routing entry for each content in the routing table. Lastly, an 268

effective loop avoidance mechanism is designed in order to detect 269

c 270

s 271

f272

4273

274

o 275

b 276

I 277

m 278

b279

280

c 281

p 282

n283

W 284

r 285

t 286

t 287

o288

i 289

b290

291

c 292

v 293

� 294

o 295

e 296

u 297

m 298

i299

4.2. The objective function (F) 300

The objective function F is executed on an objective node i in 301

order to find out the most suitable next hop node j for each traf- 302

fic content k among N neighbo ring candidates. Since the traffic is 303

differentiated by its content type, the objective node maintains a 304

separate routing entry for each content k and updates it by exe- 305

cuting the objective function. Details of the objective function are 306

described as below in (3) . 307

F (k ) = max j∈ N

(

˜ g k j − g k j + β

˜ l k j − l j ∗

˜ l k j

+ ε k j

)

(3)

where the first term

˜ g k j − g k

j calculates the normalized communica- 308

tion data reduction via aggregation process which is called as the 309

marginal processing gain. The second term

˜ l k j −l j ∗˜ l k j

is the link quality 310

aware local network lifetime gain estimation; while β is a tuning 311

parameter to provide weights between the two parameters. Finally, 312

ε k j

is a reward parameter. We’ll explain each parameter in the fol- 313

lowing sections. 314

4.2.1. The processing gain 315

The first term in (3) , ˜ g k j

is the processing gain by allocating ap- 316

p 317

w 318

319

g

320

a 321

o 322

t 323

j 324

t 325

326

327

328

329

330

331

332

333

334

335

336

T 337

b 338

t 339

a 340

N 341

t 342

C 343

p 344

a 345

u 346

d 347

ommunication loops and conserve the limited amount of energy

tored at each node. Details of each function are described in the

ollowing sections.

.1. Trigger function

In dynamic network environments, most routing protocols peri-

dically update their routing information and keep the routing ta-

le up to date. This, however, incurs additional control overheads.

n resource constrained networks with lossy links, these signa ling

essages should be controlled in order to conserve limited on-

oard node energy.

The frequency of executing the objective function at a time t is

ontrolled by a probability p t . This probability is calculated inde-

endently on each node and does not require any local or global

etwork information. p t is defined as below:

p t = min

( (

t ∑

t 1

| �k | + 1

)

× p de fault , 1

)

(2)

here �k is the traffic content variation of each node at a time

ound. 3 t is the current time instance while t 1 is the previous

ime instance when the node ran the objective function. p default is

he default probability determined by system parameters, details

f this can found in Section 6.1.2 . An example of variation of �k

s shown in Fig. 6 (a), and the system function flow to execute F

ased on p t is illustrated in Fig. 6 (b).

Thus, the probability of executing the objective function in-

reases if a large value of �k is produced due to traffic content

ariation. On the other hand, when the network stabilizes (small

k ), the probability p t decreases. It becomes p default if no changes

ccur, which effectively reduces control overhead. This ensures that

ven in a slow changing environment, the routing table is still kept

pdated. Yet, the probability to execute the objective function is

uch lower in a stable network compared to a dynamically chang-

ng one.

3
A round is a basic time unit defined in this paper. s


lication content k ’s traffic to Node j , and g k j

is the processing gain

ithout allocating content k ’s traffic to j , where g k j

is calculated as:

k j =

∑

k ∈ K R

in j (k ) − ∑

k ∈ K R

out j

(k ) ∑

k ∈ K R

in j (k )

(4)

Basically, ∑

k ∈ K R in j (k ) and

∑

k ∈ K R out j

(k ) stand for the total

mount of incoming and outgoing traffic for total K applications

n Node j , respectively. Therefore, the numerator of (4) represents

he total amount of traffic reduction via data aggregation at node

. This value is then divided by the total incoming traffic. The ra-

ionale behind this parameter is:

• It is the normalization process which makes the marginal pro-

cessing gain numerically comparable with the local lifetime

gain (second term shown in (3) ) and therefore facilitates com-

putation of a multi-gain and,

• For load balancing purposes, it is preferable to relay traffic to

a node that can provide the same processing gain (reduce the

same amount of data), but with less traffic than is already as-

signed to it. In other words, with the same amount of reduc-

tion in traffic achievable through aggregation, the more incom-

ing traffic a node has, the smaller processing gain it can obtain.

An example illustrating the above concept is shown in Fig. 7 .

wo applications ( a 1 & a 2 ) are collecting data in a network formed

y 6 nodes. Nodes 1 –3 are the source nodes of a 1 and Node 4 is

he source node for application a 2 . It is assumed that both Nodes 4

nd 5 can process a 1 and a 2 with ω a 1 = ω a 2 = 1 /M. 4 Assume that

ode 3 is executing the objective function to determine which of

he two nodes (Node 4 or Node 5) should forward its traffic ( a 1 ).

learly, in this example, Node 5 will be selected as it has a better

rocessing gain due to the fact that it is only ferrying traffic for

single application type and therefore can aggregate information

nlike Node 4 which cannot aggregate traffic as it is transporting

ata for two different types of application.

4 M is the total number of messages received for the same application as de-

cribed in Section 3.2.




ARTICLE IN PRESS


Fig. 5. CCR architecture and operational difference.

ic trig

348

349

350

351

352

353

354

355

l 356

i 357

i 358

4 359

360

c 361

e 362

Fig. 6. Dynam

By taking advantage of the processing gain, the amount of com-

munication traffic can be reduced by aggregating correlated data.

However, this does not necessarily imply that a longer network

lifetime can be achieved because energy consumption could be

higher if the selected link has a very poor channel quality. Fur-

thermore, heterogeneous node energy levels need to be consid-

ered as, in principle, if a node is equipped with more energy it

can relay and process more information compared with those with



ger function.

ess on-board energy. Therefore, another parameter is introduced

n the objective function shown in Eq. (3) , known as the link qual-

ty aware local lifetime gain.

.2.2. Link quality aware local lifetime estimation

Due to the inherent nature of the wireless medium, link quality

an vary. There are various link quality estimation methods. For

xample, ETX (Expected Transmission count) [30] is a popular link




ARTICLE IN PRESS


Fig. 7. Examples for p

quality/reliability parameter used in many routing protocols such 363

a 364

a365

366

a 367

t 368

l 369

w 370

p 371

t372

373

a 374

N375

l

w 376

t 377

t 378

r 379

t 380

F 381

t 382

o 383

j 384

c 385

h 386

n387

e

w 388

f 389

U 390

e391

392

o393

e

w 394

o395

c396

p397

4 398

399

m 400

n 401

t 402

o 403

w 404

t 405

w 406

ε

407

c 408

t 409

a 410

w 411

d 412

F 413

c 414

p 415

i 416

s 417

t 418

r 419

c 420

4 421

422

fi 423

t 424

o 425

i 426

c 427

‘ 428

w 429

a 430

s 431

n 432

distributed processing and to reduce the network traffic volume. 433

s RPL [6] . ETX is the average number of transmissions required by

sender to successfully deliver a message to the destination.

Since the ETX value of a link can be easily converted to the

verage amount of energy spent on transmissions per packet via

hat link, we chose this parameter to assess the communication

ink quality. This further contributes to estimation of the local net-

ork lifetime. Even though ETX is used in this work, it should be

ossible to use other link quality metrics with simple modification

o the estimation function.

The local lifetime gain parameter ˜

l k j −l j ∗˜

l k j

shown in (3) is defined

s the minimum node lifetime among the objective node i and its

qualified neighbo ring candidate nodes.

= min

(E i e i

, min

j∈ N

(E j

e j

))(5)

here E i and E j is the current battery energy level for the objec-

ive node and the candidate node respectively; and e i and e j is the

otal energy consumption including processing, transmission and

eception costs. In (3) , l j ∗ stands for the current local network life-

ime which can be simply obtained via the query process shown in

ig. 4 . While ˜ l k j

is the estimated local network lifetime if the con-

ent k ’s traffic is allocated to a new candidate j rather than j ∗. In

rder to calculate ˜ l k j , the estimated energy consumption of the ob-

ective node ˜ e i and each candidate node ˜ e j have to be estimated by

onsidering switching the content traffic k from the current next

op node j ∗ to a new candidate node j . Thus, for each candidate

ode j ( j � = j ∗), ˜ e k i

can be calculated as:

˜

k i

= e ∗i − (ET X

j ∗

i − ET X

j i ) × U

k × e t (6)

here ET X j ∗

i and ET X

j i

stand for the ETX value of the current link

rom i to j ∗ and the link from i to a candidate node j respectively,

k is the total amount of data for traffic k and e t is the average

nergy consumption to transmit one bit of data.

Similarly, the estimated energy consumption

˜ e k j

( j � = j ∗) can be

btained as shown in (7) .

˜

k j = e ∗j + U

k × e r + U

k × e p + ET X

NextHop j

× U

k p × e t (7)

here e r , e p are the energy consumption to receive and process

ne bit of data and, U

k p is the amount of additional data after pro-

essing which j has to send to its next hop node. If node j cannot

rocess content k , then U

k p = U

k . l



rocessing gain.

.2.3. Reward parameter ε The reward parameter ε k

j is introduced in order to accom-

odate the heterogeneous processing capability of nodes. Certain

odes, for example, may only be capable of processing specific

ypes of content, due to hardware or software constraints, while

ther nodes may not be able to process any type of data. The re-

ard parameter ε k j

is used to give additional credit for a node j

hat can process the corresponding content k . The value of the re-

ard parameter is set as follows:

k j =

{0 , if j cannot process k

σ, if j can process k ( σ is a constant)

Please note that the marginal processing gain in F already gives

redit to a Node j that is able to process content k , providing a

raffic reduction of k can be produced on j . Therefore, even in the

bsence of the reward parameter, traffic is more likely to be for-

arded to nodes that are capable of processing the data in ad-

ition to merely relaying it. An example of this is illustrated in

ig. 8 (a). 5 However, if a Node j has the capability of processing

ontent k but there is currently no other traffic k routed via j , the

rocessing gain is zero because there is no traffic reduction. In this

nstance, the reward parameter can help to ensure that traffic is

till forwarded to that Node j as shown in Fig. 8 (b). Thus, although

he value of σ could be relatively small compared to the other pa-

ameters in F , it provides a bias to forward traffic to nodes that are

apable of processing the particular type of content in question.

.3. Candidate selection and loop avoidance

Communication loops can cause several problems such as traf-

c congestion, packet loss (due to Time-To-Live expiry), and addi-

ional energy consumed in repeatedly processing and transmission

f looping messages. In RPL [6] , a popular routing protocol used

n lossy wireless networks, a message header is used to detect

ommunication loops. RPL does not allow messages to be routed

down’ to a child node, if these are supposed to be sent ‘up’ to-

ards the root. If a loop is detected, the message is discarded

nd a local repair is carried out. However, such a loop avoidance

cheme limits the number of neighbo rs that can be selected as the

ext hop relay. Consequently, this limits the possibility to perform

5 Note that for simplicity, in this example, the link quality aware local network

ifetime estimation is omitted from consideration.




ARTICLE IN PRESS


Fig. 8. Example of the benefit of ε.

Fig. 9. Example shown the advantage of TTGF loop avoidance.

To overcome this limitation, we introduce the Time-To-Go-Forward 434

(TTGF) in order to select appropriate neighbo ring nodes (as candi- 435

date next hop nodes) that would respond to the local query mes- 436

sage and avoid communication loops. TTGF relaxes the restriction 437

introduced in RPL that traffic bound for upward nodes cannot be 438

routed to a downward node, provided a higher processing gain can 439

be achieved within the TTGF tolerance range. Fig. 9 shows an ex- 440

ample of the difference between the TTGF approach ( Fig. 9 (a)) and 441

the conventional RPL loop avoidance approach ( Fig. 9 (b)). 442

443

4 4 4

445

446

447

448

449

450

is forwarded on the way to the sink. If a successful forward trans- 451

mission is made (the current/recipient node layer ID < TTGF layer 452

ID), the value of the TTGF layer ID is updated by the current node 453

layer ID. The TTGF count works as a ‘count down’ parameter. In 454

case the recipient has the same or higher node layer ID compared 455

to the TTGF layer ID, the message has not reached ‘closer’ to the 456

sink. Therefore, the TTGF count is reduced by one. Once the TTGF 457

count reaches zero, only those with a lower layer ID compared to 458

the objective node’s layer ID can be chosen as the next hop can- 459

d 460

T 461

462

t 463

T 464

f 465

t 466

h 467

TTGF is a similar notion to the Time-To-Live (TTL) metric which

can be added to the header of the data packet. It works together

with the node layer ID, which represents the minimum number

of hops required for each node to reach the sink. Details of how

to obtain this node layer ID is described in Section 3 . TTGF con-

tains two parameters: (1) the TTGF layer ID, (2) the TTGF count.

The TTGF layer ID points to the lowest node layer ID that a mes-

sage reaches. The value of TTGF layer ID is updated as the packet



idate. The TTGF count is set to the preset default value once the

TGF layer ID is updated.

By using TTGF, we allow messages to be relayed to nodes with

he same or even higher depth of the network layer within the

TGF tolerance value, such that a proper processing node can be

ound in order to aggregate data. On the other hand, if a message

hat has not been forwarded any ‘closer’ to the sink within TTGF

ops, is forced to do so by selecting a lower layer node as the next




ARTICLE IN PRESS


voidan

h 468

c 469

f 470

I 471

o 472

t 473

t 474

1 475

a 476

s477

5478

5479

480

i 481

I 482

m 483

r 484

t 485

r 486

D 487

c 488

D 489

p 490

w 491

D 492

t 493

a 494

d 495

t 496

t 497

a 498

u 499

5 500

501

i 502

t 503

n 504

f 505

s 506

r 507

a 508

t 509

510

a 511

d 512

p 513

C 514

f 515

516

m 517

a 518

s 519

t 520

i 521

m 522

For each content (RPL instance) c , the root node first starts ad- 523

vertising the information about the DODAG graph using the DIO 524

message. Any node within the listening vicinity receives the mes- 525

sage, and then it processes the message and makes a decision 526

Fig. 10. Loop a

Fig. 11. The integration of CCR components into Contiki and RPL architecture.

op candidate. An example of using TTGF is shown in Fig. 10 . In

ase of event (a) shown in Fig. 10 , a forward transmission is made

rom node 1 (layer 3) to node 4 (layer 2). Hence, the TTGF layer

D becomes 2 and TTGF count is set to default. Therefore, all the

ne hop neighbo ring nodes apart from the previous sender can be

he next hop candidate for node 4. For case (b) shown in Fig. 10 ,

he TTGF layer ID is the same while the TTGF count is reduced by

and becomes 0 when it reaches node 4. Thus, only those with

lower layer ID (Node 5 and 6) are qualified for the candidate

election and respond to the query message.

. CCR implementation and integration in RPL

.1. Summery of RPL

The Routing Protocol for Low-power and Lossy Networks (RPL)

s developed and standardized by IETF for enabling connectivity in

oT mesh networks. RPL uses a proactive process to construct and

aintain a Destination-Oriented Directed Acyclic Graph (DODAG)

outing topology, where the data concentrator sits at the root of

he DODAG and the edges form a path from each node to the DAG

oot. The DODAG construction starts with the root broadcasting a



ce with TTGF.

IO (DODAG Information Object) control message. Any node re-

eived this message can choose to join the DODAG by adding the

IO sender to its parent list, and computes its rank relative to the

arent node based on an objective function. It then further for-

ard the DIO message with updated rank information. Once the

ODAG is in place, nodes can send data via their relay parents un-

il it reach the root. If the network is in a steady state, RPL uses

low-rate DIO beacon process controlled by Trickle timer in or-

er to maintain the DODAG routing topology. However, RPL would

emporarily increase the DIO sending frequency by resetting the

ricker time if network inconsistencies were detected. This process

llows RPL to dynamically adjust its control operations and reduces

nnecessary control overheads.

.2. CCR’s operation in Contiki RPL

In the following, the integration of CCR components into the

ndustrial RPL protocol is described. The detailed system architec-

ure is shown in Fig. 11 , where our contributions are highlighted,

otably we have: a) Developed a content based objective function

or the RPL protocol; b) Enabled multiple RPL instances on the

ame RPL root, such that messages with different content types are

outed via different RPL DODAG instances. c) Caching, processing

nd forwarding functions are added to the network layer to facili-

ate in-network data aggregation. Details are described below.

There are a few ways to implement CCR, one way is to specify

content Byte in the packet routing header, and the procedures

escribed in Section 4 can be used. However, a standard based im-

lementation is more promising. Therefore, we adopt the existing

ontiki RPL standard as a baseline, which is augmented with more

unctionality without affecting backwards compatibility.

To meet Contiki RPL’s implementation style, we revised CCR’s

essaging exchange procedure and adopted the existing DIO

nd DAO (DODAG Destination Advertisement Object) control mes-

ages proposed in RPL. In addition, since RPL supports multi-

opology routing over the same physical mesh network by using an

nstance-id, we assign instance-id to each content type and create

ultiple overlaid routing topologies (DODAGs) based on content.




ARTICLE IN PRESS


whether or not to join the graph according to the objective func- 527

tion. Node rank is computed representing the relative position in 528

the DODAG with respect to the root. For simplicity, the objective 529

function in (3) is simplified for CCR implementation and the node 530

rank for each instance c can be calculated as per (9) . 531

R Node (c) = R parent (c) − N content (c) ∗ ω + O rank (c) ∗ η + BaseHop

(9)

where R parent is a parent node’s rank; N content is the total num- 532

ber of child nodes associated with the parent node for the same 533

content c (parent node is inclusive if it is also the source node of 534

content c ). This means if a parent node having more children for 535

the same content, it would have a larger value of N content , hence a 536

lower rank (a better parent) in the DODAG graph; O rank stands for 537

any other objective function (3) related parameters, for instance, 538

ETX or Residual battery level etc.; ω and η are weighting parame- 539

ters; and BaseHop is a constant. If BaseHop is not equal to 0, the 540

R Node increases by adding more hops. 541

An example of CCR based multi-DODAG construction is shown 542

in Fig. 12 , where Nodes 2, 4, 7, generates content A, Nodes 3, 5, 6, 543

generate content B, and Node 8 generates both content A and con- 544

tent B. The initial single DODAG routing topology without CCR is 545

shown in Fig. 12 (1). Now, when we apply CCR, different instance- 546

ids are given to content A and content B, hence the DODAG shown 547

in Fig. 12 (1) can be separated into two as shown in Fig. 12 (2) and 548

(3). For simplicity, we assume O rank = 0 , root rank is 10, and Base- 549

Hop is set to 4. Each parent will pass its own rank ( R parent ) along 550

with the Content factor ( N content ) in the DIO message. Let us take 551

content A for example as shown in Fig. 12 (3). Since the root node 552

only has Node 2 to provide content A messages, the rank of Node 553

2 R 2 ( A ) can be calculated by using (9) as R 2 (A ) = R root (A ) − 1 + 4 = 554

13 . Similarly, the rank of Node 4 and Node 5 can be calculated ac- 555

cordingly. Now, in order to choose the best parent for Node 8, it 556

needs to calculate its rank based on whether to choose Node 4 or 557

Node 5 as its parent. Since, there would be 3 nodes (Nodes 4, 7, 558

8) sending content A messages to Node 4, hence N content (A ) = 3 . 559

In contrast, Node 5 would only have Node 8 to send content A 560

packets if it was chosen as parent, therefore N content (A ) = 1 . Obvi- 561

ously, Node 4 is a better parent compared with Node 5 based on 562

the objective function. As a result, Node 8 will switch its parent 563

from Node 5 to Node 4 as shown in Fig. 12 (5). Same parent se- 564

lection process is carried out for Content B in Fig. 12 (2) and (4). 565

Eventually, two distinctive DODAGs for content A & B are formed 566

as shown in Fig. 12 (6). 567

5.3. CCR core modules 568

Memory allocation : a set of memory blocks is statically allocated 569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

Table 1

Energy consumption of different operations per

Byte.

Operations Energy consumption ( μJ)

Transmission 9.72

Reception 8.22

Flash write 0.445

Flash read 0.315

Data aggregation 0.0011

the corresponding content is reached, or a timeout() is triggered. 588

The processed data will be forwarded based on the destination IP 589

address and destination port. 590

6. Performance evaluation 591

6.1. Simulation results 592

A simulation based study was first carried out in order to eval- 593

uate the performance of the proposed CCR protocol with the con- 594

ventional methods. A global network lifetime maximization tree 595

algorithm [27] (referred to as Static Tree hereafter) and the tradi- 596

tional centralized processing scheme (referred to as Central here- 597

after) were chosen as benchmarks. 598

The Static Tree is a centralized algorithm which pre-constructs 599

a maximum-lifetime data gathering tree before the network starts 600

to operate. In order to achieve a fair comparison, we added the 601

data aggregation to the Static Tree approach. In addition, since 602

global knowledge is required to perform the optimization for Static 603

Tree, which can be very time consuming to re-compute the op- 604

timal tree each time there is a change in the network such as 605

node/link failures. To mitigate this issue, we slightly modified the 606

static tree algorithm to adapt to such failure cases, and apply a 607

simple but fast recovery mechanism to randomly choose the next 608

hop node with a lower layer ID if a failure event happens. On the 609

other hand, the central algorithm first gathers all the data at the 610

sink and then carries out processing to compute the results. 611

6.1.1. Simulation parameters 612

Unless specified otherwise, a network deployment compris- 613

ing of 200 nodes with nodes being uniformly distributed with a 614

200 × 200 m

2 area was assumed. Three applications with hetero- 615

geneous traffic rates were considered in the simulations. Nodes 616

were assumed to have unequal energy levels at the startup time 617

in the r ange 4 –6 J. The TTGF count was set to 2 and the con- Q3

618

trol packet size was assumed to be 500 bits. p default was set to 619

0 620

t 621

t 622

d 623

b 624

i 625

w 626

c 627

f 628

T 629

w 630

r 631

c 632

s 633

9 634

T 635

w 636

for buffers, caches, and other data structure to handle CCR’s com-

munication.

Content entry : this module includes three main functions,

Node_Has_Content( ), ∗Content_Type_Get() and Node_Add_

Content( ). The first function checks whether a parent Node has

already cached the same content of a received message from its

child. If so, the second function is called to retrieve the pointer

pointing to the corresponding content in the memory. Otherwise,

the Node_Add_Content( ) is used to allocate memory to the new

content. Due to memory limitation of the Hardware platform, the

maximum number of content is set to 3 in this implementation.

Content caching : a content table is built with an unique index

assigned to each content object. The received packet payload is

then copied to the content table with a matching to the corre-

sponding content type.

Content processing and forwarding : cached data for each content

will be processed if the parent node receives packets from its chil-

dren or the maximum number of message stored in the buffer for m



.05 and the value of β was set to 2. A simple data aggrega-

ion function which computes the maximum and the average of

he sensed values was considered in the simulations. A variable

ata aggregation rate ω =

1 M

was used, where M is the total num-

er of messages received for the same application on a process-

ng node. Tmote Sky node was chosen as our basic node model

hich is equipped with an MSP430 processor and CC2420 radio

hip. The energy consumed by the different operations (per Byte)

or the Tmote Sky platform are adopt from [31] , [32] and listed in

able 1 . Finally, the performance of the proposed CCR algorithm

as compared with a centralized lifetime maximization tree algo-

ithm [27] (referred to as Static Tree hereafter) and the traditional

entralized processing scheme (referred to as Central hereafter). All

imulation results were averaged from 200 test runs which show

9% confidence interval with about mean-value ± 10% precision.

he implementation experiments were run for more than 40 times

hich show 95% confidence interval within ± 10% of the sample

ean. 637




ARTICLE IN PRESS


ilding

Fig. 12. Mutil-DODAG graphs bu



process based on content types.




ARTICLE IN PRESS


nd β

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

d 665

f 666

m 667

6 668

669

d 670

t 671

e 672

t 673

fi 674

d 675

t 676

p 677

t 678

t 679

s 680

c 681

t 682

S 683

t 684

r 685

i 686

t 687

n 688

o 689

n 690

m 691

a 692

c 693

C 694

o 695

T 696

p 697

i 698

6 699

700

w 701

t 702

a 703

t 704

n 705

t 706

t 707

A 708

s 709

t 710

i 711

q 712

Fig. 13. Impact of p a

Fig. 14. Energy consumption per round for different processes.

6.1.2. Impact of p default and β on lifetime

To begin with, simulations were run to determine the probabil-

ity p default of executing the objective function F , and the weight pa-

rameter β to decide the tradeoffs between the processing gain and

the local lifetime gain. p t = p de fault when the network is in a sta-

ble status. Intuitively, a larger value of p default gives more chances

for each node to select the best hop candidate in terms of having

a higher processing gain as well as a balanced lifetime. However,

as seen from Fig. 13 (a), the network lifetime first increases when

p default is set to 0.05, but then it drops very quickly as the value of

p default further increases. This stems from the fact that when p default

increases, more energy is spent on the control overhead to gather

local information in order to execute F . As evident from Fig. 13 (a),

the energy consumption related to the increased control overhead

also increases linearly with p default which implies that the node en-

ergy depletes.

A suitable value of β is also needed as it has an impact on

the local lifetime gain. A large value of β puts more weight on

the local network lifetime gain which consequently produces a

smaller value of F for the bottleneck node. However, when β is

large enough to avoid overloading the bottleneck node, this in-

crease of β value has no further impact on the network lifetime

as evident from Fig. 13 (b).

Therefore, application or network specific configurations might

be required before the network start to operate. Nevertheless, such

simple configuration is acceptable by the industry, for example, the

Trickle timer parameter can be tuned in the RPL protocol in or-



on network lifetime.

er to achieve the best performance result. Please note that in the

ollowing experiments, corresponding p default and β values deter-

ined in this section are used.

.1.3. Energy consumptions

Simulations were run to identify the contribution of each of the

ata processing, flash read/write and communication operations to

he total energy consumption. Fig. 14 shows the per round en-

rgy consumption of processing, flash read/write and communica-

ion operations and, the sum total of these. It is evident from this

gure that the energy consumed by communications significantly

ominates the energy consumed by the other operations. The cen-

ral algorithm gathers all the data at the sink and then carries out

rocessing as a result of which it exhibits the highest communica-

ion cost. By taking advantage of content-centric data aggregation

o reduce the volume of data that needs to be transported, CCR

aves more than half of the energy spent on communication in

omparison to the Central approach, about a third in comparison

o Static tree. Although in-network data aggregation is enabled in

tatic Tree, it still incurs higher communication cost in comparison

o the proposed algorithm. This is because it employs a centrali zed

outing optimi zation approach, i.e. tree does not adapt to changes

n the underlying network (traffic dynamics). Global knowledge of

he network is needed to perform the optimization. In a dynamic

etwork environment, it can be time consuming to recompute the

ptimal tree each time there is a change in the network such as

ode/link failures, or arrival of a new application. Thus, the perfor-

ance of the pre-optimized network topology in the Static Tree

pproach degrades over time. Furthermore, since the processing

ost is too small to be spotted in Fig. 14 , we point out that the

entral approach spent only 31 μJ of energy on processing. This is

nly half of the processing cost compared with CCR and Static tree.

he key point to take note of here is that even a small increase in

rocessing cost for CCR and Static tree translates to large increase

n energy saving gains on communication.

.1.4. Network lifetime

The network lifetime is defined as the time duration between

hen the network starts to operate until the first node dies due

o energy depletion. As evident from this Fig. 15 (a), CCR provides

significant increase in network lifetime compared with the other

wo. Furthermore, we observe that CCR has a smaller gap when the

etwork is scaled from 100 nodes to 300 nodes. This boils down

o the ability of CCR to reduce considerable amount of traffic in

he network as a result of using content-centric data aggregation.

dditionally, Fig. 15 (b) shows the total energy spent on retransmis-

ions per simulation round. As evident from this figure, CCR spends

he least amount of energy on retransmissions. This is attributed to

ts ability to form a more reliable routing topology by taking link

uality into account. The central algorithm has the highest energy




ARTICLE IN PRESS


Fig. 15. Network lifetime comparison.

spent on retransmissions due to heavy traffic on links. However, 713

it drops significantly at the latter stage. This stems from the fact 714

that the number of alive nodes in the network is significantly de- 715

creased, hence less traffic is generated in the network compared 716

to the other two. Finally, the number of alive nodes against sim- 717

ulation time is shown in Fig. 15 (c). Clearly, CCR conserves more 718

energy resources for nodes which is vital for resource constrained 719

devices. 720

6.1.5. Graphical network traffic comparison 721

Fig. 16 provides visualized traffic maps for a simulated network Q4

722

with nodes generating three different types of contents. The line 723

width in the traffic map represents the volume of data flowing 724

through that link, i.e., the thicker the line, the higher the volume of 725

traffic flowing through it. Nodes marked by red color in each con- 726

tent traffic map are those that can process the corresponding con- 727

tent. By using CCR, it can be observed that traffic flows of the same 728

content are more likely to be routed to those red processing nodes 729

and correlated data is more likely to be aggregated within the net- 730

work resulting a much less traffic amount as shown in Fig. 16 . 731

Fig. 17 provides traffic map comparison at different network op- 732

eration time instances. The ‘x’ mark indicates a dead node that has 733

already depleted its energy. We can see that the Central approach 734

has much heavier communication traffic compared with CCR. In 735

addition, since the nodes in the area that are closer to the sink 736

need to relay information for those located in the outer region. 737

Massive traffic can be observed at the centre of the network for 738

the Central method. This could easily cause the hot-spot problem, 739

while CCR and Static tree have much less communication data vol- 740

ume after aggregation. Furthermore, by observing the number of 741

dead nodes in Fig. 17 , we can clearly tell that CCR performs much 742

Table 2

Experiment setup.

Experiment setup Parameters

High data rate 1 Packet per second per node

Low data rate 1 Packet per 5 seconds per node

Traffic type CBR

Number of nodes 10(3Hops), 15(4Hops), 20(5Hops)

Types of contents 2

Maximum cached messages per content 3

Baseline benchmark RPL

better in conserving node energy as well as in providing full net- 743

work coverage. 744

6.2. Implementation results 745

In this section, we experiment on the evaluation of CCR’s per- 746

formance in Contiki Cooja Emulator based on the TelosB (also 747

known as Tmote Sky) Platform. A screen shot of the emulator is 748

shown in Fig. 18 and details of the experiment setup are shown 749

in Table 2 . Since it is not straight forward to implement the Static 750

Tree in contiki cooja, we choose the RPL standard as the main com- 751

petitor in our implementation based experiments. Similar to the 752

Central approach, RPL does not process data while routing packets. 753

Fig. 19 presents the number of average transmitted packets over 754

a 10 s of period in the network. It can be observed that CCR is 755

able to significantly reduce the amount of traffic. As a results, CCR 756

spends less energy on communication and prolongs network life- 757

time as shown in Fig. 20 . Although it can be noticed that CCR 758

outperforms RPL in extending the network lifetime, the perfor- 759

mance gain is reduced compared with our simulation results. This 760





ARTICLE IN PRESS


Fig. 16. Network traffic maps with 3 different contents. (For interpretation of the referen

affic m

761

762

763

764

765

766

767

768

769

770

771

772

773

774

775

776

777

778

i 779

d 780

t 781

d 782

t 783

f 784

o 785

i 786

b 787

t 788

a 789

a 790

6 791

792

w 793

c 794

Fig. 17. Graphic comparison of tr

is mainly due to the reason that we adopted the RPL based mes-

sage signaling in order to make it compliant with the standard.

However, this incurs additional costs on control overhead.

Two additional experiments were conducted in this implemen-

tation evaluation, which could not be performed in the previous

simulation based tests. We first measure the average packet de-

lay. In this test, a special message is generated on the farthest leaf

node, the average reception time on the root node is recorded. In

order to have a correct and fair measurement of network latency,

this special message is not cached in CCR as this incurs additional

waiting time, while the other messages are cached and processed

in the network. The results obtained are shown in Fig. 21 .

Although the network latency increases when the number of

hops increases in the case of both approaches (CCR & RPL), CCR

outperforms RPL in both low data rate case and high data rate

case. This is because the network is less congested by using CCR,

therefore a low network latency can be achieved. We also observe

that the magnitude of the improvement increases with an increase



ces to color in this figure, the reader is referred to the web version of this article).

aps at different time instances.

n the scale of the network. With 5 Hops (20 nodes) and high

ata rate setting, CCR can provide as much as twice the reduc-

ion in network latency. This indicates the scalability of CCR in

ense deployments. We further measured the packet delivery ra-

io and the outcome is illustrated in Fig. 22 . RPL has a rapid per-

ormance degradation when the number of nodes increase to 20,

nly 46% and 20% of the messages will eventually reach the sink

n the low data rate and high data rate case, respectively. This is

ecause the central area is highly congested due to heavy network

raffic, which RPL is not able to accommodate. In contrast, CCR still

chieves over 90% of PDR in the low data rate case with 20 nodes

nd 60% of PDR in high data rate case.

.3. CCR demonstration

Finally, we ported our implementation codes to the real hard-

are (TelosB node) and developed a Demo. Since it is very

hallenging to deploy a large-scale multi-hop network with real




ARTICLE IN PRESS


uation on Contiki Cooja.

result

Fig. 18. CCR’s eval

Fig. 19. Experimental



s – aggregation gain.




ARTICLE IN PRESS


Fig. 20. Experimental results – network lifetime.

Fig. 21. Experimental results – network latency.

esults

Fig. 22. Experimental r



– packet delivery ratio.




ARTICLE IN PRESS


Fig. 23. CCR demo steup.

hardware nodes, as a first step we found a hybrid solution with 795

a Contiki Cooja emulator emulating a large-scale mesh network 796

along with a few physical nodes to form the outer part of the mesh 797

network. Both the physical node and emulated node are running 798

the same CCR code. The boarder router of the physical network is 799

connected to one of the leaf nodes emulated in the Contiki Cooja 800

emulator. Hence, all packets sent by the telosB motes will route 801

through both the small scale real mesh network and the emu- 802

lated large-scale wireless mesh network. By such approach, we can 803

demonstrate CCR technological benefit for a large scale mesh net- 804

work, a demo setup picture can be seen in Fig. 23 . We have suc- 805

cessfully showcased the CCR demo in various occasions including 806

Venturefest Bristol and Bath, 2015. 807

7. Conclusion 808

In this paper, we proposed and studied the performance of an 809

efficient data aggregation and reliable data delivery scheme CCR 810

for a deployment scenario where data from the IoT network end- 811

points such as sensors have to traverse over wireless lossy links on 812

the way to the other endpoint hosting the IoT application. In par- 813

ticular, CCR is a distributed approach which considers the traffic 814

reduction gain achieved through content-centric data aggregation 815

when routing traffic over reliable communication links by incor- 816

porating link quality information. Based on the content of a mes- 817

sage, each node constructs a separate routing entry for each con- 818

tent type by running the proposed novel objective function; the 819

key idea being to route heterogeneous types of content via selected 820

reliable communication links to nodes which are capable of aggre- 821

gating and processing the information before forwarding the sum- 822

mary information. This greatly reduces redundant communication 823

traffic and reduces retransmissions as a positive side-effect. Both 824

simulation and implementation results confirm that CCR can sig- 825

nificantly extend the network lifetime, reduce network latency and 826

improve communication reliability. 827

For future work, hardware motes using the CCR protocol will 828

be deployed in our office premises in order to collect more data. 829

In addition, the impact of the number of content types will be in- 830

vestigated with the support of new hardware with larger memory. 831

Last but not the least, technologies such as data mining, fuzzy logic 832

will be explored to support in-network processing. We expect the 833

performance of CCR to improve further with the implementation 834

of more advanced processing functions and a better content defi- 835

nition supporting more content types in the network. 836

Uncited Refrerences 837

Ref. [9] , [16] , [19] , [20] 838

References 839

[1] D. Datla, X. Chen, T. Tsou, S. Raghunandan, S. Hasan, J. Reed, C. Dietrich, 840 T. Bose, B. Fette, J. Kim, Wireless distributed computing: a survey of research 841 challenges, IEEE Commun. Mag. 50 (1) (2012) 144–152, doi: 10.1109/MCOM. 842 2012.6122545 . 843

[2] J. Yick, B. Mukherjee, D. Ghosal, Wireless sensor network survey, Comput. 844 Netw. 52 (12) (2008) 2292–2330. 845

[3] E. Fasolo, M. Rossi, J. Widmer, M. Zorzi, In-network aggregation techniques for 846 wireless sensor networks: a survey, IEEE Wirel. Commun. 14 (2) (2007) 70–87, 847 doi: 10.1109/MWC.2007.358967 . 848

[4] Y. Jin, P. Kulkarni, S. Gormus, M. Sooriyabandara, Content centric and load- 849 balancing aware dynamic data aggregation in multihop wireless networks, in: 850 Proceedings of the IEEE 8th International Conference on Wireless and Mobile 851 Computing, Networking and Communications (WiMob), 2012. 852

[5] C. Alvarado, J. Teevan, M.S. Ackerman, D. Karger, Surviving the Information Ex- 853 plosion: How People Find Their Electronic Information, MIT, USA, 2003. 854

[6] T. Winter, P. Thubert, etal, Rpl: Ipv6 Routing Protocol for Low-power and Lossy 855 Networks, (rfc 6550), http://www.ietf.org/rfc/rfc6550.txt , 2012. 856

[7] A. Dunkels, B. Gronvall, T. Voigt, Contiki – a lightweight and flexible operating 857 system for tiny networked sensors, in: Proceedings of the 29th Annual IEEE 858 International Conference on Local Computer Networks, 2004.

Q5

859 [8] CCNx Project, http://www.ccnx.org/ 860 [9] G. Mishra, M. Dave, A review on content centric networking and caching 861

strategies, in: Proceedings of the 2015 Fifth International Conference on Com- 862 munication Systems and Network Technologies (CSNT), 2015, pp. 925–929, 863 doi: 10.1109/CSNT.2015.119 . 864

[10] G. Xylomenos, C. Ververidis, V. Siris, N. Fotiou, C. Tsilopoulos, X. Vasilakos, 865 K. Katsaros, G. Polyzos, A survey of information-centric networking research, 866 IEEE Commun. Surv. Tutor. 16 (2) (2014) 1024–1049, doi: 10.1109/SURV.2013. 867 070813.0 0 063 . 868

[11] R. Rajagopalan, P. Varshney, Data-aggregation techniques in sensor networks: 869 a survey, IEEE Commun. Surv. Tutor. 8 (4) (2006) 48–63, doi: 10.1109/COMST. 870 2006.283821 . 871

[12] S. Lindsey, C. Raghavendra, K. Sivalingam, Data gathering algorithms in sensor 872 networks using energy metrics, IEEE Trans. Parallel Distrib. Syst. 13 (9) (2002) 873 924–935, doi: 10.1109/TPDS.2002.1036066 . 874

[13] H.-C. Lin, F.-J. Li, K.-Y. Wang, Constructing maximum-lifetime data gathering 875 trees in sensor networks with data aggregation, in: Proceedings of the 2010 876 IEEE International Conference on Communications (ICC), 2010, pp. 1–6, doi: 10. 877 1109/ICC.2010.5502286 . 878

[14] H.O. Tan, I. Körpeo ̌glu, Power efficient data gathering and aggregation in wire- 879 less sensor networks, SIGMOD Rec. 32 (4) (2003) 66–71, doi: 10.1145/959060. 880 959072 . 881

[15] J. He, S. Ji, Y. Pan, Y. Li, Constructing load-balanced data aggregation trees in 882 probabilistic wireless sensor networks, IEEE Trans. Parallel Distrib. Syst. 25 (7) 883 (2014) 1681–1690. 884



http://dx.doi.org/10.1109/MCOM.2012.6122545

http://dx.doi.org/10.1109/MWC.2007.358967

http://www.ietf.org/rfc/rfc6550.txt

http://www.ccnx.org/

http://dx.doi.org/10.1109/CSNT.2015.119

http://dx.doi.org/10.1109/SURV.2013.070813.00063

http://dx.doi.org/10.1109/COMST.2006.283821

http://dx.doi.org/10.1109/TPDS.2002.1036066

http://dx.doi.org/10.1109/ICC.2010.5502286

http://dx.doi.org/10.1145/959060.959072



ARTICLE IN PRESS


[16] B. Zhang, W. Guo, G. Chen, J. Li, In-network data aggregation route strategy 885 based on energy balance in WSNS, in: Proceedings of the 2013 11th Interna- 886 tional Symposium on Modeling Optimization in Mobile, Ad Hoc Wireless Net- 887 works (WiOpt), 2013, pp. 540–547. 888

[17] S. Ji, J.S. He, Y. Pan, Y. Li, Continuous data aggregation and capacity in proba- 889 bilistic wireless sensor networks, J. Parallel Distrib. Comput. 73 (6) (2013) 729–890 745. 891

[18] W. Heinzelman, A. Chandrakasan, H. Balakrishnan, An application-specific pro- 892 tocol architecture for wireless microsensor networks, IEEE Trans. Wirel. Com- 893 mun. 1 (4) (2002) 660–670, doi: 10.1109/TWC.2002.804190 . 894

[19] O. Younis, S. Fahmy, Heed: a hybrid, energy-efficient, distributed clustering ap- 895 proach for ad hoc sensor networks, IEEE Trans. Mob. Comput. 3 (4) (2004) 896 366–379, doi: 10.1109/TMC.2004.41 . 897

[20] M. Ye, C. Li, G. Chen, J. Wu, Eecs: an energy efficient clustering scheme in 898 wireless sensor networks, in: Proceedings of the 24th IEEE International Per- 899 formance, Computing, and Communications Conference, 2005 (IPCCC 2005), 900 2005, pp. 535–540, doi: 10.1109/PCCC.2005.1460630 . 901

[21] D. Wei, Y. Jin, S. Vural, K. Moessner, R. Tafazolli, An energy-efficient cluster- 902 ing solution for wireless sensor networks, IEEE Trans. Wirel. Commun. 10 (11) 903 (2011) 3973–3983, doi: 10.1109/TWC.2011.092011.110717 . 904

[22] Y. Abidy, B. Saadallahy, A. Lahmadi, O. Festor, Named data aggregation in wire- 905 less sensor networks, in: Proceedings of the 2014 IEEE Network Operations and 906 Management Symposium (NOMS), 2014, pp. 1–8. 907

[23] L. Villas, A. Boukerche, H. Ramos, H. de Oliveira, R. de Araujo, A. Loureiro, 908 Drina: a lightweight and reliable routing approach for in-network aggregation 909 in wireless sensor networks, IEEE Trans. Comput. 62 (4) (2013) 676–689. 910

[24] Y. Jin, S. Gormus, P. Kulkarni, M. Sooriyabandara, Link quality aware and con- 911 tent centric data aggregation in lossy wireless networks, in: Proceedings of 912 the 2014 IEEE Wireless Communications and Networking Conference (WCNC), 913 2014, pp. 3082–3087. 914

[25] S. Madden, M.J. Franklin, J.M. Hellerstein, W. Hong, Tag: a tiny aggregation 915 service for ad-hoc sensor networks, SIGOPS Oper. Syst. Rev. 36 (SI) (2002) 916 131–146, doi: 10.1145/84 4128.84 4142 . URL http://doi.acm.org/10.1145/844128. 917 844142 . 918

[26] S. Motegi, K. Yoshihara, H. Horiuchi, Dag based in-network aggregation for sen- 919 sor network monitoring, in: Proceedings of the International Symposium on 920 Applications on Internet (SAINT ’06), IEEE Computer Society, Washington, DC, 921 USA, 2006, pp. 292–299, doi: 10.1109/SAINT.2006.20 . URL http://dx.doi.org/10. 922 1109/SAINT.2006.20 . 923

[27] Y. Wu, Z. Mao, S. Fahmy, N. Shroff, Constructing maximum-lifetime data- 924 gathering forests in sensor networks, IEEE/ACM Trans. Netw. 18 (5) (2010) 925 1571–1584, doi: 10.1109/TNET.2010.2045896 . 926

[28] A. Sharaf, J. Beaver, A. Labrinidis, K. Chrysanthis, Balancing energy efficiency 927 and quality of aggregate data in sensor networks, VLDB J. 13 (4) (2004) 384– 928 403, doi: 10.10 07/s0 0778-0 04-0138-0 . 929

[29] I. Solis, K. Obraczka, The impact of timing in data aggregation for sensor net- 930 works, in: Proceedings of the 2004 IEEE International Conference on Commu- 931 nications, 6, 2004, pp. 3640–3645Vol.6, doi: 10.1109/ICC.2004.1313222 . 932

[30] D.S.J. De Couto, D. Aguayo, J. Bicket, R. Morris, A high-throughput path metric 933 for multi-hop wireless routing, in: Proceedings of the 9th Annual International 934 Conference on Mobile Computing and Networking (MobiCom ’03), ACM, New 935 York, NY, USA, 2003, pp. 134–146. 936

[31] N. Tsiftes, A. Dunkels, A database in every sensor, in: Proceedings of the 9th 937 ACM Conference on Embedded Networked Sensor Systems (SenSys ’11), ACM, 938 New York, NY, USA, 2011, pp. 316–332, doi: 10.1145/2070942.2070974 . 939

[32] S. Nath, Energy efficient sensor data logging with amnesic flash storage, in: 940 Proceedings of the 2009 International Conference on Information Processing 941 in Sensor Networks (IPSN ’09), IEEE Computer Society, Washington, DC, USA, 942 2009, pp. 157–168. 943



http://dx.doi.org/10.1109/TWC.2002.804190

http://dx.doi.org/10.1109/TMC.2004.41

http://dx.doi.org/10.1109/PCCC.2005.1460630

http://dx.doi.org/10.1109/TWC.2011.092011.110717

http://dx.doi.org/10.1145/844128.844142

http://doi.acm.org/10.1145/844128.844142

http://dx.doi.org/10.1109/SAINT.2006.20

http://dx.doi.org/10.1109/SAINT.2006.20

http://dx.doi.org/10.1109/TNET.2010.2045896

http://dx.doi.org/10.1007/s00778-004-0138-0

http://dx.doi.org/10.1109/ICC.2004.1313222

http://dx.doi.org/10.1145/2070942.2070974


ARTICLE IN PRESS - Download-Paper€¦ · Content centric routing in IoT networks and its...

Documents

Transcript of ARTICLE IN PRESS - Download-Paper€¦ · Content centric routing in IoT networks and its...