6LowPAN and MQTT etc

Non-IP Based WPAN


WPAN Networks have adopted protocols that
are typically not TCP/IP.

Non-IP communication systems are optimal
as for cost and energy

IEEE 802.15: Wireless personal area network
definitions

IEEE 802.15.1: Original foundation of the
Bluetooth PAN
 Other Standards

IEEE 802.15.2: Coexistence specifications for WPAN and WLAN
for Bluetooth

IEEE 802.15.3: High data rate (55 Mbps+) on WPAN for
multimedia

IEEE 802.15.3c: High-Speed (>1 GBps) using mm-wave
(millimeter wave) technology

IEEE 802.15.4: Low data rate, simple, simple design, multi-
year battery life specifications (Zigbee)

IEEE 802.15.5: Mesh networking

IEEE 802.15.6: Body area networking for medical and
entertainment
 IP-based WPAN

Protocol stacks for Bluetooth, Zigbee, and
Z-Wave have similarities to TCP/IP but do
not inherently communicate over TCP/IP.

There are adaptions of IP on Zigbee (using
Zigbee-IP) and IP over Bluetooth (using
Internet Protocol Support Profile (IPSP) to
support 6LoWPAN).

Also, 6BLEMesh and RFC 7668
 IPv6 Header Format
0 4 12 16 24 31
Version Traffic Class Flow Label
Payload Length Next Header Hop Limit

Source Address

Destination Address

• Version field for version number 0110

• Traffic class to support differentiated services
• Flow: sequence of packets from particular source to particular
destination for which source requires special handling
 IPv6 Header Format
0 4 12 16 24 31
Version Traffic Class Flow Label
Payload Length Next Header Hop Limit

Source Address

Destination Address

• Payload length: length of data excluding header, up to 65535 B

• Next header: type of extension header that follows basic header
• Hop limit: # hops packet can travel before being dropped by a router
IPv6 Datagram
 IPv6 Addressing
 Unicast: single network interface
 Multicast: group of network interfaces, typically at different locations.
 Anycast: group of network interfaces. Packet sent to only one interface in
group, e.g. nearest.
 Hexadecimal notation
 Groups of 16 bits represented by 4 hex digits
 Separated by colons
 4BF5:AA12:0216:FEBC:BA5F:039A:BE9A:2176
 Shortened forms:
 4BF5:0000:0000:0000:BA5F:039A:000A:2176
 To 4BF5:0:0:0:BA5F:39A:A:2176
 To 4BF5::BA5F:39A:A:2176
 Mixed notation:
 ::FFFF:128.155.12.198
Address Structure
Provider-Based Address
Address Hierarchy
 Link-Local Address
 Meaningful only in a single link zone, and may be re-
used on other links
 Link-local addresses for use during auto-configuration
and when no routers are present
 Required for Neighbor Discovery process, always
automatically configuration
 An IPv6 router never forwards link-local traffic beyond
the link
 Prefix= FE80::/64
 IPv6 Address Generation Through
DHCPv6 or SAA

Stateless Address Autoconfiguration (SAA) is a
distributed mechanism that allows devices to
obtain a unique unicast IPv6 address that serves
for proper routing of datagrams.

A device relying on SSA dynamically generates its
IPv6 address by combining its 64-bit Interface
Identifier (IID) with the router supplied prefix.

The IID is derived from the device link layer
address and depends, therefore, on the link layer
technology in use.
 6LoWPAN

Purpose to allow IP networking over low-
power RF devices that are power and
space constrained and do not need high
bandwidth services.

Protocol can be used with other WPAN
communications such as IEEE 802.15.4 as
well as Bluetooth, sub-1GHz RF protocols,
and power line controller (PLC).
 IPv6 over Low power Wireless Personal
Area Networks (6LoWPAN )

IPv6 header field and the protocol itself is unsuitable for
IoT applications

All devices in a WPAN have IPv6 addresses that share the
same prefix.

The prefix and an IID that are derived via SAA from link
layer addresses and edge router parameters received in
6LoWPAN Neighbor Discovery (ND) RA messages.

6LoWPAN ND messages are ICMPv6 ND messages that
are exchanged in the context of 6LoWPAN and have been
optimized to work in WPANs as per IETF RFC 6775.
 Three Types of WPAN
1.Simple WPANs that have connectivity to
the IP core by means of edge routers,
2.Ad hoc WPANs that locally connect devices
and have no access to the IP core, and
3.Extended WPANs that have connectivity to
the IP code by means of several edge
routers along a backbone link.
 Adopting IPv6 into IoT Systems

Adopting IPv6 in constrained environments
through 6LoWPAN introduces:

packet fragmentation (into small link-layer
frames) and compression at the transmitter;

fragment reassembly (from small link-layer
frames) and decompression at the receiver.
 Effect of Small Size Packets in
6LowPANs

