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
(ABDF)
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
