EEEM048- 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 2014 1

Overview

− Network Module

− Routing Technologies

− Performance Issues

− Network Programming in Contiki with an example

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
− DOGAG 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

22
RPL: DOGAG 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

DIO
C

B received 2 DIO E
messages & set A as F H
23
preferred parent
RPL: DOGAG Building Process

− Procedure (cont’d):
− 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
24
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
25
RPL: Other Issues

− Topology maintenance
− A Trickle timer to control the sending rate of DIO
− 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

− Supporting multiple topologies

− RPL uses RPLInstanceID to label a graph
− RPLInstanceID is included in graph building process

26
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

27
Performance Issues

28
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)

29
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!

30
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

31
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

32
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!

33
Network Programming in Contiki

34
Network Programming in Contiki

− Two Packages
− The uIP TCP/IP stack:
− It provides Internet communication abilities to Contiki.
− The uIP implementation is designed to have only the
absolute minimal set of features needed for a full TCP/IP
stack. It can only handle a single network interface and
contains the IP, ICMP, UDP and TCP protocols.
− The Rime communication stack:
our focus
− It provides a set of lightweight communication primitives
ranging from best-effort anonymous local area broadcast to
reliable network flooding.

35
The Rime Communication Stack

Modules
− Rime buffer management, Packet queue, Rime queue buffer
management, Anonymous best-effort local area broadcast,
Announcements, Rimebroadcastannouncement, Best-effort local
area broadcast, Link estimate management, Collect neighbor
management, Tree-based hop-by-hop reliable data collection, Ipolite
best effort local broadcast, Mesh routing, Best-effort multihop
forwarding, Neighbor discovery, Best-effort network flooding,
Rimepoliteannouncement, Polite anonymous best effort local
broadcast, Rime addresses, Rime route discovery protocol, Rime
route table, Single-hop reliable bulk data transfer, Multi-hop reliable
bulk data transfer, Single-hop reliable unicast, Stubborn best-effort
local area broadcast, Stubborn unicast, Reliable single-source multi-
hop flooding, Single-hop unicast.
36
Example:
Best-effort local area broadcast
Data Structures
struct broadcast_callbacks;
struct broadcast_conn;

Functions
void broadcast_open (struct broadcast_conn *c,
uint16_t channel,
const struct broadcast_callbacks *u)
// Set up an identified best-effort broadcast connection.

int broadcast_send (struct broadcast_conn *c)

// Send an identified best-effort broadcast packet.

void broadcast_close (struct broadcast_conn *c)

// Close a broadcast connection.
37
Best-effort local area broadcast
Data structures
Data Structures
struct broadcast_callbacks;
struct broadcast_conn;

struct broadcast_callbacks {
void (*recv)(struct broadcast_conn *ptr, const rimeaddr_t *sender);
void (*sent)(struct broadcast_conn *ptr, int status, int num_tx);
}

struct broadcast_conn {
struct abc_conn c;
const struct broadcast_callbacks *u;
}

struct abc_conn {
struct channel channel;
const struct abc_callbacks *u;
};

38
Best-effort local area broadcast
Broadcasting a packet
#include "net/rime.h"
...
static const struct broadcast_callbacks broadcast_call = {broadcast_recv};
static struct broadcast_conn broadcast;

PROCESS_THREAD(example_broadcast_process, ev, data)

{
static struct etimer et;
PROCESS_EXITHANDLER(broadcast_close(&broadcast);) // exit process handler
PROCESS_BEGIN();
broadcast_open(&broadcast, 129, &broadcast_call); // open a handler
while(1) {
/* Delay 2-4 seconds */
etimer_set(&et, CLOCK_SECOND * 4 + random_rand() % (CLOCK_SECOND * 4));
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));

packetbuf_copyfrom("Hello", 6); // copy a string into the packet buffer

broadcast_send(&broadcast); // send the packet
printf("broadcast message sent\n");
}
PROCESS_END(); // broadcast_close() will be called
} 39
Best-effort local area broadcast
…and the receiving callback
#include "net/rime.h"
...
static const struct broadcast_callbacks broadcast_call = {broadcast_recv};
static struct broadcast_conn broadcast;

PROCESS_THREAD(example_broadcast_process,
static void ev, data)
{ broadcast_recv(struct broadcast_conn *c, const rimeaddr_t *from)
static struct
{ etimer et;
PROCESS_EXITHANDLER(broadcast_close(&broadcast);)
printf("broadcast message received from // exit '%s'\n",
%d.%d: process handler
PROCESS_BEGIN(); from->u8[0],
broadcast_open(&broadcast, 129, &broadcast_call); // open a handler
from->u8[1],
while(1) { (char *)packetbuf_dataptr());
/* Delay
} 2-4 seconds */
etimer_set(&et, CLOCK_SECOND * 4 + random_rand() % (CLOCK_SECOND * 4));
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));

packetbuf_copyfrom("Hello", 6); // copy a string into the packet buffer

broadcast_send(&broadcast); // send the packet
printf("broadcast message sent\n");
}
PROCESS_END(); // broadcast_close() will be called
} 40
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

− Network programming in Contiki

41
Questions?

42