Network protocols

Internet Wireless
 IPv4 WiFi
 IPv6 Bluetooth
 TCP Zigbee
 UDP Z-wave
Wired Powerline
 1-wire, 2-wire X10, LonTalk

Wireless protocols for IoT

 Bluetooth low energy

 6LoWPAN (IPv6 over low power PAN)
 Zigbee
 Z-Wave
 LoRaWAN
 NB-IoT
 ...

Communication Technologies for IoT

 1-Bluetooth
• Standard: Bluetooth 4.2 core specification
• Frequency: 2.4GHz (ISM)
• Range: 50-150m (Smart/BLE)
• Data Rates: 1Mbps (Smart/BLE)

 2-Zigbee
• Standard: ZigBee 3.0 based on IEEE802.15.4
• Frequency: 2.4GHz
• Range: 10-100m
• Data Rates: 250kbps

1
Communication Technologies for IoT
3-Z-Wave : Z-Wave is a low-power RF communications
technology that is primarily designed for home automation for
products such as lamp controllers and sensors among many
others
• Standard: Z-Wave Alliance ZAD12837 / ITU-T G.9959
• Frequency: 900MHz (ISM)
• Range: 30m
• Data Rates: 9.6/40/100kbit/s
4-WiFi : may be too power-consuming for many IoT
applications.
 Standard: Based on 802.11n (most common usage in homes
today)
 Frequencies: 2.4GHz and 5GHz bands
 Range: Approximately 50m
 Data Rates: 600 Mbps maximum, but 150-200Mbps is more
typical, depending on channel frequency used and number of 4
antennas (latest 802.11-ac standard should offer 500Mbps

5-Cellular : Any IoT application that requires operation over

longer distances can take advantage of GSM/3G/4G cellular
communication capabilities.
• Standard: GSM/GPRS/EDGE (2G), UMTS/HSPA (3G), LTE (4G)
• Frequencies: 900/1800/1900/2100MHz
• Range: 35km max for GSM; 200km max for HSPA
• Data Rates (typical download): 35-170kps (GPRS), 120-384kbps
(EDGE), 384Kbps-2Mbps (UMTS), 600kbps-10Mbps (HSPA), 3-
10Mbps (LTE)
6-NFC : (Near Field Communication) two-way interactions between
electronic devices, and applicable for smartphones, (contactless payment
transactions, access digital content and connect electronic devices )
• Standard: ISO/IEC 18000-3
• Frequency: 13.56MHz (ISM)
• Range: 10cm
• Data Rates: 100–420kbps
5

7-Sigfox : Sigfox uses a technology called Ultra Narrow Band

(UNB) and is only designed to handle low data-transfer speeds of
10 to 1,000 bits per second. It consumes only 50 microwatts
compared to 5000 microwatts for cellular communication,
Already deployed in tens of thousands of connected objects
• Standard: Sigfox
• Frequency: 900MHz
• Range: 30-50km (rural environments), 3-10km (urban
environments)
• Data Rates: 10-1000bps
8- LoRaWAN : similar in some respects to Sigfox and Neul,
LoRaWAN targets wide-area network (WAN) applications
• Standard: LoRaWAN
• Frequency: Various
• Range: 2-5km (urban environment), 15km (suburban
environment)
• Data Rates: 0.3-50 kbps. 6

2
9- RFID
There are two types of radio frequency identification: active
and passive. This protocol was designed specifically so devices
without batteries could send a signal

10-Neul :Similar in concept to Sigfox and operating in the sub-

1GHz band, the devices can consume as little as 20 to 30mA
from 2xAA batteries, meaning 10 to 15 years in the field.
 Standard: Neul
 Frequency: 900MHz (ISM), 458MHz (UK), 470-790MHz)
 Range: 10km
 Data Rates: Few bps up to 100kbps

IoT Network Topology

Unified & Horizontal IoT Platform
Device Management/Cloud
2G/3G/LTE/WiFi/Fixed Unlicensed LPWA Networks in 3GPP Licensed
LPWA Network(s)
ISM bands (+ other bands) NB-IoT + EC-GSM

+20dB Link
budget gain

Concentrator
RF Mesh

Smart Meters

Smart Meter Smart Building Fleet Management Smart Waste Smart Parking with
Management Management with battery-powered
battery-powered sensors sensors

IOT Routing Protocoles

 the organization in charge of Internet protocol
