Module: Internet of Things

Lecture 4: Network

Dr Payam Barnaghi, Dr Chuan H Foh

Centre for Communication Systems Research
Electronic Engineering Department
University of Surrey

Autumn Semester 2015 1

Overview

− Network Module

− Routing Technologies

− Performance Issues

2
Network Module

3
Network Module

RF-based IoT applications

− Communication module only provides data link
solution
− i.e. transmitting a packet between nodes within the
radio range
− Network module is needed to provide a solution
for end-to-end packet delivery
− Since source/destination pair may not be within each
other radio range, intermediate nodes are needed to
forward packet
− It is a distributed system. All nodes need to perform
networking related tasks.
− It is often software implementation.

4
Network Module

− RF-based IoT applications: Multi-hop Wireless

Network. Some examples:
− Wireless Sensor Networks (WSNs)
− Mobile Wireless Ad hoc Networks (MANETs)
− Wireless Mesh Networks (WMNs)
− Vehicular Ad Hoc Networks (VANETs)
− and others...

− Main concern: Reliability & Performance

5
Network Module: Roles

− Management:
− Packet: Adapting the packet sizes and formats
− Address: Adapting and/or resolving addresses
− Device: Joining/leaving of nodes
− Service: Providing adds-on services such as security

− Operational:
− Route discovery & maintenance
− Packet forwarding

6
Routing Technologies

7
Common Routing Techniques

− Flooding
− When receiving a packet, each node rebroadcasts the
packet
− No memory is kept in a node
− Very wasteful in bandwidth usage

− Source Routing
− A source node partially or completely specifies the route
that a packet should be forwarded
− Source node is responsible for finding the route to the
destination
− Implementation: DSR

8
Common Routing Techniques

− Distance Vector
− Exchange distance vectors only with neighbours to
establish routing tables
− Less traffic for table maintenance makes it suitable for
wireless networks
− Implementation: RIP, AODV, etc

− Link State
− Flood link information in the network and use Dijkstra’s
algorithm to compute routing tables
− Popular solution in wired network. Not adequate for
wireless, as it requires network-wide flooding
− Implementation: OSPF, OLSR, etc

9
Common Routing Techniques

− Path Vector
− Based on distance vector, path information is used
instead of distance
− Permit implementation of some policy to take control of
the route
− Used in inter-domain routing
− Implementation: BGP

10
Route Establishment & Maintenance

− Proactive (table-driven):
− Nodes maintain a table describing how a packet should
be forwarded to destinations
− It is more suitable for networks with static topology

− Reactive (on-demand):
− Upon a request, nodes flood the network to find the
destination
− It is more suitable for networks with changing topology

− Mixed:
− Hybrid: Operate both proactive and reactive routing
− Hierarchical: Separate nodes into different levels and
use different routing techniques in different levels 11
Routing in IoT

− Ad hoc On-demand Distance Vector (AODV)

− Specified in RFC 3561
− Implemented in ZigBee

− IPv6 Routing Protocol for Low-Power and Lossy

Networks (RPL)
− Specified in RFC 6550
− Implemented in ContikiOS, TinyOS

NOTE: We’ll also review Flooding & Source Routing

12
Flooding

− When receiving a packet

− If it is not seen before, broadcast the packet
− Else discard the packet

Broadcast
the packet
Source
Destination
A first received
G
the packet
B D from D
(A
B
D
F)

E Destination
F H
13
Source Routing

− In source routing, the source takes control of the

forwarding
− Basic idea:
− The SOURCE broadcasts a REQUEST
− Each node include the path information in the REQUEST
− When the REQUEST reaches the DESTINATION, the
DESTINATION unicasts a REPLY with the path info
− When the REPLY reaches the SOURCE, it may transmit data
packet with the received path info included in the header
− Each intermediate node uses the path info in the header to
forward the data packets
− Each node maintains route cache to improve route
discovery performance

14
 Source Routing: Example

− RREQ: Route Request

− RREP: Route Reply

A
A-B A-B-D RREQ

