CoAP
# CoAP

CoAP (Constrained Application Protocol) est un protocole de transfert Web optimisé pour les périphériques et réseaux contraints utilisés dans les réseaux de capteurs sans fil pour former l'Internet des objets. Basé sur le style architectural 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’Internet des objets 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'Internet des objets tel que le support de l'asynchrone ou du multicast. CoAP est prévu pour devenir un protocole d'application omniprésent dans le futur Internet des objets.

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. 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.

## Description

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». CoAP permet l’interaction avec ces capteurs au travers de services web RESTful. Ce protocole 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, compris entre 10 et 20 octets facilement interprétable par des périphériques contraints, tout en conservant un mécanisme de retransmission en cas de perte de messages. 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.

### Architecture

CoAP s'appuie sur un modèle client-serveur semblable à HTTP, où les clients envoient des requêtes sur des ressources REST pour récupérer de l'information d'un capteur ou contrôler un périphérique et son environnement. Cependant 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.

L'architecture CoAP est divisée en deux $couches^,.$ Une couche message qui apporte fiabilité et le séquencement des échanges de bout en bout qui repose 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.

**Couche Message**


    Figure 3 : Transaction CoAPLa 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^,.$

**Couche Requête-Réponse**


    CoAP dispose des méthodes $suivantes^,^,:$

| Méthode | Action |
| - | - |
| «GET» | Cette méthode récupère la représentation de l'information correspondant à la ressource identifiée par la requête URI. |
| «POST» | Cette méthode demande le traitement de la représentation jointe à la ressource identifiée par la requête URI. Normalement cela aboutit à la création d'une nouvelle ressource ou de sa mise à jour. |
| «PUT» | Cette méthode demande que la ressource identifiée par la requête URI soit mise à jour 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 requete URI soit supprimée. |

Les réponses sont identifiées par des codes réponses analogues aux codes d'état de succès 2.xx , d'erreur 4.xx ou 5.xx 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.

### 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.

### 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 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».

**L'entête en version 1 contient les informations suivantes**

| Champ | Description | Description |
| - | - | - |
| Ver (Version) | Le champ Ver possède 2 bits, indiquant la version de CoAP utilisée. | Le champ Ver possède 2 bits, indiquant la version de CoAP utilisée. |
| T (Type) | Le champ Type est utilisé pour préciser le type du message : Confirmable (0) : Le message requiert une réponse qui peut être véhiculée par un message d'acknowlegment ou envoyé de façon asynchrone si la demande ne peut être traitée immédiatement. Dans ce cas un Reset sera retourné. Nota, un message Confirmable peut être aussi bien une requête qu'une réponse qui doit être acquittée; Non-confirmable (1) : Le message ne requiert aucune réponse ou acquittement; Acknowledgment (2) : Le message confirme la réception d'un message Confirmable. Il peut éventuellement contenir la réponse d'un message Confirmable dans le cas où la demande n'aurait pu être traitée de façon synchrone, le message ID sera alors utilisé pour associer la réponse à la demande; Reset (3) : Dans le cas où le message n'a pu être traité. | Figure 6 : Message de type Confirmable (0) Figure 7 : Message de type Acknowlegment (2) contenant la réponse |
| TKL (Token Length) | est composé de 4 bits, indiquant la longueur du champ Token. | est composé de 4 bits, indiquant la longueur du champ Token. |
| Code | est composé de 8 bits, dont les 3 bits les plus significatifs (c) indiquent la classe et les 5 bits les moins significatifs les détails (dd). Le code au format « c.dd », permet d’indiquer le type de message, « 0 » pour une requête, « 2 » pour une réponse OK , « 4 » pour réponse en erreur client, « 5 » pour une erreur serveur. Dans le cas d’une requête le code indique la méthode de la requête et dans le cas d’une réponse, le code de la réponse. Le code « 0.00 » indique quant à lui un message vide. | est composé de 8 bits, dont les 3 bits les plus significatifs (c) indiquent la classe et les 5 bits les moins significatifs les détails (dd). Le code au format « c.dd », permet d’indiquer le type de message, « 0 » pour une requête, « 2 » pour une réponse OK , « 4 » pour réponse en erreur client, « 5 » pour une erreur serveur. Dans le cas d’une requête le code indique la méthode de la requête et dans le cas d’une réponse, le code de la réponse. Le code « 0.00 » indique quant à lui un message vide. |
| Message ID | est composé de 16 bit, utilisés pour détecter la duplication de messages et faire correspondre les messages acknowledgment/reset aux messages de type Confirmable/Non-Confirmable. | est composé de 16 bit, utilisés pour détecter la duplication de messages et faire correspondre les messages acknowledgment/reset aux messages de type Confirmable/Non-Confirmable. |
| Token | est composé de 0 à 8 octets, utilisés pour associer une requête avec une réponse. | est composé de 0 à 8 octets, utilisés pour associer une requête avec une réponse. |