standardization, has created several working groups to
specify interoperable protocols for networks with highly
constrained devices or LLNs (Low Power and Lossy
Networks).

 https://tools.ietf.org/html/draft-ietf-core-coap-18
 http://www.bortzmeyer.org/7252.html
 https://www.researchgate.net/figure/An-example-of-
Constrained-RESTful-Environments-CoRE-direct-resource-
discovery-and_fig2_262819123

3
IOT Routing Protocoles
We can mention mainly
1. Coap : The CORE group is developing a simplified version of HTTP that
requires fewer resources while maintaining HTTP compatibility.

2. RPL As for the ROLL working group, it has defined the RPL routing protocol,
which makes it possible to build a routing topology on constrained networks
(pronounce RPL as the English word "riple" meaning undulation).

3. 6LoWPAN (The IPv6 in Low-Power Wireless Personal Area Networks)

working group that defined how to transport IPv6 datagrams over low-
bandwidth, low-power links, and how to train and maintain them IPv6 subnet
(Internet Protocol version 6).

4. Finally, the ACE group deals with security in constrained environments.

These four working groups have a key role in defining an open and interoperablee
Internet of Things.

10

Protocole CoAP : Introduction

2/23

11
11

COAP(1)
 CONSTRAINED APPLICATION PROTOCOL
 Transport UDP
 Sécurity DTLS (Datagram Transport Layer Security)
 Architecture REST
 OSI Aplication Level
 RESTful protocol transfert

3/23

12

4
 COAP(CONSTRAINED APPLICATION PROTOCOL)

• Transport UDP
• Sécurity DTLS (Datagram Transport Layer Security)
• Architecture REST
• OSI Aplication Level
• RESTful protocol transfert
13

Architecture du COAP

14

COAP Request / Response

URI

15

5
Méthodes du COAP :CoAP/RESTful

 Méthode Get
Récupération des informations qui corresponds à la ressource
identifier par l’URI de la requête, un code de réponse 2.05 ou 2.03
devrait être présent
 Méthode Post
Demande que la requête doit être traitée, si le test post est réussi un
code de réponse 2.04 devrait être présent
 Méthode Put
Demande que la ressource identifiée par la requête URI doit être
mise à jour ou créée , si le test réussit un code de réponse 2.01
devrait être présent
 Méthode Delete
Demande que la ressource identifiée par l'URI de la requête soit
supprimée, si le test réussit un code de réponse 2.02 devrait être
présent
16

Types du message

 CON / Confirmable message :

- Accusé de réception positif / accusé de réception
négatif.
 NON / Non-confirmable message :
- Transmission non fiable.
 ACK / Acknowledgement :
- Accusé réception d'un message confirmable (CON).
 RST / Reset :
- Accusé de réception négatif.

17

CoAP/protocol header

0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | OC | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Message Format
3.1. Header Format

The fields in the header are defined as follows:

Version (Ver): 2-bit unsigned integer. Indicates the CoAP version
number. Implementations of this specification MUST set this field
to 1. Other values are reserved for future versions.
Type (T): 2-bit unsigned integer. Indicates if this message is of
type Confirmable (0), Non-Confirmable (1), Acknowledgement (2) or
Reset (3). See Section 4 for the semantics of these message
types.
Option Count (OC): 4-bit unsigned integer. Indicates the number of
options after the header (0-14). If set to 0, there are no
options and the payload (if any) immediately follows the header.
If set to 15, then an end-of-options marker is used to indicate
the end of options and the start of the payload. The format of 18
options is defined below.

6
Format du message COAP

• Message size : Must fit in a single IP datagram

• Default MTU 1280 bytes
• 6LOWPAN 127 bytes
• WSN based on IEEE 802.15.4 127 bytes

19

CoAP/example
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=1, MID=0x7d34)
| GET | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=69,
MID=0x7d34)
| 2.05 | Payload: "22.3 C"
| |

20

COAP Observe

21

7
CORE Ressource Discovery

22

COAP Multicast

23

Perte des paquets

24

8
COAP open source implementation

Erbium Californium Copper

pour pour JAVA pour
CONTIKI FIREFOX

25

COPPER

26

RPL

RPL

27

9
RPL (Routing Protocol for Low power
and Lossy Networks)

 RPL (Routing Protocol for Low power and Lossy Networks)

protocole de routage à vecteur de distance, le routage est basé sur
des graphes acycliques dirigés vers une destination (DODAG).
 DAG (Directed Acyclic Graph): est un graphe orienté sans cycle
comme dans la Fig.01
 Root : c'est la destination des noeuds dans le DAG.

Roots

cycle

Fig.01. DAG structure

