ANALYSIS OF Co-RPL USING ENHANCED

LOOP REPAIR MECHANISM AND

PREVENTION OF ATTACKS

A PROJECT REPORT

Submitted by

ABIRAMI R

RegisterNo: 14MCO001

in partial fulfillment for the requirement of award of the degree

of

MASTER OF ENGINEERING

in

COMMUNICATION SYSTEMS

Department of Electronics and CommunicationEngineering

KUMARAGURU COLLEGE OF TECHNOLOGY

(An autonomous institution affiliatedto Anna University,Chennai)

COIMBATORE-641049

ANNA UNIVERSITY: CHENNAI 600 025

APRIL 2016

ii

BONAFIDE CERTIFICATE

Certified that this project report titled, “ANALYSIS OF Co-RPL USING ENHANCED

LOOP REPAIR MECHANISM AND PREVENTION OF ATTACKS,” is the bonafide

work of ABIRAMI.R (Reg. No. 14MCO001) who carried out the research under my

supervision. Certified further that, to the best of my knowledge the work reported here in

does not form part of any other project or dissertation on the basis of which a degree or award

was conferred on an earlier occasion on this or any other candidate.

The candidate with Register No.14MCO001 was examined by us in the project

viva-voice examination held on............................

INTERNAL EXAMINER EXTERNAL EXAMINER

SIGNATURE

Dr. M. ALAGUMEENAAKSHI

PROJECT SUPERVISOR

Department of ECE

Kumaraguru College of Technology

Coimbatore-641 049

SIGNATURE

Dr. A. VASUKI

HEAD OF THE DEPARTMENT

Department of ECE

Kumaraguru College of Technology

Coimbatore-641 049

iii

ACKNOWLEDGEMENT

First, I would like to express my praise and gratitude to the Lord, who has

showered his grace and blessings enabling me to complete this project in an excellent

manner.

I express my sincere thanks to the management of Kumaraguru College of

Technology and Joint Correspondent Shri. Shankar Vanavarayar, for the kind

support and for providing necessary facilities to carry out the work.

I would like to express my sincere thanks to our beloved Principal

Dr.R.S.Kumar, Kumaraguru College of Technology, who encouraged me in each and

every steps of the project.

I would like to thank Dr.A.Vasuki, Head of the Department, Electronics and

Communication Engineering, for her kind support and for providing necessary

facilities to carry out the project work.

I wish to thank and express my heartfelt gratitude to the project coordinator

Dr.M.Alagumeenaakshi, Assistant Professor III, Department of Electronics and

Communication Engineering, throughout the course of this project work.

I am greatly privileged to express my heartfelt thanks to my project guide

Dr.M.Alagumeenaakshi, Assistant Professor III, Department of Electronics and

communication Engineering, for her expert counselling and guidance to make this

project to a great deal of success and I wish to convey my deep sense of gratitude to

all teaching and non-teaching staffs of ECE Department for their help and

cooperation.

Finally, I thank my parents and my family members for giving me the moral

support and abundant blessings in all of my activities and my dear friends who helped

me to endure my difficult times with their unfailing support and warm wishes.

iv

ABSTRACT

Targeting at increasing number of prospective application domains, wireless

sensor networks (WSN) have been an interesting research area. However, hardware

constraints have limited their application and real deployments have demonstrated that

WSNs have difficulties in coping with complex communication tasks such as mobility

in addition to application-related tasks. Mobility support for WSNs is crucial for most

of the application scenarios and notably, for the Internet of Things. RPL is a tree

based routing protocol designed for Wireless Sensor Networks (WSNs). RPL protocol

was originally designed with static topologies for static networks. The mobility

support for wireless sensor networks (WSNs) will be in dispensable in near future for

maintaining connectivity with the network to avoid packet losses and degraded

Quality of Service (QoS). RPL has been extended to Co-RPL using Corona

mechanism in order to support mobility and improve QoS. In this paper, mobility

support is provided for RPL by giving node positions in ContikiOS. The impact of

various network parameters such as Packet Delivery Ratio (PDR), Average power

consumption, Convergence time, Memory occupation for RPL and Co-RPL are

simulated in COOJA simulator and their results are compared. Also an enhanced loop

repair mechanism for Co-RPL has been proposed to prevent attacks such as Rank

increasing attacks, DAG inconsistency attacks, Version Number attacks that arise due

to looping nature in RPL. This reduces the waste of precious network resources.

v

TABLE OF CONTENTS

CHAPTER

NO

TITLE PAGE

NO

ABSTRACT iv

LIST OF FIGURES vii

LIST OF TABELS viii

1 INTRODUCTION 1

1.1 WIRELESS SENSOR NETWORKS 1

1.2 RPL 2

1.2.1 RPL INTRODUCTION 2

1.2.2 RPL DODAG Construction Process 2

1.3 CONTIKI OPERATING SYSTEM 4

1.3.1 Introduction 4

1.3.2 COOJA simulator 4

2 LITERATURE REVIEW 6

2.1 Introduction 6

3 Co-RPL 10

3.1 Introduction 10

3.2 Network model 10

3.3 Modifications for Mobility 11

3.3.1 Disabling DIO Trickle Timer 11

3.3.2 Immediate ETX Probing for a New Neighbor 12

3.4 Control Messages for Co-RPL 12

3.4.1 Structure of modified DIS message 12

3.4.2 Structure of modified DIO message 13

4 PROPOSED METHODOLOGY 14

4.1 Problem Statements 14

4.2 Proposed Methodology 14

4.2.1 Establishment of RPL with Mobility (Co-RPL) 14

4.2.2 Loop creation by attacks 16

4.2.2.1 Increased rank attacks 16

4.2.2.2 DAG inconsistency attacks 17

4.2.2.3 Version number attacks 17

4.2.2.4 Enhanced Loop Repair Mechanism 17

vi

5 SIMULATION ENVIRONMENT 18

5.1 ContikiOS Structure 18

5.2 Cooja simulator: Simulation Steps 19

6 RESULTS AND DISCUSSIONS 22

6.1 Mobility Plugin in ContikiOS 22

6.2 PERL Script 26

6.2.1 Convergence Time 26

6.2.2 Power Consumption 30

6.3 Establishment of Co-RPL 33

6.4 Impact on Memory Consumption 34

6.5 Impact on Convergence Time 34

6.6 Impact on Power Consumption 35

6.7 Impact on Packet Delivery Ratio 36

6.8 Implementation of Enhanced RPL Loop Repair Mechanism 36

