Capitolo 4
4 Il dimostratore della scatternet
4.1
Introduzione
La nostra applicazione host è vista come un ampliamento del progetto, discusso in precedenza, realizzato in ambito dell’elaborazione e smistamento dei dati voce per rendere possibile i servizi quali l’interfono e la gestione delle chiamate via cellulare. La vera novità consiste nella presenza di moduli software che gestiscono l’instaurazione ed il mantenimento della scatternet, ed inoltre lo smistamento dei dati che attraversano i vari nodi. Qui di seguito verrà mostrato un modo con cui si può raggiungere questo risultato.
4.2 Adattamento dei moduli BlueCore per il supporto della
connessione scatternet.
Tra i firmware Casira reperibili sull’omonimo sito ufficiale solo il firmware HCIStack.1v16.x, l’ultimo della serie, supporta una scatternet definita “limitata”, per il fatto che non permette ad un dispositivo Bluetooth di connettersi ad un numero arbitrario di piconet. La scatternet più complessa che è possibile sostenere contiene “2,5” piconet, un valore che sarà spiegato in seguito. Le versioni di tale firmware possono girare sia nel Bluecore01 che nel Bluecore02.
La differenza sostanziale del firmware HCIStack.1v16.x rispetto a quelli precedenti sta nella possibilità da parte dei moduli di supportare sia lo stato Inquiry che l’Inquiry Scan.
Le tipologie di scatternet descritte nel documento, vengono descritte in base al numero di piconet appartenenti a ciascuna di esse. Ecco una breve descrizione:
• Scatternet costituita da “1,5” piconet. Il significato di tale definizione è il seguente: il dispositivo A, che fa da master nella connessione con il dispositivo B, può, simultaneamente, eseguire il Page Scan come risposta ad un Paging da un terzo dispositivo C. Il nuovo link diventa attivo e subito dopo produce un Role Switch tra i due dispositivi A e C. Quindi il nodoA rimane tale anche dopo la seconda connessione, ed il dispositivo C diventa il suo secondo slave. La scatternet, dunque, non è propriamente tale perché la seconda piconet viene inglobata nella piconet iniziale tramite il Role Switch, da cui la definizione di “1,5” piconet.
• Scatternet costituita da “2” piconet. La procedura di formazione è identica al caso precedente ma con la differenza che non viene eseguita il Role Switch dei dispositivi A e C. Abbiamo, quindi, la scatternet vera e propria in cui il nodo A è simultaneamente master nella connessione col nodo B e slave nella connessione col nodo C.
• Scatternet costituita da “2,5” piconet. Il significato della parte decimale è identico al primo caso con la differenza che adesso il nodo A appartiene attivamente a due piconet (rispettivamente come master e come slave). Inoltre può eseguire il Page Scan e creare una terza connessione (con Role Switch) con un quarto nodo D.
Nel nostro caso specifico, la scatternet contiene soltanto due piconet, quindi il firmware menzionato prima supporta l’architettura del nostro sistema.
Oltre a dare indicazioni circa le tipologie di scatternet supportate, il documento fornisce spiegazioni circa il modo di intervenire sulle impostazioni dei chip, risiedenti nei Persistent Store, tramite il software PSTool per attivare il supporto della scatternet da parte del firmware. A questo proposito sono indicati tre parametri (PS keys) che agiscono direttamente sulla capacità dei moduli di supportare la scatternet. Essi sono:
a) PSKEY_ENABLE_MASTERY_WITH_SLAVERY - E’ un parametro di tipo booleano che, se di valore TRUE, rende possibile al dispositivo il comportamento simultaneo sia come master che come slave, necessario per partecipare in una scatternet.
b) PSKEY_MAX_REMOTE_MASTERS - E’ un parametro che indica il numero massimo di connessioni nei quali il nodo può partecipare come slave. Per default viene messo a 2, come necessario per la scatternet di tipo 3.
c) PSKEY_LM_MAX_PAGE_HOLD_TIME - E’ un parametro numerico che abilita il dispositivo, prima di fare il Paging per una nuova connessione, di mettere in modalità Hold tutte le altre connessioni. Questo dovrebbe aumentare la probabilità dell’instaurazione della scatternet. Il suo valore è pari al minimo valore tra Hold time (misurato in numero di slot temporali) e Page Timeout.
Per quanto riguarda i tipi di connessioni supportate dai moduli Bluetooth partecipanti in una scatternet, la limitazione più stringente riguarda il link SCO: infatti, il firmware non è abilitato a supportare alcuna connessione SCO tra i nodi quando essi partecipano in una scatternet. La ragione di ciò è data ovviamente dalla mancanza di sincronizzazione tra le piconet partecipanti in una scatternet. Per quanto riguarda invece il link ACL, esso può essere attivato con successo all’interno della rete scatternet. Si ha, quindi, la possibilità di instaurare la scatternet e di dimostrare il suo funzionamento usando le connessioni ACL per inviare dati tra i nodi A, B e C.
4.3 Il formato dei dati.
Attraverso l’interfaccia HCI, e quindi sulla UART, possono transitare quattro tipi diversi di pacchetto. La specifica Bluetooth, sezione H4 stabilisce degli “indicatori di pacchetto” da premettere ai vari tipi di pacchetto quando essi siano fatti transitare su una UART, in modo da poterli distinguere l’uno dall’altro. La Tabella 1 mostra le associazioni fra indicatori e pacchetti, ed evidenzia le direzioni in cui possono muoversi i dati. Ricordiamo che per host controller
s’intende essenzialmente il chip Bluetooth, e per host il controllore esterno, che può essere un micro, un DSP o addirittura un palmare o un PC.
Tipo di pacchetto SCO Indicatore di pacchetto Direzione
Comandi 0x01 host → host controller
Dati ACL 0x02 host ↔ host controller
Dati SCO 0x03 host ↔ host controller
Eventi 0x04 host ← host controller
Tabella 1 : indicatore dei pacchetti
I pacchetti ACL ed SCO (rappresentati in figura 4-1 e in figura 4-2) trasportano informazioni destinate ad essere trasmesse o ricevute in aria, dati nel primo, audio digitale nel secondo caso. È necessario, dunque che ognuno di questi pacchetti rechi una qualche etichetta che identifichi il destinatario se il pacchetto è uscente, il mittente se invece è entrante, per poter instradare correttamente i dati. Questa informazione viene fornita non direttamente con, ad esempio, l’indirizzo fisico ma indicando piuttosto a quale connessione ci stiamo riferendo. Nelle comunicazioni basate sullo standard Bluetooth, infatti, ogni singola connessione all’interno della piconet è univocamente identificata da un parametro a 12 bit detto connection handle. Ogni pacchetto dati ACL ed SCO è quindi associato ad una particolare connessione fisica mediante il connection handle, che ci permette di capire da dove provengono i dati e, seguentemente, di decidere dove mandarli. In generale, ogni qual volta ci si debba riferire ad una particolare connessione bisogna esplicitare il relativo connection handle. Si osservi che in queste figure non compare l’indicatore di pacchetto, e bisogna immaginarlo come un byte premesso alle stringhe raffigurate.
figura 4-1 : il pacchetto HCI ACL
Nel pacchetto ACL i campi PB flag e BC flag sono adoperati per aiutare le operazioni di segmentazione e riassemblaggio di pacchetti più grandi, indicando se il pacchetto è il primo, l’ultimo o uno intermedio, e per indicare se il pacchetto è di tipo broadcast o meno, più altre funzioni speciali. I 4 bit riservati nel pacchetto SCO sono generalmente posti a zero.
figura 4-3 : il pacchetto eventi HCI
I comandi e gli eventi ( in figura 4-4 e in figura 4-3, rispettivamente) rappresentano il mezzo mediante il quale l’host e l’host controller comunicano. Tipicamente l’host manda un comando e l’host controller manderà uno o più eventi in risposta al comando stesso, per segnalarne la ricezione e, in seguito, il successo o meno della sua esecuzione, restituendo vari parametri se il caso lo richiede.
4.4 L’architettura della applicazione host.
Il software che controlla tutti e tre i moduli è stato realizzato usando il programma LabView™ di National Instruments, che ha l’enorme pregio di implementare routine software in forma grafica, basandosi su una serie di primitive che permettono, ad esempio, di accedere in modo semplice alle interfacce del calcolatore, o di gestire strutture dati come array, code (fifo), e così via.
L’architettura del programma che gestisce ciascuno dei nodi A, B e C è mostrata in figura 4-5, in figura 4-7 e in figura 4-6, rispettivamente. Ogni blocco di essi rappresenta un modulo software che viene eseguito in modo concorrente con tutti gli altri.
figura 4-6 : il programma che gestisce il nodo C
figura 4-7 : il programma che gestisce il nodo B
I programmi che gestiscono i nodi A e C (le centraline) sono identici per quanto riguarda l’architettura ed il funzionamento, questo dovuto al fatto che i nodi in questione devono entrambi poter agire sia come master che come slave, e devono
prevedere le stesse funzionalità. Il programma del nodo B (il casco), invece, è meno complesso rispetto ai primi due, dovendo esso gestire soltanto la connessione del nodo come slave e la gestione del flusso dati con il proprio master.
Il calcolatore host, in cui gira il software comunica con i moduli tramite tre porte seriali che vengono attivate dal programma appena viene mandato in esecuzione. In seguito vengono eseguiti contemporaneamente i tre sottoprogrammi che stabiliscono la sequenza delle operazioni che ciascun nodo deve eseguire per arrivare alla creazione della scatternet.
Riferendosi alla figura 4-5 il blocco Serial Rx A accedendo in lettura alla porta seriale del calcolatore a cui è connesso il Casira, immagazzina tutti i dati che arrivano in un buffer (Coda Rx A), che viene periodicamente svuotato con cadenza di 20 ms dal parser A, che ha il compito di riconoscere il tipo dei dati che arrivano, e di metterli nella coda corretta. In particolare il parser, confronta il campo handle dei pacchetti ACL con gli handle contenuti in un’apposita area di memoria chiamata parameter storage. In questa maniera possono essere riempite di dati ACL tre code diverse, due per ogni connessione ACL dentro la piconet (coda ACL slave B e coda ACL other slave) e la restante per la connessione inter-piconet (coda ACL master C). Ovviamente nel nostro caso non viene usata la coda ACL other slave perché la piconet 1 contiene il solo slave B. Quando non c’è ancora nessuna connessione attiva gli handle ACL presenti nel parameter storage valgono per default zero.
Il diagramma di flusso del parser A è riportato in figura 4-8. La prima operazione che il parser compie è il prelievo degli elementi della coda Rx A, fino a svuotarla. I dati prelevati vengono appoggiati in un buffer interno al parser, chiamato S_buff A. Il parser provvede poi a cercare nel buffer un qualunque indicatore di pacchetto, ovvero uno dei byte 0x02, 0x03 e 0x04. Se non ne trova nessuno siamo in una condizione catastrofica che conduce al reset del sistema. Se infatti il flusso dei dati che transita attraverso la seriale è corretto, esso è costituito sempre da una successione ininterrotta di pacchetti HCI. In questo nodo il primo byte che passa sulla seriale in entrambe le direzioni deve essere un indicatore di pacchetto, e così il primo byte che segue l’ultimo di ogni pacchetto. Quando questa condizione non è verificata si dirà che il parser non è più agganciato, ovvero ha perso il
sincronismo, e vuol dire che si è verificato un malfunzionamento molto grave all’interno del sistema.
A seconda degli indicatori di pacchetto 0x02, 0x03 e 0x04 il parser sceglie una di tre possibili strade, indicate in figura 4-9, in figura 4-11 e in figura 4-10, rispettivamente. In tutti e tre i casi controlla se di seguito all’indicatore di pacchetto è presente una intestazione valida, ossia se non sono ancora arrivati tutti i byte di cui è composta. Dato che ciò viene fatto in ognuno dei tre casi, si potrebbe sollevare un obiezione dicendo che la differenziazione del comportamento del programma sulla base del tipo di indicatore potrebbe avvenire più tardi, facendo cioè il controllo della presenza di una intestazione valida contestualmente alla ricerca di un indicatore di pacchetto. Questa obiezione cade però osservando che in realtà le intestazioni hanno una forma diversa nei tre casi, e quindi la soluzione usata è tutto sommato abbastanza efficiente.
simbolo Spiegazione
Coda Rx A Coda dati ricevuti sulla seriale.
S_buff A Buffer interno del parser A. Viene usato
per appoggiarci i dati prelevati dalla Coda Rx A.
L Indica la lunghezza in byte di tutti i dati
che seguono l’intestazione. Se il buffer contiene almeno un pacchetto si ha L>=Length.
Length È il campo lunghezza contenuto nella
intestazione dei pacchetti.
H_ACL È il campo ACL Handle contenuto nella
ACL_H_B, ACL_H_C Sono gli handle ACL memorizzati nel parameter storage. Il valore di default è zero.
H_SCO È il campo SCO Handle contenuto nella
intestazione dei pacchetti.
SCO_H_B, SCO_H_C Sono gli handle SCO memorizzati nel parameter storage. Il valore di default è zero.
Code ACL_B, ACL_C, SCO_B, SCO_C
Sono le code dove vengono memorizzati i dati ACL ed SCO, ricevuti dai nodi B e C.
Coda eventi A E’ la coda dove vengono memorizzati gli eventi provenienti dal host controller A.
Tabella 2 : legenda del diagramma di flusso
Ritornando al discorso principale, se non c’è una intestazione valida, il parser riprende a prelevare dati dalla coda, ma non prima che siano trascorsi 20 ms dall’ultima volta che lo si è fatto: quest’attesa costituisce in un certo senso l’orologio del parser, nel senso che non si effettua mai un prelievo di dati più spesso di una volta ogni 20 ms. Se invece è presente una intestazione valida, si procede a controllare la lunghezza dei dati, verificando cioè, che il numero di byte seguenti l’intestazione siano in quantità almeno pari alla quantità indicata nel campo lunghezza. Se non fossero presenti, infatti, dati a sufficienza, dovremmo aspettare altro tempo ed ottenere nuovi dati dalla seriale. Se invece è presente un numero di byte sufficiente, il parser provvede a prelevare l’intero pacchetto dati
dal buffer S_buff A e a immagazzinarlo nella coda opportuna. Nel caso di pacchetti ACL ed SCO vengono controllati i rispettivi handle, confrontandoli con quelli contenuti nel parameter storage, per poter memorizzare i dati nella coda corretta.
figura 4-8
Prendi un dato dalla Coda Rx A
Salva il dato nel buffer S_buff A Cerca un indicatore di pacchetto qualunque Trovato? La coda è vuota? 0x02 0x03 0x04 0x02 0x03 0x04 02 03 04 Inizio si no si no ERRORE attesa
figura 4-9 figura 4-10 02 C’è una intestazione? Inizio L >= Length Misura lunghezza dati L
Preleva da S_buff L byte + intestazione
H_ACL=ACL_H_B
Salva I dati nella fifo ACL_B Salva I dati
nella fifo ACL_C
no no no si si si si 04 C’è una intestazione? Inizio L >= Length Misura lunghezza dati L
Preleva da S_buff A L byte + intestazione
Salva i dati nella coda eventi A
si si
no
figura 4-11
La fifo eventi A contiene i pacchetti evento che l’host controller, ovvero il nodo A manda all’host in risposta ai comandi che esso gli invia, nel nostro caso per mezzo del Connection manager A. Questo modulo software è realizzato con una macchina a stati finiti il cui grafo di flusso è riportato in Figura 4-12.
03
C’è una intestazione?
Inizio
L >= Length Misura lunghezza dati L
Preleva da S_buff L byte + intestazione
H_SCO=SCO_H_B
Salva I dati nella fifo SCO_B Salva I dati
nella fifo SCO_C
no no no si si si si
Figura 4-12 : il diagramma di flusso del Connection Manager A
Questa macchina si preoccupa di inviare i comandi necessari ad eseguire le procedure occorrenti per cercare un eventuale nodo (casco) B ed instaurare una connessione con esso. Come si vede in figura, compiendo un Reset come prima operazione, ci si assicura che il sistema parta da uno stato perfettamente noto. Soltanto dopo la notifica della corretta esecuzione del comando, mediante l’evento
Command Complete, la macchina transisce nel secondo stato, nel quale viene
inviato il comando Inquiry. Tale comando permette al master di individuare la presenza di eventuali caschi attivi nelle vicinanze. Se all’interno della portata della radio è effettivamente presente un casco, ed esso è nella modalità di inquiry scanning, ovvero è posto in condizione di rispondere, questo risponde comunicando al master il proprio indirizzo fisico e il valore dell’offset tra il suo clock Bluetooth e quello del master. Questi parametri servono per il calcolo della corretta sequenza delle frequenze di salto, permettendo la sincronizzazione fra
master e slave. Una volta che lo slave ha risposto, il software confronta l’indirizzo con quelli riportati in un elenco di indirizzi di caschi autorizzati alla connessione, che si trova nell’area di memoria parameter storage già menzionata. Nel nostro caso l’unico indirizzo autorizzato coincide semplicemente con quello del modulo B. La macchina a stati rimane in Inquiry fino a quando viene ricevuta una risposta dal nodo B, dopodiché passa nello stato di Add connection nel quale si compiono le operazioni necessarie per inserire il nodo B nella piconet; in particolare, viene instaurata una connessione ACL. Ribadiamo che in una piconet ogni connessione è univocamente individuata da un identificatore a 12 bit chiamato connection handle. È per mezzo di questi identificatori, registrati insieme con l’indirizzo del dispositivo in una opportuna area di memoria, che il software potrà inviare i dati ACL al destinatario corretto.
Terminata con successo la fase di connessione di un casco, esattamente con un messaggio di connection complete da parte del nodo B, la macchina a stati transisce nello stato denominato Scan enable, nel quale si mette in attesa di un messaggio di inquiry da parte di un terzo nodo (il nodo C nel nostro caso). Dopo l’evento command complete, la macchina a stati transisce nello stato Wait for connection request, durante il quale attende l’arrivo della richiesta di connessione da parte del nodo C, per mezzo del comando create connection. Lo stato successivo è quello chiamato Accept connection, durante il quale compie tutte le operazioni necessarie per l’instaurazione del link ACL con il nodo C. Da notare che ora il nodo A ha sia il ruolo di master (con il nodo B) che il ruolo di slave (con il nodo C), quindi la rete ottenuta è una scatternet. Lo stato di Accept connection termina quando viene memorizzato nel parameter storage l’handle ACL nella nuova connessione, che, insieme all’handle ACL della connessione col nodo B, verrà utilizzato dal parser A per smistare opportunamente i dati ricevuti. Lo stato finale è quello denominato Send & receive data, a cui si perviene tramite l’evento connection complete mandato dal nodo C. Durante questo stato avviene la vera e propria trasmissione di pacchetti ACL tra i nodi. Tramite il blocco Parser A, il nodo può ricevere e inviare dati ad entrambi i nodi B e C, che, in questo caso appartengono a due piconet diverse.
Per quanto riguarda la gestione degli altri nodi B e C, va detto che i blocchi Parser C e Parser B sono molto simili al Parser A; varia soltanto il numero delle code
nelle quali vengono salvati i dati. Per il Parser C, i dati provenienti dal nodo A vanno nell’unica coda ACL2_A, mentre per il Parser B i dati vengono salvati nella coda ACL1_A. La differenza sostanziale con il nodo A consiste nella sequenza dei comandi implementati all’interno del blocco Connection Manager B e C, sequenza che dipende strettamente dal ruolo dei nodi B e C nella rete finale. Analizziamo ora il diagramma di flusso del Connection manager B e C, rappresentati in figura 4-13 e in figura 4-14, rispettivamente.
figura 4-14 : diagramma di flusso del Connection Manager C
Per quanto riguarda il nodo B, si può notare che il suo diagramma di flusso gestisce la connessione del nodo come slave. Per fare ciò, subito dopo lo stato iniziale di Reset, esso passa allo stato Inquiry scan enable tramite un evento
command complete. Il nodo rimane in questo stato fin quando riceve un altro
evento command complete, dopodiché passa allo stato Wait for connection request nel quale attende una richiesta di connessione da parte del nodo A. Nel frattempo, il nodo A è passato dallo stato Inquiry allo stato Add connection, per via dell’evento inquiry valid che indica che l’indirizzo del nodo B è stato confrontato con gli indirizzi presenti nel parameter storage A e tale confronto ha dato esito positivo. Il nodo B, quindi, elabora la richiesta di connessione e passa allo stato Accept connection dove esegue le operazioni necessarie all’instaurazione del link. L’ultima operazione sarà quella di salvataggio del valore del handle ACL in parameter storage B. A questo punto il nodo B è diventato slave per il nodo A e, quindi, può passare allo stato finale Send & receive data. La piconet 1 è, dunque, attiva ed il nodo A può eseguire i passi successivi per instaurare la seconda piconet col nodo C.
Dal canto suo, il nodo C esegue tutte le operazioni necessarie per connettersi come master al nodo A, cui indirizzo era già stato salvato in parameter storage C.
Il nodo C passa dallo stato Reset allo stato Inquiry, quindi allo stato Add connection e, dopo aver ricevuto l’evento connection complete da parte del nodo A, passa allo stato Send & receive data. Questo stato rende attiva la trasmissione dei dati tra i nodi A e C nella piconet 2.
Per chiarire ulteriormente la relazione temporale tra gli stati di tutti e tre i diagrammi di flusso, proponiamo, nella figura 4-15 l’andamento nel tempo del flusso dei Connection Manager A, B e C. Da notare che i tre sottoprogrammi iniziano contemporaneamente, dopodiché i nodi A e B creano la loro connessione, mentre il nodo C rimane nello stato Inquiry. A questo punto un dubbio che può essere sollevato è il seguente: Può accadere che il nodo C, in inquiry, riesca a contattatare per primo il nodo B, in inquiry scan, e stabilisca una connessione con esso, al posto del nodo A? La risposta è negativa, dato che il nodo C, al contrario del nodo A, non possiede l’indirizzo di B nel suo parameter storage, quindi, se non riceve l’evento inquiry valid non può passare allo stato successivo, quello di Add connection. Dunque, il nodo B può instaurare una connessione soltanto col nodo A e non esiste alcun rischio di eventuali conflitti col nodo C.
Passiamo ad analizzare più dettagliatamente l’applicazione che rende possibile lo scambio dei dati tra i nodi. Supponiamo che, una volta stabilita la connessione di tipo scatternet, il nodo C voglia inviare un dato ACL al nodo B. Tale trasmissione deve ovviamente passare per il nodo A che, dopo una verifica del valore di ACLHandle presente nel pacchetto ACL, invia il dato al nodo destinatario.
I blocchi Connection Manager C, A e B sono rappresentati in figura 4-16, in figura 4-17 e in figura 4-18, rispettivamente.
figura 4-17 : la finestra del Connection Manager A
figura 4-18 : la finestra del Connection Manager B
Da notare che le variabili enumerate Status, Status2 e Status3, presenti all’interno delle finestre definiscono lo stato attuale di ogni nodo, e in questo caso tutti i nodi si trovano allo stato Send & receive data. Inoltre, per ogni nodo vengono evidenziate le code nelle quali vengono salvati i dati ricevuti e i dati da inviare. Il nodo C contiene le code ACL3master-slaveIn, CodaEvents3 e CodaSerialTx3, rispettivamente per i dati provenienti dal nodo A, per gli eventi e
per i dati da trasmettere. Il nodo A, invece, deve ricevere dati da due nodi sorgenti, quindi, le code necessarie per la gestione di tali dati sono due; le code ACLmasterIn e ACLslaveIn, rispettivamente per i dati provenienti dal nodo C e dal nodo B. Per il nodo B vale lo stesso discorso del nodo C, dato che deve gestire una sola connessione ACL col nodo A, quindi necessita della sola coda ACL2master-slaveIn.
Oltre alle varie code, nella finestra del Connection manager C sono presenti due piccole finestre di scrittura e lettura dati, rispettivamente Data send master e Data receive master. Inoltre, è presente anche la variabile booleana data send master messo sotto forma di un tasto on-off, tramite il quale l’utente può decidere in totale autonomia il tempo dell’inizio della trasmissione. Inizialmente il tasto è allo stato off e l’utente, dopo aver scritto il messaggio da mandare, può iniziare la trasmissione dei dati semplicemente premendo il tasto. Il dato viene ricevuto dal nodo A e subito messo in evidenza nella finestra Data from master to slave situata nel Connection manager A. Il nodo A prevede automaticamente a prelevare dalla coda ACLmasterIn il dato salvato, costruire il pacchetto ACL e metterlo nella coda CodaSerialTx, per poi essere trasmesso al nodo B.
Il dato ricevuto dal nodo B viene salvato nella coda ACL2master-slaveIn e subito evidenziato nella finestra Data receive slave situata nel Connection manager B. La trasmissione è quindi conclusa con successo.
Ed ora occupiamoci dei blocchi Parameter Storage, analizzando il loro funzionamento durante l’intero processo di creazione della scatternet e della trasmissione dati dal nodo C al nodo B. In figura 4-19 e in figura 4-20 sono rappresentate le finestre dei blocchi Parameter storage A e Parameter storage B al termine della trasmissione dei dati ACL.
figura 4-19 : la finestra del Parameter Storage A
Il Parameter storage A presenta varie finestre, tra cui la finestra Registered helmets dove, appena il programma entra in esecuzione vengono salvati gli indirizzi ed i nomi di, al massimo due slave (caschi). Quando il nodo A passa da Inquiry e Add connection, l’evento inquiry valid indica che lo slave B è stato riconosciuto dal master A e, a notifica di ciò, l’indirizzo del nodo B, insieme al suo nome (in questo caso Slave2) nella finestra Helmet1. Inoltre, in questa fase, il nodo A riceve l’evento Inquiry Result con diverse informazioni sul nodo B, tra le quali il parametro ClockOffset (CKOffs), ossia la differenza tra il clock del master A e il clock dello slave B, necessario per la sincronizzazione tra i due nodi. Dopo che la connessione ACL è stata stabilita, il nodo A riceve l’evento
connection complete con il quale viene trasmesso l’ACLHandle della
connessione, ed evidenziata nella sottofinestra ACL Handle. Il nodo B, dal canto suo, riceve l’indirizzo del nodo A nella finestra Master-slave al termine dell’Inquiry scan, e solo dopo lo stato Accept connection riceve l’ACLHandle della connessione. A questo punto si nota che i due ACL Handle riferiti alla stessa connessione sono diversi l’uno dall’altro. Il motivo di ciò è legato al fatto che gli Handle delle connessioni ACL interessanti un determinato nodo devono essere univocamente determinati per poter smistare in modo efficiente i dati e prevenire eventuali conflitti in trasmissione. Dato che nella scatternet progettata il nodo A ha il duplice ruolo di master e di slave in due connessioni, se il nodo C impone un ACLHandle nella connessione con A può accedere che tale Handle sia uguale all’ACLHandle stabilito dal nodo A nella connessione col proprio slave B. Per evitare ciò, entrambi i nodi A e C scelgono autonomamente gli Handle della loro connessione, in particolare il nodo A lo sceglie in modo che sia diverso dall’Handle stabilito in precedenza col nodo B. Di conseguenza, per ogni connessione ci sono sempre due valori di Handle, stabiliti da ogni nodo.
Ritornando alla finestra Parameter Storage A, si nota la presenza della sottofinestra chiamata Second master, dedicata alle informazioni ricevute dal nodo C, tra cui l’indirizzo situato nel campo Address, il tipo di connessione (se ACL o SCO) nel campo LinkType, il tipo di dispositivo Bluetooth nel campo ClassOfDevice, ed infine l’ACL Handle della connessione ACL. Inoltre sono presenti delle finestre accessibili in lettura tra cui l’Event buff, nella quale vengono visualizzati gli eventi provenienti da host-controller, l’ACLmasterIn
buff per evidenziare i pacchetti ACL provenienti dal nodo C e l’ACLslaveIn buff per i dati provenienti dal nodo B.
Il Parameter Storage B, invece, presenta soltanto due finestre, una per gli eventi (event buff slave) ed una per i dati ACL provenienti dal nodo A (ACL2master-slaveIn buff).
Per quanto riguarda la trasmissione dei pacchetti ACL dal nodo B al nodo C il procedimento è lo stesso; infatti nella finestra del Connection Manager B c’è il tasto on-off tramite il quale l’utente decide l’inizio della trasmissione dei dati al nodo A. Quest’ultimo fa un confronto tra il sottocampo handle del pacchetto ACL in arrivo e gli ACLHandle presenti in Parameter storage, dopodiché salva i dati nella coda ACLslaveIn. In seguito, il dato viene inviato al nodo C, con la stessa modalità di prima; esso viene, quindi, salvato nella coda ACLmaster-slaveIn e visualizzato nella finestra Data receive master. Le varie fasi della trasmissione suddetta sono rappresentate in figura 4-21, in figura 4-22 e in figura 4-23, rispettivamente per il nodo B, il nodo A ed il nodo C.
figura 4-22 : ricezione del dato da parte del nodo A
Le finestre del Parameter Storage A e del Parameter Storage C, al termine della trasmissione dei dati ACL dal nodo B al nodo C, sono rappresentate in figura 4-24 e in figura 4-25, rispettivamente. Si nota nella prima figura che il dato proveniente dal nodo B viene evidenziato nella finestra ACLslaveIn buff, dopodiché viene trasmesso al nodo C.
figura 4-25 : la finestra del Parameter Storage C
La finestra del Parameter Storage C non presenta molte differenze rispetto a quella del Parameter Storage A, dato che i due nodi sono concepiti per avere gli stessi requisiti e le stesse prestazioni. Le poche differenze tra le due finestre sono dovute al fatto che, nel nostro caso, per facilitare la connessione tra il nodo A e il nodo C e la formazione della scatternet, i nodi in gioco hanno dei ruoli già fissati. Il nodo C può assumere soltanto il ruolo di master nella connessione con il nodo A, quindi nella finestra del Parameter storage C non è presente il campo Second master, come nella finestra del Parameter Storage A. Ci sono, invece, tutti gli altri campi, tra cui Helmet1 master, dove si mettono in evidenza le informazioni ricevute dal nodo A, quali l’indirizzo, il nome, l’ACL Handle, il Clock Offset ecc. Il dato proveniente dal nodo A viene, infine, evidenziato nella finestra ACL3master-slaveIn buff.
