Sei sulla pagina 1di 41

IOT ARCHITECTURE – ABSTRACTION LAYERS

Preprocessing

IoT non è una singola tecnologia ma un agglomerato di più tecnologie. Tutti gli scenari IoT sono Data-Driven
e dunque abbiamo la necessità di processare e memorizzare intelligentemente i dati per derivarne aspetti
interessanti di analisi. Tuttavia, queste capacità sono strettamente limitate dalle caratteristiche intrinseche
dei nodi IoT (limitati in dimensioni, energia, potenza). Possiamo decidere dunque di fare un preprocessing
(filtraggio) dei dati per diminuirne la mole. A noi interessa dunque avere dei dati correttamente processati
nel tempo reale.

Comunicazione

Un'altra challenge legata all’IoT è sicuramente la comunicazione: spesso i nodi, connessi senza cavi, non
hanno comunicazione affidabili.

Di seguito vediamo le architetture possibili, atte a gestire la complessità del mondo IoT.

Architettura a 3 livelli:

• Perception: più vicino al mondo fisico, con sensori, attuatori etc…


• Network: connette gli smart object tra loro e con i server.
• Application layer: responsabile di dare uno specifico servizio agli utenti finali.

Architettura a 5 livelli:

• Il network layer si splitta in due livelli: trasport layer (non c’entra con il trasporto del TCP IP) e il
processing layer. Il trasport layer trasferisce i dati ottenuti dal perception layer. Il processing layer
immagazzina e analizza i dati; usa database, cloud computing etc. Nel processing layer ha incluso il
middleware: questo permette ai livelli superiori di accedere ai dati in maniera eterogenea.
• Business layer: business, profit model, privacy dell’utente.

SPIEGAZIONE GENERALE DELL’ARCHITETTURA IOT

Il mondo IoT parte dal nostro microcontrollore, costituito da sensori e attuatori. Includiamo anche lo
smartphone ed i suoi sensori nel mondo IoT. Per motivi computazionali e tempistici, metto delle risorse di
computazione più vicine possibili al nodo IoT per fare operazioni di filtraggio, ad esempio tutto ciò è svolto
dal FOG computing. È come se avvicinassi il cloud al nodo IoT. In generale, il preprocessing può avvenire
anche sul MIST (concetto
simile al FOG; è una risorsa di
computazione ancora più
vicina al nodo rispetto al FOG
ed al CLOUD).

Il MIST fa preprocessing
all’interno del perception
layer (nel nodo o in cluster di
nodi); funge in locale per
sprecare meno energia
(filtrando i dati – inviandone
meno).
Sia MIST che FOG servono a fare da intermediari tra il nodo IoT e il servizio Cloud.

Tutte le app sono sostenute dal middleware, esso si occupa di nascondere ai dati, tutta la parte hardware di
sensori e attuatori del mondo IoT.

È fondamentale osservare la centralità della comunicazione nei nodi IoT; ci sono svariate tecnologie
utilizzate, da quelle proprietarie a quelle standardizzate basate su TCP/IP.

IOT PERCEPTION: SENSORS & ACTUATORS


I sensori sono fondamentali per dare al nodo IoT la consapevolezza del contesto e del mondo in cui
l’oggetto si trova. I requisiti principali sono: piccole dimensioni, costo basso, pochi consumi.

• Giroscopio: capta l’orientamento del device tramite masse e effetti capacitivi


• Magnetometro: capta campi magnetici (esempi di applicazione: indoor localization).
• Sensori Neurali: le onde celebrali possono essere categorizzate in onde alpha, beta, gamma etc in
maniera dipendente dalla frequenza.
• RFID: Tag Radio Frequency Identification; ogni tag può identificare in maniera univoca un id di un
elemento; vi sono elementi attivi o passivi in base all’alimentazione.
• Accelerometro: capta il movimento e l’accelerazione di un device nei 3 assi.
o Capacitivo: una massa fa spostare le armature di un condensatore
o Piezoelectric: una massa pressa un corpo, il quale misura una tensione.
o Semiconduttore: integrazione del’ accelerometro nel silicio. Un elettrodo (1) è capace di
oscillare verso altri due elettrodi (5,4). Posso misurare la tensione tra gli elettrodi. È
fabbricato su un microscopico chip di silicone come un transistor.

NB: ci sono altri esempi di sensori degli smartphone ma li ha semplicemente accennati…

Tutti questi sensori, ad esempio sullo smartphone, abilitano la “context awareness”, e dunque il mondo
IoT può abilitare dei servizi relativi al contesto fisico attorno all’utente (ES: servizio che conta chilometri
quando faccio una corsa).

Gli attuatori sono dei device che possono effettuare un cambiamento nell’ambiente attorno a noi
convertendo l’energia elettrica in qualche forma utile di energia. ES: aprire una porta, accendere le luce
etc...

IOT ARCHITECTURE: PREPROCESSING


Cloud computing è uno dei pezzi fondamentali dell’internet del futuro. Permette di connettere un grande
numero di oggetti fisici (animali, piante, smartphone) equipaggiati da sensori, i quali producono “big data”.
IoT sfrutta in maniera massiccia il concetto di big data, grazie alla sua grande mole di sensori e dunque di
contenuti informativi da essi provenienti. In
questa ottica, il cloud computing diventa una
risorsa centrale. Poiché i nodi IoT sono limitati
in potenzialità, il concetto di cloud come
“estensione” dei nodi è assolutamente
necessario. Tuttavia, con l’uso del Cloud PURO
in ambito IoT, vi sono comunque delle
problematiche:
o Mobilità: poiché la posizione del device cambia, è difficile che la connessione sia sempre affidabile;
o Real time actuation: problemi di latenza e di perdita di informazioni a causa dell’uso dei link
wireless;
o Scalabilità: più device connessi al cloud incrementano la latenza;
o Consumi: la comunicazione continua consuma molta potenza.

È possibile vedere nel grafico il grande consumo di potenza in un nodo; ciò avviene anche nello stato IDLE
(ovvero quando attendiamo una trasmissione ad esempio). Dobbiamo dunque evitare questa grande
dissipazione di potenza dovuta alla comunicazione; è necessario fare dunque un PREPROCESSING tale che
diminuisco i consumi legati alla comunicazione. Devo dunque investire in computazione locale
(PREPROCESSING) per non gravare troppo sui consumi a causa della comunicazione col cloud. Il problema
sta dunque nella natura centralizzata del Cloud Computing.

È nato dunque il paradigma FLUID COMPUTING. L’idea è dunque quella di distribuire il processing
(preprocessing) verso i nodi IoT, sfruttando i concetti di edge computing. Queste tecniche sono chiamate
MIST & FOG computing. Facendo cosi, elimino l’unica idea centralizzata del CLOUD, rendendo tutto più
dinamico in relazione ai 4 problemi dell’IoT in CLOUD.

LEZIONE 23/04

FOG VS MIST VS CLOUD


PERCHE’ SI USA IL FLUID COMPUTING? QUAL’E’ L’OBIETTIVO FINALE?

Per superare i limiti del “cloud computing” è stato necessario portare delle capacità di processamento fino
all’edge del network, vicino alla sorgente dei dati, ovvero al nodo IoT. In base alla “vicinanza” si parla di
MIST o FOG computing (entrambi fanno parte del FLUID computing paradigm).

Per comprendere questo modello, è possibile fare un riferimento alla realtà (in questo modello, la terra
rappresenta i nodi IoT):

• CLOUD è una nuvola densa d’acqua condensata in alto nel cielo;


• FOG è condensa meno densa che si trova sotto le nuvole;
• MIST è la nebbia vicino alla terra.

L’importante NON è questa nomenclatura ma il concetto di FLUID computing e di sistemi di


memorizzazione e di computing DISTRIBUITI. Tutto ciò al fine di fixare la latenza e i consumi nelle
comunicazioni.

QUESTE TECNOLOGIE SONO COOPERANTI? CHE VANTAGGI HANNO SUL CLOUD CLASSICO? IL CLOUD HA
SENSO?

Tutte e tre le tecnologie lavorano in cooperazione e sono complementari tra loro; ciò significa che possono
lavorare insieme al fine di minimizzare le debolezze di ognuna.

Vantaggi (in particolare lui si riferisce al FOG COMPUTING):

• LATENZA: Grazie alla prossimità del FLUID rispetto al CLOUD e rispetto al nodo IoT, si ha una
migliore latenza;
• DISTRIBUTION: tanti fog micro center, i quali costano molto meno di un data center (del CLOUD
computing);
• SCALABILITY: fog migliora la scalabilità del mondo IoT al crescere del numero dei nodi e degli user;
• STANDARDIZATION: compatibile con i servizi cloud.
• REAL TIME : migliori performance per servizi real time.
• ON THE FLY ANALISYS: FOG può effettuare data aggregation o filtering (opposto al concetto di raw
data del CLOUD processing puro).

In ultima analisi, il FLUID computing è particolarmente adatto al mondo IoT poiché snellisce il lavoro del
cloud tramite preprocessing dei dati che avviene su risorse computazionali più vicine ai nodi (FOG) o grazie
alla computazione dei nodi (MIST).

Il CLOUD ha comunque senso perché ha funzioni di grossa possibilità di storage e grandi potenzialità
computazionali per operazioni NOT real time.

FOG COMPUTING: Cos’è? Quali device sono usati? Perché sono usati? Quali progetti sono adatti? Problemi?

Fog computing è il paradigma attraverso il quale si porta capacità di computazione nelle connessioni tra i
nodi e il cloud server. Di solito questa capacità è attuata da device come gateway (posizionati nelle antenne
delle reti cellulari ad esempio). Il gateway ha maggiore capacità di storage e computazione e quindi può
ricevere dati da più sensori. FOG è usato da progetti che necessitano di processare dati da più sensori e con
minima latenza (ES: auto autonome). Il problema del FOG è proprio la centralità del gateway, il quale può
dare problemi ad un intero sistema qualora si guastasse (al gateway si agganciano più device appunto).

MIST COMPUTING: Cos’è? Quali device sono usati? Perché sono usati? Problemi? Cluster MIST?

MIST computing significa fare preprocessing sui sensori dei nodi IoT. L’obiettivo è quello di fare un
preprocessing ai fini di diminuire la dimensione dei dati (filtraggio) e dunque consumare meno nella
comunicazione/trasferimento; potenzialmente potrebbe diminuire anche la latenza perche invio meno dati
e saturo meno banda. La potenza di computing di solito viene dai microcontrollori integrati nei dispositivi:
per questo motivo, il processing MIST è molto più limitato.

