Service Discovery Protocol (SDP) Bluetooth

Transcript

1 Service Discovery Protocol (SDP) Bluetooth I protocolli di service discovery permettono a dispositivi ed applicazioni di cercare servizi offerti da altri dispositivi ed applicazioni. Per servizio si intende un'entità in grado di fornire informazioni, eseguire un'azione o controllare una risorsa per conto di un'altra entità. Un servizio può essere implementato in software, hardware o una combinazione dei due. All'esigenza primaria di procedure standardizzate per scoprire i servizi disponibili sono legate altre problematiche: trovare e ottenere le modalità di accesso a un servizio, controllare l'accesso ai servizi, render noti i servizi offerti, scegliere tra servizi concorrenti, etc. L'esigenza di protocolli di service discovery è un problema di importanza crescente, in virtù del sempre maggior orientamento dei calcolatori alle reti. Molte aziende, enti di standardizzazione e consorzi lo stanno affrontando. Sono perciò nati diversi protocolli di service discovery, tra cui Service Location Protocol (SLP), Jini, Salutation, UPnP (Univeral Plug and Play) e UDDI (Universal Description Discovery and Integration). Tutte queste architetture funzionano in generale in modo simile. Un client effettua una richiesta a un directory server, che offre un catalogo di servizi, oppure a uno specifico fornitore di servizi. La richiesta può contenere esplicitamente un identificativo di risorsa con uno o più attributi. Il directory server o il fornitore di servizi cerca nel suo database le risorse aventi descrizioni corrispondenti ai criteri di ricerca e risponde al client con l'identificativo e l'ubicazione delle risorse trovate. Il Service Discovery Protocol (SDP) fa parte dello stack di protocolli Bluetooth e affronta il problema del service discovery in modo ottimizzato per la natura altamente dinamica delle comunicazioni Bluetooth. Il protocollo SDP si occupa essenzialmente di scoprire i servizi resi disponibili da o attraverso dispositivi Bluetooth; non definisce, invece, metodi per accedere ai servizi. Una volta che un servizio è stato trovato tramite SDP, può essere utilizzato mediante altri protocolli definiti dalla specifica Bluetooth; le modalità d'accesso dipendono dal particolare servizio. Il meccanismo di service discovery, schematizzato in Figura 1, permette ad un'applicazione client di scoprire l'esistenza e gli attributi dei servizi forniti da applicazioni server. Il Bluetooth SIG ha prodotto, inoltre, la specifica di un profilo per definire i requisiti implementativi del Service Discovery Protocol e le funzionalità minime richieste ai protocolli dei livelli inferiori nello stack Bluetooth. Esso è denominato Service Discovery Application Profile (SDAP) e delinea anche, tramite un insieme di primitive generiche, possibili modalità di utilizzo del 1 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

2 protocollo SDP da parte delle applicazioni utente. Per quanto concerne strettamente il Service Discovery Protocol, l'interazione avviene tra un client e un server SDP in una o più transazioni, ognuna formata da una richiesta e una risposta. Ciascuna richiesta o risposta consta a sua volta di un'unica PDU (Protocol Data Unit). Un dispositivo Bluetooth può agire sia da client sia da server SDP; se non fornisce servizi, non c'è bisogno del server. Ciascun dispositivo può avere un solo server e un solo client, che però possono operare per conto di diverse applicazioni. Le informazioni fornite da un server SDP riguardano solo i servizi offerti dal dispositivo su cui risiede: le specifiche vietano la possibilità che un dispositivo interroghi un altro per cercare i servizi presenti su un terzo dispositivo. Applicazione client Client SDP Richiesta SDP Risposta SDP Figura 1: Interazione nel protocollo SDP Applicazione server Server SDP 1. Record di servizio Per ciascun servizio che un dispositivo Bluetooth è in grado di offrire, il server SDP possiede uno e un solo record di servizio (service record), che contiene tutte le informazioni ad esso relative. Un record di servizio SDP è costituito unicamente da un elenco di attributi di servizio. Ogni attributo di servizio descrive una singola caratteristica di un servizio ed è composto da due elementi: 1. un identificativo (ID) di attributo a 16 bit; 2. un campo di lunghezza variabile, il cui formato e significato sono specificati dall'identificativo di attributo e dalla classe di servizi a cui il particolare servizio appartiene. Ogni servizio, infatti, appartiene almeno ad una classe di servizi. Una classe di servizi identifica una particolare tipologia di servizi e definisce: quali attributi possono essere presenti nel 2 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