28

RPL
 Up : C'est tout edge qui est dirigé vers le Root .
 Down : C'est tout edge qui est dirigé loin de Root.
 DODAG (Destination Oriented DAG ) : C'est un type
particulier de DAG où chaque nœud veut atteindre un
seul destination (Fig.02).
 Rank : Comme le montre
la Fig.02, c’est la
distance du Root.

29

RPL

 RPL instance: When we have one or More DODAGs, then each

DODAG is an instance. Fig.03 shows two RPL instances.

Instance 1 instance 2
• DODAG ID : Each DODAG has
an IPv6 ID (128 bit). This ID is DODAG_ID=1
DODAG_ID=2
given to its root only. And as long
as the root doesn’t change ID
also doesn’t change.

• DODAG Version: Each new shape

(modification) Of a DODAG means
a new version. Fig.03. RPL instances

30

10
RPL

 Objective Function : Cela nous aide à décider si nous sommes près de la

racine ou si nous en sommes éloignés. La fonction objectif est décidée par un
programmeur ou un concepteur. C'est quelque chose que nous voulons
minimiser. Cela peut être de l'énergie, cela peut être de la latence. Et une fois
que nous décidons ce que nous voulons minimiser, nous lui donnons un
nombre (définition métrique).

GOAL: C’est là où un DODAG veut atteindre, il

peut s’agir d’un réseau câblé. Le but est différent de la
fonction objectif. En fonction objective, notre objectif
est de minimiser. Cependant, l'objectif est où nous
voulons aller.
Grounded: Lorsqu'un DODAG
atteint son objectif, il est appelé
Grounded. G sur la Fig.04. montre
Fig.04. Floating and Grounded
DODAG Grounded. DODAGs

Floating : lorsqu'un DODAG n'est

pas connecté ou n'a pas encore 31
atteint l'objectif, il s'appelle Flottant.

RPL
 Parent Le parent est l'endroit où se dirige la flèche. Et un
enfant est d'où vient la flèche. Les parents peuvent avoir
plusieurs enfants, tout comme un enfant peut avoir
plusieurs parents
 Sub-DODAG : C'est n'importe quel sous-arbre d'un DODAG
donné.
 Storing: Les nœuds de stockage conservent la totalité de la
table de routage. Ils savent comment aller d'un nœud à un
autre.

 Non storing: Ils sont simples, ils ne stockent pas une table
de routage complète, ils ne connaissent que leurs parents.
L'ensemble du DODAG, à l'exception de la racine Root, doit
conserver une uniformité, qu'il soit Storing ou non storing. 32
Le Root est toujours storing.

RPL Approach
 Construire et maintenir un DAG prenant en charge les flux
MP2P
• plusieurs successeurs lorsque disponibles (vs. Tree)
• Implémentation des métriques et fonctions objectives spécifiques à
la mise en œuvre pour trouver les chemins les moins coûteux
 Utilisez DAG pour contraindre et guider le calcul des routes
prenant en charge les flux P2MP
 Utiliser MP2P + P2MP comme support de base de P2P
• P2P plus optimal fourni avec des mécanismes complémentaires

33

11
Approach – the DAG
 Les nœuds occupant une position dans le DAG calculent une
valeur de «profondeur» spécifique à la fonction métrique et
objective utilisée

 La valeur de profondeur peut être utilisée pour évaluer la

position relative dans le DAG

34

Approach - Forwarding
 Le transfert du trafic MP2P vers des nœuds de moindre
profondeur évite les boucles
• se produisent uniquement en présence d'une incohérence de
profondeur, qui est évitée ou découverte et résolue
• Redondance importante dans la plupart des réseaux
 Le transfert de trafic vers des nœuds de même profondeur
(frères DAG) peut être utilisé si le transfert à une
profondeur inférieure échoue temporairement
• Augmente la redondance, mais une protection supplémentaire
contre les boucles, par exemple, id's, doit être ajoutée
 Le transfert du trafic MP2P vers des nœuds plus profonds
est peu probable et en boucle

35

Approach - Loops
 Les nœuds plus profonds peuvent se trouver dans leur
propre sous-DAG, ce qui augmente considérablement le
risque de création de boucles.
• Transférer le trafic dans son propre sous-groupe de disponibilité de
base de données signifie qu’il risque de revenir!

 RPL construit et maintient le DAG de manière coordonnée

en évitant de former des boucles

36

12
RPL Control -messages:
There are 5 Control Messages, they form the Spanning tree :
 DODAG information Object (DIO) : This message is Multicasted
