CoAP

CoAP ( Constrained Application Protocol ) è un protocollo di trasferimento web ottimizzato per dispositivi e reti vincolate utilizzate nelle reti di sensori wireless per formare l' Internet delle cose . Basato sullo stile architettonico REST , consente di manipolare, attraverso un modello di interazione client-server , le risorse di comunicazione di oggetti e sensori identificati dagli URI facendo affidamento sullo scambio di richieste-risposte e metodi simili al protocollo HTTP .

Nel 2016, l'uso dei servizi web è comune nelle applicazioni Internet. CoAP estende questo paradigma all'Internet of Things e alle applicazioni M2M che possono così essere sviluppate con servizi web RESTful condivisi e riutilizzabili. Tenendo conto dei vincoli e delle esigenze dell'Internet of Things come il supporto asincrono o multicast . CoAP è destinato a diventare un protocollo applicativo onnipresente nel futuro Internet of Things.

Il protocollo CoAP si trova a livello di applicazione del livello OSI e si basa su UDP per la comunicazione. Implementa un metodo di osservazione delle risorse e fornisce funzioni di rilevamento dei dispositivi per ridurre al minimo l'intervento umano. Implementato con diverse lingue, questo protocollo può essere utilizzato in campi come la salute o la gestione energetica. Offre prestazioni adatte per oggetti con poche risorse e protezione per dati sensibili.

Descrizione

CoAP è stato creato dal gruppo di lavoro CoRE ( Constrained Restful Environment ) e fa seguito al lavoro svolto dall'IETF con la specifica 6LoWPAN che consente alle reti di sensori wireless vincolate di utilizzare il protocollo "IPv6". CoAP consente l'interazione con questi sensori tramite i servizi web RESTful. Questo protocollo è stato sviluppato per dispositivi alimentati a batteria con limitazioni, dotati di microprocessori con prestazioni scadenti e con una quantità limitata di RAM e memoria ROM . Offre semplicità, basso sovraccarico per ambienti di rete a bassa potenza vincolati che devono affrontare tassi di perdita elevati. CoAP abilita le comunicazioni M2M necessarie per l'interazione e il funzionamento dei sistemi di bordo. È definito come un protocollo generico per reti a bassa potenza e con perdite e si basa sui protocolli e sulle reti sottostanti 6LoWPAN, IEEE802.15.4 . Tuttavia, CoAP si differenzia dalla sua controparte HTTP per la sua ridotta complessità con l'utilizzo di UDP che gli consente di avere una dimensione dell'intestazione ridotta, tra 10 e 20 byte facilmente interpretabile da dispositivi vincolati, pur conservando un meccanismo di ritrasmissione in caso di perdita di messaggi. Sviluppato appositamente per ambienti vincolati, fornisce queste caratteristiche principali:

Basso sovraccarico dell'intestazione e ridotta complessità di interpretazione;
Trasporto UDP con livello applicativo unicast affidabile e supporto multicast;
Scambio di messaggi senza stato asincrono;
Possibilità di utilizzo di proxy (facilita l'integrazione con quella esistente) e di caching delle informazioni (dispositivi in standby);
Scoperta e osservazione delle risorse;
Rappresentazione delle risorse URI e supporto per diversi tipi di contenuto.

Architettura

CoAP si basa su un modello client-server simile a HTTP, in cui i client inviano richieste alle risorse REST per recuperare informazioni da un sensore o controllare un dispositivo e il suo ambiente. Tuttavia, CoAP elabora gli scambi in modo asincrono tramite datagrammi UDP. HTTP è un protocollo collaudato, tuttavia la sua implementazione richiede un codice di grandi dimensioni per dispositivi con solo 100 kb di memoria ROM e un elevato utilizzo delle risorse di rete.

Una richiesta CoAP è simile a una richiesta HTTP. Viene inviato dal client per richiedere un'azione GET, POST, PUT o DELETE su una risorsa identificata da un URI . Il server risponde con un codice di risposta eventualmente accompagnato dalla rappresentazione della risorsa.

L'architettura CoAP è divisa in due livelli. Un livello di messaggi che fornisce affidabilità e sequenze di scambio end-to-end basate su UDP. Un livello "Richiesta / Risposta" che utilizza metodi e codici di risposta per le interazioni richiesta / risposta. Tuttavia, è davvero un unico protocollo che offre queste funzionalità nella sua intestazione.

Livello messaggio Il livello Messaggio fornisce affidabilità per i messaggi digitati confermabili . Assicura quindi il controllo end-to-end e la loro ritrasmissione in caso di smarrimento. L'utilizzo di un token consente a CoAP di effettuare l'associazione tra richieste e risposte durante una comunicazione. Mentre una “Etichetta” generata e inserita dal cliente in ciascuna intestazione del messaggio CoAP consente di rilevare i duplicati. Quando i messaggi non richiedono la garanzia di un buon instradamento, è anche possibile, pur beneficiando del rilevamento di duplicati, utilizzare messaggi di tipo Non confermabile . Un server che riceve un messaggio confermabile deve confermare la sua ricezione al client che avvia la connessione e rispondere con un messaggio di riconoscimento digitato ACK . Se il server può fornire la risposta immediatamente, viene aggiunta al messaggio di riconoscimento e la transazione termina. In caso contrario, al client viene restituito un messaggio di riconoscimento vuoto per indicare che la risposta è ritardata. Quando un messaggio confermabile viene inviato al server, il client conta alla rovescia il tempo trascorso e ritrasmette il messaggio periodicamente fino a quando il messaggio non è stato riconosciuto. Se il server non è in grado di elaborare la richiesta, può indicarlo al client rispondendo con un messaggio di tipo RST .

Livello richiesta-risposta CoAP ha i seguenti metodi:

Metodo	Azione
"OTTENERE"	Questo metodo recupera la rappresentazione delle informazioni corrispondenti alla risorsa identificata dalla richiesta URI.
"INVIARE"	Questo metodo richiede l'elaborazione della rappresentazione allegata alla risorsa identificata dalla richiesta URI. Normalmente questo si traduce nella creazione di una nuova risorsa o nel suo aggiornamento.
"METTERE"	Questo metodo richiede che la risorsa identificata dalla query URI venga aggiornata con la rappresentazione allegata. Il formato della rappresentazione è specificato dal tipo di supporto e dalla codifica contenuti nell'opzione Content-Format, se fornita.
"ELIMINA"	Questo metodo richiede che la risorsa identificata dalla richiesta URI venga eliminata.

Le risposte sono identificate da codici di risposta analoghi ai codici di stato di successo del protocollo HTTP 2.xx, errore 4.xx o 5.xx che indicano lo stato dell'operazione.

Successo 2.xx, indica che la richiesta è stata correttamente ricevuta, compresa e accettata. Errore del client 4.xx indica che il client ha riscontrato un errore. Errore interno del server 5.xx indica che il server non è in grado di elaborare la richiesta.

Posizionamento nel modello OSI

CoAP si inserisce in un modello a 5 livelli, fisico, collegamento dati, rete, trasporto e applicazione.

Livello 5 CoAP come protocollo di trasferimento web allo stesso livello del protocollo HTTP, i livelli superiori si trovano all'interno del perimetro del browser web e delle applicazioni M2M. Livello 4 Il livello di trasporto UDP si interfaccia con il sottolivello Message di CoAP. I messaggi vengono inseriti nei datagrammi UDP, il suo utilizzo consente di risparmiare larghezza di banda e fornisce supporto multicast . Livello 3 IPv6, i datagrammi UDP vengono inseriti nei pacchetti IPv6. Il livello 6LowPAN effettua gli adattamenti, per il livello sottostante avente una dimensione del frame limitata a 128 byte. Procede alla compressione degli header IPv6, esegue la frammentazione e il riassemblaggio dei pacchetti IPv6. Ma anche responsabile dell'indirizzamento, del routing. Livello 2 e 1 IEEE 802.15.4 è lo standard che specifica le specifiche Layer 1 e Layer 2 per le reti personali wireless.

Formato messaggio CoAP

I messaggi CoAP vengono trasportati per impostazione predefinita tramite datagrammi UDP. Questa comunicazione può essere trasmessa tramite DTLS ma anche con altri mezzi come SMS, TCP o SCTP. I messaggi sono codificati in un semplice formato binario. Un messaggio inizia con un'intestazione fissa di 4 byte, seguita da un campo “Token” di dimensione variabile tra 0 e 8 byte che consente negli scambi di associare le richieste alle risposte. La sua lunghezza è indicata dal campo "TKL". Viene quindi visualizzata una sequenza di opzioni in formato TLV seguita opzionalmente dai dati che occupano il resto del datagramma. Se questi ultimi sono presenti, sono separati dall'header da un marker di 1 byte contenente il valore “0xFF”.

L'intestazione nella versione 1 contiene le seguenti informazioni

Campo	Descrizione
Worm (versione)	Il campo Ver ha 2 bit, che indicano la versione di CoAP utilizzata.
T (tipo)	Il campo Tipo viene utilizzato per specificare il tipo di messaggio: Confermabile (0): il messaggio richiede una risposta che può essere trasmessa da un messaggio di conferma o inviata in modo asincrono se la richiesta non può essere elaborata immediatamente. In questo casoverrà restituitoun Reset . Nota, un messaggio confermabile può essere sia una richiesta che una risposta che deve essere riconosciuta; Non confermabile (1): il messaggio non richiede alcuna risposta o riconoscimento; Riconoscimento (2): il messaggio conferma la ricezione di un messaggio confermabile . Può facoltativamente contenere la risposta di un messaggio confermabile nel caso in cui la richiesta non possa essere elaborata in modo sincrono, l'ID del messaggio verrà quindi utilizzato per associare la risposta alla richiesta; Reimposta (3): nel caso in cui il messaggio non possa essere elaborato.
TKL (lunghezza token)	è composto da 4 bit, che indicano la lunghezza del campo Token.
Codificato	è composto da 8 bit, di cui i 3 bit più significativi (c) indicano la classe e i 5 bit meno significativi i dettagli (dd). Il codice in formato "c.dd" viene utilizzato per indicare il tipo di messaggio, "0" per una richiesta, "2" per una risposta OK, "4" per una risposta in errore del client, "5" per un errore del server . In caso di richiesta, il codice indica la modalità della richiesta e in caso di risposta, il codice della risposta. Il codice "0.00" indica un messaggio vuoto.
ID messaggio	è composto da 16 bit, utilizzati per rilevare la duplicazione dei messaggi e per abbinare i messaggi di riconoscimento / ripristino ai messaggi di tipo confermabile / non confermabile .
Gettone	è composto da 0 a 8 byte, utilizzato per associare una richiesta a una risposta.

Osservazione

Lo stato di una risorsa può cambiare nel tempo e un client potrebbe aver bisogno di queste modifiche di stato. In HTTP, le transazioni vengono sempre avviate dal client, che esegue più richieste GET per mantenere aggiornato lo stato di una risorsa. Questo meccanismo che consuma risorse non è adatto in un ambiente limitato con risorse di rete limitate e per lo più dispositivi inattivi. Per soddisfare questa esigenza, CoAP beneficia di un'estensione del protocollo RFC7641 che consente ai clienti di osservare le risorse utilizzando l'opzione di osservazione. Un server CoAP è l'autorità per determinare in quali condizioni le risorse cambiano il loro stato e quindi è lui che decide quando informare gli osservatori dei nuovi stati di queste risorse. Poiché il protocollo non offre mezzi espliciti per impostare trigger o soglie, spetta al server esporre risorse osservabili che notificano il loro stato in modo utile nel contesto dell'applicazione. Ad esempio, un server con un sensore di temperatura può esporre una o più risorse. Nel caso in cui una risorsa cambi stato ogni x secondi. Una risorsa può cambiare il suo stato in freddo o caldo in base a soglie corrispondenti o anche in base a espressioni complesse.

Principio di funzionamento

Gli osservatori si registrano presso un soggetto per indicare che desiderano essere informati di ogni cambiamento di stato. Il soggetto è responsabile dell'amministrazione del suo elenco di osservatori registrati. Se l'osservatore è interessato a più argomenti, deve registrarsi separatamente a ciascuno di essi. Un client si registra inviando una richiesta GET estesa con l'opzione "osservare: 0" al server. Il valore "0" è una richiesta di registrazione e il valore "1" corrisponde a una richiesta di annullamento della registrazione. Il server restituisce una notifica 2.xx che indica che ha aggiunto la voce all'elenco degli osservatori. Quando lo stato cambia, il server invia la notifica al client. Il token consente al cliente di identificare le osservazioni nel caso siano multiple. Per evitare la congestione, i server non dovrebbero inviare più di una notifica ogni 3 secondi e dovrebbero usare un valore meno aggressivo se possibile. In futuro sono previste ottimizzazioni come CoCoA (Congestion Control / Advanced) che estende la specifica CoAP con un controllo avanzato della congestione.

Servizio di scoperta

Nell'ambiente machine-to-machine ( M2M ), i dispositivi devono essere in grado di rilevarsi l'un l'altro e le proprie risorse. Questi dispositivi vincolati comunicano tra loro utilizzando comunicazioni wireless a bassa potenza. La sfida è rendere questi dispositivi il più autonomi possibile riducendo al minimo l'intervento umano. Come illustrato, esistono due tipi di servizi di rilevamento per il protocollo CoAP: centralizzato e distribuito.

Topologia distribuita Scoperta CoAP

Distributed Resource Discovery è il metodo di base utilizzato da un dispositivo per rilevare le risorse di un altro dispositivo senza la necessità di una directory. Quando un dispositivo client deve ottenere le risorse ospitate su un server, invia una richiesta GET all'URI /.well-known/core del server RFC5785.

Nel caso di una richiesta unicast perché l'indirizzo del server è noto, solo il server di destinazione risponderà comunicando tutte le sue risorse rilevabili nel formato Core Link RFC6690.

Se il multicast IP è supportato all'interno della rete, è anche possibile inviare una richiesta multicast per scoprire gli endpoint e le relative risorse offerte in un'unica richiesta. Tuttavia, le richieste multicast non sono affidabili perché il client non può sapere se la loro richiesta ha raggiunto tutte le destinazioni. I client possono anche avviare query per tipi specifici di risorse specificando parametri (rt). I server decidono quali sono le loro risorse disponibili da scoprire. Questo metodo di rilevamento distribuito ha il vantaggio che le richieste vengono effettuate direttamente dal client al server senza un intermediario. Ma questo richiede che il client conosca l'indirizzo IP o il nome host del server, il che significa che un'applicazione esterna deve fornire l'indirizzo o dovrà essere codificato nel firmware del client. Nel caso in cui l'indirizzo IP sia sconosciuto, il client può anche inviare una richiesta di discovery del prossimo il cui indirizzo sarà ottenuto dal livello di rete. Tuttavia, questo metodo non è desiderabile per una rete vincolata in cui l'energia deve essere preservata.

mDNS

Il DNS multicast (mDNS) è un protocollo COAP indipendente definito da RFC6762. MDNS è adatto per i dispositivi connessi poiché funziona senza infrastruttura, non è necessario configurare i dispositivi manualmente o utilizzare un'amministrazione aggiuntiva per gestirli. Dopo la scoperta, i dispositivi pubblicano informazioni sui servizi e le risorse che offrono facendo un annuncio multicast. Quando un dispositivo client (ad esempio di tipo switch) vuole accedere a una risorsa (ad esempio di tipo light) utilizzerà le informazioni ottenute (durante la pubblicazione) per accedervi.

Topologia centralizzata

Il gruppo di lavoro CoRE propone l'uso di un'entità Resource Directory (RD) nel LowPAN per l'esplorazione delle risorse.

Directory delle risorse di Coap

La Resource Directory memorizza le descrizioni delle risorse detenute dai server (registrati da loro stessi sul RD). In questo modo i clienti possono scoprire tutte le risorse necessarie in un'unica richiesta. Per utilizzare il DR, sia per la registrazione che per la ricerca, il dispositivo deve sapere come raggiungerlo. L'endpoint può individuare il DR in diversi modi. O il punto terminale ha l'indirizzo dell'RD in statico nel suo firmware e lo scopre all'avvio, o dall'Edge Router che trasmette le informazioni durante l'annuncio del router (ad esempio la route predefinita se l'RD è installato nel router) o utilizzando il CoRE Link Format eseguendo un GET / .well-known / core? rt = core.rd *.

