IOT E M2M: UNA PANORAMICA DAI CONSTRAINED … · 3.1.1.4 Bootstrap da Server ... il protocollo a...
42
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in RETI DI CALCOLATORI IOT E M2M: UNA PANORAMICA DAI CONSTRAINED DEVICE ALLA GESTIONE DEI DISPOSITIVI CON LWM2M Anno Accademico 2016/2017 Relatore: Simon Pietro Romano Candidato: Nicola d’Ambrosio matr. N46/2251
Transcript of IOT E M2M: UNA PANORAMICA DAI CONSTRAINED … · 3.1.1.4 Bootstrap da Server ... il protocollo a...
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in RETI DI CALCOLATORI
IOT E M2M: UNA PANORAMICA DAI CONSTRAINED DEVICE ALLA GESTIONE DEI DISPOSITIVI CON LWM2M
Anno Accademico 2016/2017 Relatore:
Simon Pietro Romano Candidato:
Nicola d’Ambrosio
matr. N46/2251
Indice
Introduzione ....................................................................................................................................... 1
Capitolo 1: I Constrained Device ...................................................................................................... 3
1.1 Classificazione dei Constrained Device .................................................................................. 3 Capitolo 2: Il protocollo CoAP ......................................................................................................... 5
2.1 Introduzione ................................................................................................................................. 5
2.2 Caratteristiche ............................................................................................................................. 5
2.3 Formato dei messaggi ............................................................................................................... 6
2.3.1 Definizione di metodi ............................................................................................................... 8
2.3.2 Definizione di codici ................................................................................................................ 9
2.3.3 Options .................................................................................................................................... 11
2.4 Comunicazione/Trasmissione/Funzionamento ................................................................... 13
2.4.1 Modello messaggi ................................................................................................................ 13
2.4.2 Trasmissione affidabile dei messaggi ............................................................................... 14
2.4.3 Piggybacked .......................................................................................................................... 15
2.4.4 Separate ................................................................................................................................ 15
2.4.5 Trasmissione dei messaggi senza Reliability .................................................................. 15
2.4.6 Trasmissione dei messaggi senza Reliability .................................................................. 16
2.4.7 Messaggi e Endpoint ............................................................................................................ 16
2.4.8 Controllo congestione ........................................................................................................... 16 Capitolo 3: Il protocollo LwM2M ................................................................................................... 18
3.1 Le interfacce .............................................................................................................................. 20
3.1.1 L’interfaccia Bootstrap .......................................................................................................... 21
3.1.1.1 Bootstrap di fabbrica .......................................................................................................... 21
3.1.1.2 Bootstrap da Smartcard .................................................................................................... 22
3.1.1.3 Bootstrap da Client ............................................................................................................ 22
3.1.1.4 Bootstrap da Server ........................................................................................................... 23
3.1.1.5 I comandi di Bootstrap....................................................................................................... 24
3.1.2 L’interfaccia Client Registration........................................................................................... 24
3.1.3 L’interfaccia Device Management and Service Enablement .......................................... 25
3.1.4 L’interfaccia Information Reporting ..................................................................................... 26
3.2 Modello delle risorse ................................................................................................................ 27
3.2.1 Creazione e istanziazione di un modello delle risorse ............................................................. 28
3.2.1.1 Creazione di un modello delle risorse............................................................................. 29
3.2.1.2 Istanziazione delle risorse ................................................................................................ 31
3.2.2 Collegamento con il livello trasporto................................................................................... 33
3.2.2.1 Bootstrap Interface ............................................................................................................. 33
3.2.2.2 Registration Interface ........................................................................................................ 34
3.2.2.3 Device Management & Service Enablement Interface ................................................ 35
3.2.2.4 Information Reporting Interface ....................................................................................... 37
Bibliografia ....................................................................................................................................... 38
1
Introduzione
Al giorno d’oggi, si sta avendo un notevole sviluppo dell’ “Internet of Things”, conosciuto anche
con l’ acronimo “IoT”, ovvero con la terminologia italiana di “Internet delle cose” o “Internet degli
oggetti”.
L’idea fondante è quella di rendere gli oggetti intelligenti, dotati di una propria identità e capaci di
comunicare, scambiarsi informazioni, interagire e cooperare tra loro, tramite la rete. In virtù di
questa cooperazione e scambio di informazioni si possono creare nuove applicazioni e nuovi
servizi.
I potenziali vantaggi dell’IoT sono quasi illimitati e le applicazioni IoT stanno cambiando il nostro
modo di lavorare e vivere, facendo risparmiare tempo e risorse, aprendo nuove opportunità di
crescita, innovazione e creazione di conoscenze. L’Internet delle cose consente alle organizzazioni
private e pubbliche di gestire asset, ottimizzare le prestazioni e sviluppare nuovi modelli di
business. Nell'ultimo anno, l'IoT si è trasformato da una visione futuristica ad una realtà di mercato,
in continuo aumento.
L’IoT è così definito da ITU1 e da IERC
2:
“A dynamic global network infrastructure with self-configuring capabilities based on
standard and interoperable communication protocols where physical and virtual
‘things’ have identities, physical attributes, and virtual personalities and use
intelligent interfaces, and are seamlessly integrated into the information network.”
L’aspettativa dell’IoT è quella di un mondo in cui il reale, il digitale e il virtuale convergano per
creare ambienti intelligenti che rendano l'utilizzo dell’energia, i trasporti, le città e molte altre cose
più intelligenti. L'obiettivo di Internet delle cose è quello di consentire la connessione a chiunque, di
qualsiasi cosa, in qualsiasi momento, ovunque, con (idealmente) qualsiasi mezzo, qualsiasi rete e
qualsiasi servizio. L’IoT è la nuova rivoluzione di Internet. Gli oggetti si rendono riconoscibili e
acquisiscono intelligenza, potendo prendere decisioni, grazie al fatto che possono scambiarsi
informazioni, possono accedere ad informazioni che sono state aggregate da altri oggetti e possono
essi stessi essere componenti di servizi complessi.
1 ITU, acronimo di International Telecommunication Union 2 IERC sta per IoT European Research Cluster
2
In questo scenario diventano di fondamentale importanza le comunicazioni e le interazioni
Machine-to-Machine (M2M) e, quindi i sistemi M2M.
I componenti di un sistema M2M sono i seguenti:
M2M Device. Dispositivo M2M collegato al bene di interesse; fornisce funzionalità di
rilevamento ed attuazione. Tali dispositivi spesso hanno potenzialità limitate e per tale
ragione prendono il nome di ‘Constrained Device’.
Network. Fornisce la connettività remota tra i dispositivi M2M client e server (è
implementata un’architettura client-server).
M2M Service Enablement. Fornisce funzionalità generiche che sono comuni ad una serie di
applicazioni diverse. Il suo scopo primario è quello di ridurre i costi per l'implementazione,
evitando sviluppi di implementazioni specifiche, e di facilitare lo sviluppo di applicazioni.
M2M Application. L’applicazione che utilizza i dispositivi M2M
Tra i dispositivi M2M al giorno d’oggi si sta assistendo al notevole incremento produttivo dei
Constrained Device, dispositivi dalle ridotte dimensioni, peso e costo.
In questo lavoro di tesi verrà esaminato il protocollo Lightweight Machine-to-Machine per il
management dei Constrained Device, il protocollo a livello di Sessione CoAP3 e la libreria Leshan
per lo sviluppo di applicazioni per i Server ed i Client.
3 CoAP acronimo di Constrained Application Protocol
3
Capitolo 1: I Constrained Device
I Constrained Device nascono dall’esigenza di ridurre le caratteristiche di questi device per renderli
economicamente e fisicamente realizzabili. Tali device spesso vengono utilizzati per realizzare
dispositivi M2M.
Un Constrained Node è un nodo di rete costituito da un Constrained Device dove alcune
caratteristiche, che sono considerate scontate per i nodi di Internet, non sono presenti, spesso a
causa dei vincoli di costo e/o vincoli fisici come dimensione, peso e potenza del dispositivo. I limiti
di potenza, memoria e risorse di elaborazione portano all’introduzione di limiti per lo spazio di
codice e cicli di elaborazione. Bisogna anche osservare che i maggiori vincoli di questi dispositivi
vengono riscontrati nella bandwidth della rete.
La presenza dei suddetti limiti si manifesta in varie forme:
Vincoli sulla complessità massima del codice (ROM / Flash)
Vincoli sulla dimensione dello stato e dei buffer (RAM)
Vincoli sulla quantità di calcolo per unità di tempo ("potere di elaborazione")
Vincoli sull'interfaccia utente e accessibilità in fase di implementazione (capacità di
impostare chiavi, aggiornamento software, ecc.).
1.1 Classificazione dei Constrained Device A causa della vastissima varietà di dispositivi connessi a Internet che si possono utilizzare può
risultare utile andare a fare una classificazione degli stessi.
Name Data size (e.g., RAM) Code size (e.g., Flash)
Class 0, C0 << 10 KB << 100 KB
Class 1, C1 ~ 10 KB ~ 100 KB
Class 2, C2 ~ 50KB ~ 250 KB
I device di classe 0 sono dispositivi estremamente limitati (generalmente sensori). Sono così
gravemente vincolati dalle scarse capacità di memoria e di elaborazione che la maggior parte non ha
le risorse necessarie per comunicare direttamente con Internet in modo sicuro. I dispositivi di classe
0 partecipano alle comunicazioni via Internet con l'aiuto di dispositivi più grandi che agiscono come
proxy, gateway o server.
I dispositivi di classe 1 sono abbastanza limitati nello spazio e nell'elaborazione dei codici. Tali
device incontrano notevoli difficoltà nel comunicare con altri nodi presenti in rete che utilizzano
protocolli come HTTP, Transport Layer Security (TLS) e relativi protocolli di protezione, basati
sulla rappresentazione dei dati come XML. Tuttavia, essi sono in grado di utilizzare un protocollo
stack specificamente progettato per i Constrained-Node (come ad esempio CoAP) e partecipare a
comunicazioni di rete senza l'aiuto di un nodo gateway.
I dispositivi di classe 2 sono meno vincolati e fondamentalmente capaci di supportare la maggior
parte degli stessi stack di protocolli utilizzati sui notebook o server. Tuttavia, anche per questi
dispositivi è consigliabile utilizzare protocolli efficienti nell’utilizzo della larghezza di banda.
Inoltre, usando meno risorse per il networking si lascia più banda disponibile per le applicazioni.
4
Si può osservare che, comunque, esistono dispositivi limitati con potenzialità superiori rispetto alla
classe 2. Tali dispositivi creano meno problemi per lo sviluppo di applicazioni poiché possono
utilizzare i protocolli esistenti senza alcun tipo di variazione.
5
Capitolo 2: Il protocollo CoAP
Il Constrained Application Protocol (CoAP) è un protocollo di trasferimento web progettato per lo
scambio di messaggi tra nodi e network aventi hardware dalle potenzialità limitate. CoAP fornisce
un modello di interazione richiesta/risposta tra le applicazioni endpoint studiato per interfacciarsi
facilmente con HTTP, permettendo anche comunicazioni multicast e, allo stesso tempo, limitando
l’overhead.
2.1 Introduzione
L’utilizzo di servizi web (web api) è diventato fondamentale nella maggior parte delle applicazioni
grazie all’uso dell’architettura REpresentational State Transfer (REST). È importante ricordare che
l’utilizzo di architetture REST può richiedere risorse hardware spesso non disponibili negli
ambienti di Constrained RESTful Environments (CoRE) e per tale ragione si devono individuare
delle soluzioni per rendere utilizzabili architetture software REST anche da dispositivi con capacità
hardware limitate. I progettisti del protocollo CoAP, per raggiungere tale scopo, hanno cercato di
limitare il più possibile l’overhead all’interno dei messaggi al fine di diminuire il bisogno di
frammentazione. Con tali linee guida CoAP fornisce un generico protocollo web disegnato su
misura per i dispositivi constrained. È importante ricordare che l’obiettivo di tale protocollo non è
quello di comprimere “ciecamente” il protocollo HTTP, ma di realizzare un sottoinsieme comune di
operazioni REST con HTTP, ottimizzate per i dispositivi M2M. Le interazioni tra gli utilizzatori di
tale protocollo risultano essere molto semplici. Lo scambio di messaggi previsto da CoAP segue le
regole del modello client/server di HTTP con alcune piccole differenze. Infatti, nelle interazioni
M2M, i ruoli di client e di server vengono spesso scambiati tra gli endpoint presenti nella
comunicazione. All’interno di una comunicazione, il client è colui che effettua l’invio di una
determinata richiesta mentre, il server, è colui che riceve la richiesta e risponde fornendo la risorsa
desiderata. È importante ricordare che, a differenza di HTTP, CoAP è in grado di inviare messaggi
asincroni grazie all’utilizzo di canale di trasmissione a datagrammi come UDP. Tale protocollo
prevede anche la possibilità di avere una comunicazione affidabile attraverso un layer Messanger
che permette di colmare le lacune presenti nel protocollo di trasporto UDP.
2.2 Caratteristiche
Le principali caratteristiche di CoAP sono:
Protocollo Web che soddisfa i requisiti M2M UDP con possibilità di trasmissione affidabile dei messaggi sia con richieste unicast e
multicast. Scambio di messaggi asincroni Basso overhead nel header dei messaggi e bassa complessità di parsing. Supporto di URI e Content-type
6
Semplici capacità di proxy e caching dei messaggi Possibilità di utilizzo di un canale DTLS Un mapping HTTP senza stati
2.3 Formato dei messaggi
CoAP si basa sullo scambio di messaggi compatti trasportati con UDP (viene previsto anche
l’utilizzo di altri protocolli come DTLS, TCP, SMS). Un messaggio CoAP inizia con un header di
lunghezza fissa di 4 byte. Quest’ultimo è seguito da un campo opzionale di lunghezza variabile (0-8
byte) denominato Token value. Dopo il Token value è previsto un campo di dimensione variabile
(0-8 byte) in cui è previsto l’inserimento di zero o più opzioni di trasferimento del messaggio.
Un’opzione può essere seguita dalla fine del messaggio, da un’altra opzione oppure dal payload-
ma’ker e il payload. Il payload-maker è un prefisso a lunghezza fissa di un byte (0xFF) per indicare
la fine delle opzioni e l’inizio del payload. Il payload si estende dalla fine del payload maker fino
alla conclusione del datagramma UDP. La presenza di un payload-maker associato ad un payload di
lunghezza nulla indica un errore di costruzione del messaggio. Si deve osservare che le specifiche
CoAP prevedono esclusivamente un limite superiore per la dimensione dei messaggi. Messaggi di
lunghezza superiore al pacchetto IP risultato indesiderabili a causa della frammentazione che
quest’ultimi devono subire. Per tale ragione i pacchetti CoAP dovrebbero avere le dimensioni
adeguate per calzare perfettamente in un unico datagramma IP ed evitare la frammentazione del
messaggio. Tale formattazione del messaggio viene utilizzata sia dal Client per effettuare le
richieste desiderate sia dal Server per rispondere a queste ultime.
Versione (2 bit unsigned integer)
Indica il version number utilizzato di CoAP. Tale campo deve essere settato con il valore 1 (01 in
binario). Altri valori sono riservati per versioni future. I messaggi con versioni non identificate
vengono silenziosamente ignorate dal server.
7
Type (2 bit unsigned integer)
Due bit che indicano il tipo del messaggio. In CoAP sono previsti quattro tipi di messaggi:
confermabile (0 - 00), non confermabile (1 - 01), acknowledgement (2 - 10) e reset(3 - 11).
I messaggi confirmable hanno bisogno di un acknowledgement. Quando il messaggio è arrivato a
destinazione il server è obbligato a rispondere con un acknowledgement oppure con un reset. Tale
tipo di messaggio permette la comunicazione reliable.
I messaggi non confirmable non richiedono alcun onere di invio di acknowledgement e sono
necessari per l’implementazione della comunicazione asincrona.
Il messaggio di acknowledgement indica la corretta ricezione di una determinata richiesta.
Il messaggio di reset viene utilizzato quando il messaggio ricevuto da un server presenta
determinate caratteristiche tali da non essere poter essere processato dal Server.
Nella descrizione di questi tipi di messaggi si evince subito l’ortogonalità delle interazioni
richiesta/risposta infatti i messaggi confermabili/non confermabili sono utilizzati dal client per
avanzare una richiesta mentre i messaggi di reset/acknowledgement sono utilizzati dal server per
rispondere a tali richieste.
Message ID (16 bit unsigned int)
Utilizzato per identificare i messaggi duplicati e soprattutto per permettere un corretto match tra gli
acknowledgement/reset e i messaggi confermabili/non confermabili. Infatti, i messaggi di
acknowledgement e di reset sono associati ad un messaggio confermabile o non confermabile grazie
al message ID e alle informazioni sull’indirizzo dell’endpoint corrispondente.
Il message ID viene deciso dal mittente del messaggio e, successivamente, copiato nel messaggio di
risposta creato dal server. Si osservi che non è possibile riusare lo stesso message ID all’interno
della stessa EXCHANGE_LIFETIME (finestra temporale in cui il client è ancora in attesa della
risposta).
Un altro importante utilizzo del message ID è quello di eliminare i messaggi duplicati. Un ricevente
potrebbe ricevere lo stesso messaggio confermabile più volte all’interno dello stesso intervallo
EXCHANGE_LIFETIME. Il ricevente dovrebbe rispondere con un acknowledgement o con un
reset per ogni copia del messaggio confermabile duplicato ma, allo stesso tempo, processare ogni
richiesta o risposta una sola volta. Le duplicazioni del messaggio si possono verificare nel caso in
cui l’ack non venga ricevuto dal suo destinatario oppure non riesca a raggiungere il destinatario
all’interno della finestra temporale prevista dal protocollo.
Inoltre, un ricevente potrebbe ricevere più volte lo stesso messaggio non confermabile ad istanti di
tempo ravvicinati. In queste condizioni il destinatario di tali messaggi può decidere di ignorare
silenziosamente ogni duplicato del messaggio non confermabile e processare qualsiasi richiesta o
risposta una sola volta.
8
Code (8 bit unsigned int)
Il campo codice può indicare un Method code (per la richiesta) oppure un Responce Code (per la
risposta). Tale campo risulta essere suddiviso in due sezioni: “class”(3 bit più significativi) e
“detail”(i rimanenti 5 bit). Le classi possono indicare una richiesta (0), una risposta avvenuta con
successo (2), una risposta causata dagli errori del client (3), una risposta causata dagli errori del
server (4)(Il valore 1 è riservato). Un caso speciale risulta essere il codice 0.00 il quale indica la
presenza di un messaggio vuoto. Nel caso fosse presente all’interno della classe del codice il valore
0 allora tale campo indicherà una richiesta di metodo. Nel caso in cui il codice fosse presente in un
messaggio di risposta il codice risulterà essere di risposta (ovvero classi 2 3 4).
2.3.1 Definizione di metodi
GET
Il metodo GET recupera una rappresentazione per le informazioni che correntemente corrispondono
alla risorsa identificata dall'URI della richiesta. Se eseguita con successo è possibile all’interno del
messaggio individuare i codici 2.05 (Content) oppure 2.03 (Valid).
Tale metodo è sicuro e idempotente.
POST
Il metodo POST richiede di elaborare la rappresentazione allegata alla richiesta. La funzione
effettiva eseguita dal metodo POST è determinata dal server di origine e dipende dalla risorsa di
destinazione. Di solito o si crea una nuova risorsa o la risorsa di destinazione viene aggiornata.
Se la risorsa è stata creata sul server, la risposta inviata avrà il codice 2.01 (create) e l'URI
corrispondente sarà inserito in una sequenza di Location-Path e / o Location-Query contenute nelle
opzioni.
Invece, nel caso in cui il POST va comunque a buon fine, ma non provoca la creazione di una
nuova risorsa sul server, la risposta avrà il codice 2.04 (modified).
Infine, se il POST ha esito positivo e come risultato la risorsa di destinazione viene eliminata, la
risposta avrà il codice 2,02 (deleted).
Il metodo POST non è sicuro e idempotente.
PUT
Il metodo PUT richiede che la risorsa identificata dall'URI della richiesta venga aggiornata o creata
con la rappresentazione allegata. Il formato di rappresentazione è specificato dal tipo di supporto e
dal codice contenuto contenuto nell'opzione Content-Format Option, se previsto. Se una risorsa
esiste all'URI di richiesta, la rappresentazione allegata sarà considerata una sua versione modificata
e verrà restituito un codice di risposta 2.04 (changed). nel caso in cui non dovesse esiste alcuna
risorsa, il server potrebbe crearne una nuova con tale URI, generando un codice di risposta 2.01
(created). Se la risorsa non è stata creata o modificata, è necessario inviare l’errore appropriato.
9
L’operazione PUT non è sicura ma è idempotente.
DELETE
Il metodo DELETE richiede che la risorsa identificata dall'URI della richiesta venga eliminata. Il
codice di risposta 2.02 (deleted) sarà usato sia in caso di successo sia nel caso in cui la risorsa non
esistesse prima della richiesta.
DELETE non è sicura ma è idempotente.
2.3.2 Definizione di codici
I codici di risposta vengono inseriti dal server all’interno del messaggio. Tali codici hanno lo scopo
di informare il client sullo stato di terminazione dell’operazione richiesta.
Success 2.xx
Questa classe di codice di risposta indica che la richiesta dei client è stata ricevuta, compresa e
accettata con successo.
2.01 Created
Utilizzata esclusivamente nelle richieste di PUT e POST. Il payload ottenuto con la risposta, se è
presente, è una rappresentazione del risultato dell'azione richiesta. Se la risposta include una o più
opzioni di Location-Path e / o di Location-Query, i valori di questi ultimi specificano la posizione in
cui è stata creata la risorsa (l’URI).
Questa risposta non è cachable.
2.02 Deleted
Tale codice è utilizzato esclusivamente in risposta alle richieste che causano la terminazione della
disponibilità di una data risorsa. Il payload restituito, se presente, fornisce una rappresentazione del
risultato dell’azione.
Anche questa operazione non è cachable.
2.04 Changed
Tale codice è utilizzato esclusivamente con i metodi POST e PUT e indica la corretta
modifica/creazione della risorsa desiderata. Il payload restituito con la risposta, se presente, è una
rappresentazione del risultato dell'azione.
Tale risorsa non è cachable.
10
2.05 Content
Tale codice indica il corretto conseguimento della operazione di GET. Il payload restituito con la
risposta è una rappresentazione della risorsa di destinazione. Tale operazione è cachable.
Client Error 4.xx
Questa classe di codice di risposta è destinata a casi in cui si ha un errore da parte del client. Questi
codici di risposta sono applicabili a qualsiasi metodo di richiesta.
4.00 Bad Request
Questo codice di risposta è equivalente a HTTP 400 "Bad Request
4.01 Unauthorized
Il client non è autorizzato a eseguire l'azione richiesta. Il client non dovrebbe ripetere la richiesta
senza prima aver cambiato il suo stato di autenticazione sul server.
4.02 Bad Option
La richiesta non è stata eseguita dal server a causa di una o più opzioni non riconosciute o non
correttamente inserite all’interno del messaggio.
4.03 Forbidden
Questo codice di risposta è analogo al 403 "Forbidden" di HTTP.
4.04 Not Found
Questo codice di risposta è analogo al 403 "Not Found" di HTTP.
Server Error 5.xx
Questa classe di codice di risposta indica i casi in cui il server è consapevole dell’impossibilità di
eseguire la richiesta. Tali codici sono applicabili a qualsiasi metodo di richiesta.
5.00 Internal Server Error
Questo codice di risposta è analogo al 403 "Internal Server Error" di HTTP.
5.01 Not Implemented
Questo codice di risposta è analogo al 403 "Not Implemented" di HTTP.
11
5.02 Bad Gateway
Questo codice di risposta è analogo al 403”Bad Gateway" di HTTP.
5.03 Service Unavailable
Questo codice di risposta è analogo al 403 "Service Unavailable" di HTTP.
5.04 Gateway Timeout
Questo codice di risposta è analogo al 403 "Gateway Timeout" di HTTP.
Token Length (TKL) (4 bit unsigned int).
Indica la lunghezza del campo Token (0-8 byte). Valori di lunghezza del token tra 9 e 15 non sono
ammessi e pertanto il messaggio non può essere inviato e deve essere processato come avente un
errore di costruzione.
I token sono utilizzati per far coincidere richieste e risposte. Ogni richiesta inviata dal client
trasporta un token da trascrivere nel messaggio di risposta generato dal server. I token sono
utilizzati come identificatori dal client per differenziare le richieste correnti. Infatti, la generazione
dei token da parte del client è effettuata garantendo l’unicità per ogni specifica source/destination.
Può essere utilizzato un token nullo esclusivamente nel caso in cui non sono utilizzati altri token per
una data destinazione oppure quando le richieste vengono fatte serialmente e ricevono sempre
risposte.
2.3.3 Options
CoAP definisce un numero di opzioni che possono essere inserite all’interno del messaggio. Ogni
istanza di opzione specifica: il numero di opzione tra quelle definite in CoAP, la lunghezza del
valore dell’opzione e il valore dell’opzione stessa. Invece di specificare direttamente il numero
dell’opzione, le istanze devono essere inserite in ordine secondo il loro option number e in modo da
utilizzare una codifica “ delta” tra di esse: il numero dell’opzione per ogni istanza è calcolato come
somma tra il suo delta e il valore dell’istanza dell’opzione precedente presente nel messaggio. Per la
prima istanza del messaggio viene assunta l’esistenza di un’istanza di opzione precedente avente
valore nullo. Più istanze della stessa opzione possono essere inserite utilizzando un valore delta
nullo.
12
I campi in una determinata opzione sono definiti come seguono:
Option Delta (4 bit unsigned int): può assumere valori tra 0 e 12. Tre valori sono utilizzati per usi
speciali:
13 - Viene utilizzato per rappresentare la delta un unsigned int di 8 bit. Tale valore viene
memorizzato dopo il primo byte dell’istanza dell’opzione. Il valore contenuto in tale campo deve
essere sottratto di 13.
14 - Viene utilizzato per rappresentare la delta un unsigned int di 16 bit. Tale valore viene
memorizzato dopo il primo byte dell’istanza dell’opzione. Il valore contenuto in tale campo deve
essere sottratto di 265.
15 - Riservato per il payload maker.
Il delta viene calcolato come la differenza tra il numero dell’opzione corrente e quello dell’istanza
precedente, pertanto l’option number può essere calcolato semplicemente sommando
esclusivamente tutti i delta.
Option Length (4 bit unsigned int): può assumere valori tra 0 e 12. Tale campo indica la lunghezza
dei valori associati all’opzione in byte. Tre valori sono utilizzati per usi speciali:
13 - Viene utilizzato per rappresentare l’Option Lenght con un unsigned int di 8 bit. Tale valore
viene memorizzato dopo il primo byte dell’istanza dell’opzione oppure dopo l’estensione del delta
se presente. Il valore contenuto in tale campo deve essere sottratto di 13.
14 - Viene utilizzato per rappresentare l’Option Lenght con un unsigned int di 16 bit. Tale valore
viene memorizzato dopo il primo byte dell’istanza dell’opzione oppure dopo l’estensione del delta
se presente. Il valore contenuto in tale campo deve essere sottratto di 269.
15 - Riservato per il payload maker.
Lista opzioni
CoAP definisce un singolo insieme di opzioni che vengono utilizzate sia per le richieste che per
risposte: ETag
Location-Path
Location-Query
Max-Age
Proxy-Uri
Proxy-Scheme
Uri-Host
Uri-Path
Uri-Port
Uri-Query
Accept
If-Match
If-None-Match
Size1
13
Option Length
I valori delle opzioni sono definiti per avere una lunghezza specifica e, pertanto, l’insieme dei
valori rappresentabili è delimitato da un limite inferiore e superiore. Se la lunghezza di un valore di
opzione in una richiesta è al di fuori del range definito, tale opzione deve essere trattata come
un'opzione non riconosciuta.
Option Numbers
Le opzioni sono riconosciute da un numero identificativo il quale fornisce anche alcune
informazioni aggiuntive sul tipo di opzione. Il numero di una determinata opzione è costruito in
maniera tale che, confrontando con una determinata maschera permette di individuare se l’opzione
risulta essere critica, elective, Unsafe or Safe-to-Forward. La maschera per individuare le
caratteristiche di una determinata opzione può essere costruita su un singolo byte
Il bit 7 (il bit meno significativo) uguale a 1 indica che un'opzione è Critica (e elective quando 0). Il
bit 6 uguale a 1, indica che un'opzione è Unsafe (0 quando è Safe-to-Forward). Se il bit 6 è 0, cioè
l'opzione Safe-to-Forward, e i bit 3-5 sono tutti impostati su 1, non è memorizzata alcuna chiave di
cache (NoCacheKey). Tutte le altre combinazioni di bit significa che è in realtà una chiave di cache
Payload
I messaggi di richiesta e di risposta avranno o meno un payload a secondo del codice di metodo o
codice di risposta utilizzato. Se un determinato metodo o codice di risposta non è definito per avere
un payload allora quest’ultimo risulterà essere ignorato.
In genere il payload nelle operazioni avvenute con successo (sia metodi che risposte) mantiene una
rappresentazione della risorsa richiesta. Il formato di rappresentazione del payload è specificato
dalla codifica dei contenuti del payload ed è indicata nell'opzione Content-Format Option. In
assenza di questa opzione non viene assunto alcun valore predefinito ed il formato deve essere
dedotto dall'applicazione.
2.4 Comunicazione/Trasmissione/Funzionamento
2.4.1 Modello messaggi Il modello messaggi di CoAP è basato sullo scambio di messaggi attraverso il canale a datagrammi
UDP tra due endpoint. Tale protocollo permette la consegna affidabile e inaffidabile dei messaggi. I
modelli Richiesta/risposta sono necessari per un corretto scambio di messaggi tra client e server.
14
L’affidabilità dei messaggi è fornita grazie all’utilizzo di messaggi Confirmable. In questo caso,
infatti, si fa uso di un timeout predefinito per le ritrasmissioni e un Back-off esponenziale tra esse. Il
client termina le ritrasmissioni alla ricezione di un messaggio di conferma (ACK) con lo stesso ID
del messaggio iniziale.
Quando il destinatario non è in grado di processare il messaggio appena ricevuto, invia un
messaggio di reset (RST) invece del messaggio di acknowledgement.
Nel caso non si fosse interessati ad uno scambio affidabile dei messaggi è possibile inoltrare la
richiesta desiderata con un messaggio non confermabile. In tal condizioni il Server non è obbligato
all’invio del acknowledgement.
2.4.2 Trasmissione affidabile dei messaggi
I messaggi CoAP vengono scambiati in modo asincrono tra gli endpoint CoAP. Poiché CoAP è
legato al protocollo di livello trasporto non affidabile UDP, i messaggi CoAP possono arrivare fuori
ordine, duplicati oppure, nella peggiore delle ipotesi, essere persi. Per questo motivo, CoAP
implementa un meccanismo di affidabilità leggera, senza cercare di ricreare l'insieme completo di
funzionalità offerte dal protocollo TCP. Pertanto, l’affidabilità in COAP è data da:
la possibilità di ritrasmissione e attesa con back-off esponenziale per i messaggi confermabili.
il rilevamento dei duplicati per i messaggi confermabili e non-confermabili.
La trasmissione affidabile di un messaggio viene avviata contrassegnando come confermabile
nell'intestazione CoAP.
Un messaggio confermabile porta sempre una richiesta o una risposta, a meno che non venga
utilizzato solamente per generare un messaggio di RESET (messaggio vuoto in questo caso). Il
destinatario ha l’obbligo di inviare un acknowledgement nel caso in cui possa processare la richiesta
oppure deve rigettare la richiesta se presenta qualche forma di ambiguità. Il rigetto di una richiesta
confermabile impone al destinatario l’invio di un messaggio di RESET al mittente. Il messaggio di
acknowledgement deve riportare l'ID messaggio del messaggio confermato e la risposta
(piggybacked) oppure essere vuoto. Il messaggio di ripristino deve riprendere solo l'ID messaggio
del messaggio confirmable. Si ricordi che i riceventi di un messaggio di acknowledgement o di reset
non devono rispondere con altri acknowledgement o reset.
In caso di mancata ricezione dell' acknowledgement il mittente dovrà ri-trasmettere il messaggio.
Tale ritrasmissione del messaggio avverrà con intervalli esponenzialmente maggiori, fino a quando
15
non si riceve l’acknowledgement oppure si esauriscono i tentativi disponibili. La ri-trasmissione è
controllata da due fattori di cui un endpoint CoAP deve tenere traccia: il timeout e il conteggio delle
ritrasmissioni. Per un nuovo messaggio confermabile il timeout è settato randomicamente mentre il
conteggio delle ritrasmissioni è impostato a zero. Allo scadere del timeout, se il contatore di
ritrasmissione è inferiore a MAX_RETRANSMIT, il messaggio viene ritrasmesso. Se il contatore
di ritrasmissione raggiunge MAX_RETRANSMIT in un timeout o se l'endpoint riceve un
messaggio di reset il tentativo di trasmettere il messaggio viene annullato. Invece, se l'endpoint
riceve un acknowledgement in tempo, la trasmissione è considerata riuscita. Esistono casi in cui un
endpoint CoAP che ha inviato un messaggio confirmable potrebbe declinare nel tentativo di
ottenere un ACK ancor prima che il valore del contatore MAX_RETRANSMIT sia raggiunto (per
esempio alla ricezione di un risposta per un messaggio con risposta separata).
2.4.3 Piggybacked
Nella maggior parte dei casi la risposta viene riportata direttamente nel messaggio di
riconoscimento associato alla richiesta. Tale metodologia di risposta prende il nome di
Piggybacked. La risposta viene restituita nel messaggio di acknowledgement, indipendentemente
dal fatto che la risposta indica il successo o il fallimento. Utilizzando questa tecnica la risposta
viene inviata insieme al acknowledgement e non è necessario inviare un messaggio separato per
fornire la risposta della richiesta.
2.4.4 Separate
Esistono casi in cui non è possibile restituire una risposta piggybacked a causa della mancata
disponibilità della risorsa richiesta. Quindi, per evitare l'eccessiva duplicazione dei messaggi, si
separano le due componenti del messaggio piggybacked: acknowledgement e risorsa. Un server
può implementare tale soluzione avviando un timer insieme alla richiesta per ottenere la
rappresentazione della risorsa . Se la risorsa non è ancora disponibile allo scadere del timer, il
Server invierà al mittente un acknowledgement associato ad un messaggio vuoto. Quando il server
ha finalmente ottenuto la rappresentazione delle risorse, invierà la risposta al client. Tale risposta è
inviata con un messaggio confirmable utilizzando un nuovo message ID scelto dal server e lo stesso
token presente nella richiesta iniziale. Pertanto, quando il server invia un acknowledgement vuoto,
non deve inoltrare la risposta in un altro acknowledgement, anche se il client nel frattempo ha
effettuato un'altra richiesta identica. Il server termina la trasmissione della risposta alla ricezione di
un acknowledgement o di un reset da parte del client.
2.4.5 Trasmissione dei messaggi senza Reliability
Alcuni messaggi non necessitano di acknowledgement. Un messaggio può essere inviato senza
reliability marcandolo come non confermabile. Un messaggio non confermabile deve sempre
trasportare una richiesta o una risposta e pertanto non può essere inviato vuoto; il messaggio non
16
confermabile non obbliga il ricevente all’invio del acknowledgement. Un destinatario deve rifiutare
il messaggio se manca il contesto per elaborarlo correttamenteoppure presenta errori nel formato. Il
rigetto di un messaggio non confermato comporta l’invio di un messaggio di reset al client ed il
rifiuto della richiesta in maniera silenziosa. Per il mittente non esiste alcun sistema per scoprire
informazioni riguardo la consegna del messaggio. Per tale ragione un mittente può decidere di
inviare copie multiple dello stesso messaggio per aumentare le probabilità di ricezione di
quest’ultimo. I messaggi non confermati specificano un solo message ID per evitare che il ricevente
processi più volte la stessa identica richiesta.
2.4.6 Trasmissione dei messaggi senza Reliability
CON NON ACK RST
Request X X - -
Response X X X -
Empity * - X X
Il simbolo "*" indica che la combinazione non viene utilizzata nel normale funzionamento del
protocollo ma solo per generare un messaggio di ripristino ("Coap ping").
2.4.7 Messaggi e Endpoint
Un endpoint CoAP è la sorgente o la destinazione di un messaggio CoAP. In questo protocollo
l'endpoint viene identificato a seconda della modalità di sicurezza utilizzata. Senza alcun sistema di
sicurezza, l'endpoint è solamente identificato da un indirizzo IP e un numero di porta UDP. Con
altre modalità di sicurezza, l'endpoint viene identificato come definito dalla modalità di sicurezza
utilizzata. All’interno di questo protocollo esistono vari tipi di messaggi. Il Tipo di messaggi può
essere individuato dal campo tipo del header. Oltre al tipo i messaggi possono essere classificati in:
richiesta, risposta oppure vuoto. La classificazione di tali messaggi può essere riconosciuta grazie al
campo codice dell’header. Se la classe del campo codice presenta il valore 0 allora quest’ultimo
risulta essere un messaggio di richiesta, altrimenti è un messaggio di risposta. Caso particolare è il
codice 0.00. Tale codice viene utilizzato per segnalare la presenza di un messaggio vuoto. In un
messaggio vuoto il campo lunghezza del Token deve essere impostato su 0 e non deve essere
presente payload. Nel caso almeno una di queste condizioni non vengano rispettate allora il
messaggio vuoto verrà processato come un messaggio di errore.
2.4.8 Controllo congestione
Un elementare controllo della congestione è effettuato utilizzando il meccanismo di bake-off
esponenziale. Per non causare congestione i client devono limitare le interazioni simultanee
eccezionali che mantengono in un determinato momento con uno specifico server. Il numero
17
massimo di interazioni è indicato dal parametro NSTART. Una interazione eccezionale è un
messaggio confermabile (CON) per il quale si sta aspettando ancora un acknowledgement o una
risposta. Il valore di default di interazioni simultanee aperte ammesse è 1. Al raggiungimento
dell’istante di tempo denominato EXCHANGE_LIFETIME il client termina l’attesa di una risposta
e pertanto l’interazione eccezionale può considerarsi conclusa.
2.4.9 Regole per il matching delle richieste e delle risposte
Le regole per il matching di una risposta a una richiesta sono le seguenti:
L'endpoint di origine della risposta deve essere lo stesso dell'endpoint di destinazione della richiesta originale.
In una risposta piggybacked, l'ID messaggio della richiesta confermabile e la acknowledgement devono corrispondere e i token della risposta e della richiesta originale devono coincidere. In una risposta separata, solo i token della risposta e della richiesta originale devono corrispondere
18
Capitolo 3: Il protocollo LwM2M
Il protocollo LwM2M4 è un protocollo ideato per dispositivi con risorse limitate, nel seguito
indicati come ‘LwM2M devices’. Per questi dispositivi è necessario utilizzare un protocollo leggero
e compatto ed un efficiente modello di dati delle risorse.
L’OMA5 definisce un ‘LwM2M Enabler’ dotato delle seguenti caratteristiche:
Un modello di risorse semplice
Operazioni per la creazione, l'aggiornamento, la cancellazione e il recupero delle risorse.
Notifiche asincrone delle modifiche delle risorse.
Supporto per diversi formati di serializzazione.
Sicurezza della comunicazione basata sul protocollo DTLS6 che supporta diversi tipi di
credenziali.
Funzionalità per un client LwM2M di informare il server LwM2M che potrebbe essere
disconnesso per un periodo prolungato e di avvisarlo quando diventa nuovamente
raggiungibile.
Supporto per l'utilizzo di più server LwM2M.
Fornitura di credenziali e ‘access control lists’ da un server di avvio dedicato (LwM2M
bootstrap-server).
L'Enabler LwM2M definisce il protocollo di comunicazione, a livello di applicazione, tra un server
LwM2M e un client LwM2M, che è situato in un dispositivo LwM2M. Viene, quindi, introdotta
un'architettura client-server, dove il dispositivo LwM2M funge da client LwM2M ed il servizio,
ovvero l'applicazione M2M, funge da server LwM2M.
L'Enabler LwM2M dispone di due componenti, LwM2M Server e LwM2M Client e quattro
interfacce tra queste due componenti che sono:
Bootstrap
Client Registration
Device management and service enablement
Information Reporting
L'Enabler LwM2M utilizza il protocollo CoAP, descritto nel capitolo precedente.
Il DTLS fornisce la sicurezza per il livello di trasporto UDP.
4 LwM2M è acronimo di Lightweight Machine-to-Machine 5 OMA è acronimo di Open Mobile Alliance 6 DTLS è acronimo di Datagram Transport Layer Security
19
L’architettura è mostrata nella figura seguente:
Nella figura successiva è mostrato lo stack del protocollo LwM2M:
L'Enabler LwM2M definisce un modello di risorse semplice; ogni pezzo di informazione, reso
disponibile dal Client LwM2M, è una Risorsa.
20
Le Risorse sono logicamente organizzate in Oggetti.
Ad ogni Risorsa è assegnato un identificatore unico all’interno dell’oggetto.
Ad ogni Oggetto è assegnato un identificatore unico allocato e mantenuto dall’ OMNA7.
Nella figura seguente è illustrata questa struttura e le relazioni tra le Risorse e gli Oggetti.
Il Client LwM2M può avere un numero di Risorse qualsiasi, ognuna delle quali appartenenti ad un
Oggetto. Per esempio, l’Oggetto ‘Firmware Update’ contiene tutte le Risorse usate per il firmware
update.
L'Enabler LwM2M definisce Oggetti e Risorse standard. Altri Oggetti possono essere aggiunti
dall’OMA8 o da altre organizzazioni per abilitare Servizi M2M
9 addizionali.
Nella versione 1.0 dell'Enabler LwM2M sono definiti i seguenti Oggetti standard: 0. Security Object
1. Server Object
2. Access Control Object
3. Device Object
4. Connectivity Monitoring Object
5. Firmware Update Object
6. Location Object
7. Connectivity Statistics Object
Una Risorsa può contenere un valore (se essa è Readable e/o Writeable) oppure può essere
indirizzata da un server LwM2M per eseguire un’azione nel client LwM2M (se è Executable).
La specifica dell’Oggetto definisce le operazioni (Read, Write, Execute) che sono individualmente
consentite per le Risorse appartenenti a quell’Oggetto.
L'Enabler LwM2M definisce un meccanismo di controllo degli accessi per le ‘Object Instances’. Le
‘Object Instances’ dovrebbero avere associate un ‘Access Control Object Instance’. Un ‘Access
Control Object Instances’ contiene una Access Control Lists (ACLs) che definisce quali operazioni
sono permesse su una ‘Object Instance’ per quel/quei Server LwM2M.
L'Enabler LwM2M definisce quattro formati di dati: plain text, opaque, TLV e JSON. Il Server
LwM2M deve supportare tutti questi formati di dati; il Cliente LwM2M deve supportare almeno il
formato TLV.
3.1 Le interfacce
Come già detto precedentemente, ci sono quattro interfacce: 1) Bootstrap, 2) Client Registration, 3)
Device Management and Service Enablement, e 4) Information Reporting.
Le operazioni per queste interfacce possono essere operazioni di uplink, se dirette dal Client
LwM2M al Server LwM2M, oppure operazioni di downlink, se dirette dal Server LwM2M al Client
LwM2M.
Le operazioni su queste interfacce sono riassunte nella seguente tabella:
7 OMNA è acronimo di Open Mobile Naming Authority 8 OMA, acronimo di Open Mobile Alliance 9 M2M, Machine to Machine
21
3.1.1 L’interfaccia Bootstrap
L'interfaccia Bootstrap viene utilizzata per fornire informazioni essenziali nel client LwM2M per
consentire al client LwM2M di eseguire l'operazione di registrazione con uno o più server LwM2M.
Ci sono quattro modalità di bootstrap supportate dall'Enabler LwM2M:
Bootstrap di fabbrica
Bootstrap da Smartcard
Bootstrap iniziato dal Client
Bootstrap iniziato dal Server
Le ultime due modalità Bootstrap richiedono l'ausilio di un Bootstrap-Server LwM2M ed è
necessario che il Client LwM2M abbia un Account Bootstrap-Server sul Bootstrap-Server.
Il Bootstrap-Server LwM2M deve supportare sia il Bootstrap iniziato dal Client che quello iniziato
dal Server.
Il Client LwM2M deve supportare almeno una modalità di bootstrap specificata nell'interfaccia di
Bootstrap.
Il modello operazionale è schematizzato nella figura seguente:
3.1.1.1 Bootstrap di fabbrica
In questa modalità il Client LwM2M viene fornito delle informazioni di Bootstrap necessarie prima
del suo utilizzo.
22
3.1.1.2 Bootstrap da Smartcard
Quando il dispositivo supporta una smartcard, il Client LwM2M deve recuperare ed elaborare i dati
di bootstrap contenuti nella smartcard.
Operativamente, dopo che il recupero dei dati di bootstrap è riuscito, il Client LwM2M deve
applicare le informazioni di Bootstrap della Smartcard alla sua configurazione, per aumentare la
sicurezza. A causa della natura sensibile di questi dati, deve essere stabilito un canale di
comunicazione sicuro tra la Smartcard ed il Device.
Il Client LwM2M deve anche assicurarsi che i dati recuperati precedentemente dalla Smartcard
siano rimasti invariati all’interno della stessa. Se questi dati sono variati, le precedenti informazioni
di Bootsrap devono essere disabilitate nel Client LwM2M e questo dovrebbe applicare le nuove
informazioni alla sua configurazione. Se la Smartcard è disabilitata, come accade se essa viene
rimossa, le informazioni di Bootstrap da questa precedentemente caricate, devono essere cancellate.
Il controllo per entrambi questi due casi deve essere eseguito ogni volta che viene eseguita una
operazione di “Register” o di “Update”.
3.1.1.3 Bootstrap da Client
Questa modalità si ha quando il riferimento del Server LwM2M non è configurato nel Client
LwM2M oppure quando l’operazione di “Register” con il Server LwM2M è fallita. Quando ciò
accade, questa modalità fornisce un meccanismo per recuperare le informazioni di Bootstrap da un
Bootstrap-Server LwM2M.
Questa modalità Il Bootstrap iniziato dal Client richiede che il Client LwM2M abbia un Account
Bootstrap-Server sul Bootstrap-Server. Le informazioni minime che occorre siano precaricate sono
le credenziali per la sicurezza per una connessione sicura DTLS al Bootstrap-Server LwM2M.
Nella figura seguente è rappresentato il flusso dei dati per questa modalità:
23
Step 0 - Il client LwM2M invia un "Bootstrap-Request" al Bootstrap-Server LwM2M identificato
dal suo URI10
che è stato precaricato nel Client LwM2M. Il client LwM2M invia l’ “Endpoint
Client Name”, come parametro per consentire al Bootstrap-Server LwM2M di fornirgli le
informazioni di Bootstrap.
Step 1 - Il Bootstrap-Server LwM2M configura il Client LwM2M con le informazoni di Bootstrap
usando le operazioni di “Write” e/o “Delete”.
Step 2 – Quando il Bootstrap-Server LwM2M ha finito di inviare le informazioni di Bootstrap al
Client LwM2M invia un ‘Finish Bootstrap Indication’ al Client per chiudere correttamente questa
fase. Se il Client non riceve il ‘Finish Bootstrap Indication’ in un certo periodo deve considerare la
procedura di Bootstrap fallita.
Step 3 - Se il comando Bootstrap-Finish è stato ricevuto dal client LwM2M e la configurazione
caricata è considerata coerente dal Client LwM2M, viene eseguita un’operazione di pulizia.
3.1.1.4 Bootstrap da Server
In questa modalità, il Bootstrap-Server LwM2M configura le informazioni di Bootstrap nel Client
LwM2M, senza una richiesta di "Bootstrap-Request" al Bootstrap-Server LwM2M da parte del
Client LwM2M. Pertanto il Bootstrap-Server ha bisogno di sapere se il dispositivo LwM2M è
pronto per il Bootstrap. Il meccanismo col quale il Bootstrap-Server acquisisce questa
informazione è una implementazione specifica. Uno scenario comune è che gli elementi della rete
del provider informano il Bootstrap-Server LwM2M quando un dispositivo LwM2M si connette
alla rete del provider.
In questa modalità occorre che il Client LwM2M abbia un Account e le credenziali di sicurezza per
una connessione sicura DTLS al Bootstrao-Server LwM2M siano precaricate. Quando al
Bootstrap-Server è stato notificato che il dispositivo LwM2M è pronto per ricevere le informazioni
di Bootstrap,
vengono eseguiti gli step dal numero 1 al 3 del paragrafo precedente. Il flusso delle informazioni è
quindi il seguente:
10 L’URI (Uniform Resource Identifier) è una sequenza di caratteri che identifica univocamente una risorsa generica.
24
3.1.1.5 I comandi di Bootstrap Si elencano brevemente i comandi utilizzati sull’interfaccia Bootstrap; essi utilizzano il protocollo
CoAP11
.
BOOTSTRAP-REQUEST. Questo comando è utilizzato per iniziare una sequenza di Bootstrap
nella modalità ‘Bootstrap iniziato dal Client’.
BOOTSTRAP-FINISH. Questo comando è utilizzato unicamente per terminare una sequenza di
Bootstrap iniziata in modalità ‘Bootstrap iniziato dal Client’ oppure in modalità ‘Bootstrap iniziato
dal Server’. Con questo comando si informa il Client LwM2M che tutte le informazioni per il
Bootstrap sono state fornite.
BOOTSTRAP DISCOVER. Questo comando viene utilizzato per scoprire quali ‘LwM2M
Objects’ e quali ‘LwM2M Object Instances’ sono supportate da un determinato Client LwM2M.
Questo comando è utile per ripulire o aggiornare la configurazione del Client LwM2M.
BOOTSTRAP WRITE. Per effetto di questo comando il client LwM2M scrive il valore incluso
nel payload indipendentemente dall'esistenza della relativa ‘LwM2M Object Instance’ o ‘LwM2M
Resource. Questo comando può essere inviato più volte.
BOOTSTRAP DELETE. Con questo comando viene cancellata la ‘LwM2M Object Instance’
indicata.
3.1.2 L’interfaccia Client Registration
L'interfaccia ‘Client Registration’ viene utilizzata da un Client LwM2M per registrarsi con uno o
più Server LwM2M, mantenere aggiornata la registrazione e, alla fine, deregistrarsi da un server
LwM2M.
Quando viene inviato il messaggio “Register” il Client LwM2M fornisce al Server LwM2M le
informazioni necessarie per ricontattarlo (per es.: ‘End Point Name’) nonché le informazioni
aggiornate sugli ‘Object’ supportati e sulle ‘Object Instances’ esistenti sul Client LwM2M.
Il Client LwM2M esegue periodicamente un aggiornamento delle sue informazioni di registrazione
al o ai Server LwM2M con cui si è registrato tramite il messaggio “Update”. Se il lifetime della
registrazione scade senza che sia stato ricevuto un “Update” dal Client LwM2M, il Server LwM2M
rimuove la registrazione di questo Client LwM2M e questo deve ri-registrarsi per connettersi
nuovamente.
Infine, il Client LwM2M, quando determina che non è più richiesta la disponibilità del Server
LwM2M, ad esempio nel caso di un Factory Reset o di un suo uso discontinuo, invia il messaggio
“De-register”. Al ricevimento di questo messaggio il Server LwM2M elimina le informazioni di
registrazione.
11 CoAP è acronimo di Constrained Application Protocol
25
Riepilogando, il flusso dei messaggi relativi a questa interfaccia è il seguente:
3.1.3 L’interfaccia Device Management and Service Enablement
L’interfaccia ‘Device Management and Service Enablement’ viene usata dal Server LwM2M per
accedere alle ‘Object Instance’ ed alle Risorse disponibili di un Client LwM2M registrato 12.
L'interfaccia fornisce questo accesso tramite l'utilizzo dei comandi “Create”, “Read”, “Write”,
“Delete”, “Execute”, “Write-Attributes”, or “Discover”.
READ. Il comando “Read” viene usato per accedere al valore di una ‘Resource’, o ai valori di un
array delle ‘Resource Instances’, o ad una ‘Object Instance’ o a tutte le ‘Object Instances’ di un
‘Object’.
DISCOVER. Il comando “Discover” è usato per apprendere gli attributi di un ‘Object’, o delle
‘Object Instances’, o delle ‘Resources’.
WRITE. Questo comando viene usato per cambiare il valore di una ‘Resource’, o i valori di un
array delle ‘Resource Instances’, o i valori di più ‘Resources’. Il messaggio deve contenere il valore
da scrivere in uno dei formati supportati13
.
WRITE-ATTRIBUTES. Questo comando viene usato per cambiare gli Attributi14
. I valori degli
Attributi sono specifici di un dato Server LwM2M.
EXECUTE. Questo comando è utilizzato dal Server LwM2M per avviare un'azione e può essere
eseguita solo su Risorse individuali.
CREATE. Questo comando è usato dal Server LwM2M per creare una o più ‘Object Instance’
all’interno del Client LwM2M.
12 registrato secondo la procedura descritta al § 3.1.2. 13 V. § 3. 14 Gli attributi sono metadati che possono essere associati a un Object, ad una Object Instane o ad una Resource.
26
DELETE. Questo comando è usato per cancellare una ‘Object Instance’.
Di seguito si riporta il flusso dei messaggi di questa interfaccia relativi a due esempi.
3.1.4 L’interfaccia Information Reporting
L'interfaccia ‘Information Reporting’ viene utilizzata da un Server LwM2M per osservare eventuali
modifiche di una Risorsa su di un Client LwM2M registrato15
, ricevendo notifiche quando sono
disponibili nuovi valori. Questa relazione di osservazione viene avviata inviando il comando
15 registrato secondo la procedura descritta al § 3.1.2.
27
"Observe" al Client L2M2M per un ‘Object’, una ‘Object Instance’ o una ‘Resource’.
L'osservazione termina quando viene eseguito il comando "Cancel Observation".
Di seguito una breve descrizione dei comandi utilizzati su questa interfaccia.
OBSERVE. Con questo comando il Server LwM2M fa partire l’osservazione per eventuali
variazioni relative ad una Risorsa specifica o a Risorse di una ‘Object Instance’ o per tutte le
‘Object Instance’ di un ‘Object’ all’interno di un Client LwM2M.
Fino a quando il Client LwM2M non invia un nuovo messaggio “Register”, il server LwM2M
prevede che il Client LwM2M ricordi le richieste di osservazioni. Se un Client LwM2M dimentica
queste richieste, come avviene, ad esempio, in caso di un factory reset del dispositivo, esso deve
eseguire una nuova operazione “Register”.
NOTIFY. Questo comando viene inviato dal client LwM2M al server LwM2M durante un valido
periodo di osservazione su di una ‘Object Instance’ o su di una ‘Resource’. Nel messaggio è
contenuto il nuovo valore della ‘Object Instance’ o della ‘Resource’.
CANCEL OBSERVATION. Il comando “Cancel Observation” viene inviato dal Server LwM2M
al Client LwM2M per terminare le operazioni di osservazione.
Di seguito si riporta un esempio di flussi dei messaggi per questa interfaccia.
3.2 Modello delle risorse
Il protocollo LwM2M definisce un semplice modello delle risorse. Definiamo risorsa ogni tipo di
informazione utilizzabile dal LwM2M Client. Le risorse sono contenute negli oggetti ed ogni
risorsa ha un identificativo univoco all’interno dell’oggetto per permettere il suo riconoscimento.
28
Un client può avere un numero indeterminato di risorse ma ognuna di queste deve appartenere ad un
oggetto, anch’esso dotato di un identificativo univoco per essere riconosciuto.
Un oggetto specifica esclusivamente un raggruppamento di risorse pertanto va prima di tutto
istanziato dal client per poter usare le risorse collegate.
Una risorsa all'interno di un'istanza di oggetto può essere: un valore
un indirizzamento utilizzato dal server LwM2M per attivare un'azione nel client LwM2M.
La specifica dell’oggetto definisce le sue caratteristiche e quelle delle risorse ad esso correlate.
Le caratteristiche più importanti memorizzate all’interno della specifica sono: le operazioni (Read, Write, Execute) supportate individualmente dalle risorse appartenente a
tale oggetto.
la possibilità di dichiarare obbligatorie o facoltative determinate risorse. Una risorsa
specificata come obbligatoria all'interno di un oggetto deve essere istanziata in ogni istanza di tale
oggetto. Una risorsa specificata come opzionale all'interno di un oggetto può essere omessa da
alcune o anche tutte le istanze di tale oggetto.
La possibilità di avere più istanze di oggetti e risorse.
3.2.1 Creazione e istanziazione di un modello delle risorse
Nel descrivere descrivere al meglio questo tipo di operazioni è stato utilizzato il framework Leshan.
Al termine del capitolo verrà fatta una piccola descrizione su tale framework.
29
3.2.1.1 Creazione di un modello delle risorse
Gli oggetti, come visto in precedenza, sono una raccolta di risorse con un noto ObjectID che
rappresentano un particolare tipo di sensore fisico, attuatore, oggetto collegato o altra origine di
dati. Invece le risorse che costituiscono l'oggetto rappresentano le proprietà statiche e dinamiche
dell'oggetto fisico collegato e del software in esso installato.
La creazione di tale modello avviene attraverso l’utilizzo di un file XML.
Il documento XML che descrive il modello delle risorse deve seguire la seguente forma:
Linea 5 - Nome del device
Linea 6 - Descrizione del device
Linea 7 - ID dell’oggetto. Permette l’identificazione in modo univoco dell'oggetto nel client
LwM2M( un client non può avere due oggetti aventi lo stesso ID).
Linea 8 - Specifica della versione LWM2M da utilizzare per questo determinato oggetto (quando la
versione minima LwM2M che supporta l'oggetto è la versione iniziale del protocollo LwM2M (1.0)
queste informazioni possono essere omesse)
Linea 9 - Versione dell’oggetto (quando la versione Object è la versione iniziale di tale oggetto
(1.0), le informazioni sulla versione dell'oggetto possono essere omesse)
Linea 10 - URN dell’oggetto. L’URN (Uniform Resource Name) è un URI che identifica una
risorsa all'interno di un namespace, ma, a differenza del URL, non permette l'identificazione della
locazione della risorsa stessa. L’utilizzo del URN risulta essere necessario per facilitare le
modifiche sui modelli delle risorse. Infatti, in questi casi , l’objectID non viene modificato ma deve
essere utilizzato un nuovo URN . La costruzione del URN deve seguire le seguenti regole:
urn:oma:lwm2m:oma:44:2.4
30
urn:oma:lwm2m:oma - parte fissa
44 - Id dell’oggetto
2.4 - versione dell’oggetto
Linea 11 - Indica la presenza di istanze multiple ovvero se l’oggetto supporta più istanze di oggetto
o meno. Se questo campo è "Multiple", il numero di Instance Instance può variare da 0 a molti. Se
questo campo è "Single", il numero di Instance Instance può valere 0 o 1.
Linea 12 - Indica un possibile obbligo del client nei confronti dell’oggetto. Se questo campo è
"obbligatorio", allora il client LwM2M deve in ogni caso supportare questo oggetto. Se questo
campo è "Facoltativo", il client LwM2M potrebbe supportare tale oggetto.
Linea 13 - Inizio definizione delle risorse
Linea 14 - Specificazione dell’ID della risorsa. Il Resource ID identifica in modo univoco la risorsa
all'interno dell'oggetto. Tale ID risulta essere univoco per l’oggetto ma ovviamente può essere
riutilizzato da altri oggetti presenti nel Client.
Linea 15 - Nome della risorsa
Linea 16 - Indica quali operazioni dell’interfaccia "Device Management & Service Enablement"
sono supportate sulla risorsa. Questo campo può essere impostato su una combinazione di R (Read,
Observe, Discover, Write-Attributes) ed W (Write) oppure può essere impostato su E (Esegui). Può
anche avere un valore nullo, il che significa che su questa risorsa non è consentito accedere tramite
l'interfaccia di "Device Management & Service Enablement", ma è consentito l'accesso tramite
l'interfaccia di "Bootstrap".
Linea 17 - indica se questa risorsa supporta più istanze di risorse o meno. Analogamente alla linea
11, se il valore riportato è questo campo è "Multiple", il numero di istanze di risorse può variare da
0 a molti. Se il campo è "Single", possiamo avere solo 0 o 1 istanze di risorse
Linea 18 - se questo campo è "obbligatorio", allora il client LwM2M deve in ogni caso supportare
tale oggetto. Se questo campo è "Facoltativo", il client LwM2M dovrebbe supportare questo
oggetto.
Linea 19 - indica il tipo di valore della risorsa. Le risorse che supportano l'operazione "Esegui" non
deve avere alcun tipo di dato associato.
Linea 20 - questo campo limita il valore di Resource
Linea 21 - descrizione della risorsa
In seguito riportiamo due tabelle riassuntive che forniscono una visione generale su tutti i valori
inseribili sui campi presenti all’interno del modello delle risorse.
Definizione degli oggetti:
31
Definizione delle risorse
3.2.1.2 Istanziazione delle risorse Dopo aver definito il modello delle risorse il passo successivo ovviamente risulta essere
l’istanziazione dell’oggetto da parte dell’applicazione Client. Il programma di seguitoriportato è
stato effettuato attraverso l’utilizzo delle operazioni fornite dal framework Leshan. In tale
applicazione abbiamo deciso di voler stanziare cinque oggetti distinti: un sensore di potenza (ID 3312)
un sensore di controllo dell’illuminazione (ID 3311)
un sensore di controllo della temperatura(ID 3303)
un oggetto security (ID 0)
un oggetto server (ID 1)
Il codice necessario per eseguire tale operazione è il seguente.
COSTANTI
CODICE
La prima operazione da eseguire è il caricamento dei moduli XML che vanno a definire gli oggetti
che desideriamo controllare. Le funzioni che permettono tale tipo di operazioni sono le seguenti: public static List<ObjectModel> loadDefault()
public static List<ObjectModel> loadDdfResources(String[] paths)
public static List<ObjectModel> loadDdfResources(String path, String[] filenames)
32
La funzione loadDefault() effettua il caricamento dei modelli degli LwM2M Object già definiti dal
protocollo. Gli oggetti sono:
LwM2M Security (ID 0),
LwM2M Server (ID 1),
Access Control (ID 2),
Device (ID 3),
Connectivity Monitoring (ID 4),
Firmware (ID 5), Location (ID 6),
Connectivity Statistics (ID 7).
La funzione loadDdfResources(String path, String[] filenames) e loadDdfResources(String[]
paths)
permettono il caricamento dei modelli attraverso l’utilizzo di file XML presenti in un determinato
filepath (se espresso).I valori presenti presenti nel file XML, vengono memorizzati nella classe
ObjectModel.
La classe ObjectsInitializer si preoccupa dell’inizializzazione degli oggetti. I costruttori previsti da
tale modulo sono due: public ObjectsInitializer()
public ObjectsInitializer(LwM2mModel model)
Nel caso andassimo ad utilizzare il costruttore senza argomenti, come si può evincere dal codice,
viene invocato il costruttore successivo. Il costruttore ObjectsInitializer(LwM2mModel model) nel
caso in cui model sia null decide di caricare e utilizzare i modelli di default.
La classe LwM2mModel è una raccolta di definizioni di oggetti LWM2M e non contiene funzioni
membro di rilevante importanza per fini pratici.
Inizializzazione di un oggetto può avvenire utilizzando una classe oppure un'istanza di una classe.
Tali inizializzazioni vengono eseguite con le funzioni membro della classe ObjectInizializer: public void setClassForObject(int objectId, Class<? extends LwM2mInstanceEnabler>
clazz)
public void setInstancesForObject(int objectId, LwM2mInstanceEnabler... instances)
La prima istruzione permette l'istanziazione dell’oggetto attraverso l’utilizzo di una classe mentre la
seconda permette l’istanziazione dell’oggetto attraverso l’utilizzo di una istanza dell’oggetto. La
prima operazione permette l’istanziazione di un singolo oggetto a differenza della seconda che
permette l’istanziazione di più oggetti contemporaneamente, grazie all’utilizzo di un array.
33
Le istruzioni che sono state utilizzate per l'istanziazione degli oggetti sono presenti tra la linea 48 e
la linea 53 del codice.
L’istruzione initializer.setInstancesForObject(SECURITY, noSec(serverURI, 123));
viene utilizzata per istanziare l’oggetto di sicurezza,fondamentale poiché permette il collegamento
al server LwM2M. In tale codice è stato deciso di non utilizzare il bootstrap Server e il
PSK.L’istruzione public static Security noSec(String serverUri, int shortServerId), infatti,
restituisce una nuova istanza security (NoSec) per un server di device management.
L’istruzione presente nella linea 54
initializer.setInstancesForObject(SERVER, new Server(123, 30, BindingMode.U, false));
permette l'inizializzazione dell’oggetto Server. Tale oggetto ci va a definire le modalità di
collegamento con il server che verranno utilizzate dal Client. Il secondo parametro è il costruttore
della classe Server che il framework mette a disposizione:
public Server(int shortServerId, long lifetime, BindingMode binding, boolean notifyWhenDisable)
Di particolare interesse è il secondo parametro del costruttore. Il BindingMode ci permette di
decidere il protocollo a livello trasporto che il client ha intenzione di utilizzare per collegarsi con il
Server.
Le altre istruzioni permettono l’inizializzazione del device e degli altri oggetti. Dopo aver preparato
gli oggetti con tutte le informazioni necessarie con l’istruzione presente nelle linee 55-56 si può
passare alla creazione degli stessi. Tale istruzione richiede necessariamente tra i valori inseriti come
parametri di ingresso l’id 0. In caso di sua assenza il programma lancerà una eccezione runtime che
causerà l’arresto improvviso del programma.
3.2.2 Collegamento con il livello trasporto
In tale sezione andiamo ad analizzare come vengono implementati i protocolli descritti in
precedenza, sulle relative interfacce.
3.2.2.1 Bootstrap Interface
L'interfaccia bootstrap viene utilizzata per configurare un LwM2M client in modo tale che possa
registrarsi ad un determinato LwM2M server. L'operazione di bootstrap client viene eseguita
inviando una richiesta POST CoAP al server di bootstrap. Tale richiesta deve contenere l’Endpoint
Client Name come parametro della query.
Durante l’operazione di bootstrap, il Bootstrap-Server esegue una serie di operazioni di scrittura
(PUT), discovery (GET) e/o cancellazione (DELETE).
Il bootstrap server informa il client della terminazione di tale procedura con l’invio di un messaggio
bootstrap-finish (POST).
34
3.2.2.2 Registration Interface
L'interfaccia di registrazione viene utilizzata dal LwM2M client per registrarti ad un LwM2M
server, identificato da un URI. La registrazione viene eseguita inviando un messaggio CoAP
di POST all'URI del server con i parametri di registrazione passati come parametri della stringa
della query. Nel caso la registrazione venga eseguita con successo il server invia al client il
Location-Path. Il Location-Path indica il percorso da utilizzare per aggiornare o eliminare la
registrazione. L'aggiornamento della registrazione viene eseguito utilizzando un POST CoAP al Location-Path
restituito al client a seguito della registrazione. La disattivazione viene eseguita inviando un CoAP DELETE al Location-Path restituito al client a
seguito della registrazione.
35
Messaggio di richiesta registrazione
Messaggio di risposta
3.2.2.3 Device Management & Service Enablement Interface L'interfaccia di Device Management & Service viene utilizzata per accedere e gestire le risorse.
Un'istanza di oggetto viene identificata, come già visto in precedenza, dal percorso / {Oggetto ID} /
{OggettoID istanza}.
L'istanza o la risorsa di oggetto vengono letti inviando un GET CoAP al path corrispondente. La
risposta deve includere il valore richiesto nel formato corrispondente.
Un'istanza o una risorsa di oggetto viene scritta inviando un CoAP PUT o un CoAP POST al path
corrispondente. La richiesta comprende il valore da scrivere nel corrispondente formato.
Una Risorsa viene eseguita inviando un POST CoAP al path corrispondente. La richiesta può
includere un elenco di argomenti all’interno del payload, espressi in formato testo normale. Si
ricordi che iIl comportamento dell'operazione "Esegui" è specificato nella descrizione delle risorse
dell'oggetto.
36
Un'istanza di oggetto viene creata inviando un POST CoAP al path corrispondente. La richiesta
include il valore da scrivere nel corrispondente formato richiesto.
Un'istanza di oggetto viene eliminata inviando un CoAP DELETE al percorso corrispondente.
Messaggio di richiesta di lettura
37
3.2.2.4 Information Reporting Interface
L’interfaccia di Information Reporting Interface permette al client LwM2M di informare il server,
in maniera periodica e sistematica, di eventuali modifiche dei valori di una determinata risorsa.
L’implementazione di tale funzionalità avviene attraverso la CoAP Observation.
Questo semplice meccanismo viene attivato quando il server invia una richiesta GET con opzione
Observe pari a 0. Tale messaggio obbliga il client a informare il server di eventuali modifiche alla
risorsa che si desidera osservare.
Nei messaggi inviati dal client il token presente nell’header CoAP deve mantenere sempre il valore
indicato nel messaggio di Observation mandatoinviato dal server.
Il server LwM2M può annullare tale operazione inviando un messaggio RESET oppure con
messaggio GET con opzione Observe pari a 1.
Messaggio di richiesta di osservazione
38
Bibliografia
[1] OMA-TS-LightweightM2M-V1_0-20170208-A
[2] Ovidiu Vermensan, IoT-From Research and Innovation to Market Deploymentdel, River
Publishers, 2014
[3] Jan Holler,_Vlasios Tsiatsis, Catherine Mulligan, From Machine-to-Machine to the Internet
of Things Introduction to a New Age of Intelligence, Elsevier, 2014
[4] RFC 7252 CoAP
[5] RFC 7228 Terminology for Constrained-Node Networks
