CoAP

Figure 1: Un client interrogeant un capteur pour obtenir la température ambiante.

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[4]. 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[5] - [7].

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[8]. Le serveur répond par un code réponse accompagné éventuellement de la représentation de la ressource[8].

Figure 2 : Architecture CoAP

L'architecture CoAP est divisée en deux couches[4] - [6]. 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[4]. Il s'agit cependant bien d'un seul et même protocole qui propose ces fonctionnalités dans son entête[8].

Couche Message

Figure 3 : Transaction CoAP

La couche Message apporte la fiabilité pour les messages typés Confirmables[9]. Elle assure alors un contrôle de bout en bout et leur retransmission en cas de perte. L'utilisation d'un jeton[note 5] 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[4] - [10].

Couche Requête-Réponse

CoAP dispose des méthodes suivantes[11] - [9] - [12]:

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[11].

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 s'insère dans un modèle à 5 couches , physique, liaison de données, réseau, transport et application.

Figure 4 : Position de CoAP[13] - [14] - [15] - [7]

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.

Figure 5 : Entête 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 »[16]. Il apparait ensuite, une séquence d’options au format TLV[note 6] 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»[17].

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

Champ	Description[16]
Ver (Version)	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.
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.
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.
Token	est composé de 0 à 8 octets, utilisés pour associer une requête avec une réponse.

Figure 8 : Observation d'un ressource dans CoAP

L’état d’une ressource peut varier dans le temps et un client peut avoir besoin de ces changements d’états[18]. 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[19]. Ce mécanisme consommateur de ressources ne convient pas dans un environnement contraint avec des ressources réseau limitées [20]ainsi que des périphériques endormis la plupart du temps [19]. Pour répondre à ce besoin, CoAP bénéficie d’une extension du protocole RFC7641 [21] 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[21], il appartient au serveur d'exposer des ressources observables qui notifient leur état de manière utile dans le contexte de l'application[21]. 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[note 5] 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[22] - [23] et devraient utiliser une valeur moins agressive si c’est possible. Des optimisations sont attendues à l’avenir à l'instar de CoCoA (Congestion Control/Advanced) [note 7] - [24] qui étend la spécification CoAP avec un contrôle de congestion avancé [25].

Figure 9 : 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[19]. 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[26]. Comme illustré, il existe pour le protocole CoAP deux typologies de services de découverte : Centralisée et Distribuée[27].

CoAP Découverte

Figure 10 : Découverte ressource

La découverte de ressource distribuée est la méthode de base [28] 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 [29].

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 [30].

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 [note 8] et leurs ressources offertes en une seule requête. Toutefois, les demandes multicast ne sont pas fiables [31] 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 [31]. 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[note 9] 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[31].

mDNS

Le DNS de multidiffusion (mDNS) est un protocole indépendant de Coap défini par la RFC6762[32]. 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[33] - [34]. 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[34]. 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[34].

Figure 11 : Architecture Resource Directory

Le groupe de travail CoRE propose l’utilisation d’une entité Resource Directory (RD) [31] - [35] - [36] dans le LowPAN pour l’exploration des ressources.

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) [27]. 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[note 8] peut localiser la RD de plusieurs manières. Soit le point terminal[note 8] a l'adresse de la RD en statique dans son micrologiciel [note 9] et la découvre au démarrage, soit par le Routeur de Bordure [note 10] 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*[37].

Figure 12 : Découverte 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[note 8] et les enregistrements peuvent être supprimés par le point terminal[note 8] à tout moment. La RD peut également supprimer des enregistrements lors de la détection d'une durée de vie expirée[31].

DNS-SD