Per quanto riguarda gli aggiornamenti, i server possono aggiornare il proprio record, il DR può verificare se un record è valido interrogando l'endpoint e i record possono essere cancellati dall'endpoint in qualsiasi momento. Il RD può anche eliminare i record al rilevamento di una durata di vita scaduta.

DNS-SD

CoAP e DNS-SD sono allo studio della comunità Internet per il servizio di discovery in reti M2M vincolate. DNS-SD è un protocollo separato definito da RFC6763. DNS-SD definisce come denominare e organizzare i record DNS Per il rilevamento centralizzato del servizio DNS-SD, un server DNS-SD deve essere disponibile all'interno dell'infrastruttura di rete. I dispositivi si registrano nel DNS-SD dopo averlo scoperto con uno dei seguenti metodi: annuncio router IPV6, utilizzando il metodo mDNS descritto in precedenza o con il noto metodo. Dopo la registrazione, qualsiasi dispositivo sarà in grado di cercare servizi tramite query DNS al server DNS-SD.

Comunicazione di gruppo

Il gruppo di lavoro IETF CoRE ha riconosciuto la necessità di supportare l'invio di un messaggio multicast a un gruppo di dispositivi per manipolare le loro risorse. Il lavoro di questo gruppo ha portato alla RFC7390 sperimentale pubblicata per la revisione che descrive la comunicazione di gruppo per il protocollo CoAP. Il vantaggio è che i dispositivi vincolati possono lavorare in gruppo, ad esempio per l'automazione di un edificio dove può essere necessario attivare e / o disattivare contemporaneamente tutte le luci di una stanza. Le richieste vengono inviate in multicast mentre le risposte sono in unicast (aspetto specificato nella sezione 8 di RFC7252). Nessuna modalità di sicurezza è specificata per il multicast CoAP, vale a dire che in questo framework il CoAP non è crittografato, né autenticato e non c'è controllo degli accessi. Il multicast IP è generalmente classificato come un servizio inaffidabile perché non vi è alcuna garanzia di consegna dei pacchetti a ogni membro del gruppo. Tuttavia, la qualità di questo servizio può essere migliorata utilizzando il protocollo multicast per reti a bassa potenza e con perdita (MPL) che esegue ritrasmissioni periodiche. Coap riduce il rischio di congestione multicast con le misure descritte alle pagine 19 e 20 di RFC7390. Ci sono lavori che propongono soluzioni alternative per manipolare facilmente gruppi di risorse attraverso entità gestite da un Entity Manager.

Formato dei dati

I dispositivi di comunicazione vengono indirizzati utilizzando risorse universali (URI) e i dati vengono scambiati tramite XML standard. Il paradigma dei servizi web RESTful presenta molti vantaggi per le reti a bassa potenza rispetto ai servizi web RPC che utilizzano SOAP (e quindi XML ). XML presenta una grande complessità di interpretazione se viene utilizzato nel payload. Sebbene i servizi web abbiano molti vantaggi, i protocolli ei formati di payload utilizzati non sono necessariamente ottimizzati per i dispositivi con limitazioni wireless. Sono state sviluppate molte tecniche di compressione per adattare i dati XML a reti vincolate, ma quella scelta è EXI .

Il formato Efficient XML Interchange (EXI) è una rappresentazione XML compatta, attualmente standardizzata dal World Wide Web Consortium W3C. È progettato per supportare applicazioni XML ad alte prestazioni per ambienti con risorse limitate, riducendo drasticamente i requisiti di larghezza di banda e migliorando le prestazioni di codifica e decodifica. La compressione EXI combina XML con un algoritmo di compressione standard per ottenere tassi di compressione elevati , riducendo la verbosità dei documenti XML. Il lavoro ha dimostrato che l'utilizzo della compressione EXI per il payload può essere fino a 50 volte più efficiente rispetto al semplice utilizzo di XML di base.

Implementazioni pratiche e applicazioni

Esistono molte implementazioni CoAP scritte in diversi linguaggi, forniscono librerie e API che possono essere utilizzate per l'integrazione di CoAP in sensori wireless e lo sviluppo di applicazioni in diversi ambienti.

Implementazione	linguaggio	piattaforma	Descrizione
Californio	Giava	JVM	È un framework Java per dispositivi non vincolati. Consente lo sviluppo di client e applicazioni web in grado di comunicare con reti di sensori wireless.
Erbio	VS	Contiki	Questo è un motore REST leggero per il sistema operativo Contiki. Porta la connettività Internet a dispositivi limitati.
Rame	Javascript	Firefox	Copper è un plugin per Firefox per la gestione dei dispositivi CoAP, consente agli utenti di eseguire test.
libcoap	VS	Posix / Contiki	La libreria libcoap può essere utilizzata per l'implementazione su dispositivi di classe 1, 2 e superiori.
CoapBlip	VS	TinyOS	È un adattamento della libreria "libcoap" per TinyOS che è intesa per le periferiche di classe 1.
jCoAP	Giava	JVM	Scritto in Java, jCoAP è rivolto a dispositivi non vincolati come smartphone Android e sistemi embedded. Consente l'esecuzione di proxy CoAP-to-HTTP e HTTP-to-CoAP che si traduce tra i 2 protocolli.
coap.me	Rubino		È uno strumento di test accessibile su un front-end Web all'indirizzo, consente di ripristinare i server CoAP.
Watteco	VS	Contiki	È un'implementazione commerciale per i dispositivi Contiki Classe 1 basati su Erbio.
Cooja	VS	Contiki	Cooja è uno strumento di simulazione basato sul sistema operativo Contiki, permette simulazioni e test di implementazione.

Queste implementazioni si rivolgono a diversi dispositivi che IETF classifica come segue:

Classe 0 Questi dispositivi non sono in grado di eseguire in modo sicuro uno stack IP conforme a RFC. Devono utilizzare un gateway per connettersi a Internet. Classe 1 Include la maggior parte dei dispositivi che dispongono di risorse limitate in grado di connettersi a Internet con meccanismi di sicurezza incorporati. Hanno 100 kb di ROM e 10 kb di RAM. Non possono implementare uno stack di protocollo HTTP su TLS e richiedono l'uso di protocolli leggeri con un consumo energetico ottimizzato. Con la dimensione molto limitata della loro memoria cache, usano principalmente reti a basso consumo come IEE802.15.4 su 6LowPAN. In virtù delle loro prestazioni e del loro costo contenuto, sono le periferiche preferite per formare l'Internet of Things. Classe 2 Si tratta di dispositivi che possono connettersi a Internet e dispongono di capacità di elaborazione simili agli smartphone. Ciò è reso possibile con circa 250 KB di ROM e 50 KB di RAM. Possono beneficiare dei vantaggi di un protocollo leggero ea basso consumo energetico per liberare risorse sulle loro applicazioni e ridurre i costi di produzione.