3 service record per descrivere il servizio, il valore degli identificativi di tali attributi, il loro significato e il loro formato. Il Bluetooth SIG si occupa di standardizzare le classi di servizi. Non è necessario che ogni service record contenga effettivamente tutti gli attributi previsti dalla classe; se però contiene uno degli attributi previsti, il suo formato e il suo significato devono rispettare la specifica. Un fornitore di servizi può indicare ulteriori attributi di servizio, non previsti dalla specifica della classe di servizi, usando uno degli ID liberi. Ad ogni classe di servizi è associato anche un UUID (Universally Unique Identifier, identificativo universalmente univoco). Un UUID nella specifica SDP è definito come un numero intero a 128 bit di cui si assume garantita l'univocità ovunque e senza limiti di tempo. Non esiste un registro centralizzato di UUID, ma possono essere creati indipendentemente in maniera distribuita. La specifica prevede degli alias abbreviati a 16 o 32 bit per un intervallo di UUID riservato dal Bluetooth SIG, che ha definito anche l'algoritmo di traduzione di tali alias in UUID completi a 128 bit. A titolo d'esempio, alcuni dei più comuni attributi di servizio sono elencati in Tabella 1. Esistono solo due attributi che devono esser presenti in tutti i service record. Essi sono mostrati in Tabella 2. L'attributo ServiceRecordHandle identifica ciascun record di servizio in un server SDP mediante un handle a 32 bit. Il valore di un handle è univoco solo all'interno di un singolo server. Un unico handle ha il medesimo significato in ogni server SDP, quello che vale 0x e si riferisce al server SDP stesso. Nel corrispondente service record Nome ServiceClassIDList ProtocolDescriptorList ProviderName IconURL ServiceName ServiceDescription Descrizione Identifica il tipo di servizio rappresentato dal service record, attraverso una elenco di classi di servizio a cui appartiene. Indica i protocolli che possono essere utilizzati per accedere al servizio. Nome testuale dell'individuo o organizzazione che fornisce il servizio. Un URL che si riferisce ad un'immagine che può essere usata per rappresentare il servizio. Una stringa di testo contenente un nome del servizio comprensibile agli utenti umani. Una stringa di testo contenente una descrizione del servizio. possono essere presenti attributi che Tabella 1: Esempi di attributi di servizio SDP indicano la versione di protocollo SDP supportata e i protocolli di livello inferiore utilizzabili per la comunicazione. I valori di handle da 0x a 0x0000FFFF sono inoltre riservati. 3 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

4 L'attributo ServiceClassIDList, invece, è una sequenza di UUID che identificano le classi di servizi a cui il servizio appartiene. Nel paragrafo successivo esamineremo la rappresentazione dei dati nel protocollo SDP. Nome ID attributo Tipo di valore dell'attributo ServiceRecordHandle 0x0000 Intero senza segno a 32 bit ServiceClassIDList 0x0001 Data Element Tabella 2: Attributi di servizio SDP obbligatori Valore del descrittore di tipo Valori validi per il descrittore di lunghezza 0 0 Nil, il tipo nullo 1 0,1,2,3,4 Intero senza segno Descrizione del tipo 2 0,1,2,3,4 Intero con segno in complemento a 2 3 1,2,4 UUID, identificativo universalmente univoco 4 5,6,7 Stringa di testo 5 0 Booleano 6 5,6,7 Data Element, un Data Element il cui campo dati è una sequenza di Data Element 7 5,6,7 Data Element Alternative, un Data Element il cui campo dati è una sequenza di Data Element da cui occorre sceglierne uno 8 5,6,7 URL 9-31 Riservati Tabella 3: Possibili valori del descrittore di tipo di un Data Element SDP. Per il significato del valore del descrittore di lunghezza, si veda la Tabella Rappresentazione dei dati Per permettere la rappresentazione di valori di complessità arbitraria per gli attributi di servizio, il protocollo SDP prevede una struttura di dati flessibile che prende il nome di Data Element. Essa è composta da un'intestazione (header) di 8 bit e un campo di dati, la cui lunghezza e struttura dipendono dall'header. L'intestazione è a sua volta suddivisa in due parti: 1. descrittore di tipo (5 bit): indica come interpretare il campo di dati. La Tabella Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