CoAP et DNS-SD sont étudiés par la communauté Internet [38] pour le service de découverte dans les réseaux contraints M2M. Le DNS-SD est un protocole à part défini par la RFC6763[39]. DNS-SD définit comment nommer et arranger les enregistrements DNS [40]Pour la découverte de services DNS-SD [34] - [33] 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.

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[41] - [42] - [43]. Le travail de ce groupe a débouché sur la RFC7390 [44] 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)[45]. Aucun mode de sécurité n’est spécifié pour CoAP multidiffusion [46], 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 [47] 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[48]. Coap réduit le risque de congestion en multidiffusion grâce aux mesures décrites en pages 19 et 20 de la RFC7390 [49]. 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 [43] - [50] - [51] - [52] - [note 11].

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[53].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)[54]. 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[55], 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[56]. 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[57].

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.

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[78]. 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[79]. 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[79]. 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 HTTP[80]par 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[81]. Dans l’expérimentation[82] 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[82].

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[83]. Le système se compose d’un système de gestion d’énergie domestique dit HEMS[note 12] installé dans le domicile basé sur une solution libre, et d’un réseau d’actionneurs et capteurs dit HEC[note 13] utilisant le protocole CoAP connectés aux équipements domestiques[83].  Les HEC[note 13] 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[note 12], grâce au mécanisme d’observation de CoAP[84]. Celles-ci sont  traitées par des algorithmes d’optimisation d’énergie exécutés sur le système HEMS[note 12], qui peut alors piloter les ressources du HEC[note 13] au travers de méthodes CoAP pour demander leur allumage où extinction[85].

Dans le domaine de l’automatisation dans les bâtiments[86]. 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)[87].

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

Figure 13 : Différents domaines d'application.

• (en) « CoAP Feature Analysis draft-shelby-6lowapp-coap-00 », sur ietf.org, décembre 2009
• (en) « Constrained Application Protocol (CoAP)draft-shelby-core-coap-01 », sur ietf.org, mai 2010
• (en) « draft-bormann-core-coap-block-00 : Blockwise transfers in CoAP », sur sandbox.ietf.org, août 2010
• (en) « draft-ietf-core-resource-directory-09 : CoRE Resource Directory », sur tools.ietf.org, octobre 2016
• (en) « RFC4279 : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) », sur ietf.org, décembre 2005
• (en) « RFC4347 : Datagram Transport Layer Security », sur ietf.org, avril 2006
• (en) « RFC5785 : Defining Well-Known Uniform Resource Identifiers (URIs) », sur tools.ietf.org, avril 2010
• (en) « RFC5988 : Web Linking », sur tools.ietf.org, octobre 2010
• (en) « RFC6690 : Constrained RESTful Environments (CoRE) Link Format », sur tools.ietf.org, août 2012
• (en) « RFC6762 : Multicast DNS », sur tools.ietf.org, février 2013
• (en) « RFC6763 : DNS-Based Service Discovery », sur tools.ietf.org, février 2013
• (en) « Historique RFC7252 CoAP) », sur ietf.org, juin 2014
• (en) « RFC7252 : The Constrained Application Protocol (CoAP) », sur ietf.org, juin 2014
• (en) « RFC7341 : DHCPv4-over-DHCPv6 (DHCP 4o6) Transport », sur ietf.org, avril 2006
• (en) « RFC7390 : Group Communication for the Constrained Application Protocol (CoAP) », sur ietf.org, octobre 2014
• (en) « RFC7641 : Observing Resources in the Constrained Application Protocol (CoAP) », sur tools.ietf.org, septembre 2015
• (en) « RFC7731 : Multicast Protocol for Low-Power and Lossy Networks (MPL) », sur tools.ietf.org, février 2016
• (en) « RFC7925 : Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS)Profiles for the Internet of Things », sur ietf.org, juillet 2016
• (en) « RFC7959 : Block-Wise Transfers in the Constrained Application Protocol (CoAP) », sur ietf.org, août 2016
• (en) « Constrained Application Protocol draft-ietf-core-coap-12 », sur ietf.org, octobre 2012
• (en) « Constrained RESTful Environments (core) - », sur datatracker.ietf.org (consulté le 9 décembre 2016)
• (en) « RFC4303 : IP Encapsulating Security Payload (ESP) - », sur www.ietf.org (consulté le 15 novembre 2016)
• (en) « CoAP Simple Congestion Control/Advanced draft-ietf-core-cocoa-00 », sur www.ietf.org (consulté le 15 novembre 2016)
• (en) « Internet Protocol », sur ietf.org, septembre 1981

• (en) C. Bormann, A. P. Castellani et Z. Shelby, « CoAP: An Application Protocol for Billions of Tiny Internet Nodes », IEEE Internet Computing, vol. 16, n^o 2,‎ 1^er mars 2012, p. 62–67 (ISSN 1089-7801, DOI 10.1109/MIC.2012.29, lire en ligne, consulté le 9 décembre 2016)
• (en) W. Colitti, K. Steenhaut, N. De Caro, B. Buta et V. Dobrota, « Evaluation of constrained application protocol for wireless sensor networks », Local & Metropolitan Area Networks (LANMAN), 2011 18th IEEE Workshop on,‎ mars-avril 2011 (ISSN 1944-0375, DOI 10.1109/LANMAN.2011.6076934)