La comunità di ricerca ha realizzato molte implementazioni di CoAP. Diversi importanti attori nel campo dell'automazione degli edifici e della misurazione hanno indicato il loro interesse nell'utilizzo di questo protocollo nei loro sistemi di bordo. Questi studi hanno dimostrato la possibilità di implementare il CoAP con solo una decina di kilobyte di memoria ROM e RAM, ma anche di valutarne le prestazioni: tempo di risposta, consumo energetico, sovraccarico. Un'implementazione sul sistema operativo Contiki, evidenzia i guadagni realizzati da CoAP in termini di gestione energetica ma anche che l'uso del protocollo “ ContiMAC RDC ” per ottimizzare i cicli operativi dei componenti radio di consumo porta guadagni simili e solleva la questione. interesse a mantenere i meccanismi di risparmio energetico a livello dei livelli applicativi. L'implementazione CoAP eseguita su Contiki mostra un'occupazione di 8.5 kb di ROM e 1.5 kb di RAM con il layer REST associato. La sperimentazione mostra anche che gli scambi di richieste e risposte sono più efficienti dal punto di vista energetico quando ogni messaggio può essere contenuto in un singolo frame 802.15.4.

La valutazione della libreria CoapBlip evidenzia un problema nel processo di adattamento delle librerie indipendenti dal sistema operativo, che non garantisce quindi prestazioni ed esecuzione affidabile. Un'implementazione nativa per il sistema operativo è molto più efficiente. Le misurazioni mostrano che il carico utile non può superare i 650 byte con CoapBlip quando l'implementazione specifica di TinyCoAP raggiunge i 1200 byte. TinyCoAP è più veloce dell'adattamento CoapBlip, consuma meno energia e può gestire un volume maggiore di richieste

Infine, in diverse implementazioni, le comunicazioni end-to-end con reti di sensori che utilizzano CoAP vengono eseguite tramite un server proxy responsabile dell'adattamento del protocollo. Un approccio diverso è possibile deportando l'elaborazione degli adattamenti al browser Web del client con l'utilizzo di una JVM e JavaScript evitando quindi l'utilizzo di server intermedi.

Applicazioni pratiche

Ci sono molte aree di applicazione. Il CoAP è stato implementato con successo in esperimenti nei settori della salute, della gestione energetica e dell'edilizia.

Sistema di sorveglianza sanitaria

In ambito sanitario, una delle applicazioni pratiche è la realizzazione di un sistema di monitoraggio sanitario con una rete di sensori wireless basati su CoAP al fine di ridurre il carico di lavoro dei centri medici che effettuano le analisi e facilitare la rapida cura del paziente in un'emergenza. Questa infrastruttura monitora le condizioni di salute del paziente e consente l'accesso a parametri importanti in qualsiasi momento con un browser web da qualsiasi luogo. Ciò consente ai pazienti che non si trovano in condizioni critiche di lasciare l'ospedale, poiché i loro segni vitali possono essere monitorati in tempo reale da casa. CoAP consente di modellare le proprietà dei sensori sanitari come risorse e di esporli ai clienti. Queste risorse vengono quindi manipolate utilizzando metodi HTTP tramite un browser web.

In una rete di sensori wireless basata su CoAP, ognuno può comportarsi come un server ed esporre il percorso di una risorsa " /.well-known/core " per consentire il rilevamento delle risorse da parte dei client. Questi ultimi accedono a questo percorso tramite un metodo "POST" per dichiarare le proprie risorse, oppure un metodo "GET" per scoprire le risorse già dichiarate. L'opzione Observe quando viene utilizzata con un metodo "GET" consente ai client di indicare il loro interesse per una risorsa, in caso di aggiornamento di questa risorsa, il server avvisa in modo asincrono i client. Nell'esperimento, i tradizionali sensori responsabili del controllo della frequenza cardiaca, della saturazione di ossigeno nel sangue e degli elettrocardiogrammi sono collegati a periferiche vincolate come “Telos Mote” tramite un collegamento seriale su cui è installato il Contiki OS. L'implementazione Erbium con il suo motore REST è responsabile dell'esposizione delle risorse di ciascun sensore. Nel caso di un sensore che monitora la frequenza cardiaca ed espone le sue risorse all'indirizzo "coap: // server / oximeter / hrs". Il client invia una richiesta contenente un metodo "GET" con "uri-host = server" e "uri-path = / oximeter / hrs" per recuperare la frequenza cardiaca del paziente e futuri aggiornamenti. Le informazioni ottenute dai sensori del paziente vengono trasmesse al web server in formato JSON , quindi archiviate e utilizzate dal personale medico.

Sistema di gestione dell'energia intelligente, Smart Grid

Una rete di distribuzione elettrica intelligente mira a ottimizzare la produzione, la distribuzione e il consumo di energia. L'implementazione di un sistema di gestione dell'energia domestica in grado di interagire con le apparecchiature domestiche e dialogare con una smart grid consente di controllare i consumi e di ottenere risparmi energetici. Il sistema è costituito da un sistema di gestione energetica domestica denominato HEMS installato nell'abitazione basato su una soluzione gratuita, e da una rete di attuatori e sensori denominati HEC che utilizzano il protocollo CoAP collegati ad apparecchiature domestiche. Gli HEC collegati alla rete locale dell'abitazione recuperano il consumo energetico: tensione, potenza istantanea delle apparecchiature collegate. Questi dati vengono inviati in modo asincrono all'HEMS , grazie al meccanismo di osservazione CoAP. Questi vengono elaborati da algoritmi di ottimizzazione energetica eseguiti sul sistema HEMS, che può quindi controllare le risorse HEC tramite metodi CoAP per richiederne l'accensione o lo spegnimento.

Automazione degli edifici

Nel campo della building automation. Le risorse gestite dai protocolli storici BacNet , LON possono essere adattate per funzionare con CoAP, i messaggi storici possono essere veicolati nel payload dei messaggi CoAP. Con il supporto del multicast e della comunicazione di gruppo, un dispositivo può comunicare con altri dispositivi che condividono le stesse caratteristiche (ad esempio: indirizzamento di tutti i dispositivi in una stanza).

Altri campi di applicazione

CoAP può essere utilizzato anche in aree di applicazione come trasporti, industria, agricoltura, casa.

Prestazione

Le diverse implementazioni evidenziano i seguenti punti:

Consumo energetico efficiente grazie alla ridotta testata CoAP. L'utilizzo di quest'ultimo è più efficiente rispetto alla sua controparte HTTP e più adatto alle reti di sensori wireless;

La compressione EXI (Compact Representation of XML) associata a CoAP è un approccio più efficiente dal punto di vista energetico rispetto alla combinazione CoAP / XML. Ciò si traduce in una minore complessità, risparmi in termini di larghezza di banda e una più facile interpretazione;

Latenza ridotta grazie all'uso di UDP;

Finanziariamente, altri studi dimostrano che la scelta di utilizzare CoAP risulta essere una scelta saggia rispetto a HTTP:

la funzione Osserva del CoAP consente di risparmiare la batteria di un oggetto connesso: esso va a dormire al termine della sua sessione di connessione e si riattiva ad ogni nuova sessione;
la semplicità della specifica CoAP rispetto a HTTP può portare a risparmi sui costi di sviluppo software grazie all'implementazione più rapida e semplice di CoAP;
Il basso traffico generato da CoAP si traduce anche in un basso consumo di volume di traffico, risparmiando sui costi di connettività (paragrafo 5.2). Lo studio rivela che una soluzione CoAP di 10.000 oggetti connessi richiede 64 GB di dati e più di 400 GB per una soluzione CoAP / HTTP.

Il lavoro svolto confronta le prestazioni di CoAP con il suo predecessore, HTTP. I tempi di risposta CoAP sono molto più brevi di HTTP con un risparmio stimato di tempo di risposta di circa il 30%, grazie alla compressione dell'intestazione e al fatto che CoAP utilizza UDP. La compressione dell'intestazione avrà anche un impatto sul consumo energetico. Il numero di byte trasferiti è inferiore in una transazione CoAP rispetto a una transazione HTTP

A livello dei protocolli di discovery CoAP, il meccanismo distribuito surclassa il meccanismo centralizzato relativo al sovraccarico in quanto la discovery di RD (Resource Discovery) e le varie fasi di registrazione non vengono effettuate. Per quanto riguarda i protocolli di discovery DNS, sono meno efficienti in termini di sovraccarico rispetto al protocollo CoAp. In effetti, la scoperta CoAP è l'approccio più ragionevole in un ambiente con dispositivi a basso consumo di energia limitato.