### Observation

L’état d’une ressource peut varier dans le temps 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éesainsi 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.

**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é.

### Service de découverte

Dans l’environnement machine à machine (M2M) les périphériques doivent être en mesure de se découvrir les uns les autres ainsi que leurs ressources. Ces dispositifs contraints communiquent entre eux grâce à des communications sans fils à faible puissance. Le défi est de rendre ces dispositifs aussi autonomes que possible en minimisant l’intervention humaine. Comme illustré, il existe pour le protocole CoAP deux typologies de services de découverte : Centralisée et Distribuée.

**Topologie Distribuée**

**CoAP Découverte**

La découverte de ressource distribuée est la méthode de base utilisée par un dispositif pour découvrir les ressources d’un autre appareil sans avoir besoin d’un répertoire. Quand un dispositif client a besoin d’obtenir les ressources hébergées sur un serveur il émet une requête GET à L’URI /.well-known/core du serveur RFC5785.

Dans le cas d’une demande unicast car l’adresse du serveur est connue, seul le serveur cible répondra en communiquant toutes ses ressources découvrables dans le Core Link format RFC6690.

Si la multidiffusion IP est prise en charge au sein du réseau, l’envoi d’une demande multicast est également possible pour découvrir les points terminaux et leurs ressources offertes en une seule requête. Toutefois, les demandes multicast ne sont pas fiables car le client ne peut pas savoir si sa demande a atteint toutes les destinations. Les clients peuvent également initier des interrogations pour des types spécifiques de ressources en précisant des paramètres (rt). Ce sont les serveurs qui décident quels sont leurs ressources disponibles à découvrir. Cette méthode de détection distribuée présente l’avantage que les requêtes sont effectuées directement du client au serveur sans intermédiaire. Mais cela nécessite que le client connaisse l’adresse IP ou le nom d’hôte du serveur, ce qui signifie qu’une application extérieure doit fournir l’adresse ou alors celle-ci devra être codée en dur dans le micrologiciel du client. Dans le cas où l’adresse IP est inconnue, le client peut également émettre une demande de découverte de voisin dont l’adresse sera obtenue par la couche réseau. Cependant cette méthode n’est pas souhaitable pour un réseau contraint ou l’énergie doit être préservée.

**Topologie Distribuée**

**mDNS**

Le DNS de multidiffusion (mDNS) est un protocole indépendant de Coap défini par la RFC6762. Le mDNS est adapté pour les périphériques connectés puisqu’il fonctionne sans infrastructure, il n’est pas nécessaire de configurer les périphériques manuellement ou d’avoir recours à une administration supplémentaire pour les gérer $^,.$ Lors de la découverte, les périphériques publient les informations sur les services et ressources qu'ils offrent en réalisant une annonce par multidiffusion. Lorsqu’un périphérique client (de type commutateur par exemple) veut accéder à une ressource (de type lumière par exemple) il utilisera les informations obtenues (lors de la publication) pour y accéder.