6.9 Impact of Power Consumption and Convergence Time

with Enhanced Loop Repair Mechanism

37

7 CONCLUSION AND FUTURE WORK 39

REFERENCES 40

LIST OF PUBLICATIONS 43

vii

LIST OF FIGURES

FIGURE

NO

TITLE PAGE

NO

1.1 Wireless Sensor Network 1

1.2 Hierarchical structure of nodes in RPL 3

1.3 Upward Route 3

1.4 Downward Route 3

3.1 Corona Mechanism 11

3.2 Structure of modified DIS message 12

3.3 Structure of modified DIO message 13

4.1 Proposed methodology 15

5.1 Contiki 3.0 18

5.2 Source files for Mobility 19

5.3 Cooja simulator 21

6.1 Nodes position in RPL network 33

6.2 Nodes position in Co-RPL network 33

6.3 Impact on memory consumption 34

6.4 Impacts on convergence time 35

6.5 Impacts on power consumption 35

6.6 Impacts on Packet Delivery Ratio 36

6.7 Screenshot of Implementation of Enhanced Loop Repair

Mechanism

37

6.8 Comparison result of Power Consumption 38

6.9 Comparison result of Convergence Time 38

viii

LIST OF TABLES

TABLE

NO

TITLE PAGE

NO

6.1 Position.dat file 23

1

CHAPTER 1

INTRODUCTION

1.1 WIRELESS SENSOR NETWORKS

A wireless sensor network (WSN) (sometimes called a wireless sensor and

actor network (WSAN)) are spatially distributed autonomous sensors to monitor

physical or environmental conditions, such as temperature, sound, pressure, etc. and to

cooperatively pass their data through the network to a main location. Figure 1.1 shows

the one of the example of wireless sensor network.

Power is stored either in batteries or capacitors. Batteries, both rechargeable

and non-rechargeable, are the main source of power supply for sensor nodes.

Figure 1.1 Wireless Sensor Network

2

1.2 RPL

1.2.1 RPL INTRODUCTION

RPL is IPV6 distance vector routing protocol for Low power and Lossy

networks (LLNs) that constructs the Destination Oriented Directed Acyclic Graph

(DODAG) to route the data packets. RPL uses three ICMPV6 control messages for

creating and maintaining the topology and routing table. The Control messages are

DIO (DODAG Information Object): Initially DAG root broadcasts the DIO

message to its neighbor. The node which receives the DIO message can join the

network and this message contains information about the DODAG

configuration. DIO message used for upward direction.

DIS (DODAG Information Solicitation): DIS message used by the node to

solicit the DIO message from neighborhood nodes to join the network.

DAO (DODAG Advertisement Object): DAO message is used to support

downward traffic.

1.2.2 RPL DODAG Construction Process

A DAG is a directed graph wherein all edges are oriented in such a way that no

cycles exist. Each DAG created in RPL has a root node which acts as a gateway. Each

node (client node) in the DAG is assigned a rank that is computed on the basis of an

objective function. Figure 1.2 shows DODAG construction process for upward and

downward route.

The rank monotonically increases in the downward direction (DAG root has

the lowest rank) and represents a node’s virtual position to other nodes with respect to

the DAG root. A node in DAG can only be associated with other nodes having same

or smaller rank compared to its own rank in order to avoid cycles.

Figure 1.3 & 1.4 shows the upward and downward routes. RPL supports these

both routes.

3

Figure 1.2 Hierarchical structures of nodes in RPL

Figure 1.3 Upward Route

Figure 1.4 Downward Route

4

1.3 CONTIKI OPERATING SYSTEM

1.3.1 Introduction

Contiki is a wireless sensor network operating system and consists of the

kernel, libraries, the program loader, and a set of processes. It is used in networked

embedded systems and smart objects.

Contiki provides mechanisms that assist in programming the smart object

applications. It provides libraries for memory allocation, linked list manipulation and

communication abstractions. It is the first operating system that provided IP

communication. It is developed in C, all its applications are also developed in C

programming language, and therefore it is highly portable to different architectures

like Texas Instruments MSP430.

Contiki is an event-driven system in which processes are implemented as event

handlers that run to completion. A Contiki system is partitioned into two parts: the

core and the loaded programs. The core consists of the Contiki kernel, the program

loader, the language run-time, and a communication stack with device drivers for the

communication hardware.

The Program loader loads the programs into the memory and it can either

obtain it from a host using communication stack or can obtain from the attached

storage device such as EEPROM.

The Contiki operating system provides modules for different tasks (layers). It

provides the routing modules in a separate directory “contiki/core/net/rpl” and consists

of a number of files. These files are separated logically based on the functionalities

they provide for instance rpl-dag.c contains the functionality for Directed Acyclic

Graph (DAG) formation, rpl-icmp6.c provides functionality for packaging ICMP

messages etc.

1.3.2 COOJA simulator

Cooja is a Java-based simulator designed for simulating sensor networks

running the Contiki sensor network operating system. The simulator is implemented in

Java but allows sensor node software to be written in C.

One of the differentiating features is that Cooja allows for simultaneous

simulations at three different levels: Network Level, Operating System Level and

5

Machine code instruction level. Cooja can also run Contiki programs either compiled

natively on the host CPU or compiled for MSP430 emulator.

In Cooja all the interactions with the simulated nodes are performed via plugin

like Simulation Visualizer, Timeline, and Radio logger. It stores the simulation in an

xml file with extension 'csc' (Cooja simulation configuration). This file contains

information about the simulation environment, plugin, the nodes and its positions,

random seed and radio medium etc.

Cooja Simulator runs the Contiki applications whose files are placed in another

directory and may also contain a “project-conf.h” file which provides the ability to

change RPL parameters in one place.

6

CHAPTER 2

LITERATURE REVIEW

2.1 Introduction

The literature survey gives a brief on the resources that have been studied for

better understanding of the current research trends in the area of proposed research.

2.2 Co-RPL: RPL routing for mobile low power wireless sensor networks using

corona mechanism

RPL was originally designed for static networks, with no support for mobility.

This gap reduced by proposing Co-RPL as an extension to RPL based on the Corona

mechanism to support mobility. To demonstrate the effectiveness of Co-RPL, an

extensive simulation study using the Contiki/Cooja simulator and compared the

performance against standard RPL is conducted.

The impact of node speed, packet transmission rate and number of Directed

Acyclic Graphs (DAG) roots on network performance was simulated. The simulation

results show that Co-RPL decreases packet loss ratio by 45%, average energy