Due to the limited capabilities of objects in
the IoT, the distinction among the different
layers of the protocol stack is not as strong
as in the traditional Internet.
 Effect of Small Size Packets in
6LowPANs

Fragmentation can increase the probability of
packet delivery failure.

Given the small packet size of LoWPANs,
applications must send small amounts of data:

Less data ⇒ fewer fragments to be sent ⇒
lower energy consumption (CPU/TX/RX);

Less data ⇒ fewer fragments to be sent ⇒
lower packet loss probability.
 6LoWPAN

In an effort to bring IP addressability to the
smallest and most resource-constrained
devices, the concept of 6LoWPAN was formed in
2005.

A working group formalized the design in the
IETF under the specification RFC 4944 and later
updated with RFC 6282 to address header
compression and RFC 6775 for neighbor
discovery.
 6LoWPAN

6LoWPAN networks are mesh networks
residing on the periphery of larger
networks.

An Edge Router resides in between the
access and core networks and plays the
role of a traditional IoT gateway and relay
device.
 6LoWPAN

Edge Router handles traffic in and out of
the WPAN by performing 6LoWPAN
adaptation, ND for interaction with devices
on the same link and other types of
operations like IPv4-to-IPv6 translations for
communication with other entities in the IP
core.
6LoWPAN Architecture with Edge
Router
 Edge Router

Performs compression of IPv6 headers by
reducing a 40-byte IPv6 header and 8-byte
UDP headers for efficiency in a sensor
network.

A typical IPv6 header can compress to 2 to
20-bytes.
 Edge Router ...

Edge router initiates the 6LoWPAN network
and Exchanges data between devices on
the 6LoWPAN network.

Form 6LoWPAN mesh networks on larger
traditional network perimeters.

They can also broker exchanges between
IPV6 and IPV4 if necessary.
 Node Characteristics in 6LoWPAN

All nodes within a 6LoWPAN network share the
same IPv6 prefix that the edge router
establishes.

Nodes will register with the edge routers as
part of the ND phase.

ND controls how hosts and routers in the local
6LoWPAN mesh will interact with each other.

Multi-homing allows for multiple 6LoWPAN
edge routers to manage a network.
 Nodes in 6LoWPAN Mesh

Nodes are free to move and reorganize/reassemble in a
mesh.

A node can move and associate with a different edge
router in a multi-home scenario or even move between
different 6LoWPAN meshes.

When such topology change occurs, the IPv6 address of
the associated nodes also change.

In an ad hoc mesh without an edge router, a 6LoWPAN
router node could manage a 6LoWPAN mesh.
 Other Nodes in 6LoWPAN

Devices in a WPAN can behave like either
hosts or routers depending on source and
destination addresses of the datagrams.
 Other Nodes in 6LoWPAN

Router nodes: These nodes forward data
from one 6LoWPAN mesh node to another.

Routers can also communicate outward to
the WAN and internet.

Host nodes: Hosts in the mesh network
cannot route data and are simply
endpoints consuming or producing data.

Hosts sleep & occasionally wake to
produce data or receive data cached by
their parent routers.
6LoWPAN Stack and Translation
End-to-end IP network that combines a
traditional IPv6
core with an 6LoWPAN access
 Addresses

Most link layer IoT technologies like IEEE
802.15.4 support 64-bit MAC addresses
and configurable, 8-bit or 16-bit short
addresses typically assigned by the PAN
coordinator.
 Addresses

In the context of 6LoWPAN either one of
these types of addresses can be used to
form the 64-bit IIDs.

Edge router exchanges 6LoWPAN ND
messages that not only support SAA but
also enable it to keep track of all devices in
the link.

End devices can behave like routers or
hosts depending on their location and their
traffic processing capabilities.
 Addresses

End devices do not have direct connectivity
to the edge router and rely on mesh routing
to reach it.

Bootstrapping phase starts when the edge
router begins to advertise the 2001:11::/64
prefix to the devices by means of 6LoWPAN
ND RA messages.
 Addresses

Devices use this prefix and their own IID
derived from the 64-bit IEEE 802.15.4 MAC
address to generate IPv6 addresses.

Devices, also relying on 6LoWPAN ND,
register with the edge router and receive a
16-bit IID that is combined with the prefix to
generate a less complex IPv6 address.
 6LoWPAN Adaptation Layer

6LoWPAN standard provides header compression to
reduce the transmission overhead, fragmentation to
meet the IPv6 MTU requirement, and forwarding to
link-layer to support multi-hop delivery.

Constrained device characteristics necessitate an
adaptation layer in 6LoWPAN protocol stack that fits
IPv6 packets to the IEEE 802.15.4 specifications.
 6LoWPAN Adaptation Layer

6LoWPAN provides an adaptation layer within
layer three (network layer) and on top of layer
two (data link layer).