**Topologie Centralisée**

Le groupe de travail CoRE propose l’utilisation d’une entité Resource Directory $(RD)^,^,$ dans le LowPAN pour l’exploration des ressources.

**Topologie Centralisée**

**Coap Resource Directory**

La Resource Directory stocke les descriptions des ressources détenues par les serveurs (enregistrés par eux-mêmes sur le RD). Ainsi les clients peuvent découvrir toutes les ressources nécessaires en une seule demande. Pour utiliser la RD, soit pour l’enregistrement, soit pour effectuer une recherche, le dispositif doit savoir comment l'atteindre. Le point terminal peut localiser la RD de plusieurs manières. Soit le point terminal a l'adresse de la RD en statique dans son micrologiciel et la découvre au démarrage, soit par le Routeur de Bordure qui transmet l'information lors de l'annonce routeur (par exemple la route par défaut si la RD est installée dans le routeur) ou alors en utilisant le CoRE Link Format en faisant un GET/.well-known/core?rt=core.rd*.

En ce qui concerne les mises à jour, les serveurs peuvent mettre à jour leur enregistrement, La RD peut vérifier si un enregistrement est valable en interrogeant le point terminal et les enregistrements peuvent être supprimés par le point terminal à tout moment. La RD peut également supprimer des enregistrements lors de la détection d'une durée de vie expirée.

**Topologie Centralisée**

**DNS-SD**

CoAP et DNS-SD sont étudiés par la communauté Internet pour le service de découverte dans les réseaux contraints M2M. Le DNS-SD est un protocole à part défini par la RFC6763. DNS-SD définit comment nommer et arranger les enregistrements DNSPour la découverte de services $DNS-SD^,$ centralisée un serveur DNS-SD doit être disponible au sein de l’infrastructure du réseau. Les dispositifs s’enregistrent dans le DNS-SD après l’avoir découvert par une des méthodes suivante : l’annonce de routeur IPV6, en utilisant la méthode mDNS décrite précédemment ou par la méthode well-known. À l’issue de l’enregistrement, tout dispositif pourra rechercher des services par le biais de requêtes DNS au serveur DNS-SD.

### Communication de groupes

Le groupe de travail IETF CoRE a reconnu la nécessité de prendre en charge l’envoi d’un message multicast à un groupe de périphériques pour manipuler leurs ressources $^,$ $^,.$ Le travail de ce groupe a débouché sur la RFC7390 expérimentale publiée pour examen qui décrit la communication de groupe pour le protocole CoAP. L’intérêt est que des périphériques contraints puissent fonctionner en groupe, par exemple pour l’automatisation d’un bâtiment où toutes les lumières d’une pièce peuvent avoir besoin d’être activées et/ou désactivées en même temps. Les requêtes sont envoyées en multidiffusion alors que les réponses se font en unicast (aspect spécifié dans la section 8 de la RFC7252). Aucun mode de sécurité n’est spécifié pour CoAP multidiffusion, c'est-à-dire que dans ce cadre CoAP n’est pas chiffré, ni authentifié et il n'y a pas de contrôle d'accès. La multidiffusion IP est généralement classifiée comme un service peu fiable car il n’y a pas de garantie de livraison des paquets à chaque membre du groupe. Cependant, la qualité de ce service peut être améliorée en employant le Multicast Protocol for Low-Power and Lossy Networks (MPL) qui effectue des retransmissions périodiques. Coap réduit le risque de congestion en multidiffusion grâce aux mesures décrites en pages 19 et 20 de la RFC7390. Il existe des travaux proposant des solutions alternatives pour manipuler facilement des groupes de ressources par l’intermédiaire d’entités qui sont gérées par un Entité Manager $^,$ $^,$ $^,^,.$

### Format des données