• (en) Reem Abdul. Raham et B. Shah, « Security analysis of IoT protocols: A focus in CoAP », 2016 3rd MEC International Conference on Big Data and Smart City (ICBDSC),‎ mars 2016, p. 1-7 (DOI 10.1109/ICBDSC.2016.7460363)

• (en) R. Martins, V. Schaurich, L. Knob, J. Wickboldt, A. Filho, L. Granville et M. Pias, « Performance Analysis of 6LoWPAN and CoAP for Secure Communications in Smart Homes », Advanced Information Networking and Applications (AINA), 2016 IEEE 30th International Conference on,‎ mars 2016 (ISSN 1550-445X, DOI 10.1109/AINA.2016.82)

• (en) A. Betzler, C. Gomez, I. Demirkol et J. Paradells, « CoCoA+: An advanced congestion control mechanism for CoAP », Ad Hoc Networks, vol. 33,‎ avril 2015, p. 126-139 (DOI 10.1016/j.adhoc.2015.04.007)

• (en) Angelo P. Castellani, M. Rossi et M. Zorzi, « Back pressure congestion control for CoAP/6LoWPAN networks », Ad Hoc Networks, vol. 18,‎ mars 2013, p. 71-84 (DOI 10.1016/j.adhoc.2013.02.007)

• (en) G. Cho, S. Chun, X. Jin et K. Lee, « Enhancing CoAP proxy for semantic composition and multicast communication », UbiComp/ISWC'15 Adjunct,‎ septembre 2015, p. 205-208 (DOI 10.1145/2800835.2800920)

• (en) F. Abeele, J. Hoebeke, I. Ishaq, Girum K. Teklemariam, J. Rossey, I. Moerman et P. Demeester, « Building embedded applications via REST services for the internet of things », Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, n^o 82,‎ novembre 2013 (DOI 10.1145/2517351.2517426)

• (en) A. Betzler, J. Isern, C. Gomez, I. Dermirkol et J. Paradells, « Experimental evaluation of congestion control for CoAP communications without end-to-end reliability », Ad Hoc Networks, vol. 52,‎ décembre 2016, p. 183-194 (DOI 10.1016/j.adhoc.2016.07.011)

• (en) M. Prakash et C. J. KavithaPriya, « An Analysis of Types of Protocol Implemented in Internet of Things Based on Packet Loss Ratio », ICTCS '16, n^o 27,‎ mars 2016 (DOI 10.1145/2905055.2905085)

• (en) M. Kovatsch, « CoAP for the web of things: from tiny resource-constrained devices to the web browser », UbiComp’13 Adjunct,‎ septembre 2013 (DOI 10.1145/2494091.2497583)

• (en) A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari et M. Ayyash, « Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications », IEEE Communications Surveys & Tutorials, vol. 17, n^o 4,‎ juin 2015, p. 2347-2376 (ISSN 1553-877X, DOI 10.1109/COMST.2015.2444095)

• (en) I. Ishaq, J. Hoebeke, F. Van Den Abeele, I. Moerman et P. Demeester, « Group Communication in Constrained Environments Using CoAP-based Entities », Distributed Computing in Sensor Systems (DCOSS), 2013 IEEE International Conference on,‎ mai 2013 (DOI 10.1109/DCOSS.2013.14)

• (en) Shahid Raza, Simon Duquennoy, Tony Chung, Dogan Yazar, Thiemo Voigt et Utz Roedig, « Securing communication in 6LoWPAN with compressed IPsec », Distributed Computing in Sensor Systems and Workshops (DCOSS), 2011 International Conference on,‎ août 2011 (DOI 10.1109/DCOSS.2011.5982177)

• (en) Ajit A. Chavan et Mininath K. Nighot, « Secure and Cost-effective Application Layer Protocol with Authentication Interoperability for IOT », Elsevier Science Direct Freedom Collection, vol. 78,‎ décembre 2015, p. 646 - 651 (DOI 10.1016/j.procs.2016.02.112)