consumption by 50% and end-to-end delay by 2.5 seconds, in comparison with the

standard RPL.

2.3 Enhancing RPL Resilience against Routing Layer Insider Attacks

Resilience is needed to mitigate such inherent vulnerabilities and risks related

to security and reliability.

Routing Protocol for Low-Power and Lossy Networks (RPL) is studied in

presence of packet dropping malicious compromised nodes. Random behavior and

data replication have been introduced to RPL to enhance its resilience against such

insider attacks.

The classical RPL and its resilient variants have been analyzed through

COOJA simulations and hardware emulation. Resilient techniques introduced to RPL

7

have enhanced significantly the resilience against attacks providing route

diversification to exploit the redundant topology created by wireless communications.

2.4 RPL mobility support for point-to-point traffic flows towards mobile nodes

Although the RPL protocol was originally designed with static topologies,

recently a number of extensions have been proposed to support traffic flows from

mobile nodes towards a static gateway. RPL do not support traffic flows going the

other direction, for example, from the gateway towards mobile devices.

To remedy this, the paper first analyses the problems that prevent reliable

traffic flows towards mobile devices when using RPL. Afterwards, a new mechanism

to improve downward route updating was proposed.

The new approach minimizes the probability of connectivity loss by ensuring

that the interval state of the static network remains consistent. The end to end packet

delivery ratio to mobile nodes from 20-30% up to 80% was improved.

2.5 A Taxonomy of Attacks in RPL-based Internet of Things

In this paper, taxonomy has been proposed in order to classify the attacks

against the RPL protocol in three main categories. The attacks against resources

reduce network lifetime through the generation of fake control messages or the

building of loops. The attacks against the topology make the network converge to a

suboptimal configuration or isolate nodes.

Finally, attacks against network traffic let a malicious node capture and analyze

large part of the traffic. Based on this taxonomy, the properties of these attacks are

compared and discuss methods and techniques to avoid or prevent them. While the

RPL specification mentions two possible security modes, it does not define how they

might be implemented or how the management of keys could be performed. Most of

the security solutions in the area are still at a proof-of-concept level.

Risk management mechanisms provide new perspectives. They could typically

serve as a support for dynamically selecting the security modes and the protection

8

techniques to be considered for a given context. The context including the potentiality

of attacks and the network properties (size, nature of devices). This adaptive

configuration of RPL networks is a major challenge for addressing the trade-off

between the level of security required by applications and the overhead induced by

countermeasures.

2.6 RPL Optimization for Precise Green House Management using Wireless

Sensor Network

The Routing Protocol for low power and Lossy Network (RPL) parameter

decides battery consumption, network efficiency, convergence time of the routing

tree, routing table correction and rate of data collection. Battery consumption depends

on control overhead packets transmitted over a specific interval. Optimization of

network and battery efficiency is the primary concern for deployment of wireless

sensor network to any specific case.

The Green House Monitoring System is simulated using Contiki OS Cooja

Simulator. From the simulation results, the optimal values predicted are 11, 18, 30

seconds for DIO Interval rate, DIO Doubling rate and DIO Redundancy rates

respectively. The mathematical regression modeling analysis is done using MATLAB

tool. The optimal number of nodes per border router is 10 nodes. The hardware

implementation is under progress to validate the above concept.

2.7 Routing Attacks and Countermeasures in the RPL-Based Internet of Things

In this paper, IoT protocols and their strengths and weaknesses are highlighted

that can be exploited by the IDSs. While the RPL protocol is vulnerable to different

routing attacks, it has inherent mechanisms to counter HELLO flood attacks and

mitigate the effects of sinkhole attacks.

IDS for the IoT can be complemented with the novel security mechanisms in

the IPv6 protocol; for example, our heartbeat protocol can defend against selective-

forwarding attacks. The aim of this paper is to highlight the importance of security in

9

the RPL-based IoT and to provide grounds to the future researchers who plan to

design and implement IDSs for the IoT.

2.8 RPL under Mobility

The various parameters (e.g., various timers and speeds) have been studied on

modified RPL in terms of connectivity duration and overhead as RPL in its original

form does not adapt to the high speed vehicular environment. High speed decreases

connectivity duration since periodic updates cannot keep up with the topology change.

Trickle timer may not be suitable as it works best for sensor networks.

Loops are observed and can be avoided and detected with simple hints in DIO

messages. Future work includes proposing an adaptive timer that is cognizant of

vehicle speed and weigh in the tradeoff between performance and overhead gain and

evaluation results for realistic traffic trace with random vehicle speeds and

positioning.

10

CHAPTER 3

Co-RPL

3.1 Introduction

The improved mechanism of RPL with mobility support, referred to as Co-

RPL, addresses the QoS requirement of MWSNs. Co-RPL is based on the Corona

mechanism that enables improved localization of nodes in motion, and thus reduces

the impact of frequent node failures

3.2 Network model

In Co-RPL, DAG roots are static; indeed, this is typical for data collection

networks. These roots are usually linked to the Internet gateway and therefore it is

suitable to consider them as static nodes.

The proposed Co-RPL protocol is based on the Corona architecture for

localization of mobile nodes. This architecture facilitates in quickly finding alternative

parents as the next hop. The Corona architecture relies on the simple concept of

dividing the network area into coronas. A corona is defined as a circular region with a

certain radius centered at the DAG root. In simulations, assume that the radius of each

corona is equal to the maximum transmission range of a sensor node. An example of

the corona-based network architecture is shown in Figure 3.1.

The nodes in the network are mobile routers running with the RPL protocol.

There are four DAGs, with each DAG centered on its DAG root. A corona is

associated with each DAG. The RPL routers may belong to only one corona at a time

(even in case of overlap of connectivity), and can switch from one corona to another.

This timer mechanism may not be efficient in the case of MWSNs as the topology

changes continuously. As an alternative, the DAG root sends DIOs periodically in

order to be aware of the positions of the nodes in real-time. The interval between

transmissions of two DIOs should be adjusted based on the speed of the nodes. In

addition, upon detection of an inconsistency, the neighboring nodes transmit DIO

messages immediately without waiting for expiration of the periodic timer.

11

Figure 3.1 Corona Mechanism

3.3 Modifications for Mobility

Since RPL was originally designed for static sensor networks, RPL rank does

not update in a timely fashion to reflect frequent topology changes. Slow response to

topology changes, as reflected in slow rank update, results in a suboptimal path to the

destination or a destination unreachable error. Moreover, a node may lose connection