Source RREP
A-B-D-H A-B-D
A G
B D
A-B-D-G
A

A-B-D-H C A-B-D-H
A-C

A-B E Destination
F H
15
 Distance Vector

Node J has been switched on

The distance vector published by A, I, H, K to J:

8+25 A B C D E F G H I J K L
A B C D A 0 12 25 40 14 23 18 17 21 8 24 29

I 24 36 18 27 7 20 31 20 0 10 22 33
E F G H
H 20 31 19 8 30 19 6 0 14 12 22 9
10+18

K 21 28 36 24 22 40 31 19 22 6 0 9
8 12

I 10 J 6 6+36 K L J’s new distance vector and routing table:

A B C D E F G H I J K L
J 8 20 28 20 17 30 18 12 10 0 6 15
via A A I H I I H H I --- K K

(source, distance, next hop)

C 28 I 16
AODV

− Ad hoc On-demand Distance Vector (AODV)

− Reactive Routing using Distance Vector
− Basic idea:
− Activity starts when there is a demand for transmission
− The SOURCE broadcasts a REQUEST
− Each node rebroadcasts the REQUEST & creates DISTANCE
VECTOR for the reverse path
− When the REQUEST reaches the DESTINATION, the
DESTINATION unicasts a REPLY
− Each participated node forwards the REPLY & creates
DISTANCE VECTOR for the forward path
− When the REPLY reaches the SOURCE, data transmission
may start

17
AODV: RREQ

− Route Request (RREQ) broadcasting

− The source broadcasts a RREQ to find a connection
− Intermediate nodes rebroadcast the RREQ to others
− While rebroadcasting, intermediate nodes create a
temporary route information recording the reverse path
(i.e. source, number of hops, next hop)
RREQ

Source

A G
B D

To A, 1 hop, via A E Destination

F H
18
AODV: RREP

− Returning of Route Reply (RREP)

− Once RREQ reaches the destination, the destination
unicasts RREP to its “next hop”
− Each participated node forwards RREP to its “next hop” and
record the forward path
− Once the RREP reaches the source, the source can transmit
its data packets to its “next hop” RREQ

Source To H, 2 hops, via D RREP

A G
B D

To A, 1 hop, via A E Destination

F H
19
AODV: Some management issues

− Distance Vector maintenance

− A reverse path is purged after a timeout interval (to
make sure the interval is long enough for RREP
unicasting to complete)
− A forward path is purged after it is not used for some
time

− Enhancements
− Intermediate nodes with information to the destination
can reply RREP
− Add sequence numbers to packets to avoid duplicate
rebroadcasting
− Use “time to live” to limit the rebroadcasting of RREQ

20
IPv6 Routing Protocol for Low-Power
and Lossy Networks (RPL)

− Background:
− Need for Low power and Lossy Networks (LLN)
− IETF formed a Working Group called Routing Over Low
power and Lossy Networks (ROLL) in 2008
− ROLL developed “Ripple” routing protocol (RPL)

− RPL is a Distance Vector IPv6 routing protocol for

LLNs
− RPL is a proactive routing protocol (periodic
activity to construct route)
− RPL permits multiple routes (or graphs), each
with some specific objective

21
RPL

− PRL is about building a Destination Oriented

Directed Acyclic Graph (DODAG) with some
objectives
− Destination Oriented, single destination with a root
− Directed Acyclic Graph, no loop
− DODAG building process
− A node is designated as a root
− A set of new ICMPv6 control messages is created
− DIS: DODAG Information Solicitation
− DIO: DODAG Information Object
− DAO: DODAG Destination Advertisement Object
− An Objective Function (OF) is specified for each node to
compute its rank in the graph
− see also RFC 6551 “Routing Metrics Used for Path
Calculation in Low-Power and Lossy Networks” 22
RPL: DODAG Building Process

− Procedure:
− The root starts broadcasting DIO
− Upon receiving DIO, each node
− computes its rank based on the OF
− chooses a neighbour with a rank lower than itself as
preferred parent
− broadcasts DIO message
Preferred parent
Root
DIO
A G
DIO B D