Il processo di protezione dei flussi in CoAP non è privo di impatto sulla memoria ROM dell'apparecchiatura quando la crittografia dei dati viene eseguita in modo hardware e anche l'uso della RAM a più dell'80% può essere un problema perché ciò potrebbe impedire il corretto funzionamento di altre applicazioni in esecuzione sull'apparecchiatura.

Le prestazioni del protocollo di rete svolgono un ruolo importante nel consumo energetico e CoAP dipende da queste prestazioni a causa del protocollo di trasporto sottostante UDP, della frequente frammentazione dei pacchetti e dei semplici meccanismi di ritrasmissione. Il consumo energetico in CoAP aumenta quando la dimensione del pacchetto diventa maggiore di 1024 byte a causa della frammentazione.

sicurezza

I dispositivi che utilizzano il protocollo CoAP devono essere in grado di proteggere il flusso di informazioni di natura sensibile (ad esempio per il settore sanitario). La sicurezza efficace in CoAP può essere riassunta nei diversi temi presentati nella tabella seguente:

Temi	Minacce associate
Integrità	Download di codice dannoso
Disponibilità	Denial of Service ( DoS )
Riservatezza	Analisi del traffico Intercettazioni (intercettazioni)

Per proteggere i flussi di COAP, DTLS , Datagram Transport Layer Security, il protocollo di sicurezza principale degli oggetti che è stato specificato da IETF in RFC 6347, è stato progettato per la comunicazione sicura end-to-end tra due dispositivi. DTLS è una versione di TLS e assume le funzionalità di quest'ultimo ma utilizzerà il livello di trasporto fornito da UDP a differenza di TLS che utilizza TCP .

Rappresentazione DTLS nello stack del protocollo

CoAP
Sicurezza - DTLS
Livello di trasporto - UDP
Livello di rete - IPV6
Livello fisico - IEEE 802.15.4

DTLS è un protocollo composto da due livelli:

il livello inferiore "Record Protocol" che fornisce una crittografia a chiave simmetrica sicura per garantire la riservatezza e / o l'integrità del messaggio;

Il livello superiore comprende quattro protocolli che si occuperanno dell'autenticazione dell'host, della segnalazione degli errori e della crittografia dei dati.

I dispositivi IoT basati su CoAP sono configurati in una delle seguenti 4 modalità di sicurezza:

NoSec: non c'è sicurezza a livello di protocollo. DTLS è disabilitato;
PreSharedKey: DTLS è abilitato, c'è un elenco di chiavi precondivise (RFC4279) e ogni chiave include un elenco di nodi;
RawPublicKey: DTLS è abilitato e il dispositivo ha una coppia di chiavi asimmetriche senza certificato;
Certificato: DTLS è abilitato e il dispositivo ha una coppia di chiavi asimmetriche con un certificato X.509 .

In modalità "NoSec", il sistema è protetto solo bloccando l'invio o la ricezione di pacchetti in rete da parte di un malintenzionato e semplicemente invia i pacchetti tramite UDP.

CoAP si basa sui comandi URI "coap" o "coaps" - quando viene utilizzato DTLS - per identificare le risorse e la loro posizione. L'uso di "coaps" implica che i datagrammi UDP siano protetti con DTLS. Le risorse disponibili tramite "coap" non sono condivise con "coap" anche se il loro identificativo di risorsa è identico.

CoaP essendo per definizione un protocollo limitato, il suo utilizzo con DTLS così com'è pone un problema perché è stato progettato per le reti di computer tradizionali.

DTLS è un protocollo pesante e le sue intestazioni sono troppo lunghe per essere contenute in un singolo frame IEEE802.15.4. Per superare i problemi di compatibilità, 6LoWPAN , il livello di rete su cui si basa CoAP, fornisce meccanismi di compressione delle intestazioni per ridurre le dimensioni delle intestazioni del livello superiore (DTLS).

IPSec , il protocollo di sicurezza dello stack IP, può essere utilizzato per proteggere i flussi CoAP in ambienti vincolati e più in particolare ESP quando CoAP viene utilizzato senza DTLS.
L'utilizzo di IPsec tra gli endpoint CoAP è trasparente al livello dell'applicazione e non richiede condizioni speciali per l'implementazione in CoAP. Tuttavia, IPsec potrebbe non essere adatto a tutti gli ambienti: firewall e NAT possono limitare notevolmente l'uso di IPsec
.

L'utilizzo di un meccanismo di protezione come DTLS è essenziale per le reti e i sistemi CoAP, ma non forniscono il controllo degli accessi. L'uso del controllo degli accessi su un dispositivo CoAP può autorizzare l'accesso in LETTURA / SCRITTURA ai suoi servizi a un gruppo di utenti mentre autorizza solo l'accesso SOLO IN LETTURA a un altro gruppo. Ciò aggiunge un altro livello di protezione e quindi aumenta la sicurezza a livello dei flussi CoAP.

Storico

Il gruppo di lavoro CoRE, Constrained RESTFul Environment, ha creato il protocollo CoAP come risultato del lavoro del gruppo di lavoro 6LoWPAN . L'obiettivo di CoAP è quello di estendere l'architettura WEB alle applicazioni Machine to Machine (M2M) e Internet of Things (IoT) utilizzando sistemi vincolati.I servizi Web su Internet sono elementi essenziali nella maggior parte delle applicazioni e dipendono dall'architettura REST. Per rendere questo possibile, CORE ha definito il protocollo CoAP, Constrained Application Protocol. Questo protocollo consente la comunicazione tra oggetti collegati in un'architettura vincolata. Il protocollo CoAP si rivolge ad apparecchiature e macchine che a volte hanno solo un microcontrollore con processore a 8 bit con poca memoria e che sono collegate da collegamenti radio lenti e inaffidabili, i LowPAN.
CoAP è in continua evoluzione. Il protocollo si arricchisce di estensioni come Observe, Group communication ...

Dicembre 2009 Le basi del protocollo (draft-bormann-core-coap-block-00). Maggio 2010 Specifiche del protocollo (Constrained Application Protocol (CoAP) draft-shelby-core-coap-01). 2010-2014 Evoluzione del protocollo (le diverse versioni draft-ietf-core-coap dalla 00 alla 18). Giugno 2014 Creato da RFC7252 The Constrained Application Protocol (CoAP). Ottobre 2014 Creazione RFC7390 Group Communication for the Constrained Application Protocol (CoAP). Settembre 2015 RFC7641 Osservazione delle risorse nel protocollo dell'applicazione vincolata. Agosto 2016 RFC7959 Trasferimenti in base al blocco nel protocollo CoAP (Constrained Application Protocol).

Bibliografia

RFC