to the road-side infrastructure and then connect to a node in its neighborhood as its

parent.

3.3.1 Disabling DIO Trickle Timer

The trickle timer is disabled for the reason of studying the impact of using a

fixed timer on RPL’s performance under mobility. Since the topology changes

frequently for mobile networks, trickle timer, which is designed for static networks,

may not be suitable. Node’s rank may not change from one DIO message to the next

DIO message during one t period under low speed; doubling t’s value may cause the

node to send its DIO message later. This may cause the other nodes to double their

timer because there is no DIO message to suggest a rank change. In the meantime, the

current node may send a stale DIO message and double its timer again since it does

not receive any DIO message from its neighbors. The situation worsens as nodes

exchange stale DIO messages and continue to increase their t timer. Outdated DIO

messages can be exchanged amongst nodes in a prolonged period that ranks of nodes

12

no longer reflect the tree structure of the current network topology. The design of the

trickle timer is for LLNs where network topology does not change often. Therefore

disable trickle timer and study various fundamental factors (DIO periods, ETX

periods, and ETX) that impact RPL performance. Note that a holistic solution is to

dynamically tune the trickle timer for static and mobile scenarios.

3.3.2 Immediate ETX Probing for a New Neighbor

Whenever a node discovers a new neighbor the node schedules PING request

messages for its neighbor’s ETX value. Based on the ETX value of its new neighbor

and its parent, the node determines whether to change its parent. Scheduling of ETX

probing may delay the selection of a preferred parent if the new neighbor has a lower

ETX value than the existing parent.

This problem is especially acute in highly mobile networks as fast moving

nodes quickly change their rank. Instead of scheduling ETX probing to start at some

future time, immediately fire off ETX probing. That way, the new neighbor can be

considered for preferred parent selection in a timely fashion.

3.4 Control Messages for Co-RPL

Co-RPL maintains backward compatibility with the standard and modifies the

DIS (DODAG Information Solicitation) and DIO messages by adding flags to

distinguish between standard control messages and control messages used for Co-RPL

mechanism.

3.4.1 Structure of Modified DIS message

The DIS message is sent by a node when it does not find any parent in any

DAG, and searches for immediate parents. The bit F is used to distinguish between the

standard Specification of RPL and Co-RPL. If F = 0, it is interpreted as being the

standard DIS message. Else (that is, F = 1), the DIS message is assumed to be issued

from a node running Co-RPL. Figure 3.2 presents modified DIS message for Co-RPL.

F

(1)

Flags

(7)

Reserved

(8)

Options

(8)

Figure 3.2 Structure of Modified DIS message

13

3.4.2 Structure of modified DIO message

Each corona is identified by a corona ID (C_ID). The C_ID is used as relative

coordinate to localize mobile nodes to the DAG root (that is, the sink). The C_ID is

then used in detecting node mobility and triggering neighbor discovery. Fig. 3.3

shows the modification in the DIO message for this ID. We use the two first bits of the

Flags field to distinguish between the standard DIO and the updated DIO message. If

F = 0, the DIO message is issued from an RPL router. Else, with F = 1 the DIO is

issued from a node running Co-RPL. Also, the C ID is placed in the reserved field of

the DIO message (requires 3 bits). By integrating the corona ID in the DIO reserved

field, nodes that do not implement Co-RPL can still operate based on the default

objective function. This results in Co-RPL nodes co-existing in a transparent manner

with nodes running plain RPL.

RPLInstanceID

(8)

Version Number

(8)

Rank

(16)

G

(1)

0 MOP

(2)

Prf

(3)

DTSN

(8)

F

(2)

Flags

(6)

C_ID

(4)

Reserved

(4)

DODAGID

(128)

Figure 3.3 Structure of Modified DIO message

14

CHAPTER 4

PROPOSED METHODOLOGY

4.1 Problem Statements

In a static network with RPL as routing protocol, Quality of service support

network level is still under research. In RPL, topology changes are not continuous

whereas in mobile nodes, Network topology changes are more frequent. Establishment

of RPL with mobility support (Co-RPL) is one of the major tasks in establishing

routes among the nodes. This may become more challenging when efficient use of

existing energy comes in to play. QoS guarantees are mostly difficult for mobile nodes

rather than static wireless sensor networks. Along with the existing local and global

loop repair mechanisms, an enhanced loop repair mechanism is integrated into RPL

protocol to detect and prevent loop created by various attacks in MWSN scenario.

There are some attacks which may disturb these network functions. There are

some attacks targeting to waste the network resources (power, energy and memory).

Another attack targets the existing network topology. It may disturb the normal

operation and functions of the network. The attacker may change the network

topology to create the loop result in exhausting the network resources such as energy

of the sensor nodes.

4.2 Proposed Methodology

Our ultimate goal is reducing the disconnected nodes in the network by

providing mobility and establishing the enhanced loop repair mechanism for Co-RPL

to overcome the effects of various attacks. The proposed methodology shows in

Figure 4.1

4.2.1 Establishment of RPL with Mobility (Co-RPL)

In the mobile network, RPL router is in motion randomly. Also consider that

DAG roots are not dynamic. Usually Border rooter is connected to the Internet

gateway. Therefore it is correct to consider them as static nodes. In the RPL network,

DIO messages are sent periodically to exchange the information about neighbor and

this time interval will doubles for every DIO messages. Trickle timer, the time interval

between two DIO messages, increases with network stability. Hence Co-RPL has

15

backward compatibility with RPL. Co- RPL uses same control messages as RPL such

as DIO, DIS and DAO. It also supports both upward and downward direction route.

But in Co-RPL, Each node broadcast DIO message based on speed of the mobile

node.

Figure 4.1 Proposed methodology

16

4.2.2 Loop creation by attacks:

The RPL protocol integrates mechanisms to avoid loops, detect inconsistencies

and repair DODAGs. When inconsistencies are detected, the RPL nodes should

trigger repair mechanisms. These mechanisms contribute also to the topology

maintenance when node and link failures happen. The local repair mechanism has

ability to find an alternative path to route the packets when the preferred parent is not

available. The node chooses another parent in its parent list. It is also possible to route

packets via a sibling node e.g. node with the same rank. This alternative path may not

be the most optimized one, Due to Increased Rank Attacks, DAG Inconsistency

Attacks and Version Number Attacks, loops can create in the network topology,

Therefore Enhanced Loop Repair Mechanism is necessary to repair the loops without

triggering the Local Repair Mechanism.

4.2.2.1 Increased rank attacks:

This type of attack comes under the category of indirect attacks. The attacker in

the network increases the rank of node to create a loop. The rank of the node is

increase in downward direction in order to protect the acyclic structure of the

DODAG. When a node finds its own rank value, these own rank value must be higher

than the rank values of its parents. If a node wants to modify its rank value, it has to

update its parents list by eliminating the nodes having a greater rank than its own new

rank value.

Once a node has created the set of parents in the directed graph, it decides

preferred parent from set of parents. Malicious nodes promote its own rank value as

higher than the one which is supposed to have. This may leads to form a loop when its

new preferred parent was in its past sub-DODAG. The increased rank attack is more

harmful to network functions. More routing loops may form at the neighborhood. In

this scenario, the enhanced loop repair mechanism enables the transmission of

multiple unicast DIO messages (rearrange the trickle timer) which may lead to have a

longer convergence time.

17

4.2.2.2 DAG inconsistency attacks:

A RPL node perceive a DAG inconsistency when it take delivery of a packet

with a Down 'O' bit set from a node with a higher rank and vice-versa e.g. when the

direction of the packet does not match the rank relationship. This can be the result of a

loop in the graph.

4.2.2.3 Version number attacks:

The version number is an important field of each DIO message. It has to

propagate unchanged and can incremented by the root only, each time a rebuilding of

the DODAG is necessary which is also called global repair. An older value indicates

that the node has not migrated to the new DODAG graph and cannot be used as a

parent node. An attacker can change the version number by illegitimately increasing

this field of DIO messages when it forwards them to its neighbors. Such an attack

causes an unnecessary rebuilding of the whole DODAG graph. Multiple loops are

created in this attack which leads to loss of data packets.

4.2.2.4 Enhanced Loop Repair Mechanism:

In the process of DODAG construction in Co-RPL, there is a possibility to

create loops by various attacks such as Rank increasing attacks, DAG inconsistency

attacks, and Version Number attacks similar to RPL protocol. The attacker can also be

a defective node whose behavior can annoy network functioning and it may lead to

waste of resources. The concept of Enhanced Loop Repair Mechanism is

implemented in Co-RPL routing protocol which can be refer in Figure 4.1

In Routing protocol, Routing information is included in data packets within a

RPL Option carried in the IPv6 Hop-by-Hop header. Whenever loops are detected in

the topology construction, from the RPL option field can update the senders rank and

send unicast DIO message back to the sender. The node which receive unicast DIO

message can verify the header of the received DIO and thereby update the rank list in

the existing network. Hence unnecessary loops are repaired

Therefore, the attacks which create the loop can prevent by implementing

Enhanced Loop Repair Mechanism in Co-RPL.

18

CHAPTER 5

SIMULATION ENVIRONMENT

5.1 ContikiOS Structure

The ContikiOS is written in basic C language. The figure 5.1 shows the

different folders come under Contiki 3.0. The apps folder consists of application that

can be run on Contiki. The CPU folder has source codes for processors that can run

Contiki. The platform consists of readily available motes that can be used to build

Contiki. The Makefile.include compiles and builds the entire Contiki system. Figure

5.2 shows the source files for mobility.

Figure 5.1 Contiki 3.0

19

Figure 5.2 Source files for Mobility

5.2 Cooja simulator: Simulation Steps

The Cooja is a java based real time simulator for the Contiki OS. It can

simulate the actual working of wireless sensor nodes. The coding thus generated can

be used to build the OS in to the real time motes to establish the scenario in real. The

serial port logs from the nodes can be viewed in the mote output window, which can

be stored in the file for later analysis.

The following are the steps to simulate the wireless sensor network on Cooja

simulator,

Start the Cooja simulator by entering following commands in the path

/Contiki-3.0/tools/Cooja

$cd …./Contiki-3.0/tools/Cooja

$ant run

The above command will show the Cooja simulator default window,

from the file menu, create a new simulation.

Save the simulation in file system.

Add motes from Motes->Add Mote->choose the type of mote

20

Choose the program file to be compiled

Once the file is compiles, choose the number of motes and arrangement

Important Note: Increase the buffer size from tools->buffer size. The

buffer size denotes the no of log output lines buffer memory allocated.

The default medium of the network environment is Unit Disk Graph Medium

(UDGM) which denotes that the medium will have loss if the motes are far apart.

There is also an option to include constant loss medium or multipath ray tracer

medium. Change the simulation parameter as per requirements and click create button

to create a simulation.

When a new simulation is created, the window shown in figure 13 appears. The

figure shows multiple windows such as

Network: AN area used to create and position motes. The view menu in this

window has option that can be used for better understanding of the motes being

simulated.

Simulation control: It is used to start, stop, pause or reload the simulation when

relevant changes are made in the source code.

Mote output: The motes running in the network window will send outputs

which are generally printing statements given in the source code. These outputs

are captured in the Mote output window.

Timeline: This window displays the active time of each mote in which it sends

or receives data.

The screen shot of the Cooja simulator is shown in figure 5.3

21

Figure 5.3 Cooja simulator

22

CHAPTER 6

RESULTS AND DISCUSSIONS

6.1 Mobility Plugin in ContikiOS

Mobility plugin can be used to simulate and test mobile ad-hoc network

protocols in the COOJA Simulator. To enable mobility plugin in ContikiOS the

following steps have to be followed.

Step 1: Create a new directory by using following command in terminal window.

cd contiki/tools/cooja/apps

mkdir mobility

In that mobility folder, the following folders are available.

Java

Lib

CONTRIBUTORS.txt

PROJECT-INFO.txt

Build.xml

cooja.config

positions.dat

positions.dat.zip

Position.dat file: Position of nodes can be specified by using following format.

TABLE 6.1 shows the position data for only one node to make ease when installing.

Node id Identity of each wireless sensor nodes

TimeTime specified in seconds

xpos x position in meters

ypos y position in meters

23

TABLE 6.1 Position.dat file

Node id Time(sec) Xpos ypos

0 0.00000000 1 0

1 0.00000000 2 0

0 0.25000000 1.5000000000 0

1 0.50000000 2.5000000000 0

0 0.50000000 3 0

In order to implement mobility, the following parameters and a file with

movement data for 30 nodes was included.

#Number of nodes: 30

#Time [s]: 600.0 seconds

#Min speed [m/s]: 1.0

#Max speed [m/s]: 4.0

#Min pause time [s]: 2.0

#Max pause time [s]: 10.0

# Maximum X-size [m]:150.0