downwards . A given node In a DODAG may multicast this
message , which lets other nodes know about it , Things like
whether the node is grounded or not, whether it storing or non-
storing, and it announces other nodes “if they are interested to join ,
Please Let Me know. “
 DODAG Information Solicitation (DIS) : When no
announcement is heard, and if a node wants to join a DODAG it
sends a control message , For that it wants to know If any DODAG
exists. So the message which it sends is Like “ Is there any
DODAG ? “
 DODAG advertisement Object (DAO) : It is A request send by a
Child to parent or root. This message requests to allow the child to
join to a DODAG.
 DAO-ACK : It is a response Send by a root or parent to the child ,
this response can either be a Yes or No. 37
 Consistency check : deals with security , and We need not to know

Messages de contrôle RPL

Il y a 5 messages de contrôle, ils forment le Spanning Tree:
 DODAG Information Object (DIO): Ce message est
multicast vers le bas (downwoards). Un nœud donné Dans un
DODAG peut multidiffuser ce message, ce qui permet aux autres
nœuds de le savoir, par exemple si le nœud est grouded ou non,
qu’il est storing ou non storing, et il annonce aux autres nœuds
"s'ils sont intéressés de rejoindre, S'il vous plaît, faites-moi
savoir. “
 DODAG Information Solicitation (DIS) :
lorsqu'aucune annonce n'est entendue, et si un nœud souhaite
rejoindre un DODAG, il envoie un message de contrôle, Pour cela,
il souhaite savoir si un DODAG existe. Le message qu’il envoie est
donc le suivant: «Existe-t-il un DODAG? “
 DODAG Aadvertisement Object (DAO) : Il s’agit
d’une demande envoyée par un enfant à un parent ou à une
racine. Ce message demande d'autoriser l'enfant à rejoindre un
DODAG.
38
 DAO-ACK: C'est une réponse envoyée par une racine ou un
parent à l'enfant, cette réponse peut être un oui ou un non.

39

13
DAG Construction

Les liens LLN sont représentés

LBR-1
1 2 Les liens sont annotés avec ETX
3
On s'attend à ce que les variations
A
1
B
1
C ETX soient moyennées /
1 filtrées conformément à
1 1
[ROLL-METRICS] pour être
F
1
D 4
E suffisamment stables pour le
1
calcul d'itinéraire
1 1 1
Les nœuds doivent également
G
1
H I
observer la métrique et gagner
en confiance avant utilisation

40

DAG Construction

LBR-1 - La construction du DAG

1 2
continue…
3

1 1
A B C
1
1 1 - Et est maintenu en
1
4
permanence
F D E
1
1 1 1

1
G H I

41

MP2P Traffic

LBR-1  Le trafic MP2P circule vers

1 2 l'intérieur le long du DAG, en
3 direction de la DAG racine
1 1  La DAG racine peut également
A B C étendre la connectivité à d'autres
1
1
1 préfixes au-delà de la racine DAG,
comme spécifié dans la DIO.
1
F D 4
E  Les nœuds peuvent joindre
plusieurs groupes de
1
1 1 1 disponibilité de base si
nécessaire pour satisfaire aux
1
G H I contraintes de l'application

42

14
 6LOWPAN

43

Aperçu sur l’IPv6

• Remédier au problème de pénurie des

adresse

• IPv6 utilise des adresses codées sur

128 bits (10 adresses disponibles).

• Gestion de la fragmentation

• Simplification des entêtes IP

44

Aperçu sur l’IPv6

MTU minimum est de 1280 octets.

La taille minimale d’une entête d’un paquet IPv6 est 40 octets

45

15
 Aperçu sur l’IPv6

Traffic class : Identifier la classe de service à appliquer

au paquet.

Flow label : Marquer les paquets pour des traitements

spéciaux par les routeurs.

Payload length : taille de la charge utile du paquet.

Next header : Identifier l’entête qui suit l’entête du

paquet IPv6.

Hop limit : L’équivalent du champ Time To Live (TTL) de

IPv4.

Source address et Destination address : Spécifier

l’adresse de la source et l’adresse de la destination du
paquet

46

Aperçu sur l’IPv6

Il existe trois grandes classes d’adresses IPv6 :

 les adresses link-local (non routable): de la
forme fe80::/10
 Utilisé pour les communications
locales au lien.

 les adresses globales unicast (routable): de

la forme 2000::/3 ou 3000::/3

 Les adresses multicast : de la forme ff00::/8

(Identifier un groupe d’interfaces).