(en) " CoAP Feature Analysis draft-shelby-6lowapp-coap-00 " , su ietf.org ,dicembre 2009
(en) " Constrained Application Protocol (CoAP) draft-shelby-core-coap-01 " , su ietf.org ,Maggio 2010
(en) " draft-bormann-core-coap-block-00: Blockwise Transfer in CoAP " , su sandbox.ietf.org ,agosto 2010
(en) " draft-ietf-core-resource-directory-09: CoRE Resource Directory " , su tools.ietf.org ,ottobre 2016
(en) " RFC4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) " , su ietf.org ,dicembre 2005
(en) " RFC4347: Datagram Transport Layer Security " , su ietf.org ,Aprile 2006
(en) " RFC5785: Defining Well-Known Uniform Resource Identifiers (URIs) " , su tools.ietf.org ,aprile 2010
(en) " RFC5988: Web Linking " , su tools.ietf.org ,ottobre 2010
(en) " RFC6690: Constrained RESTful Environments (CoRE) Link Format " , su tools.ietf.org ,Agosto 2012
(en) " RFC6762: Multicast DNS " , su tools.ietf.org ,Febbraio 2013
(en) " RFC6763: DNS-Based Service Discovery " , su tools.ietf.org ,Febbraio 2013
(en) " History RFC7252 CoAP) " , su ietf.org ,giugno 2014
(en) " RFC7252: The Constrained Application Protocol (CoAP) " , su ietf.org ,giugno 2014
(en) " RFC7341: DHCPv4-over-DHCPv6 (DHCP 4o6) Transport " , su ietf.org ,Aprile 2006
(en) " RFC7390: Group Communication for the Constrained Application Protocol (CoAP) " , su ietf.org ,ottobre 2014
(en) " RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) " , su tools.ietf.org ,settembre 2015
(en) " RFC7731: Multicast Protocol for Low-Power and Lossy Networks (MPL) " , su tools.ietf.org ,febbraio 2016
(en) " RFC7925: Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things " , su ietf.org ,luglio 2016
(en) " RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) " , su ietf.org ,agosto 2016
(en) " Constrained Application Protocol draft-ietf-core-coap-12 " , su ietf.org ,ottobre 2012
(en) " Constrained RESTful Environments (core) - " , su datatracker.ietf.org (visitato il 9 dicembre 2016 )
(en) " RFC4303: IP Encapsulating Security Payload (ESP) - " , su www.ietf.org (visitato il 15 novembre 2016 )
(en) " CoAP Simple Congestion Control / Advanced draft-ietf-core-cocoa-00 " , su www.ietf.org (accesso 15 novembre 2016 )
(it) " Internet Protocol " , su ietf.org ,Settembre 1981

Articoli

(en) C. Bormann , AP Castellani e Z. Shelby , " CoAP: An Application Protocol for Billions of Tiny Internet Nodes " , IEEE Internet Computing , vol. 16, n o 21 ° marzo 2012, p. 62-67 ( ISSN 1089-7801 , DOI 10.1109 / MIC.2012.29 , letto online , accesso 9 dicembre 2016 )
(en) W. Colitti , K. Steenhaut , N. De Caro , B. Buta e V. Dobrota , " Evaluation of constrained application protocol for wireless sensor networks " , Local & Metropolitan Area Networks (LANMAN), 2011 18th IEEE Workshop on ,Marzo-aprile 2011( ISSN 1944-0375 , DOI 10.1109 / LANMAN.2011.6076934 )

( fr ) Reem Abdul. Raham e B. Shah , " Security analysis of IoT protocols: A focus in CoAP " , 2016 3rd MEC International Conference on Big Data and Smart City (ICBDSC) ,marzo 2016, p. 1-7 ( DOI 10.1109 / ICBDSC.2016.7460363 )

(en) R. Martins , V. Schaurich , L. Knob , J. Wickboldt , A. Filho , L. Granville e M. Pias , " Performance Analysis of 6LoWPAN and CoAP for Secure Communications in Smart Homes " , Advanced Information Networking and Applicazioni (AINA), 30a conferenza internazionale IEEE 2016 su ,marzo 2016( ISSN 1550-445X , DOI 10.1109 / AINA.2016.82 )

(en) A. Betzler , C. Gomez , I. Demirkol e J. Paradells , " CoCoA +: Un meccanismo avanzato di controllo della congestione per CoAP " , Ad Hoc Networks , vol. 33,aprile 2015, p. 126-139 ( DOI 10.1016 / j.adhoc.2015.04.007 )

(en) Angelo P. Castellani , M. Rossi e M. Zorzi , “ Controllo della congestione della contropressione per reti CoAP / 6LoWPAN ” , Ad Hoc Networks , vol. 18,Marzo 2013, p. 71-84 ( DOI 10.1016 / j.adhoc.2013.02.007 )

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

(en) F. Abeele , J. Hoebeke , I. Ishaq , Girum K. Teklemariam , J. Rossey , I. Moerman e P. Demeester , " Building embedded applications via REST services for the internet of things " , Atti dell'undicesimo ACM Conference on Embedded Networked Sensor Systems , n ° 82,novembre 2013( DOI 10.1145 / 2517351.2517426 )

(en) A. Betzler , J. Isern , C. Gomez , I. Dermirkol e J. Paradells , " Valutazione sperimentale del controllo della congestione per comunicazioni CoAP senza affidabilità end-to-end " , Ad Hoc Networks , vol. 52,dicembre 2016, p. 183-194 ( DOI 10.1016 / j.adhoc.2016.07.011 )

(en) M. Prakash e CJ KavithaPriya , " An Analysis of Types of Protocol Implemented in Internet of Things Based on Packet Loss Ratio " , ICTCS '16 , n . 27,marzo 2016( DOI 10.1145 / 2905055.2905085 )

(en) M. Kovatsch , " CoAP per il web delle cose: dai piccoli dispositivi con risorse limitate al browser web " , UbiComp'13 Adjunct ,settembre 2013( DOI 10.1145 / 2494091.2497583 )

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

(en) I. Ishaq , J. Hoebeke , F. Van Den Abeele , I. Moerman e P. Demeester , " Group Communication in Constrained Environments Using CoAP-based Entities " , Distributed Computing in Sensor Systems (DCOSS), 2013 IEEE International Conferenza su ,maggio 2013( DOI 10.1109 / DCOSS.2013.14 )

(en) Shahid Raza , Simon Duquennoy , Tony Chung , Dogan Yazar , Thiemo Voigt e Utz Roedig , " Securing communication in 6LoWPAN with compressed IPsec " , Distributed Computing in Sensor Systems and Workshops (DCOSS), 2011 International Conference on ,agosto 2011( DOI 10.1109 / DCOSS.2011.5982177 )

(en) Ajit A. Chavan e Mininath K. Nighot , " Protocollo a livello di applicazione sicuro ed economico con interoperabilità di autenticazione per IOT " , Elsevier Science Direct Freedom Collection , vol. 78,dicembre 2015, p. 646 - 651 ( DOI 10.1016 / j.procs.2016.02.112 )

(it) Shahid Raza , Hossein Shafagh , Kasun Hewage , René Hummen e Thiemo Voigt , " Lithe: Lightweight Secure CoAP for the Internet of Things " , IEEE Sensors Journal , vol. 13,Agosto 2013, p. 3711 - 3720 ( DOI 10.1109 / JSEN.2013.2277656 )

(en) Shahid Raza , Daniele Trabalza e Thiemo Voigt , " 6LoWPAN Compressed DTLS for CoAP " , Distributed Computing in Sensor Systems (DCOSS), 2012 IEEE 8th International Conference on ,Maggio 2012, p. 287-289 ( DOI 10,1109 / DCOSS.2012.55 )

(en) Sye Loong Keoh , Sandeep S. Kumar e Hannes Tschofenig , " Securing the Internet of Things: A Standardization Perspective " , IEEE Internet of Things Journal , vol. 1,giugno 2014, p. 265-275 ( DOI 10,1109 / JIOT.2014.2323395 )

(en) Stefanie Gerdes , Olaf Bergmann e Carsten Bormann , " Delegated Authenticated Authorization for Constrained Environments " , Network Protocols (ICNP), 2014 IEEE 22nd International Conference on ,ottobre 2014, p. 654 - 659 ( DOI 10.1109 / ICNP.2014.104 )

(en) S Bandyopadhyay e A Bhattacharyya , " Protocolli Internet leggeri per l'abilitazione al web di sensori che utilizzano dispositivi gateway vincolati " , Computing, Networking and Communications (ICNC), 2013 International Conference on ,Gennaio 2013( DOI 10.1109 / ICCNC.2013.6504105 )

(en) B Villaverde , D Pesch , R Alberola , S Fedor e 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 , Oltre a questo, devi saperne di più.Luglio 2012( DOI 10.1109 / IMIS.2012.93 )

(en) M. Castra , A. Jara e A. Skarmeta , " Abilitazione delle comunicazioni basate su CoAP end-to-end per il Web delle cose " , Journal of Network and Computer Applications , vol. 59,gennaio 2016, p. 230-236 ( DOI 10.1016 / j.jnca.2014.09.019 )

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

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