Les périphériques de communication sont adressés à l'aide de ressources universelles (URI) et les données sont échangées par le biais du XML standard.Le paradigme des webservices RESTful présente de nombreux avantages pour les réseaux de faible puissance par rapport aux webservices RPC utilisant SOAP (et donc XML). XML présente une grande complexité d'interprétation s'il est utilisé dans les données utiles. Bien que les webservices présentent de nombreux avantages, les protocoles et les formats de données utiles utilisés ne sont pas forcément optimisés pour les périphériques restreints sans fil. De nombreuses techniques de compression ont été élaborées pour adpater les données XML aux réseaux contraints, mais celle qui a été retenue est EXI.

Le format Efficient XML Interchange (EXI) est une représentation XML compacte, actuellement normalisée par le World Wide Web Consortium W3C. Il est conçu pour prendre en charge les applications XML haute performance pour les environnements à contraintes de ressources, réduisant considérablement les exigences de bande passante et améliorant les performances de codage et de décodage. La compression EXI combine XML à un algorithme de compression standard pour obtenir des taux de compression élevés, ce qui réduit la verbosité des documents XML. Des travaux ont démontré que l'utilisation de la compression EXI pour la charge utile peut être jusqu'à 50 fois plus efficace qu'une simple utilisation basique de XML.

## Implémentations et Applications pratiques

Il existe de nombreuses implémentations de CoAP écrites dans différents langages, elles fournissent des librairies et API qui peuvent être utilisées pour l'intégration de CoAP dans des capteurs sans fils et le développement d'applications dans des environnements $différents^,.$

| Implémentation | Language | Platform | Description |
| - | - | - | - |
| Californium | Java | JVM | C'est un Framework Java pour les périphériques non contraints. Il permet d'élaborer des clients et applications web capables de communiquer avec les réseaux de capteurs sans fil. |
| Erbium | C | Contiki | Il s'agit d'un moteur REST léger pour le système d'exploitation Contiki. Il apporte la connectivité Internet aux périphériques contraints. |
| Copper | Javascript | Firefox | Copper est un plugin Firefox pour la gestion de périphériques CoAP, il permet aux utilisateurs de réaliser des tests. |
| libcoap | C | Posix/Contiki | La librairie libcoap peut être utilisée pour l'implémentation sur les périphériques de classe 1, 2 et au delà. |
| CoapBlip | C | TinyOS | C'est une adaptation de la librairie «libcoap» pour TinyOS qui s'adresse aux périphériques de classe 1. |
| jCoAP | Java | JVM | Écrit en Java, jCoAP s'adresse à des périphériques non contraints tels que les smartphones Android et systèmes embarqués. Il permet l’exécution de proxy CoAP-to-HTTP et HTTP-to-CoAP qui réalise la traduction entre les 2 protocoles. |
| coap.me | Ruby | | C'est un outil de test accessible sur un frontal Web à l’adresse, il permet de récupérer des serveurs CoAP. |
| Watteco | C | Contiki | C'est une implémentation commerciale pour les périphériques de classe 1 Contiki basés sur Erbium. |
| Cooja | C | Contiki | Cooja est un outil de simulation reposant sur le système d'exploitation Contiki, il permet de réaliser simulation et tests d'implémentation. |

Ces implémentations adressent différents périphériques que l'IETF classe de la façon suivante :

### Classe 0

    Ces périphériques ne sont pas capables d'exécuter de manière sécurisée une pile IP qui respecte la RFC. Ils doivent impérativement utiliser une passerelle pour se connecter à Internet.

### Classe 1

    Elle regroupe la plupart des périphériques qui disposent de ressources contraintes capables de se connecter à Internet avec des mécanismes de sécurités intégrés. Ils possèdent 100 ko de ROM et 10 ko de RAM. Ils ne peuvent implémenter une pile protocolaire HTTP sur TLS, et requièrent l'utilisation de protocoles légers avec une consommation énergétique optimisée. Avec, la taille très limitée de leurs mémoire cache, ils utilisent en majorité des réseaux de faible puissance comme IEE802.15.4 sur 6LowPAN. De par leurs performances et leur coût modeste, il s'agit des périphériques privilégiées pour former l'internet des objets.

