Design and Development of IoT Applications 5-Aug-24

Content
Chapter 7: Wireless Embedded Internet
ICMPv6
Auto-configuration & Neighbor Discovery
IP routing in WSNs: RPL
Embedded web – REST/CoAP
MQTT-SN
HMI

Dept. of Telecoms Engineering 1

Design and Development of IoT Applications 5-Aug-24

IPv6 review
 IPv4 and IPv6
comparison
 6LoWPAN: IPv6
Header Compression:
support L3 routing
(Route-Over)
 6LoWPAN Neighbor
Discovery (ND)

Dept. of Telecoms Engineering 2

Design and Development of IoT Applications 5-Aug-24

ICMPv6
 Internet Control Message
Protocol v6
 Modification from ICMP for IPv4
 Neighbor Discovery (ND)
 Replace ARP, ICMP
 Reachability of Neighbors
 Hosts use to discovery routers,
auto-configuration of addresses
 Duplicate Address Detection
(DAD)
 5 ND messages:
• Router Solicitation (type 133)
• Router Advertisement (type 134)
• Neighbor Solicitation (type 135)
• Neighbor Advertisement (type 136)
• Redirect (type 137)

Dept. of Telecoms Engineering 3

Design and Development of IoT Applications 5-Aug-24

Auto-configuration

Dept. of Telecoms Engineering 4

Design and Development of IoT Applications 5-Aug-24

IP Routing in WSNs
Low power and Lossy Network (LLN) consists of an
edge router (also called as LLN Border Router LBR),
Router(R) and Host(H):
 H chooses only the default router
 R forwards traffic
 ROLL operates only within LoWPAN and terminates at LBR

Dept. of Telecoms Engineering 5

Design and Development of IoT Applications 5-Aug-24

RPL: new trend in WSN

Routing Protocol for Low-power and Lossy Network
(LLNs)
LLN: “Low power and Lossy networks (LLNs) are typically
composed of many embedded devices with limited power, memory,
and processing resources interconnected by a variety of links, such
as IEEE 802.15.4 or Low Power WiFi. There is a wide scope of
application areas for LLNs, including industrial monitoring, building
automation (HVAC, lighting, access control, fire), connected home,
healthcare, environmental monitoring, urban sensor networks,
energy management, assets tracking and refrigeration”

Dept. of Telecoms Engineering 6

Design and Development of IoT Applications 5-Aug-24

LLNs: Fact
 LLNs have not to be confused with Wireless Sensor Networks
 A WSN is an LLN, but not the opposite !
 LLNs are not necessarily wireless.
 Industrial automation networks are wired.
 LLNs will use IPv6. No discussions about this.
 IPv4 is a dead horse.
 LLN nodes can not be easily configured.
 Typically, they’re cheap, small and with very limited memory/CPU

Dept. of Telecoms Engineering 7

Design and Development of IoT Applications 5-Aug-24

LLNs: Open Issues

 Transmission efficiency (6LoWPAN)
 Nodes run on battery. Saving energy is a premium. IPv6 Headers must
be compressed.
 Node bootstrap (6lowpan-nd)
 Configuration is a nightmare, and ‘normal’ IPv6 auto configuration is
too chatty, NS/NA as well, etc,.
 Routing (ROLL)
 Routing requirements are scenario-based. Mainly:
• one-to-one (configuration, data reading)
• many-to-one (data gathering)
• one-to-many (data dissemination)

Dept. of Telecoms Engineering 8

Design and Development of IoT Applications 5-Aug-24

DAG and DODAG

 DAG: Directed Acyclic Graph (Fig. B)
 DAG root: a node within the DAG that has no outgoing edge
 All paths terminated at a DAG root
 All edges are oriented in such a way that no cycles exist (Fig. A is
not a DAG)
 DODAG: Destination Oriented DAG (Fig. C)
 Defines a DAG that forms paths to a single logical root

Dept. of Telecoms Engineering 9

Design and Development of IoT Applications 5-Aug-24

Why DODAG for RPL?

Traffic in LLN
Mainly for P2MP and MP2P traffic flows
As opposed to a tree topology, DODAG enables
(re)route around loss/interference and easily
adapts transient changes
RPL organizes a topology as a Directed Acyclic
Graph (DAG) that is partitioned into one or more
Destination Oriented DAGs (DODAGs)
The root in DAG acts as a sink – P2MP and MP2P traffic
• DODAG root -> LBR
• Information stored and processing at other nodes can be
reduced
Dept. of Telecoms Engineering 10
Design and Development of IoT Applications 5-Aug-24

RPL Control Messages

RPL defines a new ICMPv6 message with 3
possible types:
 DAG Information Object (DIO) - carries information that
allows a node to discover an RPL Instance, learn its
configuration parameters and select DODAG parents
 DAG Information Solicitation (DIS) - solicit a DODAG
Information Object from a RPL node
 Destination Advertisement Object (DAO) - used to
propagate destination information upwards along the
DODAG.

Dept. of Telecoms Engineering 11

Design and Development of IoT Applications 5-Aug-24

Upward and Downward Routes

 Upward: the direction from leaf
nodes towards the DODAG root
 Data flow towards the DAG root - MP2P
traffic flows

Upward Route
 Downward: the direction from the
DODAG root towards leaf nodes
 Data flow away from the DAG root –
P2MP traffic flows

 Point-to-point data flow via up and

down route

Dept. of Telecoms Engineering 12

Design and Development of IoT Applications 5-Aug-24

RPL Metrics
 A metric defines how a node (or link) will affect the path. A
metric is used to compute the node’s rank and to decide
about preferred Parents.
 Each metric is carried in a DAG Metric Container,
embedded in the relevant RPL control messages.
 Node metrics: Node-related information, such as: Node
State and Attributes, Node Energy, Hop-Count
 Link metrics: Link-related information, such as:
Throughput, Latency, Link Reliability, Link Color
 Routing metric:
 RFC 6551: path calculations (node energy, hop count, throughput,
latency, etc…

Dept. of Telecoms Engineering 13

Design and Development of IoT Applications 5-Aug-24

Rank vs OF
 Rank: node's individual position relative to other nodes
with respect to a DODAG root
 Increases in the Down direction and decreases in the Up
direction
 Rank computed depends on the Objective Function (OF) - e.g.
calculated as a simple topological distance (hop counts) or may
also be calculated as a function of link metrics
 Objective Function (OF): Defines the optimization
objectives to compute the Rank
 Optimization objectives : minimizing energy, minimizing latency,
or satisfying some constraints, etc…
 Dictates how routers (parents) inside the DODAG are selected.

Dept. of Telecoms Engineering 14

Design and Development of IoT Applications 5-Aug-24

Objective Functions (OF)

 RPL was designed as a generic protocol, can be adapted by OFs. There
exists several OFs in operation on the same node and 6LoWPAN
network - to carry traffic with very different requirements of path
quality. For example, several DODAGs may be used with:
 OF1: ‘Find the best path in terms of ETX [Expected Transmissions]
values (metric) and avoid non-encrypted links (’constraint)’ or
 OF2: ‘Find the best path in terms of latency (metric) while
avoiding battery- operated nodes (constraint)’
 RPL (generic core):
 Parent (feasible successor) selection rules
 Loop avoidance based on Rank
 The OF functions:
 Selects the Preferred Parent in parents set
 Computes Rank
Dept. of Telecoms Engineering 15
Design and Development of IoT Applications 5-Aug-24

Objective Functions (OF)

 Uses a combination of metrics (ETX, hop counts, latency, etc) and
constraints (avoiding battery powered node, avoiding non-encrypted
nodes) to compute the ‘best’ path
 OF does not necessarily specify the metric/constraints but does
dictate some rules to form the DODAG (for example, the number of
parents, back-up parents, use of load-balancing, etc)
 The OF accounts for
 Statistical information (ETX, packet losses, etc)
 Boolean information (battery operated)
 Physical information (max bandwidth)
 Configuration (preference, security level, …
 Two proposed OFs
 RPL Objective Function 0, OF0 (RFC 6552)
The Minimum Rank Objective Function with Hysteresis, MRHOF
(draft-ietf-roll-minrank-hysteresis-of-11)
 The Trickle Algorithm
 RFC 6206: to exchange information in a highly robust, energy efficient,
simple, and scalable manner
Dept. of Telecoms Engineering 16
Design and Development of IoT Applications 5-Aug-24

Example of 2 different OFs

Dept. of Telecoms Engineering 17

Design and Development of IoT Applications 5-Aug-24

RPL Instance
 RPL Instance: Composed of one or more disjoint DODAGs, each of
which has an unique DODAGID
 All DODAGs in the same RPL Instance use the same OF (Objective
Function)

 RPLInstanceID: identifies a set of one or more Destination Oriented

DAGs (DODAGs)
 RPLinstanceID can be used to identify different OFs
 RPLInstanceID and DODAGID uniquely identifies a single DODAG in
the network
 different DODAGID = different root node
Dept. of Telecoms Engineering 18
Design and Development of IoT Applications 5-Aug-24

RPL Instance Example: Multiple DAGs

Dept. of Telecoms Engineering 19

Design and Development of IoT Applications 5-Aug-24

RPL Instance Example: Multiple DAGs

Dept. of Telecoms Engineering 20

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 Distance-Vector
advertise path cost (routing
metric)
choose a parent (default router/
next hop) that minimize path
cost
Avoids loops & count-to-infinity
 Assign every node a rank
Node Rank: Relative position
within a DODAG
Rank strictly decreasing towards
the root
 Parents & Siblings
Parents –nodes with lower ranks
Siblings –nodes with same ranks
Dept. of Telecoms Engineering 21
Design and Development of IoT Applications 5-Aug-24

Data Path Validation & Loop Detection

 RPL packet information (Up/Down route) is
transported inside a data packet
 On-demand loop detection using data
packets
 maintaining an up-to-date routing topology
can waste energy for LLNs with infrequent
data
 An inconsistency between the routing
decision for a packet (upward or downward)
and the Rank relationship between the two
nodes indicates a possible loop
 E.g. if S3 receives a packet flagged as moving
in the upward direction, and if that packet
records that the transmitter (S2) is of a lower
Rank than the receiving node (S3)
 S3 should initiate a local repair

RPL does not guarantee the absence of loops but rather tries to avoid them
and specifies mechanisms to detect loops via data path validation
Dept. of Telecoms Engineering 22
Design and Development of IoT Applications 5-Aug-24

Creation of Upward routes – DIO messages

 Some nodes are configured to be DODAG
roots
 DODAG roots advertise their presence
(affiliation with a DODAG, routing cost,
and related metrics) by sending link‐local
multicast DIO messages to all-RPL-nodes
 Nodes listen for DIOs
 to join a new DODAG (thus selecting DODAG
parents),
 or to maintain an existing DODAG, according
to the specified Objective Function
 Nodes update routing table entries, for
the destinations specified by the DIO
message
 Nodes can decide to join one or more
DODAG parents as the next-hop for the
default route
Dept. of Telecoms Engineering 23
Design and Development of IoT Applications 5-Aug-24

Creation of Downward Routes: DAO Messages

 RPL uses DAO messages to establish
downward routes: nodes inform parents
of their presence and reachability to
descendants by sending a DAO message
 DAO messages are an optional feature
for applications that require P2MP or
P2P traffic
 RPL supports two modes of downward
traffic:
 Storing (fully stateful): aggregate routes
 Non‐storing (fully source routed): attach a
next-hop address to the reverse route stack
contained within the DAO message

Dept. of Telecoms Engineering 24

Design and Development of IoT Applications 5-Aug-24

Storing Mode vs Non-Storing mode

 Storing mode
 Creation of routes
• DAO propagates towards the root via
the routers
• Each router maintains routes to each
router in WSNs
 Data goes hop by hop (each router
forwards the packet to the right
next hop)

 Non-storing mode
 Only the root stores routes to the
all routers in WSNs
 Calculates routes to all destination
by piecing together the info
(address of the routers) collected
from DAO messages
 Data forwards using source routing
Dept. of Telecoms Engineering 25
Design and Development of IoT Applications 5-Aug-24

Storing Mode vs Non-Storing mode

 Storing mode:
 Requires more storage capacities and memory on each router
 Efficient communications
 Extra mechanism to avoid loops (e.g. use of RPL packet information)
 Non-storing mode:
 Does not require additional state on the routers, but increases the
message overhead
 Traffic through the root node increases for internal traffic (e.g. P2P
traffic within a 6LoWPAN)
 Loop can be avoided by checking headers?

The data packet travels ‘up’ to a

common ancestor at which point it is
forwarded in the ‘down’ direction to
the destination

Dept. of Telecoms Engineering 26

Design and Development of IoT Applications 5-Aug-24

Route Construction and Forwarding

Up routes towards nodes of
decreasing rank
Via DAG parents (always forward
to lower rank when possible)
may forward to sibling if no lower
rank exists

Down routes towards nodes of

increasing rank
Nodes inform parents of their
presence and reachability
Forward hop by hop (storing
mode) or using source routing
(non-storing mode)
Dept. of Telecoms Engineering 27
Design and Development of IoT Applications 5-Aug-24

RPL Repair
 Global repair: makes use of DODAG Sequence Numbers
 Local repair - poison the sub-DODAG by advertising the rank of
INFINITY

Dept. of Telecoms Engineering 28

Design and Development of IoT Applications 5-Aug-24

Summary: Building DODAG

 Routers sends DIO (DODAG Information Object) messages
 Uses link local multicasting
 Indicates a respective rank (= position), according to a metric (e.g.
hop count) w.r.t. the root
 Upward routes (paths towards the root) are created
 Defines the optimization objective when forming upward route
• Link properties: (Reliability, Latency), Node properties: (Powered or not)
• Objective: optimize paths based on one or more metrics
 Node issues DAO (Destination Advertisement Object)
messages
 Propagates via DAO selected parents discovered during DIO
propagation
 DAO can be acknowledged
 Downward routes are created

Dept. of Telecoms Engineering 29

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 LLN links are depicted
LBR-1  LBR is configured by the
1 2 system administrator (There
3 could be several LBR)
A
1
B
1
C  Links are annotated w/ ETX
1
1
1
 RPL uses new ICMPv6
messages
1
4
F D E  DIO: DODAG Information Object
1  DAO: Destination Advertisement
1 1 1
Object
1  DIS: DODAG Information
G H I
Solicitation

Dept. of Telecoms Engineering 30

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 Objective Code Point for
LBR-1
example
1 2
 Metric: ETX
3  Objective: Minimize ETX
1 1  Depth computation: Depth ~ ETX
A B C
• Note that a practical computation
1 may be more coarse
1 1

1
4
F D E
1
1 1 1

1
G H I

Dept. of Telecoms Engineering 31

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 LBR-1 multicasts RA-DIO
LBR-1  Nodes A, B, C receive and
1 2 process RA-DIO
3
 Nodes A, B, C consider link
1 1
A B C metrics to LBR-1 and the
1
1
1
optimization objective
1
 The optimization objective can
4
F D E be satisfied by joining the DAG
1 1
1
1
rooted at LBR-1
 Nodes A, B, C add LBR-1 as a
1
G H I DAG parent and join the DAG

RA: Route Advertisement

Dept. of Telecoms Engineering 32
Design and Development of IoT Applications 5-Aug-24

DAG Construction
 Node A is at Depth 1 in the
LBR-1
DAG, as calculated by the
1 2
routine indicated by the
3 example OCP (Depth ~ ETX)
A
1
B
1
C  Node B is at Depth 3, Node C
1
is at Depth 2
1 1
 Nodes A, B, C have installed
1
F D 4
E default routes (::/0) with
1
LBR-1 as successor
1 1 1

1
G H I

Dept. of Telecoms Engineering 33

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 The RA timer on Node C
LBR-1 expires
1 2  Node C multicasts RA-DIO
3
 LBR-1 ignores RA-DIO from
1 1
A B C deeper node
1
1
1  Node B can add Node C as
1
alternate DAG Parent,
4
F D E remaining at Depth 3
1 1
1
1  Node E joins the DAG at
Depth 3 by adding Node C as
1
G H I DAG Parent

If a node is configured to act as a router, it starts advertising the graph information to its neighbors
A leaf node, it simply joins the graph and does not send any DIO message
Dept. of Telecoms Engineering 34
Design and Development of IoT Applications 5-Aug-24

DAG Construction
 LBR-1 multicasts DIO
LBR-1  Node A is at Depth 1, and can
1 2 reach ::/0 via LBR-1 with ETX
3 1
A
1
B
1
C  Node B is at Depth 3, with
1 DAG Parents LBR-1, and can
1 1
reach ::/0 via LBR-1 or C with
1
F D 4
E ETX 3
1  Node C is at Depth 2, ::/0 via
1 1 1
LBR-1 with ETX 2
G
1
H I  Node E is at Depth 3, ::/0 via
C with ETX 3

Dept. of Telecoms Engineering 35

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 The RA timer on Node A expires
LBR-1  Node A multicasts RA-DIO
1 2
 LBR-1 ignores RA-DIO from
3
deeper node
 Node B adds Node A
1 1
A B C  Node B can improve to a more
1 optimum position in the DAG
1 1
 Node B removes LBR-1, Node C
1
4
as DAG Parents
F D E
 Node B removes (keeps as
1 backup)
1 1 1
 ::/0 via LBR-1 with ETX 3
1
 ::/0 via C with ETX 3
G H I  Adds:
 ::/0 via A with ETX 2

Dept. of Telecoms Engineering 36

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 Node A is at Depth 1, ::/0 via
LBR-1 LBR-1 with ETX 1
1 2  Node B is at Depth 2, ::/0 via
3
A with ETX 2
1 1
A B C  Node C is at Depth 2, ::/0 via
1
1
1
LBR-1 with ETX 2
1
 Node E is at Depth 3, ::/0 via
4
F D E C with ETX 3
1
1 1 1

1
G H I

Dept. of Telecoms Engineering 37

Design and Development of IoT Applications 5-Aug-24

DAG Construction
 DAG Construction
continues…
LBR-1
1 2
 And is continuously
3
maintained
 This rippling effect builds the
1 1
A B C graph edges out from the
root to the leaf nodes where
1
1 1 the process terminates
 Each node of the graph has a
1 routing entry towards its
4
F D E
parent in a hop‐by‐hop
1 fashion
1 1 1
 The leaf node can send a
1 packet all the way to root of
G H I the graph by just forwarding
the packet to its immediate
parent

Dept. of Telecoms Engineering 38

Design and Development of IoT Applications 5-Aug-24

MP2P Traffic – via Upward Route

 MP2P traffic flows inwards
LBR-1
along DAG, toward DAG Root
1 2  DAG Root may also extend
3 connectivity to other prefixes
A
1
B
1
C beyond the DAG root, as
1
specified in the DIO
1 1
 Nodes may join multiple
1
F D 4 E DAGs as necessary to satisfy
1
application constraints
1 1 1

1
G H I

Dept. of Telecoms Engineering 39

Design and Development of IoT Applications 5-Aug-24

Downward Route and Destination Advertisements

 Destination Advertisements build up
routing state in support of P2MP traffic
LBR-1 flows outward, from the sink to other
nodes
1 2
3  DA uses the same DAG
1 1
 For simplicity, we will focus on a subset
A B C of DA in the example
1  Nodes inform parents of their presence
1 1
and reachability to descendants by
1
sending a DAO message
4
F D E  Node capable of maintaining routing
1 state -> Aggregate routes
1 1 1
 Node incapable of maintaining routing
1
state -> attach a next-hop address to
G H I the reverse route stack contained within
the DAO message

Dept. of Telecoms Engineering 40

Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 Some nodes may be able to
LBR-1 store routing state for outward
1 flows (LBR-1, A, F)
 Some nodes may not (B, D)
1
A B  Some nodes may have a
1
limited ability; DAs may
indicate a priority for storage
1
F D

1 1

1
G H

Dept. of Telecoms Engineering 41

Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 DAs may be triggered by DAG
LBR-1 root or node who detects a
1 change

1
A B  DA timers configured such
1
that DAs start at greater
depth, and may aggregate as
1
F D they move up
1 1

1
G H

Dept. of Telecoms Engineering 42

Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 LBR-1 triggers Destination
LBR-1
Advertisement mechanism in DIO
1  G emits NA to F with DAO
indicating reachability to
A
1
B destination prefix G::
 F stores G:: via G
1
 H emits NA to F for destination
1
F D prefix H::
1 1
 F stores H:: via H

1
G H

NA: Neighbor Advertisement

Dept. of Telecoms Engineering 43
Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 Suppose in this example F has a
LBR-1
prefix F*:: capable of aggregating
1
{F::, G::, H::}
 The method to provision such a prefix is
1 beyond the scope of RPL
A B
 F emits NA to D with DAO indicating
1 reachability to destination prefix F*::
F
1
D
 D cannot store…

1 1
(continued)
1
G H

Dept. of Telecoms Engineering 44

Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 D adds F to the Reverse Route Stack
LBR-1 in the DAO, and passes DAO on to B
1 for F*:: [F]
 D also emits a DAO indicating prefix
1
A B D:: to B
1
 B cannot store routing state…
1
F D

1 1
(continued)

1
G H

Dept. of Telecoms Engineering 45

Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 B adds D to the Reverse Route
LBR-1 Stack in the DAO for D::, and passes
1 DAO D:: [D] on to A
 A stores D:: via B, with the
1
A B piecewise source route [D]
1
 B also emits a DAO indicating prefix
B:: to A
1
F D  A stores B:: via B
1 1

(continued)
1
G H

Dept. of Telecoms Engineering 46

Design and Development of IoT Applications 5-Aug-24

Destination Advertisements
 A emits DAOs to LBR-1 for
LBR-1 destination prefixes A::, B::, D::,
1 and F*
 LBR-1 stores A:: via A, B:: via A,
1
A B D:: via A, and F*:: via A
1
 A stored B:: via B, D:: via B [D],
F* via B [D, F]
1
F D  B, D stored nothing
1 1  F stored G:: via G, H:: via H
1
G H

Dept. of Telecoms Engineering 47

Design and Development of IoT Applications 5-Aug-24

P2MP Traffic
 The routing state setup by
LBR-1 Destination Advertisement is used
1 to direct P2MP traffic outward
 LBR-1 directs traffic for G (F*::) to A
1
A B  A adds source routing directive, [D,
1
F], and forwards to B
1
 B uses source routing directive to
F D forward to D...
1 1

1
G H

Dept. of Telecoms Engineering 48

Design and Development of IoT Applications 5-Aug-24

P2MP Traffic
 D uses source routing directive to
LBR-1 forward to F
1  F uses routing state to forward to G
 Note the use of source routing to
1
A B traverse the stateless region of the
1
LLN
 The details of the source routing
1
F D mechanism are still to be defined

1 1

1
G H

Dept. of Telecoms Engineering 49

Design and Development of IoT Applications 5-Aug-24

P2P Traffic
 By default, P2P traffic follows
LBR-1 the default route until a node
1 2 is encountered who has a
3 more explicit route
A
1
B
1
C  P2P traffic flows inwards
1 along the DAG until a
1 1
common node is reached to
1
F D 4 E direct the traffic outwards
1
1 1 1

1
G H I

Dept. of Telecoms Engineering 50

Design and Development of IoT Applications 5-Aug-24

P2P Traffic
 The default scheme allows
LBR-1 P2P traffic with minimal state
1 2 required of nodes – but is
3 not appropriate in all cases
A
1
B
1
C  More optimal P2P routes
1 may be computed and
1 1
installed if the application
1
F D 4 E requires
1
 RPL does not specify nor
1 1 1 preclude such a mechanism at
this time
1
G H I

Dept. of Telecoms Engineering 51

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Floating DAG

 Consider the case where the
LBR-1 link B—D goes bad
1 2  Node D will remove B from
3 its DAG parent set
A
1
B
1
C  Node D no longer has any
1
DAG parents in the grounded
1 1
DAG, so it will become the
1
4
root of its own floating DAG
F D E
1
1 1 1

1
G H I

Dept. of Telecoms Engineering 52

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Floating DAG

 Node D multicasts an RA-DIO
LBR-1
to inform its sub-DAG of the
1 2
change
3  Node I has an alternate DAG
A
1
B
1
C Parent, E, and does not have
1
to leave the DAG rooted at
1 1
LBR-1.
F
1
D 4 E  Node I removes Node D as a
1
DAG Parent
1 1 1

1
G H I

Dept. of Telecoms Engineering 53

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Local Repair

 Node F does not have an
LBR-1 option to stay in the DAG
1 2 rooted at LBR-1 (no alternate
3 DAG Parents), so Node F
A
1
B
1
C follows Node D into the
1
floating DAG
1 1
 Node F multicasts an RA-DIO
1
F D 4 E  Nodes G and H follow Node F
1 into the floating DAG
1 1 1

1
G H I

Dept. of Telecoms Engineering 54

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Local Repair

 The sub-DAG of node D has
LBR-1 now been frozen
1 2  Nodes contained in the sub-
3
DAG have been identified,
1 1
A B C and by following node D into
1 the floating DAG, all old
1 1
routes to LBR-1 have been
1
F D 4 E purged
1  The floating DAG seeks to
1 1 1
rejoin a grounded DAG…
1
G H I

Dept. of Telecoms Engineering 55

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance
 Node I multicasts an RA-DIO
LBR-1  Node D sees a chance to
1 2 rejoin grounded DAG at
3
depth 5 through Node I
1 1
A B C  Node D starts a DAG Hop
1
1
1
timer of duration  4
associated with Node I
1
F D 4 E
1
1 1 1

1
G H I

Dept. of Telecoms Engineering 56

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance
 Suppose a link A—F becomes
LBR-1
viable
1 2  Node A multicasts an RA-DIO
3
 Node F sees a chance to
1 1
A B C rejoin grounded DAG at
1 depth 2 through Node A
1 1 1
 Node F starts a DAG Hop
1
F D 4 E timer of duration  1
1 associated with Node A
1 1 1

1
G H I

Dept. of Telecoms Engineering 57

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Loop Avoidance

 Node F’s DAG Hop Timer
LBR-1
expires
1 2  Node F joins to the grounded
3 DAG at depth 2 by adding A
A
1
B
1
C as a DAG parent, and
1
removing D
1 1 1
 Node F multicasts an RA-DIO
1
F D 4 E  Nodes G and H follow Node F
1 to the grounded DAG
1 1 1

1
G H I

Dept. of Telecoms Engineering 58

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Loop Avoidance

 Node D sees a chance to
LBR-1
rejoin DAG LBR-1 at depth 3
1 2
through Node F
3  Node D starts a DAG Hop
A
1
B
1
C timer of duration  2
1
associated with Node F, in
1 1 1
addition the DAG Hop timer
F
1
D 4 E
already running with
duration  4 associated with
1
1 1 1 Node I
1
G H I

Dept. of Telecoms Engineering 59

Design and Development of IoT Applications 5-Aug-24

DAG Maintenance: Loop Avoidance

 Node D’s DAG Hop timer of
LBR-1
duration  2 tends to expire
1 2
first
3  Node D joins the grounded
A
1
B
1
C DAG at depth 3 by adding
1
Node F as a DAG Parent
1 1 1
 The breaking-off and re-
1
F D 4 E joining of the broken sub-
1
DAG is thus coordinated with
1 1 1
loop avoidance
1
G H I

Dept. of Telecoms Engineering 60

Design and Development of IoT Applications 5-Aug-24

Loop Avoidance
Two mechanisms to avoid count-to-infinity

Floating DAG
Leave DAG, color sub-DAG, then look for new routes
Operation local to nodes that must increase their depth
Does not guarantee loop freedom

Sequence number change

Loop freedom, but expensive network-wide operation
Used infrequently if possible

Dept. of Telecoms Engineering 61

Design and Development of IoT Applications 5-Aug-24

Joining RPL network

When a node appears (it is switched on, or it
moves the given area), it starts listening to DIO
messages
If it receives such messages, it decides which DODAG
to join
If it receives nothing, or if it wants to speed up the
process, it sends a DIS message
• DODAG Information Solicitation
• Triggers the sending of DIO messages from its neighbors
If still no DIO is received, it has the choice to become
the root of a floating DODAG
• Starts sending its own multicast DIO messages

Dept. of Telecoms Engineering 62

Design and Development of IoT Applications 5-Aug-24

RPL: summary
Working with 6LoWPAN
Support IP-based Application
Support P2MP, MP2P traffic
Routing state is minimized: stateless nodes have to
store only instance(s) configuration parameters and a
list of parent nodes
Consider both link and node properties when choosing
paths
Link failures does not trigger global network re-
optimization

Dept. of Telecoms Engineering 63

Design and Development of IoT Applications 5-Aug-24

IPv4 Interoperability

Dept. of Telecoms Engineering 64

Design and Development of IoT Applications 5-Aug-24

Protocol Stack for WSNs

 What does missing in the protocol stack?
 PHY/MAC 802.15.4
 Adaptation: 6LoWPAN
 Routing: RPL
 Transport: UDP
 Application Protocol?
 IP provides packet networking over heterogeneous links
 UDP: Best-effort (packets may be silently dropped, duplicated or
delayed and may arrive out of order) - the fastest and most
simple way of transmitting data
 TCP: Reliable connection oriented
 IP uses Socket Communication: end-points are defined by 16 bit
source and destination ports and source and destination IP
addresses
Dept. of Telecoms Engineering 65
Design and Development of IoT Applications 5-Aug-24

IP based Application Protocols

 Widely used internet protocols (TCP, HTTP, FTP; SIP and SOAP)
 Considerable work has to be done for adapting to 6LoWPAN
 Existing protocols for WSNs (mainly based on UDP)
 MQTT: Message Queue Telemetry Transport is developed by IBM
 CAP: ZigBee Compact application Protocol
 SLP: simple Service Location Protocol
 Etc..

Dept. of Telecoms Engineering 66

Design and Development of IoT Applications 5-Aug-24

IP based Application Protocols

IP based application protocols over 6LoWPAN
6LoWPAN supports the compression of UDP ports down to a
range of 16
• should be enough for limited number of applications that can be run
TCP header is not easy to compress
TCP is not efficient over lossy wireless multi-hop networks
Why UDP for 6LoWPAN?
Simple, compressible and suits most application protocols
needs
Multicast support
Reliability?

Dept. of Telecoms Engineering 67

Design and Development of IoT Applications 5-Aug-24

Application Protocols for WSNs

 MQTT (Message Queue Telemetry Transport) by IBM
Lightweight publish/subscribe protocol over TCP/IP
• Fixed-length header (2 bytes)
One-to-many message distribution
3 QoS for message delivery (At most once, at least once,
exactly once)
Applications, e.g. Facebook Messenger
 XML-based protocols (SOAP)
M2MXML
• Messages are strict ASCII
• Devices are identified by 128-bit UUID
• BiTXml
 RESTful protocols
HTTP
CoAP
Dept. of Telecoms Engineering 68
Design and Development of IoT Applications 5-Aug-24

Design Issues
 Link Layer
 Payload size, limited
bandwidth, lossy
 Multicast support
 Networking
 Limited compressed UDP port
 Host issues
 Sleeping cycles
 Identification (64 bit, 16 bit
addresses)
 Compression
 Header and payload
compression
 End-to-end or by an
intermediate node
 Security
 Application layer security
 Firewalling at the edge router
Dept. of Telecoms Engineering 69
Design and Development of IoT Applications 5-Aug-24

Web Service
 De-facto for inter-server
communications
 All Internet servers speak HTTP/XML
 SOAP or REST architecture
 Advantages
 Formal message sequences
 Internet-wide support
 Most Internet applications use web
services, which depend on the basic
Representational State Transfer (REST)
architecture
 Disadvantages for embedded services
 Inefficient, complex

Dept. of Telecoms Engineering 70

Design and Development of IoT Applications 5-Aug-24

REST Architecture
 Representational State Transfer (REST)
 Describes client-server and cacheable communications
protocol, such as HTTP, to make simple calls between
network devices
 REST-style architectures consist of clients and
servers
 Clients initiate requests to servers
 Servers process requests and return appropriate
responses
 Requests and responses are built around the transfer of
representations of resources
 Resources: mostly identified by its URI (Uniform
Resources Identifier)
 Resources may be web-address, a physical resource or
simply a document located somewhere on a server
 Representations: to manipulate resources
 Representation defines the format of the resource
 Typical representations are HTML, XML or JSON,
 but may be also binary, plain-text, MIME types, etc
 Methods: allows clients to retrieve, modify or delete
resources by use of their representations
 The basic operations/methods on a resource are GET,
PUT, POST and DELETE
Dept. of Telecoms Engineering 71
Design and Development of IoT Applications 5-Aug-24

Resource
 Protocols (e.g. HTTP, CoAP)
 Sources of specific information
(e.g. sensors, web-content)
 Identified by an Uniform
Resource Identifier (URI)
 Manipulation through
Methods (e.g. GET, PUT)
 Represented as jpg, plain-text,
etc.

Dept. of Telecoms Engineering 72

Design and Development of IoT Applications 5-Aug-24

Web Services for WSNs

 Today’s web services are no good for embedded systems
 FTP, HTTP, XML, SOAP
 Web services for embedded devices
 RESTful architecture for good web integration
 UDP based transport with multicast support
 Overhead suitable for constrained networks
 Complexity suitable for constrained nodes
 Built-in web discovery and security
 The Constrained RESTful Environments (CoRE) working group
aims at realizing the REST architecture for constrained nodes
and networks
 e.g. 8-bit microcontrollers with limited RAM and ROM
 networks (e.g. 6LoWPAN)

Dept. of Telecoms Engineering 73

Design and Development of IoT Applications 5-Aug-24

CoAP: Constrained Application Protocol

 A specialized web transfer protocol for use with constrained networks
and nodes
 M2M applications (smart energy, building automation, etc…)
 To monitor simple sensors (e.g. temperature sensors, light switches, and
power meters)
 To control actuators (e.g. light switches, heating controllers, and door locks)
 To manage devices
 Embedded web transfer protocol (coap://)
 Asynchronous transaction model
 UDP binding with reliability and multicast support
 GET, POST, PUT, DELETE methods
 URI support
 Small, simple header < 10 bytes
 Subset of MIME types and HTTP-compatible response codes
 Optional observation, block transfer and discovery

Dept. of Telecoms Engineering 74

Design and Development of IoT Applications 5-Aug-24

What is CoAP (and is not)?

CoAP is
A RESTful protocol
Both synchronous and asynchronous
For constrained devices and networks
Specialized for M2M applications
Easy to proxy to/from HTTP

CoAP is not
A replacement for HTTP
General HTTP compression
Separate from the web

Dept. of Telecoms Engineering 75

Design and Development of IoT Applications 5-Aug-24

CORE Architecture
 Use of web services on the Internet
depends on the Representational C: Constrained node ‐ sensor nodes
State Transfer (REST) architecture Non‐constrained nodes ‐ server,
 RESTful protocol to cater the special proxy, node, etc
requirements of a constrained
environment
 Simple RESTful protocol transport
 Create, Read, Update, Delete, Notify
• Small, simple header
• 4 byte base header
• TLV options, typically 1-270 bytes per
option
 URI support: e.g.
coap://fec0::1:5683/temp
 Subset of content types
 Subset of HTTP-compatible response
codes
 UDP bindings
 default port = 5683

Dept. of Telecoms Engineering 76

Design and Development of IoT Applications 5-Aug-24

The Transaction Model

Transport
CoAP is defined for UDP
Messaging
Simple message exchange between
end-points
CON, NON, ACK, RST
REST
Request/Response piggybacked on
messages
Method, Response Code and Options
(URI, content-type etc.

Dept. of Telecoms Engineering 77

Design and Development of IoT Applications 5-Aug-24

CoAP Message Format

 Ver: Version,
Message Format  T: Transaction Type
(CON,NON,ACK…)
 OC: Number of options
 Code: Method or
Response Code
 Message ID: A unique ID
assigned by the originator

Option Header
 Option Delta- Difference
between this option type
and the previous!
 Length - Length of the
option value (0-270)!
 Value- The value of
Length bytes
immediately follows
Length

Dept. of Telecoms Engineering 78

Design and Development of IoT Applications 5-Aug-24

CoAP Code
 Structure of the 8 bit
Response code:

 3 classes:
 2 – Success
 4 – Client error
 5 – Server error

 Example: "Not Found" is

written as 4.04 - indicating
a value of decimal 132

Dept. of Telecoms Engineering 79

Design and Development of IoT Applications 5-Aug-24

Methods of CoAP

Dept. of Telecoms Engineering 80

Design and Development of IoT Applications 5-Aug-24

Example of CoAP Message

Dept. of Telecoms Engineering 81

Design and Development of IoT Applications 5-Aug-24

Transaction Messages of CoAP

 Confirmable (CON)
 To know it did arrive or to
deliver the reply
 Return message type ACK/RST
 Acknowledgment (ACK)
 ACK to the CON message
(identified by a message ID)
 Payload carries more data
 Reset (RST)
 To let the client know the CON
message is received, but
processing failed
 E.g. node has rebooted
 Non-Confirmable (NON)
 Do not require an ACK
 E.g. repeated readings from a
sensor

Dept. of Telecoms Engineering 82

Design and Development of IoT Applications 5-Aug-24

CoAP Operation
 CoAP interaction is similar to the client/server model (CoAP
end points)
 URI and Content-type support (like in HTTP)
 Message exchange is similar to HTTP
 Request action is originated by a client (using a Method code)
 Request is for a Resource (identified by a URI) on a server
 Response is sent with a Response Code

Dept. of Telecoms Engineering 83

Design and Development of IoT Applications 5-Aug-24

CoAP Operation
Unlike HTTP, CoAP deals
Operates over UDP, with reliable unicast
and multicast support
• Retransmission (= reliable unicast) A CoAP end-
point keeps track of open Confirmable
messages it sent that are waiting for a response
• Simple Congestion Control - exponential back-
off mechanism
Deals with message interchanges
separately
• Server might need longer time to obtain the
representation of resource. This results in the
client retransmitting the request

Dept. of Telecoms Engineering 84

Design and Development of IoT Applications 5-Aug-24

CoAP Operation
 Operates over UDP, with
reliable unicast and best-
effort multicast support
 CON vs NON messages?
 If CON/NON messages cannot
be processed,
Server sends RST message
 Why MID & Token?

Dept. of Telecoms Engineering 85

Design and Development of IoT Applications 5-Aug-24

CoAP Options
 Content‐Type: Specifies the format of the application payload
 Max‐Age: Maximum age for a message to be cached
 Proxy‐Uri: Defines an absolute URI to a proxy
 Token: Matches a separate response to a request
 Uri‐Host: Specifies the Internet host of a resource (only added
if not representing the destination IP address of the request)
 Uri‐Path: Specifies the resource of the host
 Uri‐Port: Specifies the port of the host (only added if differs
from the destination UDP port request)
 Uri‐Query: Indicates additional options for the request
 etc..

Dept. of Telecoms Engineering 86

Design and Development of IoT Applications 5-Aug-24

Request Example
Request and Response
CON message

NON message

Dealing with packet loss

Dept. of Telecoms Engineering 87

Design and Development of IoT Applications 5-Aug-24

Request Example
Normal response

Dept. of Telecoms Engineering 88

Design and Development of IoT Applications 5-Aug-24

Caching
 CoAP includes a simple
caching model
 Cache ability determined by
response code
 Freshness model
 Max-Age option indicates
cache lifetime
 Validation model
 Validity checked using the Etag
Option
 A proxy often supports
caching
 Usually on behalf of a sleeping
node,
 and to reduce network load

Dept. of Telecoms Engineering 89

Design and Development of IoT Applications 5-Aug-24

Observation
 The Observe Option, when present,
modifies the GET method so it does
not only retrieve a representation
of the current state of the resource
identified by the request URI, but
also requests the server to add the
client to the list of observers of the
resource.
 In a response, the Observe Option
identifies the message as a
notification, which implies that the
client has been added to the list of
observers and that the server will
notify the client of further changes
to the resource state

Dept. of Telecoms Engineering 90

Design and Development of IoT Applications 5-Aug-24

Block Transfer
 Transfers larger than can be accommodated in constrained-network link-
layer packets can be performed in smaller blocks.
 No hard-to-manage conversation state is created at the adaptation layer
or IP layer for fragmentation.

Dept. of Telecoms Engineering 91

Design and Development of IoT Applications 5-Aug-24

Resource Discovery
 Resource Discovery with CoRE Link Format
 Web linking as per RFC5988
 Discovering the links hosted by CoAP servers
 GET /.well-known/core
 Returns a link-header style format
 URL, relation, type, interface, content-type etc.

Dept. of Telecoms Engineering 92

Design and Development of IoT Applications 5-Aug-24

MQTT
 MQTT (Message Queuing
Telemetry Transport) is a
machine-to-machine
connectivity protocol that
runs over TCP/IP.
 Lightweight, simple,
MQTT is based on a
publish- subscribe
structure:
 Publisher
 Broker
 Subscriber
QoS Support
 QoS 0, QoS 1, QoS 2

Dept. of Telecoms Engineering 93

Design and Development of IoT Applications 5-Aug-24

MQTT: Benefits
 Lightweight and efficient: MQTT reports by exception and message
headers are very small, minimizing the resources required for the
client and network bandwidth.
 Bi-directional: allows messaging from devices to the cloud and from
the cloud to devices, which enables broadcasting messages to
groups of things.
 Supports unreliable networks: support for persistent sessions
reduces the reconnection time required over unreliable networks.
 Scalable: can scale to connect millions of IoT devices simultaneously.
 Security enabled: MQTT makes it easy to encrypt messages using
TLS (transport layer security) and authenticate clients using modern
authentication protocols, such as OAuth.
 Reliable: The publish/subscribe functionality and the ability to
queue messages means no data loss through MQTT. MQTT also
supports reliable message delivery through the three defined QoS
Dept. of Telecoms Engineering 94
Design and Development of IoT Applications 5-Aug-24

MQTT Example
 Clients do not have addresses like in
email systems, and messages are not
sent to clients.
 Messages are published to a broker
on a topic.
 The job of an MQTT broker is to filter
messages based on topic, and
then distribute them to subscribers.
 A client can receive these messages by
subscribing to that topic on the same
broker
 There is no direct connection between
a publisher and subscriber.
 All clients can publish (broadcast) and
subscribe (receive).
 MQTT brokers do not normally store
messages.

Dept. of Telecoms Engineering 95

Design and Development of IoT Applications 5-Aug-24

MQTT-S Protocol
 MQ Telemetry transport for WSNs
 Publish/Subscribe protocol
 Optimized for low-bandwidth wireless
sensor networks (MQTT-S)
 Integrated with Brokers (gateways)
 Can be used with UDP/6LoWPAN
 Model: client/broker
 Application: M2M

Dept. of Telecoms Engineering 96

Design and Development of IoT Applications 5-Aug-24

MQTT-S Protocol
 Connect message split into three messages, two are optional
and are used for the will message
 Topic ID’s used in place of topic names.
 Short Topic names
 Pre-defined topics.
 Discovery process to let clients discover the Gateway
 Will Topic and messages can be changed during the session
 Offline keep alive procedure for sleeping clients.

Dept. of Telecoms Engineering 97

Design and Development of IoT Applications 5-Aug-24

MQTT-SN Architecture
 When client 1 talks to client 2 does it require the MQTT broker
to do so? Specifically in the diagram above for clients 3 and 4.
Is it: MQTT-SN >MQTT-SN. In this case the gateway is also a
MQTT-SN broker.
 or is it: MQTT-SN >MQTT>MQTT-SN. In this case the gateway is
an MQTT-SN gateway and an MQTT broker.

http://www.steves‐internet‐guide.com/mqtt‐sn/
Dept. of Telecoms Engineering 98
Design and Development of IoT Applications 5-Aug-24

MQTT-SN in Contiki
Gateway Type: The specification defines two gateway
types:
A transparent gateway were each MQTT-SN connection has
a corresponding MQTT connection. This is the easiest type
to implement.
An aggregating gateway were multiple MQTT-SN
connections share a single MQTT connection

http://www.steves‐internet‐guide.com/mqtt‐sn/
Dept. of Telecoms Engineering 99
Design and Development of IoT Applications 5-Aug-24

MQTT-SN: Data flow

Dept. of Telecoms Engineering 100

Design and Development of IoT Applications 5-Aug-24

Really Small Message Broker

 Really Small Message Broker (RSMB)
 Client 1 to Client 2 then RSMB = MQTT-SN Broker
 Client 3 to Client 4 then RSMB = MQTT Broker
 Client 1 to Client 3 then RSMB = MQTT-SN-MQTT Gateway
 The RSMB broker functions both as a MQTT-SN broker
and also as an MQTT broker allowing messages between
MQTT-SN clients and MQTT clients

http://www.steves‐internet‐guide.com/mqtt‐sn/
Dept. of Telecoms Engineering 101
Design and Development of IoT Applications 5-Aug-24

MQTT-SN in Contiki
 MQTT-SN with RSMB in Contiki

Dept. of Telecoms Engineering 102

Design and Development of IoT Applications 5-Aug-24

Full stack with 802.15.4 MAC

COAP/MQTT-SN

Dept. of Telecoms Engineering 103

Design and Development of IoT Applications 5-Aug-24

Full stack with 802.15.4e MAC

Dept. of Telecoms Engineering 104

Design and Development of IoT Applications 5-Aug-24

Human-Machine Interface
 Benefit:
 Make the Smart Applications more than a
Remote-control system
 Natural interaction with humane (via voice,
gesture, etc..)
 Technologies:
 AI, Machine learning, Data Science
 Cloud-based or local model (AI on-the-Edge)

Dept. of Telecoms Engineering 105

Design and Development of IoT Applications 5-Aug-24

Human-Machine Interface
 Integrated Alexa, Google Voice

Dept. of Telecoms Engineering 106

Design and Development of IoT Applications 5-Aug-24

Human-Machine Interface
-

IP/LoWPAN
Border Router
control
HMI
WSN

Voice

LoWPAN/IPv6
network

Dept. of Telecoms Engineering 107

Design and Development of IoT Applications 5-Aug-24

Human-Machine Interface

Dept. of Telecoms Engineering 108

Design and Development of IoT Applications 5-Aug-24

HMI: using Google Assistant

Dept. of Telecoms Engineering 109

Design and Development of IoT Applications 5-Aug-24

HMI: example using Google Assistant

e.g. https://io.adafruit.com
voice to Text publish
IFTTT topics MQTT Broker

-
subscribe
topics

IP/LoWPAN
Border Router
control
MQTT Client
WSN

LoWPAN/IPv6
network

Dept. of Telecoms Engineering 110

Design and Development of IoT Applications 5-Aug-24

HMI: an example with Cooja

• Google Assistant: Convert voice to text, and transfer text to IFTTT platform
• IFTTT: a platform to connect devices and applications together.
In this scenario, it connect Google Assistant with MQTT Broker. When a voice-
to-text is sent to IFTTT, it will publish this text to MQTT Broker.
• MQTT Broker: relay message to MQTT clients via topics. So it is the
intermediate node to bridge the communication between IFTTT and MQTT
client (running in virtual machine)
• MQTT Client: an application running in virtual machine to convert the text
(from voice) to command to control a node in the Cooja simulated network.
Note that in order to get the text from Google Assistant, the MQTT client and
IFTTT must use the same topic (e.g. “light” in this scenario)
• Wireless Sensor Networks (can be simulated or real): is the end node in this
system. This WSN includes some IPv6/6LoWPAN nodes with a Border Router,
connecting nodes to the outside network. Hence the command from MQTT
client can send to a specific node via UDP/IPv6 protocol.

Dept. of Telecoms Engineering 111

Design and Development of IoT Applications 5-Aug-24

HMI: an example with Cooja

 Local Broker will bridge Cloud Broker

 All nodes will run MQTT protocol
 Subscribe topics from Local broker

Dept. of Telecoms Engineering 112

Design and Development of IoT Applications 5-Aug-24

HMI: a deployment example

Dept. of Telecoms Engineering 113

Design and Development of IoT Applications 5-Aug-24

Human-Machine Interface: Alexa

Dept. of Telecoms Engineering 114

Design and Development of IoT Applications 5-Aug-24

Human-Machine Interface: Alexa

 (1) Devices using Alexa Voice Service to record the user’s command and
sends it to Alexa Service where developer create their Custom Skills.
 (2) Alexa Service converts the voice into text and analyze its, creates
intent data then sends it to Your Service. In order to Alexa Service can
send data to Your Service developer need to provide endpoint (Amazon
Resource Names (ARNs) if use Lambda or developer URL host).
 (3) Your Service needs developer’s code to implement 2 tasks: sends
command or data to Device Cloud and sends the response to Alexa
Service. This place needs to know the endpoint of Device Cloud.
 (4a) Alexa Service receives response from Your Service then converts it
to voice and sends to Devices using Alexa Voice Service. (4b) at the
same time Device Cloud gets the command from Your Service and
forwards it to IOT devices.
 (5a) Devices using Alexa Voice Service receives response and speaks to
user. (5b) IOT device implements command

Dept. of Telecoms Engineering 115

Design and Development of IoT Applications 5-Aug-24

HMI: Example using Alexa

IoT Cloud

IoT Device

Dept. of Telecoms Engineering 116

Design and Development of IoT Applications 5-Aug-24

HMI: Example using Alexa + MQTT

Dept. of Telecoms Engineering 117

Design and Development of IoT Applications 5-Aug-24

Local Voice recognition

Networking

Feedback by voice command

Amp
TTS

noise + clean syntax IoT

AFE voice ASR NLP
echo Control

Text

Acronyms: Wakeup word STT

- AFE: Audio Front-End
- ASR: Automatic Speech Recognition
- NLP: Natural Language Processing
- STT: Speech To Text
- TTS: Text To Speech

Dept. of Telecoms Engineering 118