( pollici ) MP. Palattella , N. Accettura , X. Vilajosana , T. Watteyne , LA. Grieco , G. Boggia e M. Dohler , " Stack di protocollo standardizzato per Internet di cose (importanti) " , IEEE Communications Surveys & Tutorials , vol. 15, n o 3,Dicembre 2012, p. 1389-1406 ( ISSN 1553-877X , DOI 10.1109 / SURV.2012.111412.00158 )
(en) G. Ketema , J. Hoebeke , I. Moerman e P. Demeester , " Efficiently Observing Internet of Things Resources " , 2012 IEEE International Conference on Green Computing and Communications (GreenCom) ,1 ° novembre 2012, p. 446–449 ( DOI 10.1109 / GreenCom.2012.70 , letto online , accesso 21 novembre 2016 )
(en) C. Hennebert e JD Santos , " Security Protocols and Privacy Issues into 6LoWPAN Stack: A Synthesis " , IEEE Internet of Things Journal , vol. 1, n o 5,1 ° ottobre 2014, p. 384–398 ( ISSN 2327-4662 , DOI 10.1109 / JIOT.2014.2359538 , letto online , accesso 22 novembre 2016 )
(en) August Betzler , Javier Isern , Carles Gomez e Ilker Demirkol , " Valutazione sperimentale del controllo della congestione per comunicazioni CoAP senza affidabilità end-to-end " , reti ad hoc , modellazione e valutazione delle prestazioni delle reti wireless ad hoc, vol. 52,1 ° dicembre 2016, p. 183–194 ( DOI 10.1016 / j.adhoc.2016.07.011 , letto online , accesso 23 novembre 2016 )
(en) J. Pradilla , R. González , M. Esteve e C. Palau , " Sensor Observation Service (SOS) / Constrained Application Protocol (CoAP) proxy design " , 2016 18th Mediterranean Electrotechnical Conference (MELECON) ,1 ° aprile 2016( DOI 10.1109 / MELCON.2016.7495411 )
(en) B. Carballido Villaverde , RDP Alberola , AJ Jara e S. Fedor , " Service Discovery Protocols for Constrained Machine-to-Machine Communications " , IEEE Communications Surveys Tutorials , vol. 16, n o 1,1 ° gennaio 2014( ISSN 1553-877X , DOI 10.1109 / SURV.2013.102213.00229 )
(en) Isam Ishaq , Jeroen Hoebeke , Floris Van den Abeele e Jen Rossey , " Flexible Unicast-Based Group Communication for CoAP-Enabled Devices " , Sensors , vol. 14, n o 6,4 giugno 2014, p. 9833–9877 ( PMID 24901978 , PMCID 4118386 , DOI 10.3390 / s140609833 )
(en) Alessandro Ludovici , Pol Moreno e Anna Calveras , " TinyCoAP: A Novel Constrained Application Protocol (CoAP) Implementation for Embedding RESTful Web Services in Wireless Sensor Networks Based on TinyOS " , Journal of Sensor and Actuator Networks , vol. 2 n o 214 maggio 2013, p. 288–315 ( DOI 10.3390 / jsan2020288 )
(en) Miguel Castro , Antonio J. Jara e Antonio F. Skarmeta , " Abilitazione delle comunicazioni basate su CoAP end-to-end per il Web delle cose " , Journal of Network and Computer Applications , vol. 59,1 ° gennaio 2016, p. 230–236 ( DOI 10.1016 / j.jnca.2014.09.019 )
(en) Miguel Castro , Antonio J. Jara e Antonio F. Skarmeta , " Abilitazione delle comunicazioni basate su CoAP end-to-end per il Web delle cose " , Journal of Network and Computer Applications , vol. 59,1 ° gennaio 2016, p. 230–236 ( DOI 10.1016 / j.jnca.2014.09.019 )
(en) Isam Ishaq , Jeroen Hoebeke , Ingrid Moerman e Piet Demeester , " Osservare i gruppi CoAP in modo efficiente " , Ad Hoc Networks , vol. 37, parte 2,1 ° febbraio 2016, p. 368–388 ( DOI 10.1016 / j.adhoc.2015.08.030 , letto online , accesso 5 dicembre 2016 )
(en) Isam Ishaq , Jeroen Hoebeke , Ingrid Moerman e Piet Demeester , " Experimental Evaluation of Unicast and Multicast CoAP Group Communication " , Sensors , vol. 16, n o 7,21 luglio 2016, p. 1137 ( PMID 27455262 , PMCID 4970179 , DOI 10.3390 / s16071137 , letto online , accesso 6 dicembre 2016 )
(en) HA Khattak , M. Ruta , E. Di Sciascio e D. Sciascio , " CoAP-based healthcare sensor networks: A survey " , Proceedings of 2014 11th International Bhurban Conference on Applied Sciences Technology (IBCAST) Islamabad, Pakistan, 14th - 18 gennaio 2014 ,1 ° gennaio 2014, p. 499–503 ( DOI 10.1109 / IBCAST.2014.6778196 )
(en) D. Ugrenovic e G. Gardasevic , " Protocollo CoAP per il monitoraggio basato sul Web nelle applicazioni sanitarie IoT " , 2015 23rd Telecommunications Forum Telfor (℡FOR) ,1 ° novembre 2015, p. 79–82 ( DOI 10.1109 / TELFOR.2015.7377418 )
(en) W. Colitti , K. Steenhaut , N. De Caro e B. Buta , " Evaluation of constrained application protocol for wireless sensor networks " , 2011 18th IEEE Workshop on Local Metropolitan Area Networks (LANMAN) ,1 ° ottobre 2011, p. 1–6 ( DOI 10.1109 / LANMAN.2011.6076934 , letto online , accesso 8 dicembre 2016 )
(en) Eleonora Borgia , “ The Internet of Things vision: Key features, applications and open issues ” , Computer Communications , vol. 54,2014, p. 1–31 ( DOI 10.1016 / j.comcom.2014.09.008 , leggi online )
(en) G. Belcredi , P. Modernell , N. Sosa e L. Steinfeld , " An implementation of a home energy management platform for Smart Grid " , 2015 IEEE PES Innovative Smart Grid Technologies Latin America (ISGT LATAM) ,1 ° ottobre 2015, p. 270-274 ( DOI 10.1109 / ISGT-LA.2015.7381166 )
(en) Kihong Kim , Jinkeun Hong , Yongick Jung e Sangyi Yi , " Nuovo protocollo di ripresa della sessione sicura utilizzando il conteggio IV per le reti wireless " , 2005 IEEE 16 ° simposio internazionale sulle comunicazioni radio personali, interne e mobili , vol. 3,1 ° settembre 2005, p. 1999-2003 Vol. 3 ( DOI 10.1109 / PIMRC.2005.1651790 , letto online , accesso 8 dicembre 2016 )
(en) AP Castellani , M. Gheda , N. Bui e M. Rossi , " Web Services for the Internet of Things through CoAP and EXI " , 2011 IEEE International Conference on Communications Workshops (ICC) ,1 ° giugno 2011, p. 1–6 ( DOI 10.1109 / iccw.2011.5963563 , letto online , accesso 8 dicembre 2016 )
(en) G. Moritz , F. Golatowski , C. Lerche e D. Timmermann , " Beyond 6LoWPAN: Web Services in Wireless Sensor Networks " , IEEE Transactions on Industrial Informatics , vol. 9, n o 4,1 ° novembre 2013, p. 1795-1805 ( ISSN 1551-3203 , DOI 10.1109 / TII.2012.2198660 , letto online , accesso 8 dicembre 2016 )
(en) PP Pereira , J. Eliasson e J. Delsing , " An authentication and access control framework for CoAP-based Internet of Things " , IECON 2014 - 40th Annual Conference of the IEEE Industrial Electronics Society ,1 ° ottobre 2014, p. 5293–5299 ( DOI 10.1109 / IECON.2014.7049308 , letto online , accesso 8 dicembre 2016 )
(en) V. Lakkundi e K. Singh , " Implementazione leggera di DTLS nell'Internet delle cose basato su CoAP " , 20a conferenza internazionale annuale sull'informatica e le comunicazioni avanzate (ADCOM) ,1 ° settembre 2014, p. 7-11 ( DOI 10.1109 / ADCOM.2014.7103240 , letto online , accesso 9 dicembre 2016 )
(en) A. Capossele , V. Cervo , G. De Cicco e C. Petrioli , " Security as a CoAP resource: An optimised DTLS implementation for the IoT " , 2015 IEEE International Conference on Communications (ICC) ,1 ° giugno 2015, p. 549-554 ( DOI 10.1109 / ICC.2015.7248379 , letto online , accesso 11 dicembre 2016 )
(en) RA Fuentes-Samaniego , AR Cavalli e JA Nolazco-Fores , " An Analysis of Secure M2M Communication in WSNs Using DTLS " , 2016 IEEE 36th International Conference on Distributed Computing Systems Workshops (ICDCSW) ,1 ° giugno 2016, p. 78-83 ( DOI 10.1109 / ICDCSW.2016.13 , letto online , accesso 11 dicembre 2016 )
(en) SH Shaheen e M. Yousaf , " Security Analysis of DTLS Structure and Its Application to Secure Multicast Communication " , 2014 12th International Conference on Frontiers of Information Technology ,1 ° dicembre 2014, p. 165-169 ( DOI 10.1109 / FIT.2014.39 , letto online , accesso 11 dicembre 2016 )
(en) W. Colitti , K. Steenhaut e N. De Caro , " Integrating Wireless Sensor Networks with the Web "
(en) J. Granjal , E. Monteiro e J. Sá Silva , " Sulla fattibilità di comunicazioni sicure a livello di applicazione sul Web delle cose " , 37a conferenza annuale IEEE sulle reti di computer locali ,1 ° ottobre 2012, p. 228-231 ( DOI 10.1109 / LCN.2012.6423615 , letto online , accesso 12 dicembre 2016 )
(en) DH Mun , ML Dinh e YW Kwon , " An Assessment of Internet of Things Protocols for Resource-Constrained Applications " , 2016 IEEE 40th Annual Computer Software and Applications Conference (COMPSAC) , vol. 1,1 ° giugno 2016, p. 555-560 ( DOI 10.1109 / COMPSAC.2016.51 , letto online , accesso 12 dicembre 2016 )