### Classe 2

    Il s'agit des équipements pouvant se connecter à Internet qui possèdent les capacités de calcul similaires aux smartphones. Ceci est rendu possible avec approximativement 250 ko de ROM et 50 de RAM. Ils peuvent bénéficier des avantages d'un protocole léger et peu consommateur en énergie pour libérer des ressources sur leur applications et réduire leur coûts de production.

La communauté de recherche a réalisé de nombreuses implémentations de CoAP. Plusieurs acteurs majeurs du domaine de l'automatisation du bâtiment et de la mesure ont indiqué leur intérêt d'utiliser ce protocole dans leurs systèmes embarqués. Ces études ont démontré la possibilité d'implémenter CoAP avec seulement une dizaine de kilo-octets de mémoire ROM et RAM, mais aussi d'évaluer ses performances: temps de réponse, consommation énergétique, sa surcharge. Une implémentation sur l’OS Contiki, mets en évidence les gains apportés par CoAP en termes de gestion énergétique mais aussi qu’une utilisation du protocole «ContiMAC RDC» pour optimiser les cycles de fonctionnement des composants radio consommateurs apporte des gains similaires et soulève la question de l’intérêt de conserver des mécanismes d’économie d’énergie au niveau des couches applicatives. L’implémentation de CoAP réalisée sur Contiki montre une occupation de 8,5 ko de ROM et 1,5 ko de RAM avec la couche REST associée. L’expérimentation fait apparaitre également que les échanges de requêtes et réponses sont plus efficaces au niveau énergétique quand chaque message peut tenir dans une seule trame 802.15.4.

L'évaluation de la librairie CoapBlip met en évidence un problème dans le processus d'adaptation des librairies indépendantes de l'OS, qui ne garantit alors pas les performances et une exécution fiable. Une implémentation native pour l'OS est bien plus performante. Les mesures montrent que les données utiles ne peuvent dépasser 650 octets avec CoapBlip quand l'implémentation spécifique TinyCoAPparvient à 1 200 octets. TinyCoAP est plus rapide que l'adaptation CoapBlip, consomme moins d'énergie et peut traite un volume supérieur de requêtes

Enfin, dans plusieurs implémentations, les communications de bout en bout avec les réseaux de capteurs utilisant CoAP sont réalisées par l'intermédiaire d'un serveur mandataire chargé de faire les adaptations de protocole. Une approche différente est possible en déportant les traitements d'adaptations sur le navigateur Web du client avec l'usage d'une JVM et de Javascript évitant par conséquent l'usage de serveurs intermédiaires.

### Applications pratiques

Il existe de nombreux domaines d'applications. CoAP a été implémenté avec succès lors d'expérimentations dans les domaines de la santé, de la gestion énergétique et du bâtiment.

**Système de surveillance de soins de santé**

Dans le domaine de la santé, une des applications pratique est la réalisation d’un système de surveillance des soins de santé avec un réseau de capteurs sans fils basés sur CoAP afin de réduire la charge de travail des centres médicaux qui réalisent les analyses et faciliter la prise en charge rapide des patients en cas d’urgence. Cette infrastructure surveille les conditions de santé du patient et permet l’accès aux paramètres importants à tout instant avec un navigateur Web depuis n’importe quel endroit. Les patients dont l’état n’est pas critique peuvent ainsi quitter l’hôpital, la surveillance de leurs signes vitaux pouvant être faite en temps réel depuis leur domicile. CoAP permet de modéliser les propriétés des capteurs de santé comme des ressources et les exposer à des clients. Ces ressources sont alors manipulées en utilisant des méthodes HTTPpar le biais d’un navigateur Web.

