Internet des objets (IdO) ou Internet of Things (IoT)

Internet des objets

Quelques définitions
• Objet connecté : objet ayant la capacité d’échanger des données
avec d’autres entités physiques ou numériques.

• Internet des objets (IdO) ou Internet of Things (IoT) :

- Expansion du réseau internet à des objets et/ou des lieux du monde
physique
- Ces éléments sont identifiables de manière unique
- Communiquent à l'aide de la connectivité IP.
- Échanges d'informations et de données provenant de ces dispositifs
vers/depuis le réseau Internet

Action sur le monde physique = changer son état

 Internet des objets

• Un LoWPAN (Low power Wireless Personal Area Networks) : est constitué

d'un ensemble d’équipements ayant ressources faible (CPU, mémoire,
batterie) reliés au travers d’un réseau limité en débit

• réseaux LLNs (Low power and Lossy Networks)

 Internet des objets

Domaines applicatifs de l’IoT

•Ville intelligente : circulation routière intelligente, transports
intelligents, collecte des déchets, cartographies diverses (bruit,
énergie, etc.).
• Environnements intelligents : prédiction des séismes, détection
d’incendies, qualité de l’air, etc
.• Sécurité et gestion des urgences : radiations, attentats,
explosions.
• Logistique :aller plus loin que les approches actuelles.
•Contrôle industriel : mesure, pronostic et prédiction des pannes,
dépannage à distance.
•Santé : suivi des paramètres biologiques à distance.
•Agriculture intelligente, domotique, …
 Technologies

– Les réseaux de capteurs sans fil RCSF: (Wireless Sensor Network, WSN)
Un RCSF se compose d‘un nombre de Noeuds-Capteurs qui ont des
fonctionnalités de capturer et traiter/transmettre les données.

– Cloud Computing : fournit un espace de stockage de données IoT et offre des

services de visualisation, analyse et archivage des données.

– Big Data : offre des outils d‘analyse avancées pour les données massives
collectées par les objets IoT selon leurs caractéristiques : volume, vitesse,
variabilité (forme de données : texte, audio, video, image).

– Les protocoles de communication : sont indispensables pour assurer la

connectivité entre objets et applications. Les protocoles de communication
définissent le format des données, taille paquets, adressage, routage, etc.

– Les systèmes embarqués : Les objets connectés sont formés essentiellement

des cartes à microcontrôleur intégrant un microprocesseur, une mémoire et
des ports d‘ E/S pour la connexion des capteurs.
 Les protocoles

● L'IoT utilise un certain nombre de protocoles

● Permet d'assurer l'inter-opérabilité de systèmes très différents

● IoT : Protocoles dédiées

- ZigBee
- 6LoWPAN
- protocole de routage spécifique
 La couche MAC IEEE 802.15.4

La couche MAC IEEE 802.15.4

Utilise deux modes d’adressage IEEE 64-bit et 16-bit
Plusieurs fréquences : 868Mhz (20kb/s), 900Mhz (40kb/s), 2.4 Ghz (250kb/s)
Utilise une structure de trame simple.
Permet d’utiliser le mécanisme de « beaconing » : réveil périodique
Economise l’´energie à travers la mise en veille entre deux « beacons »,
et les nœuds ne devant pas router ou recevoir les données aléatoirement
peuvent se mettre en veille.
Assure une transmission fiable de données