NB: NON è esattamente detto che tutti i nodi abbiano funzionalità MIST, alcuni potrebbero essere
abbastanza limitati in risorse. Potrebbero esistere dei CLUSTER di nodi comunicanti che implementano
MIST computing.

MIDDLEWARE
A che serve? Cos’è? Che significa interoperabilità? Qual ‘è la funzione fondamentale del middleware?
Caratteristiche generali?

IoT è un mondo molto eterogeneo poiché include diverse tecnologie, protocolli, applicazioni. Serve dunque
un servizio che si occupa di gestire questa eterogeneità NASCONDENDOLA al livello applicativo ed al
developer che sviluppa l’app che sfrutta i nodi IoT. Costituisce una sorta di BRIDGE tra il mondo applicativo
e la realtà dei sensori.

Il middleware da un’ASTRAZIONE dell’hardware fornendo delle API per comunicazione, management dei
dati, computazione, sicurezza, privacy.

Il middleware deve dunque garantire l’interoperabilità dei sistemi IoT:

• Network interoperability: isola le applicazioni dal mondo dei protocolli di comunicazione


• Syntactic interoperability: garantisce che le app possano funzionare con formati, encoding dei dati
o strutture DIVERSE.
• Semantic interoperability: (penso sia legato al fatto che) ogni sensore può avere delle API che
descrivono il suo funzionamento.
La funzione FONDAMENTALE del Middleware è “device discovery and management”: questa feature
permette ad ogni nodo di essere consapevole degli altri device e dei servizi che essi forniscono. Infatti IoT è
un’infrastruttura molto dinamica; dunque il middleware fornisce API per tutti i device IoT , in modo tale che
si possano usare le varie funzionalità degli elementi connessi alla rete IoT.

Caratteristiche del middleware:

• Scalabilità per grandi numeri di device IoT


• Cloud Service: i dati devono essere salvati in un cloud centralizzato
• Big Data: big data algorithms per analizzare i risultati dei sensori IoT
• Sicurezza e privacy;

BIG DATA AND ANALYTICS


Uno dei fini del IoT e della sensoristica è quello di analizzare i dati e dunque estrarre knowledge da essi. Il
termine BIG DATA si riferisce al gigante volume di informazioni che arrivano dai sensori (spesso eterogenei
e non strutturati) e alla grande velocità con cui essi arrivano e devono essere processati. Tutto ciò si può
riassumere con: VOLUME, VARIETY, VELOCITY (in altre varianti viene aggiunto il concetto di VERACITY-
autenticità dei dati e VALUE – statistica e eventi).

Caratteristiche dei dati del mondo IoT:

• Streaming dei dati: tutti i dati IoT sono generati in uno stream continuo dai sensori dei nodi. Serve
dunque qualche algoritmo per estrarre gli eventi più significativi/ usare degli intervalli ragionevoli
per prendere i dati.
• Real Time: spesso le app IoT hanno la necessità di reagire (in base ai sensori) agli eventi circostanti
(tutto ciò deve essere fatto in tempo reale);
• Unstructured: diversi tipi di IoT device inviano diversi tipo di segnali (soprattutto in termini di
contenuto informativo)
• Identified: legato all’identità nel mondo IoT ( ci sono certe APP che necessitano di sapere la nostra
identità (app banking) mentre app che non necessitano di ciò (meteo)).
• Dati sensibili: ad es. informazioni mediche da proteggere nella comunicazione online.

Che tipo di Analytics possiamo fare?

• Descrittiva: risponde alla domanda “what is happening?” →probabilità future


• Diagnostic: “perché è avvenuto?” → cause degli eventi
• Predictive: “Cosa avverrà?” → previsione di trend sulla base di dati passati
• Prescriptive: “Cosa andrebbe fatto?” → dice la corretta azione da fare sulla base dello storico
passato

IOT: lezione 07/05; prima lezione dopo la pausa didattica.


COMMUNICATION (1)
Fin ora abbiamo visto l’architettura generale del mondo IOT, ora è fondamentale analizzare la parte di
comunicazione tra dispositivi IOT (ed eventualmente con internet). Analizzeremo l’insieme di tecnologie ed
algoritmi usati per la comunicazione tra smart object e i relativi problemi che portano con essi. La
comunicazione è il “ponte” che abilita il concetto di sentire, vedere, agire al fine di assumere decisioni
smart.
Perché sono necessarie le reti wireless? IOT necessita l’accessibilità ubiqua dei servizi, poiché gli utilizzatori
dei servizi e degli oggetti smart sono “mobile users”; il macrosettore coinvolto è ovviamente quello delle
reti wireless.

Considerando che spesso gli object sono alimentati a batteria, i network wireless sono generalmente a
bassa energia e inaffidabili (la rete wireless è meno affidabile di una cablata): per questi motivi sono
chiamati Low Power and Lossy Networks (LLNs).

Quali sono le sfide/problemi da risolvere dei sistemi wireless?

• fading
• interferenza (il cammino multipath è un esempio di interferenza causata dalla trasmissione del
segnale stesso)
• energia (gli smart object sono alimentati a batteria – in particolare la comunicazione consuma più
di computazione e sensing)
• sicurezza

Per tutti questi motivi, rendere le comunicazioni wireless “low power” è necessario per mantenere il
sistema IOT. Abbiamo finito la progettazione? NO, poiché i nodi sono limitati in risorse. Stiamo inoltre
parlando di “internet of things” e dunque i nodi devono essere connessi ad internet. Essi si connettono
tramite TCP/IP per la comunicazione con altri host (purché si conoscano gli indirizzi IP). Proprio per i vincoli
già detti, il protocollo che regola la comunicazione NON può essere lo stack di TCP/IP puro (ovvero quello
usato nel mondo desktop); dunque servono dei light protocols. L’avvento dell’IOT, ha mostrato la necessità
di ridisegnare alcuni protocolli per renderli leggeri (leggerezza significa che possono essere adoperati in
nodi con risorse di computazione limitate): anche le tecnologie di comunicazione devono consumare il
meno possibile. I protocolli devono dunque essere ridefiniti per essere sostenibili dalle caratteristiche degli
smart object.

Possiamo fare una distinzione nei light protocol:

• IP Compliant (compatibili con lo stack TCP/IP - il vantaggio è dialogare direttamente con internet)
• NON IP Compliant (significa che ci sono dei protocolli in cui sono stati inventati degli stack
protocollari leggeri per il mondo IOT che non sono ip compliant. Perché è stato fatto ciò? Ad
esempio per motivi di tecnologie proprietarie.)

Nella foto che vediamo sopra, possiamo vedere l’operazione che dobbiamo fare per trasportare uno stack
protocollare standard per desktop/server (a SX) in uno stack per IOT (a DX). A destra dunque vediamo le
necessità del mondo IOT a dispetto di ogni tecnologia dello stack protocollare STANDARD.

Quali sono le soluzioni disponibili? Quali sono le linee guida per la classificazione delle tecnologie wireless?

• Proprietario (ES: WirelessHart; di solito non standardizzata) vs open standard (ES:Wifi, Zigbee,
6LowPAN)
• Application specific vs application agnostic (non condizionato dall’applicazione) – Zwave per
l’automazione della casa, Wireless Hart per applicazioni industriali, 6LowPAN/Thread per tutto il
resto.
• IP compliant vs non IP compliant (classificazione più importante: perché non sono tutti IP
compliant? Prendiamo in esempio il bluetooth, dove la “alliance” che lo ha standardizzato non ha
accettato di complicare la strutturazione del bluetooth con la standardizzazione “IP compliant”.
Tutto ciò ha costretto il mondo tecnologico allo sviluppo di tecnologie ANCHE “non IP compliant”).

Vediamo come si comportano le tecnologie wireless incluse nella WPAN (wireless personal area network) in
relazione al data rate e alla distanza.

Commenti: Vediamo come il WIFI standard, avendo Data Rate molto alti, è impossibile da implementare nel
mondo IOT per problemi di consumi; per questo motivo è stato creato il Wifi Low Power. Tuttavia, sia per
wifi che per wifi HaLow, si parla non più di WPAN ma di WLAN (wireless local area network – non ha detto
in maniera seria la differenza).

Zigbee VS 6LowPAN
La differenza principale è che 6LowPAN estende IP all’ IOT (IP Compliant – rivisita e concepisce in maniera
più leggera lo stack standard TCP/IP) mentre Zigbee non ha questa implementazione. I primi due livelli
architetturali (physical e MAC – medium acces control) sono stati standardizzati dalla IEEE e sono uguali sia
in ZigBee che in 6LowPAN.

NB: NON ha strettamente specificato molto a riguardo dei livelli superiori a PHY e MAC, ha solo detto che ad
esempio lo stack TCP/IP è stato modificato per adattarsi al mondo LOW POWER; inoltre spesso viene usato
UDP perche essendo “connectionless”, è più leggero.

Sia la parte di network, sia le API e l’“application support” di Zigbee funziona diversamente dal mondo “IP
compliant”.
Quali sono le feature di zigbee?

• Low cost Hardware e software


• Raggio limitato (10m)
• Bassa latenza
• Alta efficienza energetica.

Quali sono le applicazioni di zigbee? Usato molto prima dell’avvento del bluetooth LE, ad esempio le fasce
cardiache usavano zigbee grazie al basso consumo. Altri esempi? Monitoring dei pazienti, fitness
monitoring, controllo industriale, pc e periferiche, lighting control, garden irrigation, etc..

Protocollo standardizzato tra ZigBee e 6LowPAN: IEEE 802.15.4


Il protocollo IEEE 802.15.4 è stato creato per specificare un sublayer per MAC e PHY per “low-rate wireless
private area network” (LR-WPAN). I vantaggi di questo protocollo sono i bassi consumi, bassi data rate,
basso costo, alto throughtput, comunicazione affidabile con un grande numero di nodi (65 mila). È usato
per IOT, machine to machine (M2M) e wireless sensor network (WSNs). Da questo poi si sviluppano
direttamente il 6LowPAN con la struttura IP compliant e Zigbee con un stack proprietario sopra. Qual è il
problema complessivo? Far comunicare il mondo NON IP compliant con il mondo IP compliant.