47

Motivations à la mise en place d’une sous-couche

6LoWPAN

 Un paquet IPv6 est transporté dans la charge utile des trames

de données IEEE 802.15.4
 La taille maximale d’une trame IEEE 802.15.4 est 127 octets

48

16
 Motivations à la mise en place d’une sous-couche
6LoWPAN

Taille de l’entête est de Taille maximale d’une

40 octets trame est de 127 octets
IEEE
IPv6 Champs d’adressage 802.15.4
Communication
occupe 32 octets faible débit
La valeur minimale de Communication faible
(MTU) pour IPv6 est consommation
de 1280 octets énergétique

Problème d'interopérabilité: Nécessité d’adaptation

49
49

Aperçu de 6LoWPAN

IPv6 over Low Power Wireless Personal Area Network.

 Standards de l’IETF (Internet Engineering Task Force) :

• RFC 4919, Aout 2007
• RFC 4944, Sep 2007
• RFC 6282, Sep 2011
• RFC 6775, Nov 2012

50

Aperçu de 6LoWPAN

 Un réseaux de capteurs sans fil à basse consommation qui

supporte 6LoWPAN est appelé LoWPAN (Low Power Wireless
Area Network).

 Des routeurs de bordure assurent la connectivité des LoWPAN

vers d’autres réseaux.

51

17
 Architecture des réseaux LoWPANs

Les LoWPANs peuvent être classés en trois catégories :

 Les LoWPANs ad-hoc qui ne possèdent pas

d’infrastructure.

 Les LoWPANs simples connectés à un routeur

de bordure.

 Les LoWPANs étendus partagent le même

préfixe sur plusieurs routeurs de bordure reliés
entre eux par un lien backbone.
Architecture
6LoWPAN 52

52

Couche d’adaptation 6LoWPAN

La couche d’adaptation 6LoWPAN :

• située au-dessous de la couche IP.
• Effectue une
compression/décompression des entêtes
des couches IPv6 et transport (UDP).
• Créé une entête composée de quelques
octets.
• Responsable de la fragmentation/
réassemblage des paquets. Pile IP vs pile 6LoWPAN

53

Compression des entêtes

54

18
 Compression des entêtes
Ce mécanisme se base sur les trois observations suivantes :

 Dans le cas d’une adresse autoconfigurée sans état les adresses source et
destination IPv6 sont redondantes avec les adresses de la couche MAC.

 Les champs IPv6 flowlabel et traffic class sont souvent à zéro,

 Un nombre limité de ports est utilisé par la couche transport.
Deux méthodes sont proposées par le standard pour effectuer la compression des
entêtes
 Une méthode sans état (HC) définit dans le RFC 4944.
 Une méthode avec état optionnel (IPHC) définit dans le RFC 6268 .

55

DATA Protocol Overview

 Devices must communicate with each other (D2D). Device data
then must be sent to the server (D2S).
 That server infrastructure has to share device data (S2S),
possibly providing it back to devices, to analysis programs, or
to people.
 the protocols can be described in this framework as:
• MQTT: for collecting device data and communicating it to servers
(D2S)
• XMPP: for connecting devices to people, a special case of the D2S
pattern, since people are connected to the servers
• DDS: a fast bus for integrating intelligent machines (D2D)
• AMQP: a queuing system designed to connect servers to each
other (S2S)
56

Protocol Overview
 Each of these protocols is widely adopted

 all four claim to be real-time publish-subscribe IoT

protocols that can connect thousands of devices. And it’s
true, depending on how you define “real time,” “things,” and
“devices.”

 Today’s Internet supports hundreds of protocols.

 The IoT will support hundreds more.

 It’s important to understand the class of use that each of

these important protocols addresses.
57

19
Protocol Overview

IoT protocols need to address response time.

58

MQTT
Origin of MQTT
 MQTT was created in 1999 by two engineers — Andy
Stanford-Clark (IBM) and Arlen Nipper (Eurotech).
 They had to invent a new protocol for connecting oil
pipelines over unreliable, satellite networks.
 The motivation was to create a lightweight and bandwidth-
efficient protocol that was data agnostic with support for
multiple levels of Quality of Service (QoS)
 In 2011, IBM and Eurotech donated MQTT to the proposed
Eclipse project called Paho.
 In 2013, it was submitted to OASIS for standardization. The
latest version of the protocol specification, 3.11 has become
an OASIS standard.
59

How Does MQTT Work?

 MQTT is a publish/subscribe protocol that allows edge-of-
