8/2/2019 CCBR

1/16

A CONTEXTAND CONTENT-BASED ROUTING

PROTOCOLFOR MOBILE SENSOR NETWORKS

GIANPAOLO CUGOLAAND MATTEO MIGLIAVACCA

IDREES AHMED

FA11-PCS-005

8/2/2019 CCBR

2/16

ABSTRACT

Explicitly designed for multi-sink, mobile WSNs.

CCBR adopts content-based addressing to effectivelysupport the data-centric communication paradigmusually adopted by WSN applications.

It also takes into account the characteristics (i.e.,context) of the sensors to filter data.

Simulations show that CCBR outperforms alternativeapproaches in the multi-sink, mobile scenarios it wasdesigned for, while providing good performance inmore traditional (fixed) scenarios

8/2/2019 CCBR

3/16

INTRODUCTION

mobility and the presence of multiple sinks is something that has

been largely neglected

Data-centric form of communication is usually adopt DirectedDiffusion and TinyCOPS

communication is not only data-centric but it is also often context-aware

Context and Content-Based Routing protocol for multi-sink, mobile

WSNs.

Receiver-based approach to routing, where each node decidesautonomously to forward packets, loosely collaborating with others

8/2/2019 CCBR

4/16

CONTEXTAND CONTENT-BASED ROUTING

a set of nodes possibly moving around at different speeds

receiving messages (the sinks), send out messages (the

sensors).

In such a network:

(i) the same node may act as sink and as a sensor,

(ii) messages do not necessarily carry sensors readings.

8/2/2019 CCBR

5/16

THE API:

CCBR offers three main primitives to the upper layers:

1. setComponentProp(Properties p, DataListener dl)

The setComponentProp operation allows sensors to specify the

properties that describe the context in which they are

2. listenFor(CompFilter cf, MsgFilter mf, AddData ad,MsgListener ml, int l)

ListenFor operation allows sinks to express their interests

3. send(Message m)

The send operation allows messages to be sent to the interested sinks

8/2/2019 CCBR

6/16

FORWARDING

Each sink has a sink number ranges from 1,.,K

Each node maintains: distance table and content table

8/2/2019 CCBR

7/16

Whenever the send(m) primitive is invoked the node builds aforwarding header which is composed of a unique messageidentifier, a destination vector, and a distance vector

CCBR builds a forwarding packet putting together the forwardingheader and the message m and send to the MAC for broadcast

If the receiving node is farther or equally distant from therecipients of p, it drops it otherwise

it updates the distance vector in p, putting its own distance forthose sinks it is closer, and it schedules the packet fortransmission

The packet is put in a transmission queue, where it remains for a period:

8/2/2019 CCBR

8/16

MOBILITY

Mobility is another factor that may break the mechanism

To support mobility retransmission mechanism is introduces

After transmitting a packet, a node N puts it in a

retransmission queue

If timeout of retransmission expires without hearing the samepacket with at least one element in the distance vector

lowered, the node N:i. adds a retransmission bit-vector

ii. increases the distance vector for each sink

iii. transmits the resulting packet again

8/2/2019 CCBR

9/16

Nodes hearing such a packet will reconsider it even if theyalready received it before

To limit this network traffic each node has to retransmiteach packet at most once and mechanism of credits isintroduced

Delivery to Sinks:

sink receives a packet p, it looks at the bit in ps destinationvector that corresponds to its sink number. If the bit is setthe packet is forwarded to the application layer otherwise itis not

Finally a special packet is created and broadcasted to stopthe retransmission mechanism at the sender node

8/2/2019 CCBR

10/16

ROUTING:

each sink periodically (every tb seconds) broadcasts a

beacon that contains its sink number, a sequence numberand a distance, initially set to 0

Each node receiving a beacon, first increments the included

distance and uses it to update its distance table, then itschedules the beacon for forwarding

delay and cancel mechanism to limit redundanttransmissions

Whenever the setComponentProp primitive is invoked at asensor, the CCBR layer simply stores the componentproperty and the DataListener internally

8/2/2019 CCBR

11/16

When the listenFor is invoked at a sink, its parameters(component filter, message filter, additional data, and leasetime), are stored in a filter table

Every tf (tf >= tb) seconds the filters and additional data insuch table are grouped and piggybacked on top of the nextemitted beacon

sensor N receives this special fat beacon, it updates itsdistance table but also its content table

To decide sink no each sink wait for tb seconds and randomly

picks a no from 1,., K

Clashes in choosing sink numbers may still happen whichcan be easily resolved by letting the sink with the lowest

MAC address

8/2/2019 CCBR

12/16

EVALUATION

Simulator OMNeT++ & compared with Gossip and Uni

8/2/2019 CCBR

13/16

8/2/2019 CCBR

14/16

8/2/2019 CCBR

15/16

8/2/2019 CCBR

16/16

THANKYOU