- Utilisé par des implémentation basées sur des protocole propiétaire ou IP:
ZigBee
6LoWPAN
- Contraintes :
IPV6 :
- MTU IPV6 =1280 octets
- Efficaces pour les réseaux classique (les réseaux métropolitains
et les réseaux étendus comme l'internet) mais difficiles à mettre en œuvre dans
les réseaux de capteurs et systèmes contraints à cause de :
- la taille importante des en-têtes
- besoin d’une puissance de calcul et de mémoire que les capteurs ne possèdent
pas pour supporter le système d’encodage à 128 bits requis par IPv6 (32 bits pour l’IPv4)

- IEEE 202.15.4 : MTU réduit à127 octets

- La surcharge imposée par les entêtes : les entêtes laissent peut de place pour
les données applicatives
 Architecture et contraintes
- Contraintes :
Pour délivrer les données : difficile d’utiliser IPV4 et IPV6 dans les réseaux contraints

- Besoin de :
- fragmentation et le réassemblage :
internet
fragmentation : fragmenter un paquet
IPv6 en plusieurs trames 802.15.4
- La compression de l'entête IPv6
- Le routage : Besoin d’un protocole de
routage adapté au contraintes des
nœuds et aux spécificité de
v
IEEE 202.15.4 à savoir faible débit,
v
petits paquets, forte contrainte
v énergétique
v
6LoWPAN :
IPv6 over Low power Wireless Personal Area Networks
- Couche d’adaptation : assurer une compatibilité IPv6 au dessus de IEEE 802.15.4
- Permet aux paquets IPv6 d'être envoyés ou reçus via le protocole de
communication IEEE 802.15.4 en utilisant des mécanismes d’encapsulation et de
compression d'entêtes
 Architecture et contraintes

● Solution proposée :
- 6LoWPAN
- Besoin d’un protocole de routage adapté au nœuds contraintes

● 6LoWPAN ( IPv6 Low power Wireless Personal Area Networks)

- permettre à IPv6 d'intégrer les matériels informatiques contraints
- permet l’encapsulation et la compression d'entêtes permettant aux paquets IPv6
d'être envoyés ou reçus via le protocole de communication IEEE 802.15.4

Le protocole a été développé pour définir l'adaptation d'IPv6, ainsi que la

manière de transporter les datagrammes IP sur des liaisons IEEE 802.15.4 et
d'exécuter les fonctions de configurations nécessaires pour former et maintenir
un sous-réseau IPv6. La fonction principale est de compresser les en-têtes des
paquets IPv6
 RPL : (Routing Protocol for Low power and lossy
networks-LLNs)
- Pas possible d’utiliser les protocoles de routage dédiés aux réseaux ad-hoc
- Mise en place d’un protocole beaucoup plus optimisé en terme de coût énergétique

- le protocole RPL : (Routing Protocol for Low power and lossy networks)
- Protocol de routage IPV6 conçu pour des réseaux contraints : réseaux LLNs (Low
power and lossy networks) Une seul route Pas de cycle
- RFC6551
- proactif
- Basé sur la construction du DODAG (Destination Oriented Directe Acyclic Graph)
pour l’acheminement des données vers la station de base
- Trafic : P2MP, P2P et MP2P
- Création de la topologie : basés sur les métriques de routage
exemple de métriques :
- délai de bout-en-bout
- nombre de transmissions nécessaires pour
atteindre la SB
- l’énergie consommée
 Construction de DODAG

Les messages de RPL et principe de construction:

- La construction du DODAG s’effectue par des messages de contrôle
transportées dans des paquets ICMPv6
DIO: DODAG Information Object . Le root est à l’origine de DIO pour construire
le DODAG : initié par le root et retransmis en multicast par ses voisins
DAO: Destination Advertisment Object (ID, Rang, IDs route infos)
message d’un nœud à un nœud parent préféré (je peux vous
joindre comme fils ?)
DAO-ACK : envoyé par un nœud parent vers son fils. Message de réponse à un
message DAO
DIS: DODAG Information Sollicitation DIO
DAO

DAO DIO
 Construction de DODAG

Étape 1 : Diffusion des messages DIO par le root dans son voisinage à un saut.
Étape 2 : Chaque nœuds ayant reçu le DIO, utiliser la fonction objectif contenu
dans le message DIO et l’algorithme de choix du parent préféré pour choisir son
parent préféré puis envoi un message DAO à ce dernier pour lui signaler son
choix. Les messages DAO contiennent des informations permettant au root de
construire des chemins vers les nœuds feuilles du DODAG

Étape 3 : Les nœuds ayant choisi le root comme parent vont à leur tour diffuser
des messages DIO en multicast dans leur voisinage. Les nœuds ne faisant pas
encore parti du DODAG qui vont recevoir ces messages DIO, vont donc faire un
choix de nœud parent puis répondre par des messages DAO indiquant leur
attachement au DODAG.
Étape 4 : le processus de l’étape 3 se poursuive jusqu’à ce que tous les nœuds
du réseau se connectent au DODAG
Modes de fonctionnement :
- non-storing : informations sur le routage stockés par le root.
Les autres nœuds conservent les @ de leurs
parents

- Storing : Chaque nœud conserve les informations sur le routage

 Fonction objective (OF)

- Fonction objective (OF) :

Indique la méthode qui doit être utilisée pour construire un DODAG.
Les métriques de routages sont définies dans des fonctions objectives

- Deux fonctions objectives :

1- OF0 : Objective Function Zero
2- MRHOF : Minimum Rank with Hysteresis Objective Function
 Fonction objective (OF)

Les différentes métriques du protocole RPL :

- Nombre de saut : Hop count
- basées sur les liens : la qualité du lien (LQ), latence du lien,
nombre de retransmission attendu ETX
- Energie résiduelle des nœuds

Le choix de la métrique à utiliser pour la construction du DODAG. Elle se

configure au niveau du nœud root. Le root va diffuser la fonction objectif
contenant la métrique dans les messages DIO à travers un champ réservé
à cet effet appelé “OCP” (Objective Code Point)
● Quelques OS « libres » pour l'IoT

-TinyOS
- Contiki
- RIOT
- MiniPhi
-OS « classiques » adaptés :
- GNU/Linux
- Android (wear)
- Brillo (Q3 2015)
 Contiki

● Système d'exploitation développé par le Swedish Institute of Computer

Science (SICS, 2002)
- Open source
- très léger
- une consommation électrique très faible
- Plate-forme d'émulation et de simulation
→ Cooja
● Deux piles de communication :
uIP : c’est une pile TCP / IP légère et optimisé (seules les
fonctionnalités requises sont implémentées).
RIM : Pile de communication légère conçue pour les radios de faible
puissance
● Optimisé pour la consommation
● Chargement dynamique de modules
● Bien adapté aux capteurs (quelque dizaines de Ko)
● Bonne documentation et nombreux exemples
● API de programmation un peu « spécifique »
 Fonction objective (OF) sous Cooja

Sous cooja :

cd contiki/tools/cooja
ant run

RPL :

● Les fonctions importantes :

~/contiki-2.7/core/net/rpl/rpl-conf.h
~/contiki-2.7/core/net/rpl/rpl-of0.c
~/contiki-2.7/core/net/rpl/rpl-mrhof.c
 Fonction objective (OF) sous Cooja

Ajustement de la fonction objective

voir
[Link]
1- /home/user/contiki/core/net/rpl
1- modifier [Link] comme suit :

CONTIKI_SOURCEFILES += rpl.c rpl-dag.c rpl-icmp6.c rpl-timers.c \

2. rpl-config.h
rpl-mrhof.c rpl-ext-header.c

Fct objective :
/* RPL_CONF_OF */
#ifdef RPL_CONF_OF Changer rpl_mrhof en rpl_of0
#define RPL_OF RPL_CONF_OF Si on souhaite uriliser FO0
#
else #define RPL_OF rpl_mrhof
#endif
 Métriques dans MRHOF

Métrique :
Prend en compte la métrique énergie
par défaut : ETX
 Faire ce changement :
RPL_DAG_MC : #ifdef RPL_CONF_DAG_MC
/* RPL_CONF_DAG_MC */ #define RPL_DAG_MC RPL_CONF_DAG_MC
#ifdef RPL_CONF_DAG_MC #else
#define RPL_DAG_MC RPL_CONF_DAG_MC #define RPL_DAG_MC RPL_DAG_MC_ENERGY
#else #endif
#define RPL_DAG_MC RPL_DAG_MC_NONE /* RPL_CONF_DAG_MC *
#endif

rpl-config.h
RPL_CONF_STATS
/* RPL_CONF_STATS */
#ifndef RPL_CONF_STATS
#define RPL_CONF_STATS 0
#endif
Ici, les statistiques de configuration RPL sont désactivées. Pour l'activer, nous devons en
définir 1.
● RPL fournit un mécanisme permettant le trafic
- multipoint-à point depuis les équipements (devices) dans le LLN vers un point
de contrôle central,
- point-à-multipoint du point de contrôle central vers les devices dans le LLN.
- Le support du trafic point-à-point est aussi disponible.

● UDP est implémenté au dessus de RPL. Un LLN possède un serveur UDP, qui
accepte les paquets disponibles, et plusieurs clients UDP, qui envoient des paquets
périodiquement au serveur au travers d’un saut simple (single-hop) ou de sauts
multiples (multi-hops).
Code source :
~/contiki-2.7/examples/ipv6/rpl-udp/udp-server.c
~/contiki-2.7/examples/ipv6/rpl-udp/udp-client.c
~/contiki-2.7/core/net/tcpip.c
~/contiki-2.7/core/net/tcpip.h
Le serveur UDP effectue : Client UDP effectue deux tâches principales :
1. Initialiser le DAG RPL ; [Link] une connexion UDP
2. Etablir une connexion UDP ; 2. Envoyer des paquets au serveur UDP
3. Attend les paquets des clients, periodiquement
les reçoit et les affiche sur stdout.
CoAP (Constrained Application Protocol) est un protocole de transfert Web optimisé pour
les périphériques et réseaux contraints
Simulation : cooja