5 mostra i tipi definiti dallo standard; 2. descrittore di lunghezza (3 bit): indica la lunghezza del campo di dati, come mostrato in Tabella 4. Dalla Tabella 3 si osserva, inoltre, che in base al tipo di Data Element solo alcuni valori sono ammessi per il descrittore di lunghezza. Valore del descrittore di lunghezza Bit aggiuntivi Lunghezza dei dati byte. Eccezione: se il tipo è nil, la lunghezza è 0 byte byte byte byte byte 5 8 La lunghezza dei dati è contenuta negli 8 bit aggiuntivi, che vanno interpretati come un intero senza segno 6 16 La lunghezza dei dati è contenuta nei 16 bit aggiuntivi, che vanno interpretati come un intero senza segno 7 32 La lunghezza dei dati è contenuta nei 32 bit aggiuntivi, che vanno interpretati come un intero senza segno Tabella 4: Possibili valori del descrittore di lunghezza di un Data Element SDP 3. Modalità del service discovery: searching e browsing Per permettere il reperimento dei servizi di interesse il protocollo SDP prevede due modalità di ricerca. Searching: è la transazione di ricerca di un servizio a partire dal valore di uno o più dei suoi attributi. Non è consentita la ricerca per qualsiasi tipo di attributo, ma solo per quelli di tipo UUID, che generalmente sono usati per denotare le caratteristiche distintive di un servizio. Il client effettua una ricerca inviando un search pattern costituito da uno o più UUID. Il criterio di ricerca si considera soddisfatto dai record di servizio che contengono tra i loro attributi tutti gli UUID specificati, a prescindere da quali attributi effettivamente li contengano e dall'ordine. Browsing: è la modalità di ricerca adatta a scoprire quali tipi di servizi sono offerti da un server SDP senza avere alcuna conoscenza a priori. Il meccanismo si basa su 5 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

6 un'organizzazione ad albero di gruppi di servizi. Ciascun gruppo può contenere servizi o sottogruppi di servizi forniti dal server SDP. I sottogruppi sono rappresentati da service record aventi classe di servizio BrowseGroupDescriptor. Ogni gruppo o sottogruppo, a partire dal nodo radice della gerarchia (detto root browse group), è identificato da un UUID. Se i servizi sono pochi, tipicamente al server SDP converrà inserirli tutti sotto il nodo radice. L'esplorazione di quest'albero da parte del client avviene attraverso un particolare attributo di servizio, condiviso da tutte le classi di servizi: esso è detto BrowseGroupList e il suo valore consiste in un elenco di UUID che indicano i gruppi a cui il servizio (o il sottogruppo) appartiene. Per iniziare il browsing, dunque, il client effettuerà una ricerca inviando come pattern l'uuid del root browse group; il server restituirà i riferimenti ai servizi e ai sottogruppi che appartengono ad esso. Il client potrà poi esplorare il contenuto di un sottogruppo inviando come criterio di ricerca l'uuid che lo identifica, e così via. Intestazione Parametri PDU ID Transaction ID ParameterLength Parametro 1 Parametro 2... Parametro n 1 byte 2 byte 2 byte ParameterLength byte Tabella 5: Formato di una PDU per il protocollo SDP 4. Formato di Protocol Data Unit Come già accennato, ogni transazione SDP consta di una Protocol Data Unit (PDU) di richiesta e una di risposta. La struttura di una PDU per il protocollo SDP è mostrata in Tabella 5 ed è descritta di seguito. PDU ID Descrizione del tipo di PDU PDU ID: identifica il 0x00 Riservato tipo di PDU, cioè indica il suo significato e specifica i parametri contenuti. La Tabella 6 mostra i tipi di PDU definiti dallo standard. 0x01 SDP_ErrorResponse 0x02 SDP_ServiceSearchRequest 0x03 SDP_ServiceSearchResponse 0x04 SDP_ServiceAttributeRequest 0x05 SDP_ServiceAttributeResponse 0x06 Transaction ID: SDP_ServiceSearchAttributeRequest 0x07 SDP_ServiceSearchAttributeResponse identifica ogni nuova 0x08-0xFF Riservati richiesta e serve a far Tabella 6: Tipi di PDU previsti dal protocollo SDP 6 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