Note, riferimenti e collegamenti esterni

Appunti

In inglese, Wireless Sensor Network, "WSN"
In inglese, sovraccarico basso
In inglese, dispositivi incorporati
In inglese, Low Power and Lossy Network: LLN
In inglese, Token
"TLV", digitare il valore della lunghezza
CoCoA, Congestion Control / Advanced
In inglese, end-point
In inglese, firmware
In inglese, Border Router
In inglese, Entità Responsabile
HEMS, Sistema Home Energy Management
HEC, casa Energy Controller

Riferimenti

C. Bormann 2012 , p. 66
rfc7252 2014 , p. 1
Vilaverde 2012 , p. 702
M. Palattella 2013 , p. 1400
C. Bormann 2012 , p. 64
R A. Raham 2016 , pag. 3
R A. Raham 2016 , pag. 4
rfc7252 2014 , p. 10
M. Prakash 2016 , p. 3
rfc7252 2014 , p. 11
M. Palattella 2013 , p. 1401
rfc7252 2014 , p. 47
S. Bandyopadhyay 2013 , p. 336
R A. Raham 2016 , p. 1
R A. Raham 2016 , p. 2
rfc7252 2014 , p. 16
rfc7252 2014 , p. 17
rfc7641 2015 , p. 5
Bormann 2012 , p. 65
I. Ishaq 2016 , p. 372
rfc7641 2015 , pag. 7
A. Betzler 2012 , p. 3
rfc7641 2015 , p. 18
Bozza CoCoA 2016 , p. 1
A. Betzler 2016 , p. 185
B. Carballido 2014 , p. 41
B. Carballido 2014 , p. 44
B. Carballido 2014 , p. 47
rfc5785 2012 , p. 1
rfc6690 2012 , p. 3
B. Carballido 2014 , p. 48
rfc6762 2012 , p. 1
A. Al-Fuqaha 2015 , p. 2357
B. Carballido 2014 , p. 50
I. Ishaq 2014 , p. 9839
draft-ietf-core-resource-directory-09 2016 , p. 5
draft-ietf-core-resource-directory-09 2016 , p. 15
B. Carballido 2014 , p. 46
rfc6763 2013 , p. 1
B. Carballido 2014 , p. 49
I. Ishaq 2013 , p. 5
I. Ishaq 2014 , p. 9840
I. Ishaq 2013 , p. 346
rfc7390 2014 , p. 1
rfc7252 2014 , pag. 65
rfc7390 2014 , p. 4
rfc7390 2014 , p. 6
rfc7731 2016 , p. 1
rfc7390 2014 , p. 19 e 20
I. Ishaq 2013 , p. 6
I. Ishaq 2016 , p. 373
I. Ishaq 2014 , p. 9844
AP. Castellani 2011 , p. 1
Servizi Web e EXI 2011 , p. 1799
WebServicesAndEXI 2011 , p. 1
AP Castellani 2011 , p. 3
EXI Low Power Embedded Networks 2011 , p. 702
R. Abdul Rahman 2016 , p. 4
Vilaverde 2012 , p. 706
il sito web ufficiale del Califorium
il sito ufficiale di Erbium
il sito ufficiale di rame
il sito ufficiale libcoap
il sito del progetto CoapBlip
il sito del progetto jCoAP
il sito ufficiale di coap.me
Sito ufficiale Watteco
il sito ufficiale di Cooja
M. Kovatsch 2013 , p. 1497
C. Bormann 2012 , p. 63
Vilaverde 2012 , p. 703
R. Abdul Rahman 2016 , p. 5
M. Kovatsch 2011 , p. 856
M. Kovatsch 2011 , p. 858
M. Kovatsch 2011 , p. 860
A. Ludovici 2013 , p. 301
M.Castro 2016 , p. 232
HA Khattak 2014 , p. 500
D. Ugrenovic 2015 , pag. 79
HA Khattak 2014 , p. 499
HA Khattak 2014 , p. 501
H. A. Khattak 2014 , p. 502
G. Belcredi 2015 , pag. 270
G. Belcredi 2015 , p. 272
G. Belcredi 2015 , p. 273
Vilaverde 2012 , p. 705
Vilaverde 2012 , p. 704
B. Borgia 2014 , p. 9
T. Leva 2014 , p. 33
W. Colitti 2011 , p. 1-6
SH Shaheen 2014 , p. 3
B. Carballido 2014 , p. 51
B. Carballido 2014 , p. 54
J. Granjal 2012 , p. 230
DH Mun 2016 , p. 556
DH Mun 2016 , p. 557
R. Martins 2016 , p. 1029-1030
(in) Richiesta di commenti n ° 6347 .
A. Capossele 2015 , p. 550
rfc4347 2005 , p. 1
SH Shaheen 2014 , p. 165
A. Fuentes-Samaniego 2016 , p. 79
rfc7925 2005 , p. 5
rfc7252 2014 , p. 68
; rfc4279 2005 , p. 1
C. Hennebert 2014 , p. 387
V. Lakkundi 2014 , p. 8
Shahid Raza 2012 , p. 1
draft-ietf-core-coap-12 2012 , pag. 68
rfc7959 2016 , p. 1
PP Pereira 2014 , p. 5293
PP Pereira 2014 , p. 5294
progetto-Bormann-core-coap-block-00 2009 , pag. 1
I. Ishaq 2013 , p. 346
Constrained Application Protocol (CoAP) bozza-shelby-core-coap-01 2010 , p. 1
rfc7252 History 2014 , p. 1
. rfc7641 2015 , p. 1
rfc7959 2016 , p. 1