Accueil🇫🇷Chercher

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

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

Architecture

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

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.

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.

Format du Message CoAP

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.

Observation

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

Service de découverte

Figure 10
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].


Topologie Distribuée

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

Topologie Centralisée

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.

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

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

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[58] - [59].

Implémentation Language Platform Description
Californium[60] 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[61] 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[62] Javascript Firefox Copper[62] est un plugin Firefox pour la gestion de périphériques CoAP, il permet aux utilisateurs de réaliser des tests.
libcoap[63] C Posix/Contiki La librairie libcoap[63] peut être utilisée pour l'implémentation sur les périphériques de classe 1, 2 et au delà.
CoapBlip[64] C TinyOS C'est une adaptation de la librairie «libcoap[63]» pour TinyOS qui s'adresse aux périphériques de classe 1.
jCoAP[65] Java JVM É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.
coap.me[66] Ruby C'est un outil de test accessible sur un frontal Web à l’adresse[66], il permet de récupérer des serveurs CoAP.
Watteco[67] C Contiki C'est une implémentation commerciale pour les périphériques de classe 1 Contiki basés sur Erbium.
Cooja[68] 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[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Ă©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[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].

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

Automatisation dans le bâtiment

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

Autres domaines d'applications

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.


Performances

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

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[97] dans le tableau suivant :

ThèmesMenaces 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[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]

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


DTLS est un protocole composé deux couches[103]:

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

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

Bibliographie

RFC(s)

Articles

  • (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 (ISSN 1089-7801, DOI 10.1109/MIC.2012.29, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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,‎ (ISSN 1944-0375, DOI 10.1109/LANMAN.2011.6076934) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/ICBDSC.2016.7460363) Document utilisĂ© pour la rĂ©daction de l’article
  • (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,‎ (ISSN 1550-445X, DOI 10.1109/AINA.2016.82) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (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,‎ , 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,‎ , 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, no 82,‎ (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,‎ , p. 183-194 (DOI 10.1016/j.adhoc.2016.07.011) Document utilisĂ© pour la rĂ©daction de l’article
  • (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,‎ (DOI 10.1145/2905055.2905085) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) M. Kovatsch, « CoAP for the web of things: from tiny resource-constrained devices to the web browser », UbiComp’13 Adjunct,‎ (DOI 10.1145/2494091.2497583) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (ISSN 1553-877X, DOI 10.1109/COMST.2015.2444095) Document utilisĂ© pour la rĂ©daction de l’article
  • (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,‎ (DOI 10.1109/DCOSS.2013.14) Document utilisĂ© pour la rĂ©daction de l’article
  • (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,‎ (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,‎ , 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,‎ , 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,‎ , p. 287 - 289 (DOI 10.1109/DCOSS.2012.55) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (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,‎ , 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,‎ (DOI 10.1109/ICCNC.2013.6504105) Document utilisĂ© pour la rĂ©daction de l’article
  • (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,‎ (DOI 10.1109/IMIS.2012.93) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (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,‎ (ISSN 2155-6806, DOI 10.1109/MASS.2011.100) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1016/j.dss.2013.09.009) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (ISSN 1553-877X, DOI 10.1109/SURV.2012.111412.00158) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.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 (ISSN 2327-4662, DOI 10.1109/JIOT.2014.2359538, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1016/j.adhoc.2016.07.011, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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),‎ (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, no 1,‎ (ISSN 1553-877X, DOI 10.1109/SURV.2013.102213.00229) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (PMID 24901978, PMCID 4118386, DOI 10.3390/s140609833) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.3390/jsan2020288) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1016/j.jnca.2014.09.019) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (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,‎ , p. 368–388 (DOI 10.1016/j.adhoc.2015.08.030, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (PMID 27455262, PMCID 4970179, DOI 10.3390/s16071137, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/IBCAST.2014.6778196) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/TELFOR.2015.7377418) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/LANMAN.2011.6076934, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) Eleonora Borgia, « The Internet of Things vision: Key features, applications and open issues », Computer Communications, vol. 54,‎ , p. 1–31 (DOI 10.1016/j.comcom.2014.09.008, lire en ligne) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/ISGT-LA.2015.7381166) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/PIMRC.2005.1651790, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/iccw.2011.5963563, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (ISSN 1551-3203, DOI 10.1109/TII.2012.2198660, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/IECON.2014.7049308, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/ADCOM.2014.7103240, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/ICC.2015.7248379, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/ICDCSW.2016.13, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/FIT.2014.39, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) W. Colitti, K. Steenhaut et N. De Caro, « Integrating Wireless Sensor Networks with the Web » Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/LCN.2012.6423615, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (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 (DOI 10.1109/COMPSAC.2016.51, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article

Notes, Références et Liens externes

Notes

  1. En Anglais, Wireless Sensor Network, «WSN»
  2. En Anglais, low overhead
  3. En Anglais, Embedded Devices
  4. En Anglais, Low Power and Lossy Network : LLN
  5. En Anglais, Token
  6. «TLV», Type Longueur Valeur
  7. CoCoA, Congestion Control/Advanced
  8. En Anglais, end-point
  9. En Anglais, firmware
  10. En Anglais, Border Router
  11. En Anglais, Entity Manager
  12. HEMS, Home Energy Management System
  13. HEC, Home Energy Controller

Références

  1. C. Bormann 2012, p. 66
  2. rfc7252 2014, p. 1
  3. Vilaverde 2012, p. 702
  4. M.Palattella 2013, p. 1400
  5. C.Bormann 2012, p. 64
  6. R A. Raham 2016, p. 3
  7. R A. Raham 2016, p. 4
  8. rfc7252 2014, p. 10
  9. M. Prakash 2016, p. 3
  10. rfc7252 2014, p. 11
  11. M.Palattella 2013, p. 1401
  12. rfc7252 2014, p. 47
  13. S. Bandyopadhyay 2013, p. 336
  14. R A. Raham 2016, p. 1
  15. R A. Raham 2016, p. 2
  16. rfc7252 2014, p. 16
  17. rfc7252 2014, p. 17
  18. rfc7641 2015, p. 5
  19. C.Bormann 2012, p. 65
  20. I. Ishaq 2016, p. 372
  21. rfc7641 2015, p. 7
  22. A. Betzler 2012, p. 3
  23. rfc7641 2015, p. 18
  24. draft CoCoA 2016, p. 1
  25. A. Betzler 2016, p. 185
  26. B. Carballido 2014, p. 41
  27. B. Carballido 2014, p. 44
  28. B. Carballido 2014, p. 47
  29. rfc5785 2012, p. 1
  30. rfc6690 2012, p. 3
  31. B. Carballido 2014, p. 48
  32. rfc6762 2012, p. 1
  33. A. Al-Fuqaha 2015, p. 2357
  34. B. Carballido 2014, p. 50
  35. I. Ishaq 2014, p. 9839
  36. draft-ietf-core-resource-directory-09 2016, p. 5
  37. draft-ietf-core-resource-directory-09 2016, p. 15
  38. B. Carballido 2014, p. 46
  39. rfc6763 2013, p. 1
  40. B. Carballido 2014, p. 49
  41. I. Ishaq 2013, p. 5
  42. I. Ishaq 2014, p. 9840
  43. I. Ishaq 2013, p. 346
  44. rfc7390 2014, p. 1
  45. rfc7252 2014, p. 65
  46. rfc7390 2014, p. 4
  47. rfc7390 2014, p. 6
  48. rfc7731 2016, p. 1
  49. rfc7390 2014, p. 19 & 20
  50. I. Ishaq 2013, p. 6
  51. I. Ishaq 2016, p. 373
  52. I. Ishaq 2014, p. 9844
  53. A. P. . Castellani 2011, p. 1
  54. Web Services And EXI 2011, p. 1799
  55. WebServicesAndEXI 2011, p. 1
  56. A. P. Castellani 2011, p. 3
  57. EXI Low Power Embedded Networks 2011, p. 702
  58. R. Abdul Rahman 2016, p. 4
  59. Vilaverde 2012, p. 706
  60. le site officiel de Califorium
  61. le site officiel d'Erbium
  62. le site officiel de Copper
  63. le site officiel de libcoap
  64. le site du projet CoapBlip
  65. le site du projet jCoAP
  66. le site officiel de coap.me
  67. le site officiel de Watteco
  68. le site officiel de Cooja
  69. M. Kovatsch 2013, p. 1497
  70. C. Bormann 2012, p. 63
  71. Vilaverde 2012, p. 703
  72. R. Abdul Rahman 2016, p. 5
  73. M.Kovatsch 2011, p. 856
  74. M.Kovatsch 2011, p. 858
  75. M.Kovatsch 2011, p. 860
  76. A.Ludovici 2013, p. 301
  77. M.Castro 2016, p. 232
  78. H. A. Khattak 2014, p. 500
  79. D. Ugrenovic 2015, p. 79
  80. H. A. Khattak 2014, p. 499
  81. H. A. Khattak 2014, p. 501
  82. H. A. Khattak 2014, p. 502
  83. G.Belcredi 2015, p. 270
  84. G.Belcredi 2015, p. 272
  85. G.Belcredi 2015, p. 273
  86. Vilaverde 2012, p. 705
  87. Vilaverde 2012, p. 704
  88. B. Borgia 2014, p. 9
  89. T. Leva 2014, p. 33
  90. W. Colitti 2011, p. 1-6
  91. S. H. Shaheen 2014, p. 3
  92. B. Carballido 2014, p. 51
  93. B. Carballido 2014, p. 54
  94. J. Granjal 2012, p. 230
  95. D. H. Mun 2016, p. 556
  96. D. H. Mun 2016, p. 557
  97. R. Martins 2016, p. 1029-1030
  98. (en) Request for comments no 6347.
  99. A. Capossele 2015, p. 550
  100. rfc4347 2005, p. 1
  101. S. H. Shaheen 2014, p. 165
  102. A. Fuentes-Samaniego 2016, p. 79
  103. rfc7925 2005, p. 5
  104. rfc7252 2014, p. 68
  105. rfc4279 2005, p. 1
  106. C. Hennebert 2014, p. 387
  107. V. Lakkundi 2014, p. 8
  108. Shahid Raza 2012, p. 1
  109. draft-ietf-core-coap-12 2012, p. 68
  110. rfc7959 2016, p. 1
  111. P. P. Pereira 2014, p. 5293
  112. P. P. Pereira 2014, p. 5294
  113. draft-bormann-core-coap-block-00 2009, p. 1
  114. Constrained Application Protocol (CoAP)draft-shelby-core-coap-01 2010, p. 1
  115. rfc7252 Historique 2014, p. 1
  116. .rfc7641 2015, p. 1
  117. rfc7959 2016, p. 1

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.