network devices to publish to a broker.
 Clients connect to this broker, which then mediates
communication between the two devices.
 Each device can subscribe, or register, to particular topics.
 When another client publishes a message on a subscribed
topic, the broker forwards the message to any client that has
subscribed.
 The publishers and subscribers are autonomous, which
means that they do not need to know the presence of each
other.

60

20
MQTT
 It is very light weight and binary protocol, which excels
when transferring data over the wire in comparison to
protocols like HTTP, because it has only a minimal packet
overhead.
 Another important aspect is that MQTT is extremely easy
to implement on the client side. This fits perfectly for
constrained devices with limited resources.
 MQTT is quickly becoming the most preferred protocol for
connecting devices to the cloud
 Enterprise cloud platforms such as Amazon Web Services,
Microsoft Azure, and IBM Watson expose their IoT PaaS
through MQTT

61

Terminology of MQTT

 Client : is any publisher or subscriber that connects to the centralized

broker over a network. It’s important to note that there are servers and
clients in MQTT.
 Clients can be persistent or transient. Persistent clients maintain a
session with the broker while transient clients are not tracked by the
broker.
 Clients often connect to the broker through libraries and SDKs. There
are over a dozen libraries available for C, C++, Go, Java, C#, PHP, Python,
Node.js, and Arduino.
62

Terminology of MQTT
Broker –
 The broker is the software that receives all the messages from the
publishing clients and sends them to the subscribing clients.
 It holds the connection to persistent clients. Since the broker can
become the bottleneck or result in a single point of failure, it is often
clustered for scalability and reliability.
 It is up to the implementors to decide how to create a scalable broker
layer. Some of the commercial implementations of MQTT brokers
include Hive , Xively, AWS IoT, and Loop.
Topic –
 A topic in MQTT is an endpoint to that the clients connect. It acts as the
central distribution hub for publishing and subscribing messages.
 In MQTT, a topic is a well-known location for the publisher and
subscriber. It’s created on the fly when either of the clients establish the
connection with the broker.
63

21
Terminology of MQTT
 Topics are simple, hierarchical strings, encoded in UTF-8, delimited by a /
 For example : -building1/room1/temperature and
- building1/room1/humidity are valid topic names.
 Subscribers can choose to subscribe to a specific topic or all the subtopics
through wildcards.
 A subscription to building1/+/temperature will automatically subscribe to
the temperature topic of all the rooms in the building.
 Similarly, building1/#/ will match all the topics available under building1.
Refer to the MQTT specification for more details on the wildcards.
Connection –
 MQTT can be utilized by clients based on TCP/IP.
 The standard port exposed by brokers is 1883, which is not a secure port.
Those brokers who support TLS/SSL typically use port 8883.
 For secure communication, the clients and the broker rely on digital
certificates. AWS IoT is one of the secure implementations of MQTT, which
requires the clients to use the X.509 certificates. 64

MQTT

65

MQTT Example

 For example, imagine a simple network with

three clients and a central broker.

 All three clients open TCP connections with

the broker. Clients B and C subscribe to the
topic temperature.

 At a later time, Client A publishes a value of

22.5 for topic temperature . The broker
forwards the message to all subscribed
clients.

 The publisher subscriber model allows MQTT

clients to communicate one-to-one, one-to-
many and many-to-one
66

22
MQTT-SN
 Even though MQTT is designed to be lightweight, it has two drawbacks
for very constrained devices.
 Every MQTT client must support TCP and will typically hold a
connection open to the broker at all times. For some environments
where packet loss is high or computing resources are scarce, this is a
problem.
 MQTT topic names are often long strings which make them impractical
for 802.15.4.
 Both of these shortcomings are addressed by the MQTT-SN protocol,
which defines a UDP mapping of MQTT and adds broker support for
indexing topic names.

67

COAP & MQTT

68

Application 2 (1)

69

23
Avantages
 Conçu pour M2M, IoT
 Facilement mappé sur HTTP
 Compatible avec les infrastructures Proxy
 Découverte et observation des ressources
 Faible surcharge d'entête
 Échange de messages sans état en asynchrone
 Transport UDP avec une couche application unicast fiable
et le support du multicast
 Support de différents types de contenus

21/23

70

Limitations
 Connexion sécurisée de bout en bout requise pour le
mappage CoAP/ HTTP sur un proxy à l'aide de DTLS / TLS
 Sécurisation des communications multicast
 La sémantique devrait être standardisée
 La mise en cache des demandes devrait également être
autorisée

71

24