IEEE 802.15.4 ESSENTIALS


NB: da qui in poi, ci riferiremo praticamente solo a questo protocollo, analizzandolo nei suoi vari aspetti.

802.15.4 è un protocollo wireless utilizzato da Zigbee e 6LowPAN. Vengono definiti due tipi di device. Il
primo è “Full function device (FFD)”: può trasmettere beacon, può comunicare con altri device FFD, routing
di frame, può agire come PAN (personal area network) coordinator (spesso il coordinator è alimentato). La
seconda categoria di nodi è RDF (reduced function device): non possono fare routing di frame, non
possono comunicare con RFD ma solo con FFD, sono alimentati a batteria. Fra gli FFD vi è un PAN
coordinator: i dispositivi candidati a diventare PAN coordinator competono tra loro per essere coordinator
e ne vince solo uno quindi in una sottorete c’è solo un pan coordinator (gestisce
l’associazione/deassociazione alla PAN di altri device ed è responsabile della PAN). La topologia di
connessione è la Stella: al centro vi è un PAN coordinator (FFD coordinatore). La topologia MESH in cui i
dispositivi FFD possono comunicare tra di loro senza passare dal PAN coordinator mentre il RFD devono
necessariamente comunicare con il dispositivo FFD al quale sono agganciati. Vi è anche la topologia Cluster
Tree, che però NON è inclusa nel protocollo 802.15.4.
802.15.4: PHY
Per quanto riguarda il physical qui sono inserite alcune caratteristiche: de/attivazione del ricevitore radio,
fare “energy detection”, usare un “indicatore della qualità dei pacchetti ricevuti”. La CCA è quella funzione
che consente ad un nodo di sapere se il canale è libero o no e quindi dire al il nodo se può trasmettere.

NB: non ha detto molto di più, slide 17 SALTATA

802.15.4 MAC
Il MAC permette e garantisce le regole per l’accesso al canale condiviso. Si basa su alcuni principi: beacon
management (i beacon sono frame per lo scambio di informazioni), gestisce accesso al canale, gestisce GTS
(time slot garantiti), frame validation, ACK per la consegna, associa e disassocia nodi alla PAN, meccanismi
di sicurezza.

MAC: fuctional description


Due tipologie di operazioni sono disponibili:

• Beacon enabled: il pan coordinator ha un ruolo fondamentale perché scandisce i cicli degli slot per
tutti gli altri nodi. I cicli sono scanditi dai beacon, sono quelli entro cui i nodi che devono
trasmettere competono per l’accesso al canale. Usualmente usati in topologie a STAR. Viene usato
Slotted CSMA/ CA (Collision avoidance), sostanzialmente il nodo accede al canale evitando le
collisioni e inoltre ci sono trasmissioni schedulate.
• NO Beacon: pura CSMA/CA senza slot e senza beacon

SHARED CHANNEL ISSUES


Il problema sostanziale è quello del canale condiviso.

Soluzioni:

• Scheduled Access (“ti dico quando parlare”): basati su token ad esempio (quando ti arriva il token
puoi parlare), schema di tipo polling (chiediamo ai nodi se devono parlare), schema di tipo
centralizzato.
• Random Access (“ tu decidi quando parlare ma ti assumi il problema delle collisioni e devi gestirle”):
parzialmente non coordinati, i conflitti possono essere risolti usando procedure basate su “random
retrasmission delay” (quando i nodi insistono per trasmettere e ci sono collisioni, usiamo un timer
random in ogni nodo e dunque la probabilità che ognuno abbia timer uguali diventa più bassa – mi
spiego meglio, alla fine del timer , il nodo trasmette e poiché è difficile che ogni nodo abbia lo
stesso timer, allora le trasmissioni dei vari nodi avranno degli shift temporali).

SCHEDULED VS RANDOM
Scheduled (GSM, bluetooth, wifi)

• PRO: performance garantite in termini di delay e throughput


• CONTRO: coordinazione necessaria (nodo centrale ad esempio)

Random

• PRO: facile da implementare


• CONTRO: performance scarse per traffico pesante (collisioni)

NB: non ha detto molto di più

La risorsa da condividere è in realtà il tempo: dire che trasmettiamo senza collisioni è come dire che
trasmettiamo in tempi diversi e quindi il canale risulta sempre libero (ma ciò non è sempre possibile). Nel
caso del nostro protocollo si sceglie una combinazione delle due tecniche, ovvero un mix di scheduling e
random access.

• Scheduled Access: implementati tramite PAN Coordinator (solo con beacon attivati)
• Random Access: attraverso CSMA/CA, permesso tra RDF e tra RFD ed FFD ed il PAN coordinator

BEACON ENABLED MODE (per topologia tree)

Il PAN coordinator genera il Superframe Structure (vedi immagine sopra) ed è fatta da diversi campi:

• La superframe inizia e termina da due beacon (sotto responsabilità di PAN coordinator).


• Il primo campo è il CAP (contention access period); durante questo intervallo CAP vi sono un certo
insieme di time slot che vanno in contesa tra i nodi (attraverso CSMA/CA).
• Vi possono essere uno o più periodi GTS (guardanteed time slot): significa che sono etichettati dal
PAN per assegnarli a qualcuno dei nodi; vi possono essere più GTS in un beacon ma non si possono
superare i 15 slot. Gli slot GTS sono assegnati su richiesta.
• Poi vi è un periodo di inattività; la comunicazione dissipa un sacco di energia (anche in idle), quindi
il modo di risparmiare energia è proprio spegnerlo (inattività). Questo periodo deve avere una
durata tale da consumare il minimo di potenza possibile.

Vediamo ora come avviene la contesa.


CSMA/CA
Abbiamo 3 variabili che sono inserite in ogni nodo in contesa con il protocollo CSMA/CA:

• NB: è il numero di volte che l ‘algoritmo CSMA/CA richiede di fare backoff (è il numero di volte che
trasmetto ed il canale non è libero e quindi non posso trasmettere). Se NB è troppo alto , non
trasmetto più perche capisco che è impossibile
• CW: contention window lenght, è un parametro che stabilisce il numero di periodi di backoff
necessari per stabilire in maniera puntuale che il canale sia libero e che posso definitivamente
iniziare la trasmissione (inizializzato a due).
• BE: esponente di backoff che viene usato come esponente del due per dare il tempo dopo il quale
devo ritrasmettere; man mano che trovo occupato il canale, BE si incrementa.

CSMA/CA Glance
1. Prima di trasmettere, faccio partire questo periodo random di backoff (da 0 a 2^BE-1) e attendo
(Prima di trasmettere valuto il canale per vedere è idle) .
2. Inoltre, sempre prima di trasmettere (qualora io abbia passato lo step 1), guardo se il canale è
libero (idle) per CW periodi (slot) consecutivi di backoff (dunque la trasmissione non è immediata).
3. Dunque il nodo inizia la trasmissione e attende un ACK dal PAN coordinator.
4. Se il CCA (clear channel assesstments), mi dice che il canale NON è libero, aumento l’ esponente BE
e il numero di tentativi di backoff NB e la procedura è ripetuta.
5. Dopo un NBMax tentativi , il pacchetto è scartato. Tutto ciò serve ad accedere al canale condiviso.

CSMA altre caratteristiche


La procedura di trasmissione (incluso ACK) deve terminare entro il CAP(contention access period); l’accesso
senza beacon con il CSMA/CA è unslotted e non ha sincronizzazione ; CSMA non è applicata ne per i beacon
ne per gli ACK; in caso di collisione (anche per un ACK che non torna correttamente), allora la procedura
ricomincia.
FLOWCHART

Il ramo che va a destra usa la modalità senza beacon (unslotted) mentre in verticale abbiamo i Beacon.

BEACON

1. In modalità beacon metto NB=0 e CW=2


2. Faccio trascorrere periodo random
3. Se il canale è libero, non accedo subito ma decremento CW e trasmetto (se CW è 0)

UNSLOTTED

1. È più semplice
2. Pongo NB=0
3. NON accedo subito e faccio passare un periodo random
4. Se il canale è idle, trasmetto senno incremento.
NB: ricorda che fino a qui stiamo parlando del protocollo 802.15.4

MODALITA’ SLOTTED (BEACON)

Una cosa imposta nello slotted, è che l ACK deve arrivare entro lo stesso time slot. Vediamo nell’ immagine
sia i dati verso il PAN coordinator e sia da PAN coordinator a device. “From Coordinator” è più complesso
poiché vi sono competizioni tra i nodi persino per la “data request”; vi sono infatti due ACK. Entrambi gli
ACK sono interni allo slot.

Qual‘è la filosofia?: nella modalità slotted (beacon enabled) vi è un periodo CAP in cui si deve contendere il
mezzo canale poiché è condiviso, quindi faccio partire un esponente backoff, se il canale è libero , mi
assicuro che il canale sia libero per CW slot, allora mi sono impossessato del canale; se non ricevo l’ack,
allora sono stato sfortunato e qualcuno ha sopraffatto il nostro nodo in analisi. Nel GTS vi è la richiesta al
PAN coordinator per “prenotare” il canale.

NON beacon enabled (UNslotted)

NB:Non dice nulla di interessante oltre alle immagini e oltre alla NON presenza dei beacon e dunque alla
struttura “unslotted”.

NB: Da 31 a 37 non ha detto praticamente nulla


Thread
E’ uno stack aperto di networking di tipo “ip compliant stack”. E’ costruito su IEEE 802.15.4 nel livello PHY e
MAC , il quale opera in 2.4GHz. E’ affidabile, sicuro,bassa energia, ha una tipologia mesh/peertopeer.
Poiché è MESH, non soffre delle problematiche STAR ( se si rompe il coordinarore). Può supportare tutta la
parte di TCP/IP alleggerito che si chiama 6LowPAN con la possibilità di usare application layer alleggeriti.

NB: Anche qui ha semplificato rispetto alle slide.

LEZIONE 14/05 IoT


La tecnologia Thread utilizza il protocollo 802.15.4, è nata dall’alleanza di Google, Samsung, Free Scale
ecc., è stata costruita sul protocollo a 2.4 GHz, è caratterizzata da bassa latenza ed è stata proposta sul
mercato come una delle principali tecnologie che usa l’802.15.4. Presenta una topologia di rete di tipo
mesh ed è compatibile con IP (IP compliant, che può supportare uno stack in cui è presente TCP/IP). Il
Thread specifica i layer che stanno sopra il livello fisico e MAC. Per quanto riguarda l’application layer, non
c’è una “polarizzazione” nel supportarne un tipo specifico, infatti vengono utilizzati il COAP e il MQTT,
entrambi molto diffusi per IoT e che stanno entrambi su reti IP compliant. Il COAP richiede l’UDP, mentre
MQTT prevende il TCP come protocollo di trasporto.

