Département Génie Informatique

CoAP (Constrained Application Protocol)

Pr. Omar MOUSSAOUI
o.moussaoui@ump.ac.ma

Filière : GIE2, Année 2022-2023

 PLAN
➢ Description de CoAP

➢ Architecture de CoAP

➢ Positionnement de CoAP dans le modèle OSI

➢ Format du Message CoAP

➢ Observation des ressources

 CoAP (Constrained Application Protocol)
CoAP est un protocole de transfert Web optimisé pour les périphériques et réseaux contraints utilisés dans
l’IoT. Basé sur l’architecture REST, il permet de manipuler au travers d’un modèle d’interaction client-
serveur les ressources des objets communicants et capteurs identifiées par des URI en s'appuyant sur
l'échange de requêtes-réponses et méthodes similaires au protocole HTTP.
En 2016, l'utilisation des services web est courante sur les applications Internet. CoAP étend ce paradigme
à l’IoT et aux applications M2M qui peuvent ainsi être développées avec des services web RESTful partagés
et réutilisables. Tout en prenant en compte les contraintes et besoins de l’IoT tel que le support de
l'asynchrone ou du multicast.
Le protocole CoAP se situe au niveau applicatif de la couche OSI et s’appuie sur UDP pour la
communication.
Il met en œuvre une méthode d’observation des ressources et fournit des fonctions de découverte des
périphériques pour minimiser l’intervention humaine.
Il est implémenté avec différents langages, ce protocole peut être utilisé dans des domaines tels que la
santé ou la gestion énergétique. Il offre des performances adaptées aux objets à faibles ressources ainsi
que la sécurité pour les données sensibles.
 CoAP (Constrained Application Protocol)
CoAP a été créé par le groupe de travail CoRE (Constrained Restful Environment) et s'inscrit dans la
continuité des travaux réalisés par l'IETF avec la spécification 6LoWPAN qui permet aux réseaux de
capteurs sans fils contraints d’utiliser le protocole «IPv6».
Le protocole CoAP a été élaboré pour les périphériques contraints alimentés par batterie, équipés de
microprocesseurs peu performants et disposant d’une quantité de mémoire RAM et ROM limitée. Il offre
simplicité, faible surcharge pour environnements réseaux contraints de faible puissance confrontés à des
taux de perte important.
CoAP permet les communications M2M requises pour l’interaction et l'exploitation des systèmes
embarqués. Il est défini comme protocole générique pour les réseaux à basse puissance et avec pertes et
s'appuie sur les protocoles et réseaux sous jacents 6LoWPAN, IEEE802.15.4.
CoAP se différencie cependant de son homologue HTTP de par sa complexité réduite avec l'utilisation
d'UDP qui lui permet d'avoir un entête de taille réduit, facilement interprétable par des périphériques
contraints, tout en conservant un mécanisme de retransmission en cas de perte de messages.
 CoAP (Constrained Application Protocol)
CoAP est spécialement élaboré pour les environnements contraints, il apporte ces principales
fonctionnalités :
• Faible surcharge d'entête et complexité d’interprétation réduite;
• Transport UDP avec une couche application unicast fiable et le support du multicast;
• Échange de messages sans état en asynchrone;
• Possibilité d'utiliser des proxys (facilite l’intégration avec l'existant) et de mettre les informations
en cache (périphériques en veille);
• Découverte et observation des ressources;
• Représentation des ressources URI et support de différents types de contenus.
 CoAP (Constrained Application Protocol)
CoAP s'appuie sur un modèle client-serveur semblable à HTTP, où les clients envoient des requêtes sur
des ressources pour récupérer de l'information d'un capteur ou contrôler un périphérique et son
environnement.
CoAP traite les échanges de manière asynchrone au travers de datagrammes UDP. HTTP est un protocole
éprouvé, cependant son implémentation requiert un code de taille conséquente pour des périphériques
ne disposant que de 100 ko de mémoire ROM et un usage important des ressources réseau.
Une requête CoAP est similaire à une requête HTTP. Elle est envoyée par le client pour demander une
action GET, POST, PUT ou DELETE sur une ressource identifiée par une URI. Le serveur répond par un code
réponse accompagné éventuellement de la représentation de la ressource.
 CoAP : Architecture
L'architecture CoAP est divisée en deux couches :
- Une couche message qui apporte la fiabilité et le séquencement des échanges de bout en bout
reposant sur UDP.
- Une couche «Request/Response» qui utilise des méthodes et codes réponses pour les interactions
requêtes/réponses. Il s'agit cependant bien d'un seul et même protocole qui propose ces
fonctionnalités dans son entête.
 CoAP : Architecture
La couche Message apporte la fiabilité pour les messages typés confirmables. Elle assure alors un contrôle de bout en
bout et leur retransmission en cas de perte. L'utilisation d'un jeton permet à CoAP de faire l'association entre les
requêtes et réponses au cours d'une communication. Tandis qu'un «Label» généré et inséré par le client dans chaque
entête de message CoAP permet de détecter les doublons.

Lorsque les messages ne requièrent pas de garantie de bon acheminement, il est aussi
possible tout en bénéficiant de la détection des doublons d'utiliser des messages de
types Non-Confirmables.
Un serveur qui reçoit un message Confirmable doit acquitter sa réception auprès du
client qui initie la connexion et répondre par un message d’acquittement typé ACK.
Dans le cas où le serveur peut donner la réponse immédiatement, celle-ci est ajoutée
au message d’acquittement et la transaction prend fin. Sinon, un message
d’acquittement vide est retourné au client pour indiquer que la réponse est retardée.
Lorsqu'un message Confirmable est envoyé au serveur, le client décompte le temps
écoulé et réémet le message périodiquement tant que le message n'a pas été acquitté.
Dans le cas où le serveur n'est pas en mesure de traiter la demande, il peut l'indiquer
au client en répondant par un message de type RST.
 CoAP : Architecture