Dans un réseau de capteurs sans fil basé sur CoAP chacun peut se comporter comme un serveur, et exposer le chemin d’une ressource « /.well-known/core » pour permettre la découverte des ressources par les clients. Ces derniers accèdent à cet emplacement par une méthode « POST » pour déclarer leurs propres ressources, ou une méthode « GET » pour découvrir les ressources déjà déclarées. L’option Observe lorsqu’elle est utilisée avec une méthode « GET » permet aux clients de signaler leur intérêt pour une ressource, en cas de mise à jour de celle-ci le serveur notifie alors de façon asynchrone les clients. Dans l’expérimentation les capteurs traditionnels chargés de contrôler le rythme cardiaque, la saturation d’oxygène dans le sang et électrocardiogrammes sont raccordés à des périphériques contraints type « Telos Mote » au travers de liaison série sur lequel est installé l’OS Contiki. L’implémentation Erbium avec son moteur REST se charge d’exposer les ressources de chaque capteur. Dans le cas d’un capteur qui surveille le rythme cardiaque et expose ses ressources à l’adresse « coap://server/oximeter/hrs». Le client envoie une requête contenant une méthode « GET » avec « uri-host=server » et « uri-path =/oximeter/hrs » pour obtenir en retour le rythme cardiaque du patient et les mises à jour futures. Les informations obtenues par les capteurs du patient sont transmises au serveur Web au format JSON, puis stockées et utilisées par le personnel médical.

**Système de gestion énergétique intelligent, Smart Grid**

Un réseau de distribution électrique intelligent s’efforce d’optimiser la production, la distribution et la consommation énergétique. L’implémentation d’un système de gestion d’énergie domestique capable d’interagir avec les équipements domestiques et de communiquer avec un réseau intelligent permet de contrôler la consommation et de réaliser des économies d’énergie. Le système se compose d’un système de gestion d’énergie domestique dit HEMS installé dans le domicile basé sur une solution libre, et d’un réseau d’actionneurs et capteurs dit HEC utilisant le protocole CoAP connectés aux équipements domestiques. Les HEC reliés au réseau local du foyer récupèrent la consommation énergétique : tension, puissance instantanée des équipements raccordés. Ces données sont envoyées de façon asynchrone au HEMS, grâce au mécanisme d’observation de CoAP. Celles-ci sont traitées par des algorithmes d’optimisation d’énergie exécutés sur le système HEMS, qui peut alors piloter les ressources du HEC au travers de méthodes CoAP pour demander leur allumage où extinction.

**Automatisation dans le bâtiment**

Dans le domaine de l’automatisation dans les bâtiments. Les ressources gérées par les protocoles historiques BacNet, LON peuvent être adaptés pour fonctionner avec CoAP, les messages historiques peuvent être véhiculés dans les données utiles de messages CoAP. Avec le support du multicast et la communication de groupe, un périphérique peut communiquer avec d’autres périphériques partageant les mêmes caractéristiques (par exemple : adressage de tous les périphériques d’une pièce).

### Autres domaines d'applications

CoAP peut également être utilisé dans des domaines d'applications tels que le transport , l'industrie, l'agriculture, la maison.

## Performances

Les différentes implémentations mettent en évidence les points suivants:

* Une consommation énergétique efficace grâce à l'entête réduit de CoAP. L’utilisation de ce dernier est plus efficace que son homologue HTTP et mieux adaptée aux réseaux de capteurs sans fils;
* La compression EXI (représentation compacte de XML) associée à CoAP est une approche plus efficace en termes d’énergie que la combinaison CoAP/XML. Cela induit une complexité réduite, une économie en termes de bande passante et une interprétation facilité;
* Une latence réduite de par l’utilisation d’UDP;

Financièrement, d'autres études démontrent que le choix d'utilisation de CoAP s’avère être un choix judicieux par rapport à HTTP :

