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 webRESTful 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[1].
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.
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[note 1] 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 [2]. Il offre simplicité, faible surcharge[note 2] pour environnements réseaux contraints de faible puissance confrontés à des taux de perte important[2]. CoAP permet les communications M2M requises pour l’interaction et l'exploitation des systèmes embarqués[note 3],[3]. Il est défini comme protocole générique pour les réseaux à basse puissance et avec pertes[note 4] et s'appuie sur les protocoles et réseaux sous-jacents[4] 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[5], 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[6],[4] :
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.
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 CoAPLa 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].
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[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 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.
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 de longueur 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
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.
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].
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].
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].
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 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[58],[59].
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.
Écrit en Java, jCoAP[65] 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.
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[69] :
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[69].
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é 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és pour former l'internet des objets[70].
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[71]. 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[72]. 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[73] 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[74]. 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[75].
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 TinyCoAP[76]parvient à 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[77].
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].
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[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].
Les différentes implémentations mettent en évidence les points suivants[86]:
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[89] :
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 [90] 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[87]. Le nombre d'octets transférés est inférieur dans une transaction CoAP par rapport à une transaction HTTP[91]
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[92]. 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[93].
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[94].
Les performances du protocole réseau jouent un rôle important dans la consommation énergétique[95] 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[96].
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[97] dans le tableau suivant :
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[98], a été conçu pour sécuriser de bout en bout la communication entre deux équipements[99],[100].
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[101].
Représentation DTLS dans la pile de protocoles[102]
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[104]:
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)[105], 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 [104].
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[106].
CoaP étant par définition un protocole restreint, son utilisation avec DTLS en l'état pose problème [107] 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[108]. 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[108] (DTLS).
IPSec, protocole de sécurité de la pile IP, peut être employé pour une sécurisation des flux CoAP dans des environnements contraints [109] et plus particulièrement ESP [110] 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[109] .
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[111]. 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[112].
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[113].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 [45].
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 [43],[50],[51],[52],[note 11]...
Les fondements du protocole (draft-bormann-core-coap-block-00) [113].
Spécifications du protocole (Constrained Application Protocol (CoAP)draft-shelby-core-coap-01)[114].
2010-2014
Évolution du protocole (les différentes versions draft-ietf-core-coap de 00 à 18)[115].
Création RFC7252 The Constrained Application Protocol (CoAP) [45].
Création RFC7390 Group Communication for the Constrained Application Protocol (CoAP)[44].
RFC7641 Observing Resources in the Constrained Application Protocol [116].
RFC7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP) [117].
(en) C. Bormann, A. P. Castellani et Z. Shelby, « CoAP: An Application Protocol for Billions of Tiny Internet Nodes », IEEE Internet Computing, vol. 16, no 2, , p. 62–67 (ISSN1089-7801, DOI10.1109/MIC.2012.29, lire en ligne, consulté le )
(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, (ISSN1944-0375, DOI10.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), , p. 1-7 (DOI10.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, (ISSN1550-445X, DOI10.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, , p. 126-139 (DOI10.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, , p. 71-84 (DOI10.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, , p. 205-208 (DOI10.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, no 82, (DOI10.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, , p. 183-194 (DOI10.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, no 27, (DOI10.1145/2905055.2905085)
(en) M. Kovatsch, « CoAP for the web of things: from tiny resource-constrained devices to the web browser », UbiComp’13 Adjunct, (DOI10.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, no 4, , p. 2347-2376 (ISSN1553-877X, DOI10.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, (DOI10.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, (DOI10.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, , p. 646 - 651 (DOI10.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, , p. 3711 - 3720 (DOI10.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, , p. 287 - 289 (DOI10.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, , p. 265 - 275 (DOI10.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, , p. 654 - 659 (DOI10.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, (DOI10.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, (DOI10.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, , p. 230-236 (DOI10.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, (ISSN2155-6806, DOI10.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, , p. 23-28 (DOI10.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, no 3, , p. 1389-1406 (ISSN1553-877X, DOI10.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), , p. 446–449 (DOI10.1109/GreenCom.2012.70, lire en ligne, consulté le )
(en) C. Hennebert et J. D. Santos, « Security Protocols and Privacy Issues into 6LoWPAN Stack: A Synthesis », IEEE Internet of Things Journal, vol. 1, no 5, , p. 384–398 (ISSN2327-4662, DOI10.1109/JIOT.2014.2359538, lire en ligne, consulté le )
(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, , p. 183–194 (DOI10.1016/j.adhoc.2016.07.011, lire en ligne, consulté le )
(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), (DOI10.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, no 1, (ISSN1553-877X, DOI10.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, no 6, , p. 9833–9877 (PMID24901978, PMCID4118386, DOI10.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, no 2, , p. 288–315 (DOI10.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, , p. 230–236 (DOI10.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, , p. 230–236 (DOI10.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, , p. 368–388 (DOI10.1016/j.adhoc.2015.08.030, lire en ligne, consulté le )
(en) Isam Ishaq, Jeroen Hoebeke, Ingrid Moerman et Piet Demeester, « Experimental Evaluation of Unicast and Multicast CoAP Group Communication », Sensors, vol. 16, no 7, , p. 1137 (PMID27455262, PMCID4970179, DOI10.3390/s16071137, lire en ligne, consulté le )
(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, , p. 499–503 (DOI10.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), , p. 79–82 (DOI10.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), , p. 1–6 (DOI10.1109/LANMAN.2011.6076934, lire en ligne, consulté le )
(en) Eleonora Borgia, « The Internet of Things vision: Key features, applications and open issues », Computer Communications, vol. 54, , p. 1–31 (DOI10.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), , p. 270–274 (DOI10.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, , p. 1999–2003 Vol. 3 (DOI10.1109/PIMRC.2005.1651790, lire en ligne, consulté le )
(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), , p. 1–6 (DOI10.1109/iccw.2011.5963563, lire en ligne, consulté le )
(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, no 4, , p. 1795–1805 (ISSN1551-3203, DOI10.1109/TII.2012.2198660, lire en ligne, consulté le )
(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, , p. 5293–5299 (DOI10.1109/IECON.2014.7049308, lire en ligne, consulté le )
(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), , p. 7–11 (DOI10.1109/ADCOM.2014.7103240, lire en ligne, consulté le )
(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), , p. 549–554 (DOI10.1109/ICC.2015.7248379, lire en ligne, consulté le )
(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), , p. 78–83 (DOI10.1109/ICDCSW.2016.13, lire en ligne, consulté le )
(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, , p. 165–169 (DOI10.1109/FIT.2014.39, lire en ligne, consulté le )
(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, , p. 228–231 (DOI10.1109/LCN.2012.6423615, lire en ligne, consulté le )
(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, , p. 555–560 (DOI10.1109/COMPSAC.2016.51, lire en ligne, consulté le )