This adaptation layer is defined by the IETF.

6LoWPAN adaptation layer provides reliability
by means of error detection and correction.

The adaptation layer must also support
security through encryption and
authentication.
IPv6 Encapsulation/Routing
 Route-over Network

In a route-over topology, networks will incur the
charge of forwarding packets up to layer three
(network layer) of the stack.

Route-over schemes manage routes at an IP
level.

Each hop represents one IP router.

A route-over network implies that every router
node is equally capable and can perform the
larger set of functions as a normal IP router,
such as duplicate address detection.
 Route-over Network...

When 6LoWPAN is in place, communication between
devices is by means of capillary networking where
devices acting as routers have only one interface.

Datagrams enter the router and leave the router on
the same interface.

Not all devices on a single link can talk to each due
to the power limitations that prevent long distance
radio transmissions.

6LoWPAN layer should decompress IPv6 addresses
that are used for routing.
 Route-over Network

RFC 6550 formally defines the route-over
protocol RPL (ripple).

RPL provides multipoint-to-point communication
(where traffic from devices in a mesh
communicate to a central server on the internet)
and point-to-multipoint communication
(central service to the devices in the mesh).

Storing vs Non-storing network
6LoWPAN route-over
IPv6 Routing
 Mesh Forwarding to the 6LoWPAN
Adaptation Layer (Mesh Under)

Alternative to route-over routing is to rely on the
link layer to perform multihop frame mesh
forwarding and enable local link connectivity.

Link layer keeps track of source and destination
MAC addresses for immediate hop communication
but also original source and destination MAC
addresses for end-to-end support.
 Mesh Forwarding to the 6LoWPAN
Adaptation Layer (Mesh Under)

In the context of IEEE 802.15.4, mesh forwarding
is introduced as part of IEEE 802.15.5.

Link layer mesh forwarding is invisible to both
6LoWPAN and IPv6.
 Mesh-under Network

In a mesh-under topology, routing is
transparent and assumes a single IP
subnet representing the entirety of the
mesh.

A message is broadcast in a single domain
and is sent to all devices in the mesh.

This generates considerable traffic.
 Mesh-under Network

Mesh-under routing will move from hop to
hop in the mesh but only forward packets
up to L2 (data link layer) of the stack.

IEEE 802.15.4 handles all the routing for
each hop in layer two.
Link layer mesh forwarding
 Mesh-under Network

Here, 6LoWPAN keeps track of original
source and destination MAC addresses since
the link layer keeps tracks of source and
destination MAC addresses for immediate
hop communication.
 Mesh-under Network

Essentially at every single hop source and
destination MAC addresses are overwritten at
the link layer by means of the original source
and destination addresses carried in the
6LoWPAN mesh header.

Knowing source, destination, original, and final
MAC addresses is not only needed for mesh
forwarding but also for other services provided
by 6LoWPAN like fragmentation and reassembly
6LoWPAN Mesh Forwarding example
 Mesh Header

The header defines two 1-bit fields, O and F
that, respectively, indicate whether the original
and final MAC address is 16-bit PAN coordinator
assigned or 64-bit based.

Since the mesh header carries all information
needed for forwarding, it is the very first
header included in a 6LoWPAN datagram.
 Mesh Header

The header also includes a hops left field
that indicates how many times the packet
can be forwarded before it is dropped by the
network.

As the datagram traverses a network, and it
is forwarded by different devices acting as
routers, this counter is decremented.
 6LoWPAN on Other LL Technologies

6LoWPAN requires that link layer protocols
support framing, unicast transmission and
unique addresses that can be used, in turn,
to derive unique IPv6 addresses by means
of SAA.
 6LoWPAN on Other LL Technologies

Because IPv6 fragments cannot be smaller
than 1280 bytes, 6LoWPAN performs its own
fragmentation to adapt datagram
transmission to link layer mechanisms with
small MTUs.

It is therefore desirable for link layer frames
to be as large as possible with payloads of at
least 60 bytes to minimize the number of
fragments that 6LoWPAN needs to track.
 6LoWPAN on Other LL Technologies

For fixed network packet loss, it is always good
to minimize the number of fragments per
datagram since the more fragments the higher
the probability that a datagram will get dropped
by the network.

Also, 6LoWPAN compression can be used to
efficiently compress IPv6 and UDP headers in
order to maximize link layer payload size and
therefore minimize the number of fragments per
datagram.
 IETF CoRE (Constrained RESTful
Environments) Working Group (WG)

Chartered to provide a framework for RESTful
applications in constrained IP networks.

CoAP we know is used to let constrained devices
communicate with any node, either on the same
network or on the Internet, and provides a
mapping to HTTP REST APIs.

CoAP also provides create-read-update-delete
(CRUD) primitives for resources of constrained
devices and pub/sub communication capabilities.
 CoAP Observe Option - Recap