• (en) Shahid Raza, Hossein Shafagh, Kasun Hewage, René Hummen et Thiemo Voigt, « Lithe: Lightweight Secure CoAP for the Internet of Things », IEEE Sensors Journal, vol. 13,‎ août 2013, p. 3711 - 3720 (DOI 10.1109/JSEN.2013.2277656)

• (en) Shahid Raza, Daniele Trabalza et Thiemo Voigt, « 6LoWPAN Compressed DTLS for CoAP », Distributed Computing in Sensor Systems (DCOSS), 2012 IEEE 8th International Conference on,‎ mai 2012, p. 287 - 289 (DOI 10.1109/DCOSS.2012.55)

• (en) Sye Loong Keoh, Sandeep S. Kumar et Hannes Tschofenig, « Securing the Internet of Things: A Standardization Perspective », IEEE Internet of Things Journal, vol. 1,‎ juin 2014, p. 265 - 275 (DOI 10.1109/JIOT.2014.2323395)

• (en) Stefanie Gerdes, Olaf Bergmann et Carsten Bormann, « Delegated Authenticated Authorization for Constrained Environments », Network Protocols (ICNP), 2014 IEEE 22nd International Conference on,‎ octobre 2014, p. 654 - 659 (DOI 10.1109/ICNP.2014.104)

• (en) S Bandyopadhyay et A Bhattacharyya, « Lightweight Internet protocols for web enablement of sensors using constrained gateway devices », Computing, Networking and Communications (ICNC), 2013 International Conference on,‎ janvier 2013 (DOI 10.1109/ICCNC.2013.6504105)

• (en) B Villaverde, D Pesch, R Alberola, S Fedor et M Boubekeur, « Constrained Application Protocol for Low Power Embedded Networks: A Survey », Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2012 Sixth International Conference on,‎ juillet 2012 (DOI 10.1109/IMIS.2012.93)

• (en) M. Castra, A. Jara et A. Skarmeta, « Enabling end-to-end CoAP-based communications for the Web of Things », Journal of Network and Computer Applications, vol. 59,‎ janvier 2016, p. 230-236 (DOI 10.1016/j.jnca.2014.09.019)

• (en) M. Kovatsch, S. Duquennoy et A. Dunkels, « A Low-Power CoAP for Contiki », Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Conference on,‎ octobre 2011 (ISSN 2155-6806, DOI 10.1109/MASS.2011.100)

• (en) T. Leva, O. Mazhelis et H. Suomi, « Comparing the cost-efficiency of CoAP and HTTP in Web of Things applications », Decision Support Systems, vol. 63,‎ juillet 2014, p. 23-28 (DOI 10.1016/j.dss.2013.09.009)