Parla alla fine della lezione dei protocolli applicativi, e ha detto che farà il COAP E MQTT nella lezione del
21/05

802.11AH Low Power Wifi


È tra i protocolli IP compliant. In architettura internet abbiamo studiato l’802.11(Wifi classico): dopo
qualche anno è nata questa versione con l’obiettivo di indirizzarsi all’IoT. Il wifi classico è un protocollo
molto utilizzato ma consuma molta potenza, quindi l’idea di equipaggiare i sistemi IoT con questo
protocollo genera molti problemi per quanto riguarda il consumo energetico.

È stata definita la banda operativa del protocollo al di sotto di 1Ghz (maggiore attraversamento di alcuni
ostacoli, consumo più basso). Questo protocollo non contribuisce a interferire nella banda a 2.4GHz usato
dall’802.15.4. Altre tecnologia (BLE) sono orientate ad ambiti del wireless personal area network(reti che si
estendono per pochi metri, al massimo decine) mentre l’802.11 è una LAN e può coprire distanze più
ampie, quindi l’802.11AH può ricoprire aree fino a 1km, e può essere usato per LPWAN(low power
wireless area network - quindi viene usato per applicazioni in cui si usano soluzioni a bassa potenza di tipo
wireless ma per coprire distanze più ampie).

Nelle LWPAN si usano le topologie di tipo mesh per coprire distanze maggiori.
Il protocollo può essere usato in varie applicazioni: smart homes, wearables, tracking di animali,
automazione industriale. Coprendo distanze ampie, uno smartwatch può comunicare con l’access point
senza passare per lo smartphone (a cui è collegato solitamente con bluetooth): ciò dà una possibilità di
connettività maggiore.

Nasce come protocollo scalabile, quindi può supportare molti nodi (fino a 6k).

PROBLEMI DI COMPATIBILITA’

Come si possono integrare i dispositivi IoT (con le loro problematiche di dimensioni, bassi consumi,
computazione ecc.) ad internet? I protocolli usati per far accedere un sistema ad internet non erano
adeguati all’IoT (per le questioni discusse precedentemente) quindi sono stati creati protocolli a basso
consumo di potenza (6LowPAN- protocollo IP alleggerito che si adatta alle LPAN, ROLL).

6LoWPAN
È uno strato che adatta e fa sì che IPv6 possa essere usato all’interno di una low power wireless area
network (LPWAN): esso manipola il frame IPv6 in modo che sia compatibile con le caratteristiche di un
frame su uno 802.15.4 ed è stato definito anche un protocollo di routing (roll-rpl).

Fare questo significa rendere compatibile l’IPv6 con le limitazioni imposte dai nodi IoT, ovvero “mettere a
bordo” dei nodi IoT il TCP/IP. Ciò significa creare “WIRELESS EMBEDDED INTERNET” e quindi possiamo
legittimare quella denominazione che abbiamo utilizzato: “Internet of things” ovvero qualunque cosa può
essere connessa a internet.

Vantaggi della 6lowpan:

-usare uno standard che sia valido nel tempo

-easy learning curve: corrispondenza tra il TCP/IP con cui siamo abituati a lavorare e quello dei nodi IoT

-integrazione trasparente con internet, protocolli che tra loro si parlano

-scalabilità, tipica di internet

-esporre socket standard attraverso api

-uso minimo di codice e memoria, l’ottimizzazione dell’IPv6 rende tutto più leggero e quindi in grado di
essere integrato nei nodi con prestazioni importanti

Molto spesso Le LoWPAN sono agganciate con un unico collegamento ad internet(semplice, più LoWPAN
con lo stesso backbone link collegate a internet con un router, ad-hoc quando non c’è routing al di fuori
della LoWPAN), su Ipv6 avere uno stesso prefisso( *), quindi si porebbe eliminare una parte dell’header del
frame IPv6(STUB NETWORKS)

Ha solo elencato i problemi di integrazione su internet

Frame della 6LoWPAN


IPv6: MTU (maximum transmission unit) di 1280 bytes

6LoWPAN: MTU di 127 bytes

La 6LoWPAN permette di far connettere un dispositivo a internet adattando l’IPv6.

Come si comprime l’header del pacchetto? E il pacchetto vero e proprio con il suo payload?

• (*) valori comuni per i campi dell’header che possono essere sostituiti da forme più compatte (es.
il prefisso comune di LoWPAN)
• versione di IPv6, che occupa sempre un byte, può essere omessa perché è sempre la stessa
• traffic class e flow label sono zero ma occupano spazio nel pacchetto
• la lunghezza del payload dell’IPv6 può essere ricavata dai livelli sottostanti(che trasportano un
frame con un certo payload)
• source e destination addresses sono già presenti nel MAC

Fatte queste considerazioni, è possibili abbattere l’ampiezza dell’header del pacchetto IPv6 fino ad arrivare
a 2 byte. Questo è possibile grazie alla caratteristica della topologia mesh delle LoWPAN, anche se non è
sempre possibile.

Frammentazione del payload (da 1280 a 127 byte): la 6LoWPAN frammenta il payload in diversi blocchi,
ognuno dei quali può entrare nel pacchetto dell’802.15.4 di 127 bytes, e li numera in modo che il payload
originario possa essere ricostruito. Quando i livelli applicativi che utilizzano le LoWPAN sanno che sono in
IPv6 aiutano il lavoro evitando di mettere payload ampi, perché sanno che la frammentazione e la
ricostruzione sono onerose, e peggiorano la performance.

“Non ho nessuna intenzione di chiedervi i dettagli sulla 6LoWPAN”


BLUETOOTH LOW ENERGY(BLE)
Creato per risolvere i problemi del bluetooth standard (BR/EDR): alto consumo di potenza e mancanza di
scalabilità (non può essere usato in ambienti IoT). L’alto consumo di potenza che caratterizza il bluetooth
standard è nato per risolvere problemi non legati all’IoT: il nodo è infatti sempre attivo, anche quando non
ci sono dati da trasmettere, quindi consuma tanta potenza; non si possono avere molti nodi (max 8)
collegati. Invece il BLE consuma poco, può essere alimentato a batteria che dura anni, e quindi risulta un
fortissimo candidato ad essere utilizzato in ambienti in cui la dissipazione di potenza è uno dei problemi
fondamentali. Il low power bluetooth non può essere utilizzato per trasmettere con un alto throughput
quindi spesso si usa il dual-mode bluetooth: es sugli smartphone c’è sia quello low power che quello
originale.

Il BLE è stato definito nel 2011 e il suo target era uno scenario applicativo che richiedesse bassa
dissipazione e un throughput poco elevato. È chiamato anche bluetooth smart, usa uno short range radio
con minima dissipazione di potenza per poter operare a batteria, anche per anni. Il range di copertura è 10
volte maggiore del classico bluetooth, e la latenza 15 volte minore: il BLE è un ottimo candidato per la sua
utilizzabilità in ambito IoT.

È stato sviluppato immediatamente in tutti i telefonini, ed è applicato in innumerevoli scenari. In confronto


a Zigbee, BLE è più efficiente in termini di consumo di energia e di energia per bit trasmesso.

BLE è non IP compliant, anche se i livelli dello stack svolgono funzioni simili.

(Non ha parlato in dettaglio dello stack)

La prima versione del BLE aveva un payload di 27 bytes che poi è stato incrementato a 251 nella versione
4.2. La più recente è la 5.2: è stato aumentato sia il range (distanza che si può coprire) sia la dimensione del
payload nell’advertisement e un po' il throughput. Sebbene nasca per trasmettere frame a bassa potenza,
sono stati applicati miglioramenti rispetto alle prime versioni. Il range maggiore lo rende adeguato per
applicazioni che impiegano connettività building-to-building. Un miglioramento significativo è stato
l’aumento del data rate raddoppiando il rate di modulazione (BLE high-speed mode).

Bluetooth beacon: introdotto dalla Apple dopo la nascita di BLE(iBeacon). L’uso di beacon nel
bluetooth si riferisce al trasferimento periodico in broadcast di piccoli pezzi di informazioni(max 31 byte),
come sensor data o come marketing information(advertisement). Queste informazioni possono essere “c’è
un negozio che vende questo” oppure “stai guardando il quadro di van gogh a vattelapesca”: passi davanti
al beacon e sullo smarphone ricevi queste piccole informazioni.

BLUETOOTH 5: BLE CODED AND FEC


Uno dei problemi che si inputa quando nasce una tecnologia IoT è quella di consumare poco e coprire la
max distanza possibile, il che è normalmente possibile con le tecnologie wireless che fanno uso di mesh
networking. La topologia mesh è una delle soluzioni, oppure si può aumentare la potenza di trasmissione:
facendo ciò aumenta il consumo di potenza. Il bluetooth ha implementato il BLE coded and fec per
aumentare il range senza aumentare la potenza di trasmissione.
Quando un nodo A trasmette e il nodo B riceve, entro un certo range di distanza il nodo B riceve il segnale
con una BER che garantisce un certo livello di affidabilità della trasmissione. Il segnale però va oltre la
connected region all’interno della quale si garantisce quella BER, ad esempio fino al nodo C. Questa si
chiama transitional region. Questa caratteristica delle onde elettromagnetiche è stata sfruttata per creare
questa versione di bluetooth(CODED and FEC).

Quando il segnale arriva al nodo C, la BER è cresciuta, e l’affidabilità della connessione è più bassa. Per
risolvere, si usano diversi bit di informazione per rappresentar un singolo bit. Se il bit che viene ricevuto è
corrotto, a causa della distanza, esso può essere recuperato dagli altri bit di ridondanza.

2 opzioni per codificare il singolo bit:

-8 bit per codificare 1 bit

-2 bit per codificare 1 bit

Questa codifica incrementa il range di copertura fino a 4 volte e permette al bluetooth di coprire distanze
che vanno al di fuori, ad esempio, dell’abitazione (quindi in questa forma il bluetooth è adatto per la
building automation). Se uso la ridondanza, il throughput reale si abbassa perché “sacrifico” parte del
thoughput per fare la ridondanza.