* la fonction Observe de CoAP permet d'économiser la batterie d'un objet connecté : il se met en veille à la fin de leur session d'une connexion et se réactivent à chaque nouvelle session;
* la simplicité de la spécification CoAP par rapport à HTTP peut conduire à des économies dans les coûts de développement de logiciels en raison de la mise en œuvre plus rapide et plus facile de CoAP;
* Le faible trafic généré par CoAP se traduit aussi par une faible consommation de volume de trafic, une économie sur les coûts de connectivité (partie 5.2). L'étude révèle qu'une solution CoAP de 10000 objets connectés a besoin de 64 Go de données et plus de 400 Go pour une solution CoAP/HTTP.

Des travaux effectués comparent les performances CoAP avec son ainé, HTTP. Les temps de réponse de CoAP sont bien plus courts que ceux de HTTP avec un gain de temps de réponse estimé à environ 30%, ceci grâce à la compression d'en-têtes et le fait que CoAP utilise l'UDP. La compression d'en-têtes aura aussi un impact sur la consommation d’énergie. Le nombre d'octets transférés est inférieur dans une transaction CoAP par rapport à une transaction HTTP

Au niveau des protocoles de découverte CoAP, le mécanisme distribué surclasse le mécanisme centralisé concernant la surcharge puisque la découverte de RD (Resource Discovery) et les différentes phases d'enregistrement ne sont pas réalisées. Quant aux protocoles de découverte DNS, ils se montrent moins performants en termes de surcharge que le protocole CoAp. En effet, la découverte CoAP est l'approche la plus raisonnable dans un environnement de dispositifs contraints de faible puissance.

Le procédé de sécurisation des flux dans CoAP n'est pas sans impact sur la mémoire ROM de l’équipement lorsque le chiffrement des données est effectué de façon matérielle et l'utilisation de la RAM à plus de 80% peut être également un problème car cela peut empêcher le fonctionnement correct d'autres applications fonctionnant sur l'équipement.

Les performances du protocole réseau jouent un rôle important dans la consommation énergétique et CoAP est tributaire de ces performances en raison du protocole de transport sous-jacent UDP, de la fragmentation fréquente des paquets et des mécanismes de retransmission simples. La consommation d'énergie dans CoAP augmente lorsque la taille du paquet devient plus grande que 1 024 octets en raison de la fragmentation.

## Sécurité

Les dispositifs utilisant le protocole CoAP doivent être capables de protéger les flux d'informations à caractère sensible (par exemple pour le domaine de la santé). Une sécurité efficace dans CoAP peut se résumer aux différents thèmes présentés dans le tableau suivant :

| Thèmes | Menaces associées |
| - | - |
| Intégrité | Téléchargement de codes malveillants |
| Disponibilité | Déni de services (DoS) |
| Confidentialité | Analyse de trafic Écoute clandestine (Eavesdropping) |

Pour sécuriser les flux dans CoAP, DTLS, Datagram Transport Layer Security, principal protocole de sécurité dans IoT qui était spécifié par l'IETF dans la RFC 6347, a été conçu pour sécuriser de bout en bout la communication entre deux $équipements^,.$ DTLS est une version de TLS et reprend les fonctionnalités de ce dernier mais utilisera la couche Transport fournit par UDP contrairement à TLS qui utilise TCP.

Représentation DTLS dans la pile de protocoles

* CoAP
* Sécurité - DTLS
* Couche Transport - UDP
* Couche Réseau - IPV6
* Couche Physique - IEEE 802.15.4

DTLS est un protocole composé deux couches:

* la couche inférieure «Record Protocol» qui fournit un chiffrement par clé symétrique sécurisé pour assurer la confidentialité et/ou l'intégrité du message;
* La couche supérieure comprenant quatre protocoles qui va s'occuper de l'authentification des hôtes, du signalement des erreurs et du chiffrage des données.

Les dispositifs IoT basés sur CoAP sont configurés dans l'un des 4 modes de sécurité suivants:

* NoSec: Il n'y a pas de sécurité au niveau du protocole. DTLS est désactivé;
* PreSharedKey: DTLS est activé, il existe une liste de clés pré-partagées (RFC4279), et chaque clé comprend une liste des nœuds;
* RawPublicKey: DTLS est activé et le périphérique possède une paire de clés asymétriques sans certificat;
* Certificat: DTLS est activé et le périphérique a une paire de clés asymétriques avec un certificat X.509.