7 corrispondere le PDU di risposta alle rispettive richieste. Un client SDP non può inviare una PDU con questo campo uguale ad una PDU inviata in precedenza e a cui non abbia già ricevuto risposta. ParameterLength: indica la lunghezza complessiva, in byte, dei parametri della PDU trasmessa. Prima di esaminare i tipi di transazioni SDP e le relative PDU, è opportuno accennare a due circostanze che possono verificarsi. Se il server SDP riceve una richiesta non correttamente formulata o non è in grado, per qualsiasi motivo, di rispondere con la PDU appropriata, risponderà con una PDU di tipo SDP_ErrorResponse. Essa ha come parametri un codice che identifica il tipo di errore verificatosi e un campo opzionale di informazioni aggiuntive. Se invece la risposta è troppo lunga per esser contenuta in un'unica PDU, il server SDP invierà solo una parte della risposta e, in aggiunta ai parametri normalmente previsti dal tipo di PDU inviato, inserirà un campo detto continuation state information. Il client, per ottenere il resto della risposta, invierà allora un'altra PDU di richiesta dello stesso tipo della precedente (ma con un diverso Transaction ID), a cui accluderà il valore di continuation state ricevuto. In questo modo il server saprà che il client desidera ricevere la parte successiva della risposta. 5. Transazioni SDP L'attuale specifica SDP prevede tre tipi di transazioni, descritte in questo paragrafo. 1. SDP_ServiceSearch: consiste nella ricerca di servizi mediante UUID, spiegata in 3. E' composta da una PDU di richiesta di tipo SDP_ServiceSearchRequest, con cui il client invia il pattern di ricerca, e da una risposta di tipo SDP_ServiceSearchResponse, in cui il server invia gli handle dei service record che soddisfano la richiesta. I parametri di cui si compongono queste due PDU sono descritti rispettivamente in Tabella 7 e Tabella SDP_ServiceAttribute: il client SDP invia una PDU di tipo SDP_ServiceAttributeRequest per richiedere il valore di determinati attributi di un particolare service record. Il server SDP risponde con una PDU di tipo SDP_ServiceAttributeResponse. I parametri di tali PDU sono descritti in dettaglio rispettivamente in Tabella 9 e Tabella SDP_ServiceSearchAttribute: questa transazione combina le due precedenti in un'unica richiesta. Il client SDP invia, in una PDU di tipo 7 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

8 SDP_ServiceSearchAttributeRequest, un pattern di ricerca e un elenco di attributi da restituire per i record che lo soddisfano. Il server SDP risponde restituendo una PDU di tipo SDP_ServiceSearchAttributeResponse. I parametri di queste due PDU sono descritti rispettivamente in Tabella 11 e Tabella 12. Parametro Tipo Descrizione ServiceSearch Pattern MaximumService RecordCount Data Element Intero a 16 bit Intero a 8 bit Criterio di ricerca costituito da una sequenza di UUID (al massimo 12). Numero massimo di handle di record di servizio da restituire nella risposta. Numero di byte di lunghezza del valore di continuation state ricevuto in una precedente risposta. Se non deve essere fornito un valore di continuation state, questo parametro è posto a 0. Tabella 7: Parametri di una PDU di tipo SDP_ServiceSearchRequest Parametro Tipo Descrizione TotalService RecordCount CurrentService RecordCount ServiceRecord HandleList Intero a 16 bit Intero a 16 bit Lista di handle a 32 bit Intero a 8 bit Numero totale di record di servizio che soddisfano il criterio di ricerca. Se nessun record corrisponde, è posto a 0. Non deve mai superare il valore di MaximumServiceRecordCount specificato nella richiesta. In caso di più risposte parziali ad una richiesta, questo parametro ha sempre lo stesso valore. Numero di record di servizio contenuti nel parametro successivo. Se nessun record corrisponde, è posto a 0. Non deve mai superare il valore di MaximumServiceRecordCount specificato nella richiesta. Contiene una successione di handle a 32 bit, ciascuno relativo ad un service record che soddisfa il criterio di ricerca. Non è presente un'intestazione né una struttura di tipo Data Element. Numero di byte di lunghezza del valore di continuation state inviato in caso di risposta parziale. Se la risposta è completa, questo parametro è posto a 0. Tabella 8: Parametri di una PDU di tipo SDP_ServiceSearchResponse 8 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