Nel 2017 è stato creato un BLE con topologia mesh, già usata da Zigbee, dall’802.15.4, Thread ecc.

ADVERTISING NEL BLUETOOTH 5


Che sia un beacon o uno smartwatch, tutti i dispositivi periferici iniziano sempre in advertising mode.

L’advertising permette ai dispositivi di fare il broadcast di informazioni che definiscono la loro intenzione.

Ci sono 2 ragioni per fare il broadcast:

-stabilire una connessione bi-direzionale tra due dispositivi (smartphone e smartwatch)

-broadcast di informazione senza nessuna connessione con un altro dispositivo (trasmettere un beacon con
dei dati in un museo in cui c’è una vecchia mummia di 500 anni)

Ci sono diverse combinazioni di messaggi di advertising (smartwatch che richiede la connessione a un


dispositivo centrale qualunque, o a uno specifico, beacon verso qualunque dispositivo che ascolta, o solo ad
alcuni dispositivi interessati)
In uno scenario tipo smart city, o smart agriculture, in cui si vuole controllare lo stato di salute dell’orto che
sta a 500 m dalla fattoria, la composizione del terreno ecc. le distanze da coprire possono arrivare a
centinaia di metri, o addirittura a km. In questi casi, è sensato cercare di applicare l’IoT? Ovviamente sì, per
gli obiettivi stessi che si è prefissata. In questo caso però di parla di WWAN(Wireless Wide Area Network),
in cui certe tecnologie si devono adattare all’IoT , ovvero devono avere bassi consumi di potenza, in quanto
i nodi devono essere alimentati a batteria(con distanze così grandi, è difficile che essi siano alimentati dalla
rete elettrica).

Un protocollo wireless che copre grandi distanze e consuma poco diventa fondamentale.

Per far fronte alle esigenze che derivano da questi scenari applicativi, si possono trovare tecnologie che
consumano poco che possono fare al caso nostro? Sì, le LPWAN(low power wide area network).

Le tecnologie più usate sono LoRa e Sigfox.

LoRa: comunicazione Long Rage M2M usata per applicazioni IoT che usa livelli di potenza molto bassi.
La LoRa alliance è un’associazione no profit di cui fanno parte: Cisco, IBM, ecc.

È caratterizzato da:

-basso costo

-low power (batterie che durano anche decine di anni)

-trasmissione a lunga distanza (pochi bytes poche volte al giorno, ad esempio la misurazione di un sensore
che può essere fatta alcune volte al giorno)

-frequenza di banda < 1 GHz

-banda 7.8kHz – 500 kHz

I sensori trasmettono le informazioni raccolte (in uno degli scenari) ai gateway, che con un protocollo
proprietario, trasmettono verso i server che sono connessi a internet. -> risolve il problema di trasmissione
a grande distanza.
SIGFOX: va in competizione con LoRa per quanto riguarda gli scenari applicativi.
-ultra low throughput (i dispositivi possono trasmettere da 0 a 140 messaggi al giorno, ognuno di 12 bytes)

-low power

-long range

L’antenna raccoglie i dati dai vari sensori, che sono alimentati a batteria che possono durare anni.

Ha saltato la slide 75 e 76 e ha iniziato direttamente Communication_pt2

PROTOCOLLI A LIVELLO APPLICATIVO


Dopo aver parlato dei protocolli che vengono usati nell’IoT per i vari livelli (802.15.4, 6loWPAN ecc.), è
possibile usare HTTP a livello applicativo e quindi connettere i sistemi nel “web of things”, visto che ognuno
ha il suo indirizzo IP? La risposta è sì MA ci sono dei problemi: HTTP non è nato per l’IoT, quindi è troppo
pesante, l’header troppo lungo (spreco di risorse di comunicazione ecc.). Sono stati definiti protocolli
applicativi per l’IoT, alcuni simili all’HTTP, che hanno in comune il fatto di trattare con nodi con risorse
limitate (tipici dell’IoT).

CoAP (constrained application protocol) che sta sopra UDP.


MQTT (message queuing telemetry transport) che sta sopra TCP.
Entrambi sono IP compliant. Ovviamente i protocolli a livello applicativo espongono delle api per le
applicazioni vere e proprie.

Qual è l’interazione garantita da questi protocolli?

• POLLING: l’applicazione interroga (tramite un protocollo applicativo) un nodo per avere la


misurazione fatta dal sensore del nodo;
• Publish/Subscriber: somiglia molto al meccanismo di interrupt; il nodo, attraverso il protocollo
MQTT, ogni tot tempo, “pubblica” i valori di temperature misurati (ad esempio) e li manda a tutti
quelli che potrebbero essere interessati ai valori. L’applicazione riceve le informazioni a seguito
della “pubblicazione” da parte del nodo.

CoAP e MQTT vengono spiegati in dettaglio nella lezione del 21/05

È passato alla slide 30

Dai grafici emerge che il BLE nel 2018 ha raggiunto numeri notevolmente maggiori rispetto agli altri
protocolli: il trend dimostra che il BLE è la tecnologia più utilizzata, in quanto consuma poco ed è presente
su tutti gli smartphone. Zigbee, nonostante sia utilizzato in scenari simili poiché supporta la topologia mesh,
non supporta la connettività internet in quanto non IP compliant, e gli smartphone non hanno zigbee.
Thread supporta mesh, MQTT, CoAP, fino a 200 nodi, quindi è molto promettente.

Slides 33 esempio di smart agriculture, con vari gateway.

Per l’orto si può usare un BLE-based mesh network per monitorare la salute delle piante, la qualità dell’aria
ecc. La topologia mesh evita di usare un collettore centrale; posso trasmettere tutti i dati su internet con il
LoRa protocol e trasmetterli poi su rete geografica; si può usare anche la 802.15.4.

Tutte le tecnologie studiate spesso si trovano a coesistere in scenari più complessi. La slides seguente
rappresenta una varietà di stack che possibilmente sono attivi contemporaneamente e hanno
rispettivamente un ruolo diverso. L’obiettivo dello strato di middleware(fatto nelle lezioni sull’architettura)
è quello di esporre delle api ed astrarre tutto ciò che c’è sotto per abilitare la possibilità di sviluppare
applicazioni IoT.

LEZIONE IOT 21/05


Communications: Application Protocol CoAP, MQTT
In scenari complessi, i vari protocolli e le varie tecnologie devono coesistere (sfida perché ad esempio
alcune sono ip compliant e altre no). L’abstraction middleware fa da cappello alle varie tecnologie e astrae
dai dettagli dello specifico protocollo ed espone i servizi al livello applicativo. (ultimo concetto della lezione
precedente)

Alcuni protocolli a livello applicativo sono nati apposta per applicazioni IoT.

Come detto più volte, negli scenari applicativi IoT i nodi presentano risorse limitate, di conseguenza è
necessario utilizzare protocolli a basso livello (es. wireless) che hanno come vincolo il basso consumo di
potenza.

Quando si definiscono protocolli a livello applicativo per IoT, si fa una cosa simile a quella fatta per il
6LoWPAN (adattare IPv6 all’IoT).

APPLICATION LAYER PROTOCOLS FOR THE IOT


COAP: constrained application protocol
MQTT: message queuing telemetry transport
Entrambi molto diffusi. Il requisito comune è che sanno trattare nodi IoT con risorse limitate.

In uno scenario con tanti nodi e tanti sensori, il livello applicativo tiene conto dei valori acquisiti dai sensori.

Che paradigma di interazione viene utilizzato dai protocolli applicativi?

1) Polling (COAP): l’applicazione chiede al nodo/sensore “dammi il valore della temperatura del nodo
x”
2) Publish/subscriber (MQTT): il sensore trasmette i dati (“pubblica”) a quelli che potrebbero essere
interessati, che si possono “sottoscrivere” (subscribe)
La differenza tra i due è che nel polling, l’app si deve ricordare di andare a vedere qual è il valore del
sensore, nel caso publish/subscriber l’app viene informata con un pushing e le arriva direttamente
l’informazione.

COAP
• Web based (basato su un servizio web), su cui ci sono tecnologie consolidate, che si riferiscono a
nodi con risorse:
o Microcontrollori a 8 bit
o Limited memory
o Low power networks

Perché usare un altro protocollo invece dell’HTTP? HTTP, sebbene sia un protocollo web, non è un
protocollo leggero ma pesante, troppo pesante per essere ospitato nello stack di un nodo con risorse
limitate.

OBIETTIVO: SEGUIRE LA FILOSOFIA WEB-BASED, MA ALLEGGERENDO L’HTTP DEFINENDO UN


NUOVO PROTOCOLLO, IL COAP.
CARATTERISTICHE DEL CoAP:
• Il CoAP risponde ai requisiti dell’ambito M2M
• Utilizza UDP, più leggero del TCP/IP
• Architettura client/server (simile ad HTTP) ma lo scambio di messaggi è asincrono.
• Header molto più leggero (4 byte)
• Utilizza lo schema di indirizzamento URI (UNIFORM RESOURCE IDENTIFIER)
• Utilizza PROXY E CACHING
• I verbi di CoAP sono molto simili a quelli HTTP (GET, POST, PUT, DELETE methods) quindi è
possibile fare un mapping di HTTP e CoAP. Da un client http si può fare una request verso un server
CoAP e questo attraverso il proxy è molto semplice. Request e response sono molto simili. CoAP
però è molto alleggerito.

• MESSAGE RELIABILITY IN COAP

Nel CoAP si è introdotto il concetto di affidabilità nello scambio di messaggi, implementato con una
tipologia di messaggi, “confirmable” (confermabili) e un’interazione tra client/server che rende affidabile la
comunicazione. Si può utilizzare anche la modalità unreliable (inaffidabile) con messaggi non confermabili.
Si cerca di evitare la duplicazione per pacchetti che si perdono con l’introduzione di un message identifier.

Una request CoAP è equivalente a quella HTTP ed è mandata dal client al server usando un metodo,
richiedendo un’azione su una risorsa. Il server, come nell’HTTP, replica con una response. La differenza è
che CoAP non è un protocollo sincrono, a differenza dell’HTTP.
Quando una request CoAP va verso un server, il server non risponde a quella request ma può rispondere
quando avrà la risorsa. Maggiore flessibilità del metodo sincrono dell’HTTP.