CoAP Observe option is used in GET requests in
order to let the client register its interest in the
resource.

The server then sends “unsolicited” responses
back to the client, echoing the token it specified
in the GET request

Server also reports an Observe option with a
sequence number used for reordering purposes.
 Message Queue Telemetry Transport

The IBM Websphere Message Queue technology
was first conceived in 1993 to address problems in
independent and non-concurrent distributed
systems to securely communicate.

A derivative of the WebSphere Message Queue
was authored by Andy Stanford-Clark and Arlen
Nipper at IBM in 1999 to address the particular
constraints of connecting remote oil and gas
pipelines over a satellite connection.
 MQTT

It is a lightweight broker-based
publish/subscribe application protocol that
provides session layer functionality.

Developed and designed for low
transmission rate constrained devices.

Can be used in scenarios where two-way
communications between endpoints
operating in unreliable networks must occur.
 Publish/subscribe

Publish/subscribe, also known as pub/sub, is a
way to decouple a client transmitting a
message from another client receiving a
message.

Unlike a traditional client-server model, the
clients are not aware of any physical identifiers
such as the IP address or port.

MQTT is a pub/sub architecture, but is not a
message queue
 MQTT

According to the pub/sub model, in MQTT,
messages are published to a shared topic
space inside the broker.

Topics are used as filters on the message
stream from all publishers to the broker.

MQTT supports hierarchical topics in the
form of a topic/sub-topic/sub-sub-topic
path.
 MQTT Broker

A client transmitting a message is called a
publisher; a client receiving a message is called a
subscriber.

In the center is an MQTT broker who has the
responsibility of connecting clients and filtering
data.

In MQTT, the broker applies the subscription
filters to the message stream it receives in order
to efficiently determine to which clients a
message should be dispatched.
 MQTT Client-Broker Connections

MQTT uses TCP/IP to connect to the broker.

Most MQTT clients will connect to the broker and
remain connected even if they aren’t sending data.

Connections are acknowledged by the broker
using a Connection acknowledgement message.

A device cannot publish or subscribe unless it is
connected.
 Command and Response

MQTT clients publish
a keepalive message at
regular intervals (usually
60s) which tells the broker
that the client is still
connected.

All clients are required to
have a unique client
name or ID.
MQTT Broker
 Eclipse Mosquitto

An open source message broker that implements the MQTT
protocol.

Mosquitto is lightweight and is suitable for use on all devices.

Mosquitto MQTT broker was initially developed by Roger
Light in 2009 and later donated to the Eclipse Foundation.

It was the first open source MQTT project.

The broker receives all messages from the clients, filters the
messages, determines who is subscribed to each message,
and then sends the message to these subscribed clients.
 Clean Sessions

MQTT clients by default establish a clean session with a
broker.

A clean session is one in which the broker is not expected to
remember anything about the client when it disconnects.

With a non-clean session, the broker will remember client
subscriptions and may hold undelivered messages for the
client.

However, this depends on the QoS used when subscribing to
topics, and the QoS used when publishing to those topics.
 Last Will Messages

The last-will message is to notify a subscriber that the
publisher is unavailable due to network outage.

It is set by the publishing client, and is set on a per topic
basis, which means that each topic can have its own last-
will message.

This means that each topic can have its own last-will
message associated with it.

The message is stored on the broker and sent to any
subscribing client (to that topic) if the connection to the
publisher fails.
 Matching the Condition Through
Filter

Messages are delivered to all clients that
have subscribed with a matching topic filter.

This means that a single client can receive
messages coming from multiple publishers.

The matching condition is applied to the
topic’s hierarchy, so it possible to subscribe
to just a portion of the topic.
 Filters in Pub/Sub

Subject filtering: By design, clients
subscribe to topics and certain topic
branches and do not receive more data than
they want.

Each published message must contain a
topic and the broker is responsible for either
re-broadcasting that message to subscribed
clients or ignoring it.
 Filters in Pub/Sub

Content filtering: Brokers have the ability to
inspect and filter published data. Thus, any data
not encrypted can be managed by the broker
before being stored or published to other clients.

Type filtering: A client listening to a subscribed
data stream can apply their own filters as well.
Incoming data can be parsed and the data
stream either processed further or ignored.
 MQTT Packet Formats

MQTT is a binary based protocol were the control elements are
binary bytes and not text strings.

Client ID, User names and Passwords are encoded as UTF-8
strings.

The Payload excluding MQTT protocol information like Client ID
etc is binary data and the content and format is application
specific.

The message header for each MQTT command message
contains a fixed header.

Some messages also require a variable header and a payload.
 Packet Formats

Fixed Header (Control field + Length) – Example
CONNACK

Fixed Header (Control field + Length) + Variable
Header -Example PUBACK

Fixed Header (Control field + Length) + Variable
Header + payload -Example CONNECT