9 Parametro Tipo Descrizione ServiceRecord Handle Maximum Attribute ByteCount AttributeIDList Handle a 32 bit Intero a 16 bit Data Element Intero a 8 bit Individua il service record da cui estrarre gli attributi richiesti. L'handle deve esser stato ottenuto da una precedente transazione di SDP_ServiceSearch. Numero massimo di byte di dati relativi agli attributi da restituire nella risposta. Se i valori degli attributi richiedono più spazio di quanto specificato in questo parametro, il server SDP dovrà decidere come suddividere la risposta. Sequenza di Data Element che contiene gli identificativi degli attributi oggetto della richiesta. Ogni elemento è un intero senza segno a 16 bit, che rappresenta un ID di attributo, oppure un intero senza segno a 32 bit, che rappresenta un intervallo di ID di attributi (i 16 bit più significativi indicano l'estremo inferiore e i 16 bit meno significativi l'estremo superiore dell'intervallo). Gli ID degli attributi richiesti devono essere indicati in ordine crescente e senza ripetizioni. Come il parametro omonimo in SDP_ServiceSearchRequest (cfr. Tabella 7) Tabella 9: Parametri di una PDU di tipo SDP_ServiceAttributeRequest Parametro Tipo Descrizione AttributeList ByteCount AttributeList Intero a 16 bit Data Element Intero a 8 bit Numero di byte del parametro successivo. Non deve mai superare il valore di MaximumAttributeByteCount specificato nella richiesta. Contiene una sequenza di coppie di Data Element. Ogni coppia è formata dall'id di uno degli attributi richiesti e dal rispettivo valore. Tra gli attributi richiesti non devono essere restituiti quelli per cui non è definito un valore nel service record in possesso del server SDP. Gli ID devono essere in ordine crescente. Come il parametro omonimo in SDP_ServiceSearchResponse (cfr Tabella 8) Tabella 10: Parametri di una PDU di tipo SDP_ServiceAttributeResponse 9 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab

10 Parametro Tipo Descrizione ServiceSearch Pattern Maximum AttributeByteCount AttributeIDList Data Element Come il parametro omonimo in SDP_ServiceSearchRequest (cfr. Tabella 7) Intero a 16 bit Come il parametro omonimo in SDP_ServiceAttributeRequest (cfr. Tabella 9) Data Element Come il parametro omonimo in SDP_ServiceAttributeRequest (cfr. Tabella 9) Intero a 8 bit Come il parametro omonimo in SDP_ServiceSearchRequest (cfr. Tabella 7) Tabella 11: Parametri di una PDU di tipo SDP_ServiceSearchAttributeRequest Parametro Tipo Descrizione AttributeLists ByteCount AttributeLists Intero a 16 bit Data Element Intero a 8 bit Numero di byte del parametro successivo. Non deve mai superare il valore di MaximumAttributeByteCount specificato nella richiesta. Ogni elemento della sequenza è a sua volta un Data Element, che rappresenta una lista di attributi relativa ad un service record che soddisfa i criteri di ricerca. Ogni lista di attributi è costituita da una sequenza di coppie di Data Element. Ogni coppia è formata dall'id di uno degli attributi richiesti e dal rispettivo valore. Tra gli attributi richiesti non devono essere restituiti quelli per cui non è definito un valore nel service record in possesso del server SDP. All'interno di ogni lista di attributi, gli ID devono essere in ordine crescente. Come il parametro omonimo in SDP_ServiceSearchResponse (cfr. Tabella 8) Tabella 12: Parametri di una PDU di tipo SDP_ServiceSearchAttributeResponse 10 - Bluetooth Service Discovery Protocol Floriano Scioscia - SisInfLab