I tipi di messaggi reliable, che garantiscono che lo scambio di messaggi sia affidabile, sono:

o Messaggi confermabili
o Messaggi non confermabili
o Acknowledgement
o Reset

ESEMPIO DI COMUNICAZIONE

CON: CONFIRMABLE

Se il server riceva un messaggio confirmable(es. una get), identificato da un message id, esso risponde
al client con un ack che ha lo stesso message id. Ogni messaggio confirmable deve essere ackato al
client che l’ha mandato. Questo è utile perché se il client non riceve entro un certo tempo un ack dal
server (ad es. verificando con un timeout) esso rispedisce il messaggio; oppure se il client non riceve
l’ack rimanda il messaggio confirmable. Questo permette al server di individuare le duplicazioni: se il
client rimanda lo stesso messaggio, che si capisce con il messagge id, il server capisce che quel
messaggio è un duplicato e non risponde con la stessa risorsa due volte.

NON : NON CONFIRMABLE

A destra della figura c’è un messaggio non confermabile, che quindi non richiede l’ack da parte del
server.

COAP MESSAGE SEMANTICS

Trasporto basato su udp, al di sotto del quale potrebbe esserci 6LoWPAN, e al di sopra del quale ci sono
i CoAP messages e le request/response: questi due livelli sono ortogonali, ovvero il CoAP message
incorpora le request/response rendendole affidabili.
PIGGYBACKED RESPONSE: tipico del COAP

La get viene incorporata in un messaggio confirmable, che ha un message id; nel messaggio CoAP c’è
anche un altro campo (token) con il proprio id. Quando il server riceve questo messaggio, deve
mandare un ack per confermare il messaggio: l’ack serve solo per far capire al client che il messaggio è
stato ricevuto dal server, e potrebbe non avere contenuto informativo, ma se il server ha già il
contenuto richiesto, incorpora il contenuto informativo nell’ack (PIGGYBACK) e il processo di
comunicazione è concluso.

L’ack e il token hanno lo stesso id che avevano nel messaggio di richiesta del client.

Se il server non ha l’informazione richiesta (a dx della figura) e sa di non poterlo ricavare in futuro,
manda comunque un ack per confermare la ricezione del messaggio, ma non viene utilizzato il
meccanismo di piggyback, ovvero viene generata una response “not found”.

SEPARATE RESPONSE

Un client fa una richiesta al server di tipo CON (confirmable) con una request GET istanziando un token
con id 0x73. Quando la richiesta arriva al server, esso sa che deve mandare un ack per confermare che il
messaggio CON è stato ricevuto, ma senza usare un piggyback. Il server manderà al client la
temperatura richiesta quando l’avrà disponibile, con un messaggio CONFERMABILE (il fatto di usare
messaggi confermabili viene stabilito dal client quando manda la prima richiesta con un messaggio
CON) il cui messagge id è diverso da quelli precedenti, ma il token avrà lo stesso id del token del
messaggio di richiesta per far capire al client a quale richiesta si riferisce la risposta del client. Il client
deve mandare un ack per confermare il CON, e si chiude il meccanismo di comunicazione.

Dalla separate response si evince che CoAP è asincrono, mentre HTTP è sincrono: la response del server
viene mandata quando il valore (es. di temperatura) è disponibile, mentre in HTTP la risposta sarebbe
“valore non disponibile”. Questo è ottimo per le applicazioni IoT.

MQTT

È un protocollo M2M progettato per essere un protocollo applicativo per IoT quindi è “light”; è basato su
un’interazione publish/subscriber. È progettato per essere leggero ma anche per essere ottimo in ambiti
ostili (es. wireless dove la connessione oscilla). Copre un sacco di esigenze dell’IoT.

Prevede due figure: client (più di uno) e un broker MQTT. Un client può pubblicare valori acquisiti
attraverso un sensore su un topic (es. temperatura); i topic su cui un client può pubblicare delle istanze
sono tanti e non ci sono dei vincoli specifici.

Il client può essere un publisher: attraverso un messaggio manda i valori acquisiti (es. da un sensore) al
broker. Un client subscriber è interessato a ricevere i valori su un topic pubblicati da un certo client, quindi
informa il broker MQTT che vuole ricevere informazioni di quel topic. I client possono essere sia
“publisher” che “subscriber”. Il broker riceve pubblicazioni di topic e le inoltra a quei client che si sono
sottoscritti a quei topic. I client interagiscono SOLO con il broker e mai tra di loro, quindi vi è un
disaccoppiamento tra i client: non c’è mai una linea diretta di interazione tra publisher e subscriber. Non c’è
distinzione netta tra client e server (con l’accezione usata solitamente).

I client sono sempre connessi al broker (a partire da una fase di connection che noi non approfondiamo).

AGNOSTIC PAYLOAD for flexible delivery: non importa come siano rappresentati i dati(es. file binario,
formato json, immagine png ecc.)
I topic sono stringhe strutturate in modo gerarchico (tipo file system).

Un topic è un namespace: i vari topic vengono trattati con una gerarchia usando uno slash (/) come
separatore. Questo permette flessibilità.

Un sottoscrittore si può sottoscrivere a un topic assoluto o a una wildcard, ovvero aggregare i topic a cui è
interessato (tramite + e #), una facility per agevolare le sottoscrizioni.

Chi pubblica non può usare le wildcard, ma deve fare riferimento a uno specifico topic.

Su CoAP i reliable messages assicuravano l’affidabilità della comunicazione.

Su MQTT, qual è la garanzia che il valore pubblicato dal publisher arrivi a destinazione al client subscriber?
Non c’è comunicazione tra publisher e subscriber, in mezzo c’è il broker.

Si definiscono 3 livelli di priorità nella consegna dei messaggi (quality of service QoS):

0) At most once: “al massimo uno”, il ricevitore non manda nessun ack, oppure il publisher
memorizza e rimanda il valore.
1) At least once: “almeno uno”, almeno una volta quello che io pubblico viene ricevuto dai miei
sottoscrittori. Il protocollo deve garantire la consegna ed essere sicuro che sia stato consegnato:
nell’implementare questo controllo, potrebbe esserci una duplicazione del messaggio.
2) Exactly one: “esattamente uno”, arriva certamente il messaggio e senza duplicazioni. Handshake a
4 vie (publisher pubblica, broker risponde con un ack, publisher dice “ho ricevuto l’ack”, broker dice
“possiamo terminare”). È il più lento.

All’aumentare del livello aumentano anche i costi.

CoAP, poiché utilizza il polling, ha una modalità “observe” che è simile a quella di publish/subscriber perché
il client chiede al server “ogni volta che questa determinata risorsa cambia, mandami il suo valore
aggiornato” (ad es. se l’applicazione è interessata al valore misurato da un sensore che misura
continuamente). N.d.R: ha detto che non approfondiamo questo aspetto del CoAP

CONFRONTO MQTT E HTTP

Dalla slide Communication_part2 pag 27

Molte persone sembrano ossessionate dal voler utilizzare HTTP per tutto. HTTP è stato praticamente
costruito per situazioni di request-response(“voglio un documento caricato sul mio web browser adesso,
per favore”). Col passare degli anni HTTP è stato modellato in modo da poter fare cose per cui non era stato
progettato. Nuove caratteristiche sono state aggiunte, ma in fin dei conti le limitazioni imposte dal design
originale sono rimaste. HTTP va bene per fare quello per cui è stato definito (e ha davvero cambiato il
nostro mondo); nonostante ciò non va bene per fare coso per cui non è stato progettato! Da una
prospettiva di IoT, HTTP è prolisso e inefficiente, e non è scalabile alle proporzioni richieste dall’IoT.
Dai valori di messaggi scambiati si nota che HTTP è decisamente più pesante di MQTT; inoltre anche il
consumo di batteria (ipotizzando che i nodi siano alimentati a batteria) è nettamente inferiore con
l’utilizzo di MQTT.

LEZIONE IOT 28/05


CYBER-PHYSICAL INTERFACE
Come fa un microcontrollore a interfacciarsi con il mondo fisico? Che caratteristiche deve avere? Come
devono essere i tempi di acquisizione?

L’IoT mette in comunicazione il mondo fisico e cyber (cyber-physical systems). Il mondo reale è analogico:
come fare interagire un mondo digitale, in cui si usa un alfabeto fatto di soli 2 simboli (0 e 1, on off, high
low ecc.) e il mondo analogico che varia nel continuo?

• Sono necessari dei convertitori che fanno sì che le informazioni analogiche vengano convertite in
digitale per poter arrivare nel mondo cyber (ADC); ovviamente può avvenire anche il contrario
(CDA).

Qual è il modello di interazione di mondo fisico e digitale?

▪ Microcontrollore con i vari componenti (processore, timers, SRAM, EPROM, DAC e ADC)
▪ Interfaccia con i sensori
▪ Interfaccia con la network wireless
▪ Interfaccia con gli attuatori

Il software applicativo può stare al di fuori del nodo.

Non sempre occorre la conversione A/D o D/A (es. in output c’è un display digitale, input è uno switch
ovvero on/off che non c’è bisogno di convertire).

TEOREMA DI NYQUIST-SHANNON

Una grandezza analogica che varia nel tempo in modo continuo può essere rappresentata in maniera
digitale se viene campionata. Più punti prendo, maggiore è la somiglianza tra il segnale analogico e digitale
(e di conseguenza anche il contenuto informativo sarà simile). Se la frequenza di campionamento è
sufficientemente alta, i campioni mantengono il contenuto informativo del segnale originale.

fcamp ≥ 2fmax dove fmax è la banda massima (limitata) del segnale analogico

Dopo il campionamento si quantizza l’asse delle ampiezze in un numero finito di intervalli che si possono
codificare in digitale utilizzando un certo numero di bit (risoluzione).

Tacq: tempo che serve per acquisire il valore analogico da parte dell’amplificatore Sample&Hold
Tconv: tempo di conversione (del ADC)
Tap: tempo di apertura di uno switch
La somma dei tre intervalli di tempo è il tempo necessario al sistema per fare il suo lavoro globale di
conversione della grandezza analogica.

Indichiamo con T= Tacq + Tconv + Tap il tempo necessario ad acquisire un campione.


->fmax=1/2T
Se T è il tempo necessario per il sistema di interfaccia per poter fare l’acquisizione e la conversione, la
frequenza massimo con cui posso acquisire campioni deve essere pari a 1/2T.