Couche Requête-Réponse
CoAP dispose des méthodes suivantes:

Méthode Action
Cette méthode récupère la représentation de l'information correspondant à la ressource
«GET»
identifiée par la requête URI.

Cette méthode demande le traitement de la représentation jointe à la ressource identifiée

«POST» par la requête URI. Normalement cela aboutit à la création d'une nouvelle ressource ou de
sa mise à jour.

Cette méthode demande que la ressource identifiée par la requête URI soit mise à jour
«PUT» avec la représentation jointe. Le format de la représentation est spécifié par le type de
media et le codage contenu dans l'option Content-Format, si fournie.

«DELETE» Cette méthode demande que la ressource identifiée par la requête URI soit supprimée.
 CoAP : Architecture
Couche Requête-Réponse
Les réponses sont identifiées par des codes réponses analogues aux codes d'état du protocole HTTP qui
indiquent le statut de l'opération:

Success
2.xx : indique que la requête a été correctement reçue, comprise et acceptée.

Client Error
4.xx : indique que le client a rencontré une erreur.

Internal Server Error

5.xx : indique que le serveur est dans l'impossibilité de traiter la requête.
 CoAP: Positionnement dans le modèle OSI
CoAP s'insère dans un modèle à 5 couches : physique, liaison de données, réseau, transport et application.
Niveau 5: CoAP en tant que protocole de transfert Web au même
niveau que le protocole HTTP, les couches supérieures sont du
périmètre du navigateur Web et des applications M2M.

Niveau 4 : La couche transport UDP s'interface avec la sous-couche

Message de CoAP. Les messages sont placés dans des datagrammes
UDP, son utilisation économise la bande passante et apporte le support
du multicast.

Niveau 3 : IPv6, les datagrammes UDP sont placés dans des paquets
IPv6. La couche 6LowPAN procède aux adaptations, pour la couche
sous-jacente disposant d'une taille de trame limitée à 128 octets. Elle
procède à la compression des entêtes IPv6, réalise la fragmentation et
le ré-assemblage des paquets IPv6. Mais également chargé de
l'adressage, du routage.

Niveau 2 et 1 : IEEE 802.15.4 est le standard qui précise les

spécifications des couches 1 et 2 pour les réseaux personnels sans fil.
 CoAP : Format du Message CoAP
Les messages CoAP sont par défaut transportés au travers de datagrammes UDP. Cette communication peut être
transmise via DTLS mais aussi par d’autres moyens comme SMS, TCP, ou SCTP. Les messages sont encodés dans un format
binaire simple.
Un message commence par un entête fixe de 4 octets, suivi par un champ « Token » de taille variable comprise entre 0 et
8 octets qui permet dans les échanges d’associer les requêtes aux réponses. Sa longueur est indiquée par le champ «TKL».
Il apparait ensuite, une séquence d’options au format TLV (Type–Length–Value) suivie en option des données qui
occupent le reste du datagramme. Dans le cas où ces dernières sont présentes, elles sont séparées de l’entête grâce à un
marqueur d’1 octet contenant la valeur «0xFF».
CoAP : Format du Message CoAP
CoAP : Format du Message CoAP
 CoAP : observation des ressources
L’état d’une ressource peut varier en temps réel et un client peut avoir besoin de ces changements d’états. En HTTP les
transactions sont toujours initiées par le client qui effectue de multiples requêtes GET pour garder à jour le statut d’une
ressource. Ce mécanisme consommateur de ressources ne convient pas dans un environnement contraint avec des
ressources réseau limitées ainsi que des périphériques endormis la plupart du temps.
Pour répondre à ce besoin, CoAP bénéficie d’une extension du protocole RFC7641 qui permet aux clients d’observer les
ressources grâce à l’option observe.
Un serveur CoAP est l'autorité pour déterminer dans quelles conditions les ressources changent leur état et donc c'est
lui qui décide quand informer les observateurs des nouveaux états de ces ressources. Comme le protocole n'offre pas de
moyens explicites pour la mise en place de déclencheurs ou de seuils, il appartient au serveur d'exposer des ressources
observables qui notifient leur état de manière utile dans le contexte de l'application.
Par exemple un serveur avec un capteur de température peut exposer une ou plusieurs ressources. Dans le cas où une
ressource change d'état toutes les x secondes. Une ressource peut changer son état en froid ou chaud en fonction de
seuils correspondants ou encore en fonction d’expressions complexes.
 CoAP : observation des ressources
Principe de fonctionnement
Les observateurs s’inscrivent auprès d’un sujet pour lui indiquer qu’ils
veulent être notifiés à chaque changement d’état. Le sujet est
responsable de l’administration de sa liste d’observateurs inscrits. Si
l’observateur est intéressé par plusieurs sujets, il devra s’inscrire
séparément auprès de chacun d’eux.
Un client s’enregistre en émettant une requête GET étendue avec
l’option «observe : 0» vers le serveur. La valeur « 0 » est une demande
d’enregistrement et la valeur « 1 » correspond à une demande
d’annulation de l’enregistrement. Le serveur renvoie une notification
2.xx qui indique qu'il a ajouté l'entrée à la liste des observateurs. Lorsque
l'état change le serveur envoie la notification au client.
Le jeton permet au client d’identifier les observations au cas elles
seraient multiples. Pour éviter les congestions les serveurs ne devraient
pas envoyer plus d'une notification toutes les 3 secondes et devraient
utiliser une valeur moins agressive si c’est possible.
Des optimisations sont attendues à l’avenir à l'instar de CoCoA
(Congestion Control/Advanced) qui étend la spécification CoAP avec un
contrôle de congestion avancé.