OTTOBRE 2014
AUTOMAZIONE OGGI 376
105
stabilisce le operazioni e le procedure
che lo attuano; definisce inoltre due
ruoli: ‘server’ e ‘client’. Questi non sono
necessariamente collegati con gli spe-
cifici ruoli GAP assunti, ma potrebbero
essere definiti da strati superiori. Si noti
che Gatt e ATT possono essere utilizzati
sia in BR che in BLE, ma in quest’ultimo
essi sono obbligatori, in quanto utiliz-
zati per il discovering di servizi.
Il Gatt server immagazzina le informa-
zioni trasportate tramite ATT e accetta
‘ATT request’, ‘ATT command’ e ‘ATT
confirmation’ dal Gatt client. Il server
risponde alle richieste e, quando con-
figurato, invia notifiche asincrone al
Gatt client quando accadono specifici
eventi. Il livello Gatt inoltre specifica
l’organizzazione dei dati sul Gatt ser-
ver: definisce gli elementi primari, quali
‘service’ (servizi) e ‘characteristic’, utiliz-
zati per lo scambio di informazioni. I servizi infatti possono
contenere una collezione di ‘characteristic’ e queste conten-
gono un singolo valore e un numero indefinito di descrittori.
Il profilo è quindi una definizione di alto livello che stabilisce
come i servizi possono essere utilizzati per una specifica ap-
plicazione. Ogni ‘characteristic’ contiene le proprietà (per-
messi di lettura/scrittura), il valore (di dimensione variabile
da 1 a qualche Byte) e i ‘descriptor’.
La creazione dei profili
La procedura di creazione di un profilo in accordo alla speci-
fica BLE è stata notevolmente semplificata rispetto alle ver-
sioni precedenti, purtroppo però, date le notevoli differenze,
i profili BLE non sono compatibili con i profili tradizionali.
Lo strato General Access Profile (GAP) del protocollo BLE si
occupa della gestione delle modalità e delle procedure di
accesso del dispositivo, oltre che di ‘discovery’, ‘link estabi-
lishment’, ‘link termination’, inizializzazione delle feature di
sicurezza e della configurazione.
A livello di GAP il dispositivo opera normalmente nel ruolo
di ‘peripheral’, ossia un advertiser che permette la connes-
sione e opera come uno slave in una connessione punto-
punto, oppure ‘central’, eseguendo la ricerca di advertiser
e avviando la richiesta di connessione: è un master in una
connessione punto-punto o multi-punto. Altre possibili mo-
dalità sono ‘broadcaster’ e ‘observer’.
In una tipica applicazione Bluetooth Low Energy il periphe-
ral avvisa qualsiasi nodo central in ascolto, tramite pacchetti
specifici, la sua disponibilità alla connessione. I pacchetti
contengono l’indirizzo e talvolta ulteriori informazioni utili
alla connessione, come per esempio il nome del dispositivo.
Una volta ricevuto il primo ‘avviso’, il central invia una richie-
sta di ‘scan’ al peripheral, il quale risponde con una ‘scan re-
sponse’. Questo è il processo di ‘discovery’ del dispositivo,
tramite il quale il central viene a conoscenza del peripheral
e del fatto che esso è disponibile per una connessione. Il
central può quindi avviare la procedura di ‘estabilish link’.
La richiesta di connessione contiene alcuni parametri. Prima
di tutto, il ‘connection interval’: nello stato di connessione
viene utilizzato un processo di frequency hopping per il
quale i due dispositivi scambiano dati, quindi si ‘ritrovano’
in un canale differente dopo un certo ammontare di tempo
(procedura gestita dal link layer). Questo ‘salto’ viene defi-
nito ‘connection event’ e, anche se non vi è nessuna infor-
mazione pronta per l’invio, vengono comunque trasmessi
alcuni dati per mantenere attiva la connessione. Il connec-
tion interval è il tempo che intercorre tra i connection event
in unità di 1,25 ms e può variare tra 7,5 e 3.200 ms.
Applicazioni differenti possono richiedere tempi diversi: il
vantaggio di avere un lungo tempo tra due event consiste
nel fatto che l’applicativo si trova quasi sempre in stato di
‘sleep’, con conseguente grande risparmio di energia. Lo
svantaggio consiste nel fatto che, se si ha necessità di in-
viare dei dati, bisogna aspettare fino al successivo incontro
(elevata latenza). D’altro canto, con un connection interval
breve si hanno più opportunità di scambiare dati, in quanto
i dispositivi si connettono più frequentemente, a fronte però
di un maggiore consumo energetico.
Un secondo parametro è costituito dalla ‘slave latency’, che
dà al peripheral la possibilità di ‘mancare’ a un certo nu-
mero di event. Questo fornisce flessibilità all’applicazione in
quanto, se non vi sono dati da inviare, viene mantenuto lo
stato di ‘sleep’, ottenendo un modesto risparmio energetico.
Infine, il ‘supervision timeout’ rappresenta il tempo massimo
tra due connection event andati a buon fine. Se trascorre più
tempo, il dispositivo considera persa la connessione e ritorna
nello stato precedente. In certi casi è necessario modificare i
parametri nel mezzo di una connessione; per fare ciò è pos-
sibile inviare una ‘connection parameter update request’,
messaggio gestito dall’L2CAP.
(*) Comitato Tecnico Automazione Oggi e Fieldbus & Networks
Fonte: bussolati.com