Queste componenti del periodo dipendono dalle parti di interfaccia, che deve avere dei requisiti di
velocità/timing specifici: essi determinano qual è la massima frequenza con cui posso acquisire campioni in
accordo al teorema di Nyquist-Shannon.

Visione duale:

▪ Quanto deve valere T se devo acquisire un segnale che ha una frequenza massima pari a fmax? Con
1
la formula inversa si trova che T≤ (T diventa un parametro del progetto)
2𝑓𝑚𝑎𝑥
T è il tempo entro cui devo acquisire il segnale analogico e convertirlo.
SAMPLE & HOLD
Logica del sample&hold in generale

La grandezza analogica in ingresso è collegata a un interruttore, che è collegato al ADC; (senza


condensatore) se l’interruttore è chiuso la grandezza all’ingresso del convertitore varia come il segnale
analogico; ADC vuole che la grandezza all’ingresso sia una tensione costante per tutto il tempo di
conversione, per questo nascono i sample&hold. Schematicamente si mette un condensatore tra switch e
ADC, così quando lo switch è aperto, il condensatore mantiene una tensione (più o meno) costante ai suoi
capi e quindi all’ingresso del ADC (questo fatto si nota dagli scalini costanti del grafico nella conversione).

Ovviamente questo schema semplificato non va bene per la realtà, perché il condensatore dovrebbe
rimanere carico per tutto il tempo di conversione, quando si apre lo switch. Se ci fosse un’impedenza
infinita a valle(quindi all’ingresso del convertitore), il condensatore non si scaricherebbe: ecco perché si
utilizzano due amplificatori operazionali. Gli amp. operazionali hanno un’impedenza d’ingresso
estremamente elevata, quindi il condensatore non si può scaricare (o si scarica molto poco) durante
l’intervallo di conversione. Come si pilota l’interruttore? Comando HOLD per aprire l’interruttore.

Schema chip Sample&Hold InterfacciaCyber_Physical slide 6

Catena di acquisizione

▪ Sistema fisico
▪ Trasduttore(sensor) che sfrutta un principio fisico per trasdurre una grandezza da quella che è, a
una grandezza elettrica, es. una tensione
▪ Signal Conditioning: condizionare il segnale elettrico (es. filtrare, amplificare, attenuare)
▪ Sample&Hold: attraverso un comando proveniente dal microcontrollore si chiude lo switch per
prendere il campione del segnale
▪ A/D: converte il campione in valore digitale

Tutto ciò è necessario per interfacciare il microcontrollore (mondo cyber) e il mondo fisico.

Nella catena di acquisizione sappiamo che il segnale varia nel tempo. Il comando HOLD deve avvenire con
un certo timing, e il ADC deve riconoscere quando deve convertire un nuovo valore. Il ADC ha due segnali
(SOC E EOC):

▪ SOC è un input per il ADC (Start of Conversion)


▪ EOC è un output per il ADC (End of Conversion): il microcontrollore può leggere il valore convertito
sul data bus

Ogni quanto deve avvenire la generazione dei comandi di HOLD e SOC (generati dal microcontrollore)?

Dal teorema di Shannon-Nyquist, sappiamo che ogni intervallino (hold) deve avere una certa durata, quindi
il microcontrollore deve generare questi segnali di controllo in tempi appropriati. Quale componente
permette al mc di fare ciò? Il timer, che è programmabile via software per avere un timeout che faccia
generare il segnale per pilotare il S&H e per dare l’avvio alla conversione.

Se si hanno diversi sensori, di tipo diverso, nello stesso nodo, ci sono diverse grandezze fisiche da trasdurre:
possiamo pensare che per ogni grandezza fisica si abbia una catena di acquisizione come quella appena
vista: 10 grandezze fisiche -> 10 trasduttori(ok) -> 10 signal conditiong-> 10 S&H-> 10 ADC. Questa è una
soluzione costosa e ingombrante.

Ciò che si preferisce fare è: date N grandezze fisiche da acquisire con N trasduttori ed N signal conditioning,
si utilizza un multiplexer analogico che, attraverso dei comandi che provengono dal mc, fa passare un certo
segnale tra quelli al suo ingresso (il comportamento è analogo a un mux digitale). Il mux concentra su
un’unica catena di acquisizione tutta la parte a valle: unico S&H e unico ADC che si interfacciano col mc. La
novità rispetto allo schema precedente è che ci sono dei i segnali di controllo in più: “select” del mux che
vengono generati da mc.

Attraverso questo sistema, risparmio sui componenti di S&H e ADC e sull’interfaccia tra il mc e la catena
di acquisizione, perché si devono solo generare i segnali di controllo “select” in più.

Se si hanno N sorgenti analogiche, ognuna di esse ha vincoli di timing (teorema di Nyquist-Shannon) diversi
quindi il S&H e ADC devono essere più performanti.
Multiplexer: 8 ingressi (s1, …, s8), decoder a 3 bit che provengono dal microcontrollore, in base al valore si
chiude un particolare interruttore.

Nell’acquisizione, se si usa lo schema con il mux riesco ad aver un solo ADC e S&H: che caratteristiche deve
avere il ADC rispetto allo schema con N ADC? Deve essere in grado di convertire senza violare i requisiti di
timing della singola sorgente.

Considerando che tutti i segnali di ingressi hanno la stessa banda:

(video 28/05 2° parte min 13:29) ADC ha un parametro caratteristico che è il Tcon: per una singola sorgente
𝑻𝒄𝒐𝒏
è pari a 1ms; per 10 canali multiplexati quanto deve essere il Tcon*? Tcon*≤
𝟏𝟎
I tempi di conversione devono essere più ridotti quindi il convertitore deve avere performance più
elevate.

Es. per il segnale 1, l’ADC deve tornare su s1 dopo 1ms; ma questo vale per tutti i segnali, quindi il tempo di
conversione deve essere minore uguale di Tcon/N

Anche il S&H deve essere in grado di avere una velocità di lavoro 10 volte più alta rispetto al caso di singola
sorgente.

Catena di manipolazione del mondo fisico (da cyber a fisico)

▪ D/A converter: convertitore a cui arriva il dato dal data bus


▪ Filtro
▪ Amplificatore
▪ Attuatore (es. motore, altoparlante)
▪ Mondo fisico

DAC ha delle linee di controllo (handshaking), come nella catena di acquisizione.

Modello di interazione: domande aperte

1. Che genera i comandi per l’acquisizione dei segnali analogici? Il microcontrollore attraverso i pin
I/O;
2. Come viene gestito il timing? Un elemento fondamentale all’interno del mc è il timer, che deve
essere in grado di svegliare e di indicare all’interno del mc gli istanti in cui devono essere generati
determinati segnali di controllo; è programmabile via software;
3. Chi prende l’iniziativa? (fa riferimento alla differenza tra l’interazione polling e publish/subscriber
dei protocolli caop e mqtt) due modalità: il software deve ricordarsi ogni quanto tempo generare i
segnali di controllo per la catena di acquisizione e generarli. Nell’handshaking tra mc e ADC c’è un
segnale SOC (start of Conversion) e il convertitore da in uscita sul data bus il valore convertito:
come fa il mc a sapere quando il valore è disponibile? Grazie a EOC: il software, facendo un polling,
deve stare in attesa su EOC, quando passa ad esempio da 0 a 1, sa che può leggere il dato). Questo
metodo è molto oneroso dal punto di vista della CPU. Un altro metodo è: quando arriva EOC dal
convertitore, automaticamente viene generata un interrupt, quindi quando il dato è pronto: non è
il software che in continuazione sta in attesa del segnale EOC, ma con l’interrupt si lancia un
warning alla CPU che capisce che il dato è pronto.

LEZIONE 3/06 IOT


GESTIONE I/O
Se io ho un sistema di I/O caratterizzato da una latenza Ti/o che è il tempo che occorre per scambiare
un’informazione (un byte), o da un throughput di I/O, la fmax del segnale che caratterizza un sensore
analogico che possiamo acquisire è:

fmax <= fi/o/2 = 1/(2 Ti/o)


Nel nostro sistema IOT possiamo andare a sapere, una volta noti i parametri dell’I/O, quali sensori
possiamo collegare e verificare che i requisiti del teorema di Nyquist-Shannon siano verificati.

Ti/o è caratteristico del sistema I/O; è un parametro stimabile? Sì!


Un sistema di I/O mette in comunicazione la parte interna del computer con il mondo esterno attraverso le
periferiche; si fa uso di interfacce che sono tipicamente chiamate I/O device o adattatori. A seconda della
periferica con cui devo interfacciami, nasce un device I/O apposito. Un I/O device serve ad adattare la
velocità fra i due mondi, il protocollo di comunicazione, livelli e tipi di segnali ecc.

La CPU parla con le periferiche attraverso gli I/O devices; il device si interfaccia con la periferica.

MODELLI DI INTERAZIONE

• CPU-I/O DEVICE: il device condivide un bus con la CPU per lo scambio di informazioni; la
comunicazione tra CPU e I/O device è simile a quella tra CPU e memoria;

la CPU scrive il dato che vuole mandare in output all’I/O device (data reg): siamo sicuri che il byte
che era precedentemente nel data reg è stato già consumato dalla periferica? Questo controllo è il
compito dell’I/O device. Come fa la CPU a sapere che può mandare un altro byte?
SINCRONIZZAZIONE tramite STATUS REG (registro di stato): contiene delle informazioni che la CPU
può leggere ad es. per leggere se il data reg è disponibile per mandare un altro byte; quando il dato
viene consumato, si aggiorna lo status reg. Questo meccanismo è indipendente dalla periferica in
questione.
• I/O DEVICE-PERIFERICHE: il formato dei dati scambiati (ad es. parallelo nell’I/O e seriale nella
periferica) e la sincronizzazione (handshaking) devono essere risolti.

Anche il device I/O si deve interfacciare con la periferica: stesso problema di sincronizzazione.
(ovviamente lo scambio dati può avvenire in entrambi i versi). SINCRONIZZAZIONE tramite DUE
SEGNALI: req e ack scambiati tra la periferica e device I/O.

Due modi per sincronizzarsi:

• handshake protocol: tipicamente usato per sincronizzare un master e uno slave. Il master attiva la
richiesta con “req”, lo slave riceve la richiesta e manda un “ack” al master. Quando l’ack è stato
inviato significa che lo slave è pronto per lo scambio dati. Il dato viene scambiato e viene
mantenuto per un certo tempo: quando la req passa da 1 a 0, lo slave deasserisce anche l’ack e lo
scambio del dato viene fermato.
• strobe protocol (lo ha tralasciato)

La CPU può leggere o scrivere il data reg dell’I/O device, è necessario un indirizzamento:

-Si possono usare istruzioni particolare per l’I/O (I/O mapping), se il processore ha questa modalità

-memory mapped con istruzioni load e store per scrivere sui registri

PERFORMANCE NEI DEVICES I/O


La CPU performacne evolve più velocemente di quella dei device I/O.

Secondo la Legge di Amdahl, lo speedup è limitato dall parte più lenta:

Se il 10% del tempo del programma è per l’I/O e mettiamo una CPU 10 volte più veloce di quella attuale,
otteniamo una performance migliorata di solo 5 volte.

10% I/O & 100xCPU => 10x Performance (si perde il 90%) ndR:UNA SCHIFEZZA

L’I/O rappresenta il collo di bottiglia del sistema perché limita la max performance del sistema stesso.

Un indicatore di performance è la % di tempo che la CPU spende per le operazioni di I/O:

Time(workload)=tempo per eseguire un programma


Time(CPU)=tempo per eseguire istruzioni SOLO di CPU

Time(I/O)=tempo speso dalla CPU per eseguire istruzioni di I/O

Un modo per migliorare la performance è inserire un parallelismo tra CPU e I/O.

Time(workload)= time(CPU)+time(I/O)-time(overlap)
Con il parallelismo (totale o parziale), la penalizzazione introdotta dall’I/O diminuisce.

CONFRONTO TRA IL PARALLELISMO NELLE TECNICHE DI GESTIONE DELL’I/O CHE POSSONO ESSERE
ATTIVATE DA UN SISTEMA

Incrementando il parallelismo migliora la performance.

POLLING

Nel polling c’è zero parallelismo perché tutta la gestione dell’I/O è scaricata sulla CPU: low end della
performance. La CPU è costantemente in loop “is the data ready?”. Se sono collegati N device I/O il polling
prevede che, per ognuno di essi, la CPU controlli continuamente se il dato è pronto: se non lo è passa al
device successivo.

La velocità della CPU (clock) è nettamente maggiore rispetto a quella del device I/O quindi sicuramente,
nell’attesa che il dato sia pronto, la CPU ha controllato centinaia se non migliaia di volte il registro.

Ttransfer=tempo che viene usato dalla CPU per trasferire il dato (accedere, leggere o scrivere)
Poiché tutto il resto del tempo non è tempo utile dal pov del trasferimento, possiamo definire con η
l’efficienza del trasferimento.

C’è +1 nelle parentesi perché anche quando il dato è pronto la CPU accede al registro di stato; il polling è
una tecnica inefficiente e l’overlap tra CPU e I/O è pari a zero. Il polling è detto anche “busy wait”.

INTERRUPT I/O

È il dispositivo a informare la CPU su quando il dato è pronto interrompendo il flusso della CPU e facendole
consumare il dato.

La comunicazione tra CPU e I/O device è regolato da:

• interrupt request: generato dall’I/O device


• interrupt ack: la CPU manda un ack sulla interrupt (“ho capito che mi hai interrotto quindi eseguo la
ISR”)
• dati/indirizzi per scambiare il dato
Dallo schema vediamo un programma in memoria (user program) che la CPU sta eseguendo. Durante
l’esecuzione, arriva un interrupt (1). La CPU termina l’istruzione in corso, salva il PC e viene forzata ad
eseguire l’interrupt service routine (ISR) o handler: nel codice della routine di servizio dell’interrupt c’è
qualche compito che la periferica vuole che la CPU esegui: ad es. che prenda un dato dalla memoria e lo
scriva sul device I/O. L’interrupt prevede che il flusso normale di esecuzione sia interrotto, e che venga
eseguita la ISR. Con l’istruzione rti RETURN FROM INTERRUPT, la CPU torna a eseguire l’istruzione
successiva a quella su cui si era interrotta (grazie al PC che è stato salvato): ovvero l’esecuzione è
trasparente.

Efficienza di trasferimento con l’interrupt

In questo caso la CPU lavora sul suo programma, e contemporaneamente viene controllato se il dato è
pronto dall’I/O device (“is the data ready?”): quindi non è tempo di CPU sprecato come nel polling. La parte
in grigio è il tempo che l’I/O consuma per vedere se il dato è pronto, in parallelo a quello che sta facendo la
CPU (l’I/O ha un minimo di intelligenza per fare controlli). Quando l’I/O device vede che il dato è pronto, si
scatena l’interrupt e viene eseguita la ISR.

La CPU non è mai convolta nel leggere lo stato del device (si risparmia quel tempo rispetto al polling): c’è un
parallelismo e quindi miglioramento della performance.

Quando si verifica l’interrupt c’è un overhead: (prima del data transfer) tempo di CPU consumato per
salvare il PC, mandare l’ack; (dopo il data transfer) è dovuto al RITORNO dall’interrupt. Overhead che pago
solo una volta (quando si verifica l’interrupt) e non tutte le volte che vado a controllare lo stato.
L’efficienza è maggiore rispetto al caso del polling dove al denominatore si poteva ripetere anche N volte il
check se il dato non è pronto (N controlli dello stato per trasferire un solo dato).

Qual è l’indirizzo dell’ISR? Diverse tecniche:

• fixed interrupt: sempre lo stesso indirizzo (poco utilizzato, complessità poco elevata)
• vectored interrupt (interrupt vettorizzato): il device che interrompe la CPU es. l’UART genera la req
di interrupt, la CPU manda l’ack, il device trasmette con un data bus l’indirizzo della sua interrupt
routine in memoria. Soluzione poco flessibile perché una volta che inizializzo il device I/O e vado a
scrivere l’indirizzo dove sta l’ISR, in memoria deve esserci la routine e il sistema operativo non ha
modo di spostarlo
• interrupt address table (più flessibile): il dispositivo manda l’interrupt vector table head alla CPU,
ovvero l’indirizzo di una tabella in cui sono memorizzati gli indirizzi delle ISR (0,1,2,…). Attraverso
l’indice la CPU capisce quale handler deve eseguire. Se la CPU sposta gli indirizzi degli handler, non
modifica il device che è già programmato, ma deve solo cambiare l’indirizzo nella tabella.

L’interrupt ci permette di risparmiare tempo rispetto al polling poiché il device I/O è dotato della capacità
di indicare alla CPU dove sta la routine di servizio: tolgo complessità alla CPU e la trasferisco all’I/O (di
conseguenza si aggiungere un overlap tra i due per migliorare le performance).

Se più dispositivi generano un interrupt mentre se ne sta eseguendo un’altra? Priorità: la CPU esegue la
routine che ha la priorità maggiore se ce ne sono diverse.

Priorità e vettori sono indipendenti tra loro.

La CPU può mascherare (disabilitare) gli interrupt (programmabile via software): per operazioni che non
possono essere interrotte, la CPU non esegue la routine relativa all’interrupt.
Non-maskable interrupt(NMI): interrupt con la massima priorità, che non può essere mascherata (spesso
usata per un power-down).

Generico meccanismo delle interrupt (con priorità e vettori)

Se il dispositivo non manda il vettore e scatta un timeot viene generato un errore.

CPU time budget


- Per eseguire la routine
- Overhead: ack, priorità, registare il PC, restore del PC
- Penalties di pipeline e cache (non ne ha parlato)

Intuitivamente le prestazioni risultano migliori del polling: l’evoluzione dei sistemi di I/O ha fatto emergere
l’esigenza di introdurre meccanismi più performanti dell’interrupt, per gestire nuovi scenari.

Esercizio min 19:36 2° parte 3/06

Sia l’interrupt che il polling hanno una cosa in comune, una debolezza che deve essere superata: nel
polling si spreca un sacco di tempo per controllare quando il dato è pronto, ma alla fine il trasferimento lo
fa la CPU, quindi consumo CPU time; nell’interrupt, risparmio il tempo di controllo ma il trasferimento lo fa
sempre la CPU. Per migliorare le performance devo immaginare qualcosa che spinge di più sul parallelismo:
fare si che sia il sistema di I/O a fare il trasferimento, ad es. andare a scrivere il dato in memoria quando è
pronto.
DMA: DIRECT MEMORY ACCESS

Il DMA è programmabile: quando ci sono dei dati sul dispositivo di I/O, leggi quei dati da quel dispositivo
che ha un indirizzo e scaricali in memoria a partire da quell’indirizzo, per N volte. La CPU spreca un po’ di
tempo per programmare il DMA, ma dopo di ciò il device trasferisce direttamente il dato in memoria senza
passare dalla CPU. Da un pov ideale il DMA fa il trasferimento dall’I/O verso la memoria o viceversa senza
coinvolgere la CPU, e quindi senza consumare CPU time: max del parallelismo.

Potrebbe esserci un conflitto di accesso sul bus condiviso tra CPU e memoria, quindi potrebbero non
esserci le prestazioni ideali volute.

Il DMA fa il trasferimento come se si sostituisse alla CPU (con hardware), non eseguendo istruzioni come la
CPU. Se blocco la CPU mentre lavora il DMA sto consumando del CPU time che è pari al tempo che impiega
il DMA per fare i trasferimenti. Quindi miglioro il tempo rispetto alla interrupt ma il parallelismo non esiste
tra CPU e DMA.

Tutto questo è vero se la CPU deve andare sul bus e accedere alla memoria per fare il suo lavoro, poiché
deve leggere le istruzioni; quindi si può utilizzare un’altra architettura:

Nella Von Neumann c’è una sola memoria per i dati e per le istruzioni, nella Harvard ci sono due memorie
separate a cui la CPU accede tramite bus separati. Il DMA usa solo il bus per la data memory, quindi il
conflitto sul bus si genera solo sulla data memory. Mentre il DMA fa trasferimenti, la CPU può eseguire
comunque istruzioni, e non ci sono conflitti purché le istruzioni non siano load/store (che comunque non
sono molto frequenti); effettivamente c’è un parallelismo.

Slides 46-53 le ha saltate ma ha detto che le possiamo vedere noi; PERFORMANCE I/O minuto 40:30 3/06 2° parte