En mode «NoSec», le système est protégé uniquement en bloquant l'envoi ou la réception de paquets sur le réseau par un attaquant et envoie simplement les paquets via UDP.

CoAP est basé sur les commandes URI «coap» ou «coaps» - quand DTLS est utilisé - pour identifier les ressources et leur emplacement. L'utilisation de «coaps» implique que les datagrammes UDP sont sécurisés avec DTLS. Les ressources disponibles via «coaps» ne sont pas partagées avec «coap» même si leur identificateur de ressource est identique.

CoaP étant par définition un protocole restreint, son utilisation avec DTLS en l'état pose problème car il a été conçu pour des réseaux informatiques traditionnels.

DTLS est un protocole lourd et ses en-têtes sont trop longs pour tenir dans une seule trame IEEE802.15.4. Pour aller à l'encontre des problèmes de compatibilité, 6LoWPAN, couche réseau sur laquelle s'appuie CoAP fournit des mécanismes de compression d'en-tête visant à réduire la taille des en-têtes de couche supérieure (DTLS).

IPSec, protocole de sécurité de la pile IP, peut être employé pour une sécurisation des flux CoAP dans des environnements contraints et plus particulièrement ESP lorsque CoAP est utilisé sans DTLS.

L'utilisation d'IPsec entre les points d'extrémité CoAP est transparente pour la couche application et ne nécessite pas de conditions particulières pour une implémentation dans CoAP. Cependant IPsec peut ne pas être approprié pour tous les environnements :les pare-feu et les NAT peuvent grandement limiter l'utilisation d'IPsec .

L'utilisation de mécanisme de protection comme DTLS est essentielle pour les réseaux et systèmes CoAP, mais ils ne fournissent pas de contrôle d'accès. L'utilisation d'un contrôle d'accès sur un périphérique CoAP peut autoriser l'accès en READ / WRITE de ses services à un groupe d'utilisateurs tout en autorisant uniquement l'accès en READ ONLY à un autre groupe. Cela ajoute une autre couche de protection et renforce ainsi la sécurité au niveau des flux CoAP.

## Historique

Le groupe de travail CoRE, Constrained RESTFul Environment a créé le protocole CoAP à la suite des travaux du groupe de travail 6LoWPAN. L’objectif de CoAP est d’étendre l'architecture WEB aux applications Machine to Machine (M2M) et Internet des Objets (IoT) utilisant des systèmes contraints.Les services Web sur Internet sont des éléments essentiels dans la plupart des applications et dépendent de l'architecture REST. Pour rendre cela possible, CORE a défini le protocole CoAP, Constrained Application Protocol. Ce protocole permet la communication entre objets connectés dans une architecture contrainte. Le protocole CoAP cible les équipements et les machines qui n'ont parfois qu'un microcontrôleur 8 bits pour processeur avec très peu de mémoire et qui sont connectés par des liens radio lents et peu fiables, les LowPAN. CoAP est en permanente évolution. Le protocole est enrichi avec des extensions telles que Observe, Communication de groupe $^,$ $^,$ $^,$ $^,...$

### Décembre 2009

    Les fondements du protocole (draft-bormann-core-coap-block-00).

### Mai 2010

    Spécifications du protocole (Constrained Application Protocol (CoAP)draft-shelby-core-coap-01).

### 2010-2014

    Évolution du protocole (les différentes versions draft-ietf-core-coap de 00 à 18).

### Juin 2014

    Création RFC7252 The Constrained Application Protocol (CoAP).

### Octobre 2014

    Création RFC7390 Group Communication for the Constrained Application Protocol (CoAP).

### Septembre 2015

    RFC7641 Observing Resources in the Constrained Application Protocol.

### Août 2016

    RFC7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP).