#Maximum Y-size [m]: 150.0

To avoid the compile error, have to rename all the imports from

Import se.sics.cooja.ClassDescription;

Import se.sics.cooja.GUI;

Import se.sics.cooja.Cooja.HasQuickHelp;

To this

24

Import org.contikios.cooja.ClassDescription;

Import org.contikios.cooja.Cooja;

Import org.contikios.cooja.HasQuickHelp;

And also make sure that cooja.jar in the build.xml is given as absolute path. There are

few more minor changes have to do in Config file also to build mobility plugin.

Step 2: Building the plugin

Type the following command and run in terminal window.

cd contiki/tools/cooja/apps/mobility

Sudo ant jar

Now the plugin is built successfully.

Step 3: Enabling the Mobility Plugin in COOJA

Start Cooja Simulator by the following command

Cd contiki/tools/cooja

Sudo ant run

In Cooja

SettingsExternal Tools Path

25

Edit Settings Screen will pop-up

Click Save

Close Cooja Simulator and Start it again by using following command

cd contiki/tools/cooja

26

ant run

Now go to

SettingsCooja extensions and click on “Apply for the session”

Under the Tools tab in Cooja, “Mobility” is enabled.

6.2 PERL Script

6.2.1 Network Convergence Time

The network convergence time is the time taken by all the motes to join a

particular network. This can be calculated by obtaining the difference in time of first

DIS message sent by any mote to the last mote joining the network. The information

can be obtained from the mote output in COOJA simulator. The outputs are stored as

log files which are processed by the perl script, which is a well known script language

for processing text files. The perl script is given below.

27

#!/usr/bin/perl

printf "\n\n RPL Metric - Network Convergence Extraction ====> \n";

# /****************************************************************/

$directory_file =

"/home/user/ABI_WORKSPACE/new_simulation_output/moteoutput2/";

unless ( opendir( DIR_HANDLE, $directory_file ) ) {

die("The Directory file could not be opened \n ");

}

$results_file_name =

">>/home/user/ABI_WORKSPACE/new_simulation_output/results3.log";

unless ( open( F_HANDLE_RESULTS, $results_file_name ) ) {

die("The results log file could not be opened \n ");

}

# /****************************************************************/

my $file_names;

while ( readdir(DIR_HANDLE) ) {

$file_names = $_;

#$file_names = readdir(DIR_HANDLE) || "";

if ( ( $file_names ne "." ) && ( $file_names ne ".." ) ) {

print $file_names;

print "\n";

netw_convergence( $directory_file . $file_names,

F_HANDLE_RESULTS );

control_overhead( $directory_file . $file_names,

F_HANDLE_RESULTS );

}

}

close F_HANDLE_RESULTS;

# /****************************************************************/

sub netw_convergence {

my ( $debug_logfile, $results_handle ) = @_;

28

$F_HANDLE1 = "0"; #Temporary initiazation

#print "Debug file name $debug_logfile";

unless ( open( F_HANDLE1, $debug_logfile ) ) {

die("The log file could not be opened \n ");

}

#/*************************************************************/

#Going to extract the lines with String "DIS Sent"

#Going to extract the time information

$handle_value = "F_HANDLE1";

$linein = <$handle_value>;

$first_time_DIS = 0;

$time_value_first_DIS = 0;

@words = ();

while ( defined($linein) ) {

#extraction line

if ( $linein =~ m/\bDIS sent\b/ ) {

@words = split( /[\t ]+/, $linein );

# print @words;

# print $words[0];

if ( $first_time_DIS == 0 ) {

$time_value_first_DIS = $words[0];

$first_time_DIS = 1;

print

"First DIS Match at time: $time_value_first_DIS \n";

}

} # end of if

$linein = <$handle_value>;

if ( defined($linein) ) {

chomp($linein);

}

} # end of while

29

# /*************************************************************/

#Going to extract the last line with "DAG Joined"

#Going to extract the time information

$handle_value = "F_HANDLE1";

$time_value_last_DAG_JOINED = 0;

seek $handle_value, 0, 0;

$linein = <$handle_value>;

@words = ();

while ( defined($linein) ) {

#extraction line

if ( $linein =~ m/\bJoined DAG\b/ ) {

@words = split( /[\t ]+/, $linein );

# print @words; print "\n";

# print $words[0];

$time_value_last_DAG_JOINED = $words[0];

} # end of if

$linein = <$handle_value>;

if ( defined($linein) ) {

chomp($linein);

}

} # end of while

print "The LAST DAG Joined Time: $time_value_last_DAG_JOINED \n";

print "The DAG Joined Time: $time_value_last_DAG_JOINED \n";

$network_conv_time =

( $time_value_last_DAG_JOINED - $time_value_first_DIS ) / 1000;

print "The Network Convergence $network_conv_time \n";

print $results_handle (

"The Network Convergence Time for file $debug_logfile : $network_conv_time

seconds\n "

);

close F_HANDLE1;

30

# closing the log file after doing the text processing

}

# /****************************************************************/

6.2.2 Power Consumption

The powertrace app given in Contiki can be used to obtain the time spent by a

particular mote in CPU processing, LPM mode, transmission and reception. This

information is stored in a log file and processed using perl script. The relevant time

informations are taken from all the motes from parsing the log file and power

consumption by each mote is calculated. Then finally average power consumed by all

the motes in the network is calculated. The script used to calculate powr is given

below.

#!/usr/bin/perl

#/************************************************************/

print " Start of Power Analysis Program\n"; # print a message

$file_path = '/home/user/powerinput.txt';

open(INFO, $file_path);

#@lines = <INFO>;

#close(INFO);

#print @lines;

$_ = $file_path;

$max_seq = 0;

$voltage = 3;

$power_cpu = 1.800 * $voltage;

$power_lpm = 0.0545 * $voltage;

$power_tx = 17.7 * $voltage;

$power_rx = 20.0 * $voltage;