E
F H
23
RPL: DODAG Building Process

− Assuming shortest path is used as the objective

function (OF), B will choose A as its preferred
parent.

B receives a 2nd DIO

message & discards it
(based on the OF)
Preferred parent
Root

A G
B D

C broadcasts E
F H
DIO 24
RPL: DODAG Building Process

− B broadcasts DIO, other nodes rebroadcast DIO

and set their preferred parent based on the
objective function.

B broadcasts DIO

Preferred parent
Root

A DIO
G
B D

E
F H
25
RPL: DODAG Building Process

− Procedure:
− The broadcasting of DIO continues until all nodes have
seen the DIO
− By now, each node should have nominated one of its
neighbours to be its preferred parent
− A tree is built for UPWARD routing (or MP2P traffic)
Preferred parent
Root

A G
B D

E
F H
26
RPL: P2MP & P2P

− Point-to-Multi-Point (P2MP) for Downward traffic

− Each node transmits a DAO message to the root
− Each intermediate node appends its ID and relays DAO
to the root
− Each node can make use of the passing DAO messages
to build a subtree for downward traffic
− This type of node is called a storing node
− A node without this storing capability is called a non-
storing node
− The root will build and store a complete tree for
downward traffic
− Downward traffic can be routed using source routing
− Point-to-Point (P2P) traffic
− P2P is done by upward+downward transmissions
27
RPL: Topology Maintenance

− Topology maintenance
− A Trickle timer to control the sending rate of DIO (see
also RFC 6206 “The Trickle Algorithm”)
− Trickle's basic primitive is simple: every so often, a node
transmits data unless it hears a few other transmissions
whose data suggest its own transmission is redundant
− When routing inconsistencies are detected (e.g. loops,
loss of a parent, etc), Trickle timer is reset to the
minimum value to get the problems fixed quickly

28
Mesh-under versus Route-over

− Relaying of packets can be performed at Layer 2

(mesh-under) or layer 3 (route-over)
− Layer-2 packet switching
− It creates a single layer-2 domain, all nodes appear to
be directly connected to each other somehow
− It may offer simpler solution
− It may offer lower transmission delay
− Layer-3 packet routing
− It separates data link and routing operations
− It may offer better management of a large network

29
Performance Issues

30
Network Performance

− Power Supply:
− limited power supply

− Power Consumption:
− Power consumption of communications is relatively high
− Network establishment and maintenance need
communications
− Departure of some nodes may cause the network to fail
partially or totally (e.g. nodes connecting to the
gateway, nodes connecting two islands of networks, etc)

31
Performance:

− Deployment of nodes:
− Bottleneck: When all flows aggregate at a particular
node, the node may represent the bottleneck of the
network
− Possible solutions: add more nodes to create other
paths; add gateways to divert traffic flows
This node needs to When all nodes transmit a packet,
forward packet for a large this node needs to transmit its
group of nodes packet and relay 7 others!

32
Performance:

− Deployment of nodes:
− Network lifetime: Nodes nearer to the gateway perform
more packet forwarding tasks. Their departures (due to
flat battery) may cause the network to fail.
− Possible solutions: add more nodes around the gateway;
use higher capacity battery
When this node fails, a group
of nodes will be disconnected
from the gateway

33
Performance:

− Position of a gateway:
− Bottleneck: Gateway may become bottleneck of traffic
flows if not adequately positioned in the network
− Possible solutions: reposition the gateway or nodes
around it and/or add more gateways to ease the
congestion

Bottleneck occurs at the

around the gateway

34
Performance:

− Position of a gateway:
− Delay: Nodes far away from the gateway may result in
long end-to-end transmission delay
− Possible solutions: relocating the gateway and/or place
more gateways. Ideally, we should keep the number of
hops between a node and the gateway as low as
possible
Some packets need 6 hops to
reach the gateway!

35
Summary

− Understand the roles and functions of network

module

− Understand various routing technologies related

to IoT applications

− Understand the impact of nodes/gateway

deployment on network performance

36
Questions?

37