• (en) M-P. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L-A. Grieco, G. Boggia et M. Dohler, « Standardized Protocol Stack for the Internet of (Important) Things », IEEE Communications Surveys & Tutorials, vol. 15, n^o 3,‎ décembre 2012, p. 1389-1406 (ISSN 1553-877X, DOI 10.1109/SURV.2012.111412.00158)
• (en) G. Ketema, J. Hoebeke, I. Moerman et P. Demeester, « Efficiently Observing Internet of Things Resources », 2012 IEEE International Conference on Green Computing and Communications (GreenCom),‎ 1^er novembre 2012, p. 446–449 (DOI 10.1109/GreenCom.2012.70, lire en ligne, consulté le 21 novembre 2016)
• (en) C. Hennebert et J. D. Santos, « Security Protocols and Privacy Issues into 6LoWPAN Stack: A Synthesis », IEEE Internet of Things Journal, vol. 1, n^o 5,‎ 1^er octobre 2014, p. 384–398 (ISSN 2327-4662, DOI 10.1109/JIOT.2014.2359538, lire en ligne, consulté le 22 novembre 2016)
• (en) August Betzler, Javier Isern, Carles Gomez et Ilker Demirkol, « Experimental evaluation of congestion control for CoAP communications without end-to-end reliability », Ad Hoc Networks, modeling and Performance Evaluation of Wireless Ad Hoc Networks, vol. 52,‎ 1^er décembre 2016, p. 183–194 (DOI 10.1016/j.adhoc.2016.07.011, lire en ligne, consulté le 23 novembre 2016)
• (en) J. Pradilla, R. González, M. Esteve et C. Palau, « Sensor Observation Service (SOS)/Constrained Application Protocol (CoAP) proxy design », 2016 18th Mediterranean Electrotechnical Conference (MELECON),‎ 1^er avril 2016 (DOI 10.1109/MELCON.2016.7495411)
• (en) B. Carballido Villaverde, R. D. P. Alberola, A. J. Jara et S. Fedor, « Service Discovery Protocols for Constrained Machine-to-Machine Communications », IEEE Communications Surveys Tutorials, vol. 16, n^o 1,‎ 1^er janvier 2014 (ISSN 1553-877X, DOI 10.1109/SURV.2013.102213.00229)
• (en) Isam Ishaq, Jeroen Hoebeke, Floris Van den Abeele et Jen Rossey, « Flexible Unicast-Based Group Communication for CoAP-Enabled Devices », Sensors, vol. 14, n^o 6,‎ 4 juin 2014, p. 9833–9877 (PMID 24901978, PMCID 4118386, DOI 10.3390/s140609833)
• (en) Alessandro Ludovici, Pol Moreno et Anna Calveras, « TinyCoAP: A Novel Constrained Application Protocol (CoAP) Implementation for Embedding RESTful Web Services in Wireless Sensor Networks Based on TinyOS », Journal of Sensor and Actuator Networks, vol. 2, n^o 2,‎ 14 mai 2013, p. 288–315 (DOI 10.3390/jsan2020288)
• (en) Miguel Castro, Antonio J. Jara et Antonio F. Skarmeta, « Enabling end-to-end CoAP-based communications for the Web of Things », Journal of Network and Computer Applications, vol. 59,‎ 1^er janvier 2016, p. 230–236 (DOI 10.1016/j.jnca.2014.09.019)
• (en) Miguel Castro, Antonio J. Jara et Antonio F. Skarmeta, « Enabling end-to-end CoAP-based communications for the Web of Things », Journal of Network and Computer Applications, vol. 59,‎ 1^er janvier 2016, p. 230–236 (DOI 10.1016/j.jnca.2014.09.019)
• (en) Isam Ishaq, Jeroen Hoebeke, Ingrid Moerman et Piet Demeester, « Observing CoAP groups efficiently », Ad Hoc Networks, vol. 37, Part 2,‎ 1^er février 2016, p. 368–388 (DOI 10.1016/j.adhoc.2015.08.030, lire en ligne, consulté le 5 décembre 2016)
• (en) Isam Ishaq, Jeroen Hoebeke, Ingrid Moerman et Piet Demeester, « Experimental Evaluation of Unicast and Multicast CoAP Group Communication », Sensors, vol. 16, n^o 7,‎ 21 juillet 2016, p. 1137 (PMID 27455262, PMCID 4970179, DOI 10.3390/s16071137, lire en ligne, consulté le 6 décembre 2016)
• (en) H. A. Khattak, M. Ruta, E. Di Sciascio et D. Sciascio, « CoAP-based healthcare sensor networks: A survey », Proceedings of 2014 11th International Bhurban Conference on Applied Sciences Technology (IBCAST) Islamabad, Pakistan, 14th - 18th January, 2014,‎ 1^er janvier 2014, p. 499–503 (DOI 10.1109/IBCAST.2014.6778196)
• (en) D. Ugrenovic et G. Gardasevic, « CoAP protocol for Web-based monitoring in IoT healthcare applications », 2015 23rd Telecommunications Forum Telfor (℡FOR),‎ 1^er novembre 2015, p. 79–82 (DOI 10.1109/TELFOR.2015.7377418)
• (en) W. Colitti, K. Steenhaut, N. De Caro et B. Buta, « Evaluation of constrained application protocol for wireless sensor networks », 2011 18th IEEE Workshop on Local Metropolitan Area Networks (LANMAN),‎ 1^er octobre 2011, p. 1–6 (DOI 10.1109/LANMAN.2011.6076934, lire en ligne, consulté le 8 décembre 2016)
• (en) Eleonora Borgia, « The Internet of Things vision: Key features, applications and open issues », Computer Communications, vol. 54,‎ 2014, p. 1–31 (DOI 10.1016/j.comcom.2014.09.008, lire en ligne)
• (en) G. Belcredi, P. Modernell, N. Sosa et L. Steinfeld, « An implementation of a home energy management platform for Smart Grid », 2015 IEEE PES Innovative Smart Grid Technologies Latin America (ISGT LATAM),‎ 1^er octobre 2015, p. 270–274 (DOI 10.1109/ISGT-LA.2015.7381166)
• (en) Kihong Kim, Jinkeun Hong, Yongick Jung et Sangyi Yi, « New secure session resume protocol using IV count for wireless networks », 2005 IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications, vol. 3,‎ 1^er septembre 2005, p. 1999–2003 Vol. 3 (DOI 10.1109/PIMRC.2005.1651790, lire en ligne, consulté le 8 décembre 2016)
• (en) A. P. Castellani, M. Gheda, N. Bui et M. Rossi, « Web Services for the Internet of Things through CoAP and EXI », 2011 IEEE International Conference on Communications Workshops (ICC),‎ 1^er juin 2011, p. 1–6 (DOI 10.1109/iccw.2011.5963563, lire en ligne, consulté le 8 décembre 2016)
• (en) G. Moritz, F. Golatowski, C. Lerche et D. Timmermann, « Beyond 6LoWPAN: Web Services in Wireless Sensor Networks », IEEE Transactions on Industrial Informatics, vol. 9, n^o 4,‎ 1^er novembre 2013, p. 1795–1805 (ISSN 1551-3203, DOI 10.1109/TII.2012.2198660, lire en ligne, consulté le 8 décembre 2016)
• (en) P. P. Pereira, J. Eliasson et J. Delsing, « An authentication and access control framework for CoAP-based Internet of Things », IECON 2014 - 40th Annual Conference of the IEEE Industrial Electronics Society,‎ 1^er octobre 2014, p. 5293–5299 (DOI 10.1109/IECON.2014.7049308, lire en ligne, consulté le 8 décembre 2016)
• (en) V. Lakkundi et K. Singh, « Lightweight DTLS implementation in CoAP-based Internet of Things », 20th Annual International Conference on Advanced Computing and Communications (ADCOM),‎ 1^er septembre 2014, p. 7–11 (DOI 10.1109/ADCOM.2014.7103240, lire en ligne, consulté le 9 décembre 2016)
• (en) A. Capossele, V. Cervo, G. De Cicco et C. Petrioli, « Security as a CoAP resource: An optimized DTLS implementation for the IoT », 2015 IEEE International Conference on Communications (ICC),‎ 1^er juin 2015, p. 549–554 (DOI 10.1109/ICC.2015.7248379, lire en ligne, consulté le 11 décembre 2016)
• (en) R. A. Fuentes-Samaniego, A. R. Cavalli et J. A. Nolazco-Fores, « An Analysis of Secure M2M Communication in WSNs Using DTLS », 2016 IEEE 36th International Conference on Distributed Computing Systems Workshops (ICDCSW),‎ 1^er juin 2016, p. 78–83 (DOI 10.1109/ICDCSW.2016.13, lire en ligne, consulté le 11 décembre 2016)
• (en) S. H. Shaheen et M. Yousaf, « Security Analysis of DTLS Structure and Its Application to Secure Multicast Communication », 2014 12th International Conference on Frontiers of Information Technology,‎ 1^er décembre 2014, p. 165–169 (DOI 10.1109/FIT.2014.39, lire en ligne, consulté le 11 décembre 2016)
• (en) W. Colitti, K. Steenhaut et N. De Caro, « Integrating Wireless Sensor Networks with the Web »
• (en) J. Granjal, E. Monteiro et J. Sá Silva, « On the feasibility of secure application-layer communications on the Web of Things », 37th Annual IEEE Conference on Local Computer Networks,‎ 1^er octobre 2012, p. 228–231 (DOI 10.1109/LCN.2012.6423615, lire en ligne, consulté le 12 décembre 2016)
• (en) D. H. Mun, M. L. Dinh et Y. W. Kwon, « An Assessment of Internet of Things Protocols for Resource-Constrained Applications », 2016 IEEE 40th Annual Computer Software and Applications Conference (COMPSAC), vol. 1,‎ 1^er juin 2016, p. 555–560 (DOI 10.1109/COMPSAC.2016.51, lire en ligne, consulté le 12 décembre 2016)

• (fr) « Site Watteco », 2016
• (en) « Site Californium », 2016
• (en) « Site Erbium », 2016
• (en) « Site de Copper », 2016
• (en) « Site officiel libcoap », 2016
• (en) « Site projet CoapBlip », 2016
• (en) « Site projet jCoAP », 2016
• (en) « Site officiel coap.me », 2016
• (en) « Site Contiki, installation Cooja », 2016