for($i = 0; $i < 1000; $i++) {

$max_radio[$i] = 0;

$min_radio[$i] = 10000;

31

while(<INFO>)

{

if(/P (\d+)\.\d+ (\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+)

(\d+)/)

{

$node = $1;

$seq = $2;

$all_cpu = $3;

$all_lpm = $4;

$all_tx = $5;

$all_rx = $6;

$all_idle_tx = $7;

$all_idle_rx = $8;

$cpu = $9;

$lpm = $10;

$tx = $11;

$rx = $12;

$idle_tx = $13;

$idle_rx = $14;

$total_time = $all_cpu + $all_lpm;

$nodes{$node} = 1;

$radio_now = $tx + $rx;

$idle_now = $idle_tx + $idle_rx;

$cpu_now = $lpm + $cpu;

$dutycycle = $radio_now / $cpu_now;

$dutycycle_for_node[$node][$seq] = $dutycycle;

$idle_for_node[$node][$seq] = $idle_now / $cpu_now

if($seq > $max_seq) {

$max_seq = $seq;

}

}

32

}

foreach $j (keys %nodes) {

$avg = 0;

for($i = 0; $i < $max_seq; $i++) {

$avg += $dutycycle_for_node[$j][$i];

}

$idle_avg = 0;

for($i = 0; $i < $max_seq; $i++) {

$idle_avg += $idle_for_node[$j][$i];

}

print $avg / $max_seq . " " . $idle_avg / $max_seq . " $j\n";

$total_avg += $avg;

$total_idle += $idle_avg;

}

print "\n";

print STDERR "Idle percentage " . $total_idle / $total_avg . "\n";

print STDERR "CPU Power" .$all_cpu*$power_cpu/$total_time. "\n";

print STDERR "LPM Power" .$all_lpm*$power_lpm/$total_time. "\n";

print STDERR "TX Power" .$all_tx*$power_tx/$total_time. "\n";

print STDERR "RX Power" .$all_rx*$power_rx/$total_time. "\n";

print STDERR "Total Power" .($all_cpu*$power_cpu + $all_lpm*$power_lpm +

$all_tx*$power_tx + $all_rx*$power_rx)/$total_time. "\n";

print STDERR "All CPU Power" .$all_cpu. "\n";

print STDERR "All LPM Power" .$all_lpm. "\n";

print STDERR "All TX Power" .$all_tx. "\n";

print STDERR "All RX Power" .$all_rx. "\n";

#/**************************************************************/

33

6.3 Establishment of Co-RPL

The mobility behavior for each node is established in Co-RPL to enable the

movement of nodes. Choice of Random Waypoint model energizes the nodes to reach

random destination with random velocity. DAG root is kept static whereas the other

source nodes start moving due to the inherited character of mobility during simulation.

Fig 6.1&6.2 show the screenshots of WSN with 30 nodes before and after simulation

of Co-RPL.

Figure 6.1 Nodes Position in RPL network

Figure 6.2 Nodes Position in Co-RPL network

34

6.4 Impact on Memory Consumption

Usually the Tmote sky motes resemble the TelosB motes with 48KB RAM.

There are two types of memory, ROM and RAM, contained in all mote processors.

The ROM size is very restricted. Generally, it has the compiled codes stored on its

memory. The size of RAM is even more limited than size of ROM. The simulation

result shows that size of ROM and RAM are almost same for RPL and Co-RPL

without difference in memory consumption. Memory consumption was plotted in

terms of size in kB for both RPL and Co-RPL. Fig. 6.3 shows the memory

consumption of RPL and Co-RPL.

Figure 6.3 Impact on memory consumption

6.5 Impact on Convergence Time

The simulation of the network scenario has been done with different size of

node numbers (10, 20 and 30) with RPL and Co-RPL as its routing protocol. The

convergence time was calculated with the help of Perl script. Figure 15 shows impact

on convergence time on RPL and Co-RPL. As the number of DIO messages increases

either due to node increase or due to frequent topology changes, the convergence time

of the network increases. This is obviously shown in figure 6.4. The simulation is

carried out with fixed network as well as dynamic network setup and results are

compared for RPL and Co-RPL.

35

Figure 6.4 Impacts on Convergence Time

6.6 Impact on Power Consumption

Wireless Sensor Motes are mostly intended to be battery operated which

restrict their flexibility in power and reduces overall lifetime of the network. COOJA

provides built-in power trace tool which is used to calculate the power consumption of

each node in the simulation environment. The total power consumption of each mote

is classified under four heads namely CPU, Low Power Mode (LPM), Transmission

and reception power. The comparison plot of power consumption is illustrated clearly

in Fig. 6.5. Naturally Co-RPL implementation consumes more power than the RPL

implementation and also increases with number of nodes.

Figure 6.5 Impacts on Power Consumption

36

6.7 Impact on Packet Delivery Ratio

The debug prints are included in the Contiki RPL layer code. When executed

the debug prints will be available in mote output window, the result log is stored.

From the mote output window, No of successfully received packets and transmitted

packets can be calculated. Due to Dynamic Topology changes, Packet delivery Ratio

is increased for Co-RPL compared to RPL. The impact on Packet Delivery Ratio is

shown in figure 6.6

Packet Delivery Ratio = (SUCCESSFULL RECEIVED/ TRANSMITTED PACKETS) *100;

Figure 6.6 Impacts on Packet Delivery Ratio

6.8 Implementation of Enhanced RPL Loop Repair Mechanism

Loops are avoided already due to the method by which the trees are built.

However, this does not consider the case when a node is missing a rebuild cycle or

when nodes are moving. RPL transports its control information within the headers of

ordinary data packets' external extension headers such as the one in RPL Option for

Carrying RPL Information in Data-Plane Datagram’s, the main idea being that, when

there is no need for a route to be established, it is not of importance whether or not it

is loop-free. When loop detection is performed on a packet, a node sending a packet

will prepend its own IP header. A receiving node will check whether any of the

headers has its own IP address as the source of one of the packets. If this is the case, it

37

sends an error back to the original source and initiates the repairs. Figure 6.6 shows

the implementation of Enhanced Loop Repair Mechanism.

Figure 6.7 Screenshot of Implementation of Enhanced Loop Repair

Mechanism

6.9 Impact of Power Consumption and Convergence Time with Enhanced Loop

Repair Mechanism

The Simulation scenario of network is same as previous i.e. the simulation has

been done with different size of node numbers (10, 20 and 30).After implementation

of Enhanced Loop Repair Mechanism, Average Power Consumption and

Convergence time are calculated. Average power Consumption has been reduced in-

spite of increase in Convergence time. Whenever loops creation indicated by setting

Rank error flag R=1, Loops can repair by Enhanced Loop Repair Mechanism.

Average power consumption has been reduced by 2.12%. Because there is no need to

trigger the local repair and global repair mechanism and rebuilding of network

topology. The number of unicast DIO messages is increased with implementation of

enhanced loop repair mechanism. Thereby network convergence time has been

increased. Comparison results of with and without enhanced loop repair mechanism

for Average power consumption and convergence time are shown in figure 6.7 & 6.8

38

Figure 6.8 Comparison result of Power Consumption

Figure 6.9 Comparison result of Convergence Time

39

CHAPTER 7

CONCLUSION AND FUTURE WORK

The mobility support for RPL has been proposed successfully using COOJA

simulator. Co-RPL is an extension of RPL that reuses the same control messages and

preserves backward compatibility with the standard specification. The required

Quality of Service has been achieved by incorporating mobility nature using Random

waypoint model. Therefore there is a possibility to increase the successful delivery of

the packets to the destination as the nodes move towards the DAG root. The

performance of Co-RPL has been estimated in terms of power consumption,

convergence time, packet delivery ratio and memory consumption and the results are

compared with RPL. Based on simulation results, though Co-RPL consumes more

power and takes increased network convergence time compared to RPL the mobility

nature of the wireless motes has be implemented and also packet delivery ratio is

increased. An Enhanced Loop repair mechanism suitable for RPL has been integrated

with Co-RPL as well to prevent various attacks. This helps in avoiding the wastage of

valuable network resources such as battery power, Control Packet overhead.

40

REFERENCES

[1] O. Gaddour, A. Koubaa, R. Rangarajan, O. Cheikhrouhou, E Tovar and M Abid

(2014), “Co-RPL: RPL Routing for Mobile Low Power Wireless Sensor

Networks using Corona Mechanism”, in Industrial Embedded Systems(SIES),

2014 ninth InternationalMConference on, pp. 200-209. IEEE 2014.

[2] K. Heurtefeux, O. Erdene-Ochir, N. Mohsin and H. Menouar. “Enhancing RPL

Resilience against Routing Layer Insider Attacks”, in Advanced Information

Networking and Applications (AINA), 2015 twenty ninth International

Conference on, pp. 802-807. IEEE 2015.

[3] A. Mayzaud, R. Badonnel and I. Chrisment, “A Taxonomy of Attacks in RPL-

based Internet of Things”, International Journal of Network Security, Vol.18,

No.3, PP.459-473, May 2016.

[4] W. Tang, Z. Wei, Z. Zhang and B. Zhang, “Analysis and Optimization Strategy

of Multipath RPL Based on the COOJA Simulator”, IJCSI International

Journal Of Computer Science Issues, Vol. 11, Issue 5, No 1, September 2014

[5] A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur,and R.

Alexander.“RPL:Ipv6 routing protocol for low-power and lossy networks,”

March 2012.

[6] Kevin C. Lee, Raghuram Sudhaakar, Lillian Dai, Sateesh Addepalli, Mario Gerla.

“RPL under Mobility”.

[7] A. Aijaz and A. Hamid Aghvami, “Cognitive Machine-to-Machine

Communications for Internet-of-Things: A Protocol Stack Perspective”, IEEE

Internet of Things (IOT) journal, VOL. 2, NO. 2, APRIL 2015

[8] I. Korbi, M. Ben Brahim, C. Adjih, and L. Saidane, “Mobility enhanced rpl for

wireless sensor networks,” in Network of the Future (NOF), 2012 Third

International Conference on the, 2012, pp. 1–8.

[9] P. Pongle, G. Chavan, “Real Time Intrusion and Wormhole Attack Detection in

Internet of Things”, International Journal of Computer Applications (0975 –

8887) Volume 121 - No. 9, July 2015

41

[10] K. C. Lee, R. Sudhaakar, and J. Ning, “A comprehensive evaluation of rpl under

mobility,” International Journal of Vehicular Technology, 2012.

[11] O. Gaddour and A. Koub, “Survey rpl in a nutshell: A survey,” Computer

Network, vol. 56, no. 14, pp. 3163–3178, Sep. 2012.

[12] A. Le, J. Loo, A. Lasebae, A. Vinel, Y. Chen, and M. Chai, “The impact of rank

attack on network topology of routing protocol for low-power and lossy

networks,” IEEE Sensors, vol. 13, no. 10, pp. 3685-3692, 2013.

[13] L. Wallgren, S. Raza, and T. Voigt, “Routing attacks and countermeasures in the

RPL-based internet of things,” International Journal of Distributed Sensor

Networks, vol. 2013, pp. 1-11, 2013.

[14] Pavan Pongle, Gurunath Chavan, “A survey: Attacks on RPL and 6LoWPAN in

IoT”, International Conference on Pervasive Computing (ICPC) IEEE, 2015.

[15] Oana Iova, Fabrice Theoleyre, Thomas Noel, “Using multiparent routing in RPL

to increase the stability and the lifetime of the network”, Ad Hoc Networks 29

(2015) 45–62

[16] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, “Network Mobility

(NEMO) Basic Support Protocol,” RFC 3963, Internet Engineering Task Force,

Jan. 2005.

[17] B. McCarthy, M. Jakeman, C. Edwards, and P. Thubert, “Protocols to efficiently

support nested NEMO (NEMO+),” in Proceedings of the 3rd international

workshop on Mobility in the evolving internet architecture, ser. MobiArch ’08.

ACM, 2008, pp. 43–48.

[18] J. Tripathi, J. de Oliveira, and J. Vasseur, “A performance evaluation study of

RPL: Routing Protocol for Low power and Lossy Networks,” in Information

Sciences and Systems (CISS), 2010 44th Annual Conference on, March 2010, pp.

1–6.

[19] T. Clausen and U. Herberg, “Multipoint-to-point and broadcast in rpl,” in

Network-Based Information Systems (NBiS), 2010 13th International Conference

on, September 2010, pp. 493–498.

42

[20] J. Vasseur, M. Kim, K. Pister, N. Dejean, and D. Barthel, “Routing metrics used

for path calculation in low power and lossy networks,” draft-ietf-roll-routing-

metrics-10, Internet Engineering Task Force, Apr. 2011.

[21] S. Wang, C. Lin, Y. Hwang, K. Tao, and C. Chou, “A practical routing protocol

for vehicle-formed mobile ad hoc networks on the roads,” in Intelligent

Transportation Systems, 2005. Proceedings. 2005 IEEE, September 2005, pp.

161–166.

43

LIST OF PUBLICATIONS

Presented a paper titled “Analysis of Co-RPL using Enhanced Loop Repair

Mechanism and prevention of attacks” in IEEE Sponsored 3rd International

Conference on Innovations in Information, Embedded and Communication

Systems (ICIIECS ‘16) on 17th and 18th march 2016 held at Karpagam College

of Engineering, Coimbatore.

Scanned by CamScanner