Salvatori 2006-07

Università degli studi di Roma “La Sapienza”
Facoltà di Ingegneria
Corso di laurea in Ingegneria delle
Telecomunicazioni
Tesi di laurea
Universal Plug & Play
Relatore:
Prof. Roberto Cusani
Laureando:
Riccardo Salvatori
Co-relatore:
Ing. Tiziano Inzerilli
Anno Accademico 2006-2007
Indice
Indice...................................................................................................................................................... 2
Capitolo 1................................................................................................................................................... 4
Service discovery: stato dell’arte ........................................................................................................... 4
1.1
Introduzione ........................................................................................................................ 4
1.2
Service Discovery ............................................................................................................... 6
1.2.1
L’evoluzione del service discovery ................................................................................ 6
1.2.2
Gli elementi fondamentali del service discovery............................................................ 7
1.2.3
Requisiti del service discovery per il nomadic computing ........................................... 12
1.3
Caratteristiche generali di UPnP™ ................................................................................... 14
1.4
UPnP Forum...................................................................................................................... 16
1.5
Componenti di una rete UPnP........................................................................................... 16
1.5.1
Periferiche .................................................................................................................... 17
1.5.2
Servizi .......................................................................................................................... 17
1.5.3
Punti di controllo.......................................................................................................... 19
1.6
Panoramica sui protocolli UPnP ....................................................................................... 19
1.7
Protocolli specifici di UPnP .............................................................................................. 21
1.7.1
TCP/IP.......................................................................................................................... 21
1.7.2
HTTP............................................................................................................................ 21
1.7.3
SDDP............................................................................................................................ 22
1.7.4
GENA........................................................................................................................... 23
1.7.5
SOAP............................................................................................................................ 24
1.7.6
XML............................................................................................................................. 24
1.8
Stack protocollare di UPnP ............................................................................................... 25
1.9
Fasi della connettività di UPnP ......................................................................................... 26
1.9.1
Indirizzamento.............................................................................................................. 27
1.9.2
Rilevazione................................................................................................................... 27
1.9.3
Descrizione................................................................................................................... 30
1.9.4
Controllo ...................................................................................................................... 31
1.9.5
Gestione degli eventi .................................................................................................... 33
1.9.6
Presentazione................................................................................................................ 34
1.10
Analisi dello standard UPnP ............................................................................................. 35
1.10.1 Requisiti di UPnP per il service discovery ................................................................... 36
1.10.2 Vantaggi di UPnP......................................................................................................... 36
1.10.3 Svantaggi di UPnP ....................................................................................................... 38
Capitolo 2................................................................................................................................................. 41
Descrizione del contesto applicativo.................................................................................................... 41
2.1
Introduzione ...................................................................................................................... 41
2.2
Contesto di gestione dell’ambiente domestico.................................................................. 43
2.3
Requisiti di una rete domestica ......................................................................................... 45
2.4
Modello di rete domestica UPnP....................................................................................... 46
2.5
UPnP Script di una rete domestica.................................................................................... 47
2.6
Sequence diagram dell’UPnP script.................................................................................. 60
2.7
Come creare una rete domestica UPnP: il software Intel® ............................................... 62
2.8
Il software Intel® per la tecnologia UPnP™..................................................................... 63
2.9
Esempio di costruzione di un device: Micro Light Bulb................................................... 66
2.9.1
Descrizione del dispositivo Micro Light Bulb.............................................................. 67
2.9.2
Descrizione dei servizi Micro Light Bulb: SwitchPower ............................................. 68
2
2.9.3
Descrizione dei servizi Micro Light Bulb: DimmingService ....................................... 68
2.9.4
Progettazione dei servizi di Micro Light Bulb ............................................................. 69
2.9.5
Generazione dello stack UPnP di Micro Light Bulb .................................................... 71
2.9.6
Codice sorgente generato ............................................................................................. 77
2.10
Simulazione connettività UPnP: scenario 1 ...................................................................... 77
2.11
Simulazione connettività UPnP: scenario 2 ...................................................................... 83
Capitolo 3................................................................................................................................................. 86
Analisi e sviluppo del progetto............................................................................................................. 86
3.1
Introduzione ...................................................................................................................... 86
3.2
Scenario di riferimento...................................................................................................... 87
3.3
Problema aperto: contese d’accesso .................................................................................. 89
3.4
Architettura AV UPnP: descrizione generale.................................................................... 90
3.5
Descrizione del dispositivo AV Media Server .................................................................. 91
3.5.1
Descrizione servizi AV Media server: Content Directory............................................ 92
3.5.2
Descrizione servizi AV Media server: Connection Manager ....................................... 92
3.5.3
Descrizione servizi AV Media server: AV Transport .................................................. 93
3.6
Descrizione del dispositivo AV Media Renderer.............................................................. 94
3.6.1
Descrizione servizi AV Media renderer: Rendering Control ....................................... 95
3.7
Architettura QoS UPnP: descrizione generale .................................................................. 95
3.7.1
Descrizione servizi architettura QoS: QoS Policy Holder............................................ 97
3.7.2
Descrizione servizi architettura QoS: QoS Manager.................................................... 98
3.7.3
Descrizione servizi architettura QoS: QoS Device Service.......................................... 98
3.8
Architettura AV/QoS UPnP: descrizione generale............................................................ 99
3.9
Architettura AV/QoS UPnP: sequence diagram generale ............................................... 100
3.6.1
Fase 1: Scoperta dei device ........................................................................................ 101
3.6.2
Fase 2: Visualizzazione dei contenuti AV.................................................................. 101
3.6.3
Fase 3: Visualizzazione protocolli/formato dati supportati ........................................ 102
3.6.4
Fase 4: Matching protocolli/formato dati supportati .................................................. 103
3.6.5
Fase 5: Configurazione dispositivi AV ...................................................................... 104
3.6.6
Fase 6: Selezione contenuti AV ................................................................................. 105
3.6.7
Fase 7: Rendering control........................................................................................... 106
3.6.8
Fase 8: Inizio contese ................................................................................................. 107
3.6.9
Fase 9: Inizio contese ................................................................................................. 108
Fase : Chiusura della connessione ............................................................................................ 110
Bibliografia ........................................................................................................................................ 115
Documenti .......................................................................................................................................... 117
Link .................................................................................................................................................... 117
3
Capitolo 1
Service discovery: stato dell’arte
1.1 Introduzione
Lo sviluppo delle tecnologie di comunicazione wireless ha portato in questi ultimi anni
a risultati fino a poco tempo fa insperati e ha contemporaneamente dato nuova linfa ai
processi di sviluppo e ricerca relativi alla comunicazione tra dispositivi fisici, aprendo
di fatto una nuova era per la progettazione in ambito informatico. La diffusione e il
crescente successo di device mobili come laptop computer, PDA (Personal Digital
Assistant) e telefoni cellulari ha contribuito all’accelerazione dell’utilizzo della
tecnologia wireless e alla sua rapida evoluzione nel campo della comunicazione
multimediale. Oggi la tecnologia wireless si è imposta con vigore sul mercato come
valida alternativa ai sistemi wired e ha permesso lo sviluppo di nuovi sistemi per
l’iterazione tra componenti fisici, soprattutto in ambiente mobile, grazie alla creazione
di apposite reti per l’interscambio di informazioni applicative. Le mobile ad-hoc
network (Manet) permettono una distribuzione nello spazio in modo dinamico, in
quanto i loro nodi sono costituiti essenzialmente da device portatili, come palmari e
cellulari. Si capisce come una rete di questo tipo non possa fare affidamento sulle
comuni tecniche di distribuzione dei dati, in quanto si dovrà tenere conto di molti
aspetti, come la continua trasformazione della rete e la limitatezza delle risorse messe a
disposizione, che esulano dai tipici aspetti legati alle infrastrutture wired. I recenti
progressi nelle tecnologie di comunicazione e nei modelli dell’ingegneria del software,
conducono verso nuovi scenari applicativi nell’ambito dell’elaborazione distribuita. Le
4
nuove tecnologie di connessione senza filo permettono l’evoluzione dei sistemi
distribuiti tradizionali verso i sistemi di nomadic computing, caratterizzati dalla
presenza di un’infrastruttura di rete fissa alla quale possono connettersi diverse
infrastrutture di rete mobili. Gli utenti di questi nuovi sistemi portano con sé le proprie
apparecchiature mobili (PDA, laptop, mobile phone di ultima generazione e così via)
tramite le quali interagiscono con l’ambiente che li circonda, usufruendo dei servizi da
esso offerti. La figura 1 mostra un possibile scenario di nomadic computing.
Figura 1: Esempio di Nomadic Computing.
Un aspetto molto importante in questo senso è la procedura di service discovery che
permette la scoperta, da parte di un determinato dispositivo, dei device fisici ad esso più
vicini e dei sevizi che quest’ultimi mettono a disposizione dei componenti della rete
wireless a cui appartengono.
Attualmente sono presenti sul mercato diversi standard in grado di effettuare service
discovery, tra i quali citiamo:
5
Service Location Protocol (SLP), sviluppato da IETF,
Jini,
Salutation,
Universal Plug and Play (UPnP), sviluppato da Microsoft®,
Bluetooth Service Discovery Protocol (SDP).
Questo capitolo offrirà una descrizione generale del service discovery ed in particolare
del protocollo UPnP, il più recente tra questi, analizzando tutti i vantaggi che questa
soluzione offre. Inoltre verranno evidenziate le limitazioni di cui l’attuale versione
soffre e che potrebbero condizionare l’evoluzione futura.
1.2 Service Discovery
Service discovery è un termine usato per descrivere i protocolli e i meccanismi
attraverso cui un dispositivo o componente software diviene consapevole della rete a
cui è connesso e scopre quali servizi sono disponibili. Le tecnologie di service
discovery sono state sviluppate per semplificare l’uso di dispositivi mobili in una rete
permettendo loro di essere scoperti, configurati ed usati da altri dispositivi con uno
sforzo minimo da parte dell’utente. La fase di service discovery termina con
l’indicazione della disponibilità di uno o più servizi corrispondenti a quelli richiesti. Al
service discovery, segue poi una fase di service delivery composta principalmente da
due parti: il modo in cui accedere al servizio ed il suo vero e proprio utilizzo.
1.2.1 L’evoluzione del service discovery
Il recente progresso nei sistemi distribuiti ha condotto anche all’evoluzione delle
tecniche di service discovery. Per sistemi relativamente statici, come i sistemi distribuiti
6
tradizionali, il service discovery può essere ottenuto attraverso tool di configurazione
manuali o semiautomatici: la configurazione può essere fatta una volta durante
l’installazione del sistema e mantenuta manualmente da un amministratore. Con
l’avvento dei dispositivi mobili, i servizi e le applicazioni possono agganciarsi e
lasciare la rete abbastanza frequentemente, rendendo questo approccio senz’altro poco
scalabile. Inoltre, l’evoluzione tecnologica degli ultimi tempi sta diffondendo tutta una
serie di nuovi dispositivi (PDA, smart phone, ecc …) che grazie alle nuove connettività
di rete di tipo wireless dovrebbero poter comunicare tra di loro in maniera spontanea e
con uno sforzo di configurazione minimo. Per far sì che questi dispositivi diventino
sempre più diffusi nel vivere quotidiano, è indispensabile che essi abbiano
caratteristiche di semplicità, versatilità e usabilità e che siano in grado di configurarsi
da soli. Tutte queste caratteristiche devono essere offerte dal software in esecuzione su
tali dispositivi e tale software deve essere progettato accettando l’ipotesi che non ci sia
necessariamente una persona in grado di effettuare configurazioni manuali dei servizi di
rete. A sostegno dello sviluppo di questo nuovo tipo di applicazioni non possono quindi
mancare tecniche di service discovery completamente automatiche, quale semplice
mezzo per scoprire i servizi dell’ambiente circostante senza averne conoscenza a priori.
1.2.2 Gli elementi fondamentali del service discovery
Un protocollo di discovery è caratterizzato in generale da diverse entità: i servizi,
un’entità che richiede servizi (client agent), un’entità che li offre (service agent) ed
un’entità che cataloga tutti i servizi disponibili nell’ambiente (registry).
In particolare, gli elementi citati possono essere definiti come segue:
Service; è un entità logica, definita da un interfaccia pubblica o descrittore;
Client agent; è il componente software o dispositivo che cerca i servizi di cui ha
bisogno. Nella letteratura delle SOA (Service Oriented Architetture) , tale componente
prende il nome di service requestor.
Service agent; è il componente software che implementa un servizio coerentemente al
suo descrittore e lo mette a disposizione dei client agent. Relativamente alla definizione
7
data nelle SOA, tale componente è anche denominato service provider. Si osservi che
un service agent può anche comportarsi come client agent se necessita di ricercare altri
servizi per portare a termine le proprie elaborazioni.
Registry; il registry, o service locator nel gergo delle SOA, rappresenta il luogo dove le
informazioni sui servizi disponibili nell’ambito di rete vengono memorizzate e risponde
alle richieste di pubblicazione e ricerca dei servizi. Tipicamente il registry contiene una
entry per ogni servizio pubblicato da un service agent e organizza le varie entry in una
struttura logica diversa a seconda della particolare soluzione (albero, grafo, lista,
database relazionale o ad oggetti e così via). Ogni entry consiste nel descrittore del
servizio. In particolare è possibile definire due tipi di organizzazione dei registry: flat
oppure gerarchica. Nel primo caso client e service compongono una rete di tipo peerto-peer, scambiandosi informazioni tra di loro. Nel secondo caso i servizi a cui si può
accedere sono ordinati con struttura gerarchica. DNS (Domain Name System) è un
esempio di questo tipo. Il registry può essere implementato sia localmente ai dispositivi
che offrono servizi che esternamente ad essi. Nello standard UPnP, per esempio, il
registry è interno ai dispositivi che offrono i servizi alla rete. Nel caso di registry
esterno, esso può essere sia centralizzato che distribuito. In uno schema centralizzato
tutte le informazioni sui servizi sono contenute all’interno di un’unica locazione di
memoria, con pesanti ripercussioni sulla robustezza del sistema. Infatti, in questo caso,
l’intero sistema avrà nel registry un bottleneck e un single point of failure
contemporaneamente.
La soluzione che adotta un registry distribuito sembra essere invece la migliore, in
quanto il guasto di alcune locazioni di memoria danneggerebbe soltanto una porzione
del sistema. Inoltre potendo disporre di minore informazione su ciascuna locazione, si
avrebbe maggiore efficienza.
E’ bene osservare che l’esito della fase di discovery può condurre alla localizzazione di
servizi anche fisicamente distanti dal dispositivo che ospita il client agent che ne ha
fatto richiesta, impedendo talvolta l’utilizzo del servizio (si pensi ad esempio ad un
servizio di stampa). Per i sistemi di nomadic computing risulta dunque essenziale
introdurre il principio di boundary, secondo cui i sistemi vanno progettati in maniera da
dividere l’ambiente di ricerca in zone con confini ben delineati; in questo modo la
8
richiesta di service discovery può fare esplicito riferimento a servizi all’interno di un
preciso boundary o all’esterno di esso.
Al fine di ricercare un servizio, o una risorsa, è necessario definire un meccanismo
unico di identificazione, ovvero un name space (insieme di identificatori utilizzati per
caratterizzare una entità precisa tra un insieme di oggetti). Infatti ogni servizio ha un
nome e tramite questo viene ricercato, invocato ed infine utilizzato dal client agent che
ne fa richiesta. In aggiunta è possibile fare uso di un name space descrittivo, cioè
caratterizzato dalla presenza di attributi, i cosiddetti service attributes, con i quali
fornire dettagli circa l’entità rappresentata permettendo anche una ricerca più precisa
del servizio di cui si ha necessità. Di fatto un name space del genere permette di non
dover conoscere a priori nemmeno il nome logico della risorsa cercata. Questo
approccio di ricerca è caratterizzato dal fatto che è il client a cercare il servizio che
desidera (user selection), aumentando l’interoperabilità tra le risorse, in quanto la
semantica degli attributi consente di accrescere la flessibilità della ricerca dei servizi. Il
protocollo di discovery ritornerà la lista dei servizi che rispondono ai service attributes
selezionati dal client (service matching) oppure una selezione dei migliori tra questi.
Viveversa esistono alcuni protocolli di service discovery che decidono di quali servizi il
client ha bisogno oppure offrono una lista di servizi disponibili rendendo meno
complessi i programmi del client e riducendo il costo computazionale della ricerca
(protocol selection).
Relativamente al caso di user selection, è necessario definire un linguaggio con il quale
descrivere servizi o dispositivi, ovvero un lessico ed una sintassi attraverso cui mostrare
il loro identificativo, il loro nome, i loro attributi, e tutto ciò che li distingue dagli altri
servizi. Ad ogni servizio sarà così associato un descrittore che lo caratterizza e ne
consente la ricerca in base alle sue peculiarità. In particolare, un descrittore può visto
come un record di n campi (service attributes) del tipo:
[service_ID, service_type, service_name, manufacturer_ID, version, property_1,…,
property_m, comment, ecc…]
Il linguaggio adottato dal protocollo di service discovery serve a stabilire il formato di
questo record. Nel seguito indicheremo il descrittore di servizio con il termine Service
Description Record o più brevemente SDR. Per ogni servizio, l’informazione che lo
9
riassume o meglio l’SDR, può essere disponibile in singola copia, in copie multiple
oppure replicato in ogni locazione di memoria, se il sistema dispone di registry
distribuito.
Un protocollo di discovery definisce l’insieme delle regole che client e service agent
devono rispettare per interagire. Per rendere noto un nuovo servizio nell’ambiente
oppure semplicemente per notificare un certo cambiamento di stato, un service agent
deve pubblicare la sua disponibilità, ricorrendo al meccanismo di service
advertisement. L’operazione di pubblicazione può avvenire in diversi modi, a seconda
della presenza del registry esterno ai dispositivi che offrono i servizi o assenza di
quest’ultimo: nel primo caso, il service agent deve dapprima individuare il registry per
poi inviargli l’SDR che descrive il servizio messo a disposizione; nel secondo caso
l’SDR è memorizzato nel repository locale al service provider, che si cura di notificare
la disponibilità di un nuovo servizio a tutti i potenziali client agent dell’ambiente (come
avviene nell’UPnP). La rimozione del servizio dall’ambiente può essere effettuata
esplicitamente dal service agent (meccanismo hard state) oppure ottenuta tramite
meccanismi soft state, nei quali la validità dei servizi offerti è limitata nel tempo. In
questo caso l’aggiornamento delle informazioni sui servizi viene ottenuta tramite il
meccanismo di leasing, nel caso di presenza di registry esterno, o tramite advertisement
periodico, il caso di sua assenza. Il leasing consente di rimuovere dal registry i servizi il
cui periodo di “affitto” nel registro è scaduto senza essere rinnovato. L’advertisement
periodico, invece, consente ai client agent di non fare più riferimento a servizi che non
vengono più “avvisati” dai rispettivi service provider che probabilmente hanno
abbandonato l’ambiente.
Il meccanismo di service advertisement, basato sull’invio periodico di notifiche ai
client agent, è considerato una valida alternativa al meccanismo di query, il quale si
caratterizza dal fatto che è il client agent che interroga i registry o i service agent allo
scopo di ottenere le informazioni necessarie sullo stato della rete.
Per ricercare un servizio nell’ambiente, un client agent ricorre al meccanismo del
service discovery. Un client che esplicita una richiesta di service discovery dovrà
dapprima localizzare l’infrastruttura di discovery a cui rivolgere la query di ricerca (il
registry o direttamente i singoli service provider) e successivamente inoltrarla per
10
ottenerne l’esito. La query consiste di un SDR, più o meno compilato nei suoi campi,
che viene inoltrato al registry o direttamente ai service provider. L’esito della query si
ottiene effettuando il matching del record sottoposto con tutti quelli memorizzati nel
registry o nei repository locali ai service provider. Si evince, dunque, che sono possibili
diverse modalità di service discovery, in base a come viene dettagliato l’SDR nella
query:
Ricerca di uno specifico servizio; tale service discovery si ottiene sottoponendo
un SDR specificato in tutti i suoi campi o in un insieme di attributi tali da
individuare univocamente il servizio. L’esito della query consiste nel restituire
la disponibilità di al più un servizio.
Ricerca per classe di servizi; tale service discovery si ottiene sottoponendo un
SDR specificato in uno o più campi tali da individuare una specifica classe di
servizi (ad esempio, stampanti a colori, traduttori inglese-italiano, …). La query
in questo caso viene soddisfatta assumendo che i campi nulli siano jolly e
permette di partizionare l’insieme dei servizi disponibili in classi di servizio.
L’esito della query consiste nel restituire la disponibilità di 0/n servizi.
Browsing dei servizi; tale service discovery si adotta quando non si conosce
alcun attributo del servizio ed in realtà consiste più in un’esplorazione
dell’ambiente circostante che in una vera e propria richiesta di service
discovery. Formalmente può essere rappresentata da un SDR in cui tutti i campi
sono nulli e tale da indicare che il client agent è interessato ad ottenere la
descrizione di tutti i servizi o dispositivi disponibili. L’esito della query consiste
nel restituire la disponibilità di tutti i servizi presenti.
E’ importante che le modalità di discovery siano implementate nel rispetto del principio
di boundary. In questo modo le modalità di ricerca descritte possono essere confinate
all’interno di una certa area di ricerca o estese al suo esterno. Tra le caratteristiche che
un service discovery dovrebbe avere occorre aggiungere, inoltre, quella di scopeawareness, ovvero il principio secondo cui i servizi fisicamente vicini dovrebbero
essere raggruppati allo scopo di facilitare i meccanismi di ricerca e fruizione del
servizio. Infine il protocollo di service discovery dovrà garantire QoS-awareness,
11
ovvero restituire i servizi disponibili trovati rispettando alcuni criteri relativi alla qualità
del servizio, come il carico massimo o il prezzo di servizio.
La figura 2 riassume gli elementi fondamentali del service discovery descritti in questo
paragrafo, con riferimento all’uso di un registry centralizzato esterno ai dispositivi che
offrono servizi.
Figura 2: Gli elementi fondamentali del service discovery.
1.2.3 Requisiti del service discovery per il nomadic computing
Di seguito verranno tracciati i requisiti funzionali che deve possedere un’infrastruttura
di service discovery affinchè sia possibile gestire con successo i sistemi di nomadic
computing. Questi sono:
Supporto alla mobilità; la mobilità consiste nel movimento dei dispositivi tra aree
diverse e le loro connessioni/disconnessioni da quest’ultime. Le tecniche di discovery
devono consentire la scoperta dei servizi a prescindere dalla posizione corrente del
dispositivo e dal suo stato (connesso o meno all’infrastruttura dell’ambiente di nomadic
computing).
Supporto alla dinamicità; Il supporto alla dinamicità può essere affrontato a partire da
due punti di vista:
12
Gestione della disponibilità dei servizi; la mobilità dei dispositivi e
l’inaffidabilità delle connessioni possono influenzare la disponibilità di un
servizio. E’ importante che nella fase di service discovery vengano scoperti solo
i servizi effettivamente disponibili.
Supporto alle variazioni di contesto; in un ambiente di nomadic computing il
contesto di esecuzione è fortemente dinamico e influenzato da numerosi fattori.
Il protocollo di service discovery deve fornire descrizioni di servizio che
rappresentino anche il contesto elaborativo circostante, nonché consentire
ricerche basate sulle informazioni di contesto. In altri termini, è necessario
conferire caratteristiche di context-awareness all’infrastruttura di discovery.
Completezza del meccanismo di ricerca; è importante che un protocollo di discovery
fornisca un insieme completo di modalità di ricerca (per specifico servizio, per classe di
servizi e browsing).
Definizione del confine di ricerca; il principio di boundary permette al client agent di
delimitare il confine della ricerca, traendo di conseguenza anche un vantaggio dal punto
di vista delle prestazioni (un confine più ampio comporta una ricerca più vasta).
L’introduzione dei requisiti funzionali descritti conduce alla definizione di una metrica
funzionale per la caratterizzazione dei protocolli di service discovery: un protocollo di
service discovery può essere classificato in base alla presenza o meno di una parte o di
tutte le modalità di ricerca definite (per specifico servizio, per classe di servizio,
browsing), in base al supporto offerto alla mobilità e dinamicità e in base
all’implementazione o meno di meccanismi che consentano di rispettare il principio di
boundary.
La definizione dell’infrastruttura di discovery deve poi tenere presenti anche i seguenti
requisiti non funzionali:
Scalabilità del meccanismo di discovery; un protocollo di service discovery deve
adottare scelte che consentano facilmente di aumentare il fattore di scala per gli
ambienti per i quali esso è progettato. In altre parole è indispensabile che esso non
introduca un carico (in termini di traffico generato e overhead computazionale)
eccessivo al crescere delle dimensioni del sistema.
13
Semplicità del meccanismo di discovery; negli ambienti di nomadic computing possono
essere presenti dei dispositivi mobili con scarse capacità elaborative. E’ necessario che
il software a supporto del service discovery non introduca un carico computazionale e
di memoria pesante nei dispositivi nomadi.
Eterogeneità; data la diversità dei dispositivi e dei servizi che questi offrono, il
protocollo di discovery deve definire un formato per la descrizione dei servizi quanto
più generale possibile.
Affidabilità; l’infrastruttura di discovery svolge un ruolo fondamentale nel processo di
fruizione di un servizio: un malfunzionamento in tale infrastruttura si ripercuote anche
sul successivo processo di delivery. E’ pertanto essenziale conferire caratteristiche di
affidabilità a tale infrastruttura.
Trasparenza; il meccanismo di discovery deve garantire trasparenza all’interazione,
cioè essere in grado di offrire un’interfaccia che elimini le barriere tra utente e
funzionamento del sistema.
Sicurezza; utenti maliziosi non dovrebbero avere accesso ai servizi “sicuri”. Bisogna
prevedere nella definizione del protocollo meccanismi per la garanzia della sicurezza in
termini di autenticazione, integrità e confidenzialità.
I requisiti non funzionali elencati sono sicuramente utili a stabilire la qualità di un
protocollo di discovery. Più un protocollo di discovery risponde a tali requisiti,
maggiore può essere considerata la sua qualità.
1.3 Caratteristiche generali di UPnP™
Universal Plug and Play (UPnP) è un’architettura per reti peer-to-peer costituite da
dispositivi intelligenti, dispositivi wireless e PC di ogni tipo. L’inserimento delle
funzionalità Plug and Play nel sistema operativo dei vari dispositivi che popolano la
rete, permette di installare, configurare e aggiungere periferiche ai PC in maniera
semplice e automatica. Universal Plug and Play porta questa semplicità all’intera rete,
14
consentendo di individuare e controllare dispositivi, periferiche e servizi di rete, quali
stampanti in rete, gateway Internet e apparecchiature elettroniche. Sebbene fu introdotta
come un’estensione del modello Plug and Play per le periferiche, la tecnologia UPnP è
più di una semplice estensione del modello Plug and Play. Questa tecnologia è stata
sviluppata per supportare le reti a “configurazione nulla” e il rilevamento automatico di
un’ampia gamma di categorie di dispositivi e periferiche di numerosissimi produttori.
Con Universal Plug and Play un dispositivo può entrare in rete in modo dinamico,
ottenere un indirizzo IP, mettere a disposizione le sue funzionalità e rilevare la presenza
e le funzionalità di altri dispositivi, il tutto automaticamente e praticamente senza alcun
intervento di configurazione da parte degli utenti o degli amministratori. L’universalità
di UPnP è data, infatti, dalla mancanza di driver specifici e per l’uso di protocolli
comuni largamente diffusi. I dispositivi e le periferiche possono, quindi, comunicare
direttamente fra loro, dando vita a reti peer-to-peer. Universal Plug and Play trova già
impiego in molti settori, ma soprattutto potrà contribuire alla realizzazione di nuovi
sistemi, ad esempio nei settori dell’automazione delle abitazioni, della stampa e della
realizzazione di immagini, dell’intrattenimento audio e video, degli elettrodomestici,
delle reti per autovetture e così via.
UPnP utilizza i protocolli TCP/IP e Internet standard, che permettono un’integrazione
perfetta nelle reti esistenti. Grazie all’impiego di questi protocolli standardizzati, UPnP
è in grado di sfruttare moltissime soluzioni e tecnologie, a vantaggio di
un’interoperabilità sempre più completa.
UPnP è un’architettura di rete aperta e distribuita, definita dai protocolli utilizzati,
indipendente dal sistema operativo, dal linguaggio di programmazione o dal supporto
fisico (ad esempio Internet).
15
1.4 UPnP Forum
Allo Universal Plug and Play Forum spetta il compito di definire le cosiddette "UPnP
Device and Service Descriptions" (originariamente dette Device Control Protocols o
DCP) sulla base di un'architettura comune realizzata con il contributo di Microsoft®.
Universal Plug and Play Forum è un gruppo intersettoriale composto da imprese e
singoli individui, che ha la responsabilità di definire le specifiche per le periferiche e i
servizi UPnP. Costituito il 18 ottobre 1999, raggruppa oltre 340 produttori leader nei
settori dell'elettronica, dei sistemi informatici, dell’automazione e della sicurezza
domestica, degli apparecchi elettrodomestici, delle reti di computer e dei dispositivi
portatili.
L'obiettivo del Forum è quello di facilitare l'interconnessione in rete dei dispositivi e di
semplificare l'implementazione di reti domestiche e aziendali. Per realizzare questi
obiettivi, il Forum definisce e pubblica descrizioni di periferiche, dispositivi e servizi
UPnP utilizzando standard aperti di comunicazione basati su Internet.
Nel sito Web del Forum, all'indirizzo http://upnp.org/, vengono raccolti gli schemi
sviluppati e standardizzati dal Forum. Il sito contiene inoltre il documento relativo
all'architettura delle periferiche e dei dispositivi, modelli per la descrizione di
dispositivi, periferiche e servizi e linee guida per la realizzazione di descrizioni di
periferiche, dispositivi e servizi.
1.5 Componenti di una rete UPnP
I componenti principali di una rete UPnP sono periferiche, servizi e punti di controllo.
Tali componenti sono descritti in dettaglio in questo paragrafo.
16
1.5.1 Periferiche
Una periferica o dispositivo (device) UPnP è un contenitore di servizi e di periferiche
nidificate. Una periferica videoregistratore potrebbe essere costituita, ad esempio, da un
servizio trascinamento nastro, un servizio sintonizzatore e un servizio orologio. Una
periferica TV con videoregistratore incorporato non sarebbe costituita solo da servizi
ma anche da una periferica nidificata.
Alle varie categorie di periferiche UPnP saranno associati gruppi di servizi e periferiche
incorporate diversi. I servizi di un videoregistratore saranno, ad esempio, diversi da
quelli di una stampante. I vari comitati di lavoro dell'UPnP Forum hanno il compito di
definire gli standard dell'insieme di servizi forniti da un particolare tipo di periferica e
di raccogliere tutte queste informazioni in un documento XML (eXtensible Markup
Language) di descrizione della periferica che accompagna la periferica stessa. Oltre
all'insieme di servizi, nella descrizione della periferica sono elencate le proprietà
associate a tale periferica, ad esempio il nome della periferica e le icone.
1.5.2 Servizi
L'unità di controllo più piccola di una rete UPnP è il servizio. Un servizio mette a
disposizione azioni e modella il suo funzionamento tramite variabili di stato. È
possibile creare, ad esempio, un servizio orologio che ha una variabile di stato,
ora_corrente, che definisce lo stato dell'orologio, e due azioni, imposta_ora e
ottieni_ora, che consentono di controllare il servizio. Come avviene per le periferiche,
queste informazioni sono incluse in una descrizione XML del servizio standardizzata
dall'UPnP Forum. Nelle descrizioni dei servizi è incluso un URL (Uniform Resource
Locator) che punta al documento di descrizione della periferica. Le periferiche possono
contenere più servizi.
Il servizio di una periferica UPnP è costituito da una tabella di stato, da un server di
controllo e da un server degli eventi. La tabella di stato definisce lo stato del servizio
attraverso variabili di stato, che vengono aggiornate quando lo stato cambia. Il server di
17
controllo riceve le richieste di azione, ad esempio imposta_ora, le esegue, aggiorna la
tabella di stato e restituisce risposte. Ogni volta che lo stato del servizio cambia, il
server degli eventi invia eventi ai punti di controllo interessati. Un ipotetico servizio
allarme antincendio invierebbe, ad esempio, un evento ai punti di controllo interessati
quando il suo stato diventa "allarme attivo".
Figura 3: Periferiche, servizi e punti di controllo UPnP.
18
1.5.3 Punti di controllo
Il punto di controllo (control point) o più brevemente PoC (Point of Control) di una rete
UPnP è un controller in grado di rilevare e controllare altre periferiche. Dopo il
rilevamento, il punto di controllo può eseguire un certo numero di istruzioni descritte
nel seguito:
a) Recuperare la descrizione della periferica e ottenere l'elenco dei servizi
associati.
b) Recuperare le descrizioni dei servizi allo scopo di ricercare i servizi che lo
interessano.
c) Richiamare azioni per controllare il servizio.
d) Registrarsi presso il sistema di rilevazione degli eventi del servizio. Ogni volta
che lo stato del servizio cambia, il server degli eventi invierà un evento al punto
di controllo.
Si prevede che le periferiche includeranno la funzionalità di punto di controllo (e
viceversa) per la realizzazione di reti peer-to-peer vere e proprie.
1.6 Panoramica sui protocolli UPnP
La tecnologia UPnP si basa su una serie di protocolli IP standard che le consentono di
rimanere del tutto indipendente dal tipo di supporto di rete utilizzato. Per
interconnettere periferiche in una rete UPnP è possibile utilizzare qualsiasi mezzo di
comunicazione, incluse connessioni a radiofrequenza (RF, senza fili), linee telefoniche,
linee elettriche, connessioni a infrarossi (IrDA), porte Ethernet e IEEE 1394. La
tecnologia UPnP si basa su protocolli standard aperti, quali TCP/IP, HTTP e XML. In
futuro non è escluso che si possano utilizzare altre tecnologie di connessione di rete e
questo per molteplici ragioni, inclusi motivi di costo, esigenze tecnologiche o per il
supporto delle periferiche meno recenti. Queste tecnologie di connettività, che
19
includono soluzioni HAVi, CeBus, LonWorks, EIB e X10, potranno partecipare a una
rete UPnP mediante un bridge o un proxy UPnP. Una rete UPnP che contiene
periferiche connesse con bridging potrebbe essere analoga a quella illustrata nella
figura 4.
Figura 4: Rete UPnP con bridging.
La tecnologia UPnP si basa su numerosi protocolli standard. L'utilizzo di protocolli
standardizzati assicura l'interoperabilità tra le implementazioni dei diversi produttori. I
protocolli utilizzati per implementare la tecnologia UPnP trovano vasto impiego in
Internet e nelle LAN e questa diffusione garantisce la disponibilità di molte persone in
grado di implementare e distribuire soluzioni basate su questi protocolli. Poiché questi
stessi protocolli sono già largamente utilizzati, resterebbe poco da fare per integrare le
periferiche UPnP negli attuali ambienti di rete.
20
1.7 Protocolli specifici di UPnP
I produttori di periferiche e dispositivi UPnP, i comitati di lavoro dell'UPnP Forum e il
documento UPnP Device Architecture definiscono i protocolli di livello più alto
utilizzati per l'implementazione della tecnologia UPnP. Sulla base dell'architettura delle
periferiche, i comitati di lavoro definiscono le specifiche relative a ogni singolo tipo di
periferica, ad esempio videoregistratori, sistemi di riscaldamento e condizionamento,
televisori e altre apparecchiature. Successivamente i produttori di periferiche UPnP
aggiungono i dati specifici delle proprie periferiche, ad esempio nome del modello,
URL, e così via.
1.7.1 TCP/IP
Lo stack di protocolli di rete TCP/IP (Transimission Control Protocol/Internet Protocol)
è quello su cui si fondano tutti gli altri protocolli UPnP. Grazie all’impiego della
famiglia di protocolli standard TCP/IP, di vasta diffusione, la tecnologia UPnP è in
grado di riconoscere supporti fisici diversi e di garantire l'interoperabilità tra le
soluzioni di vari produttori.
Le periferiche UPnP possono utilizzare molti dei protocolli dello stack TCP/IP, inclusi i
protocolli TCP, UDP, IGMP, ARP e IP, nonché servizi TCP/IP, quali DHCP e DNS.
1.7.2 HTTP
TCP/IP è lo stack di protocolli di base per la connettività di rete tra periferiche UPnP. Il
protocollo HTTP, a cui si deve gran parte del successo di Internet, è anch'esso un
componente importante della tecnologia UPnP. Tutti i vari aspetti della tecnologia
UPnP sono uno sviluppo del protocollo HTTP o delle sue varianti.
21
HTTPU (HTTP Unicast over UDP) e HTTPMU (HTTP Multicast over UDP) sono
varianti del protocollo HTTP, definite per il recapito di messaggi via UDP/IP anziché
TCP/IP. Questi protocolli sono utilizzati dal protocollo SSDP, descritto qui di seguito.
Il formato di base dei messaggi utilizzato da questi protocolli è conforme al formato
HTTP ed è richiesto per la comunicazione multicast.
1.7.3 SDDP
Il protocollo SSDP (Simple Service Discovery Protocol) definisce le modalità di
rilevazione dei servizi di una rete. Il protocollo SSDP si basa sui protocolli HTTPU e
HTTPMU e definisce i metodi che consentono sia a un punto di controllo di individuare
le risorse di interesse nella rete, sia alle periferiche di comunicare la loro disponibilità
nella rete. Definendo l’utilizzo contestuale sia del meccanismo di ricerca, sia del
meccanismo di comunicazione di presenza nella rete, SSDP elimina il carico di lavoro
aggiuntivo che si determinerebbe qualora venisse utilizzato uno solo dei meccanismi di
cui sopra. Ne risulta che ogni punto di controllo della rete dispone di informazioni
complete sullo stato della rete, mentre il traffico delle rete viene mantenuto basso.
Sia i punti di controllo sia le periferiche utilizzano il protocollo SSDP. Dopo l'avvio, un
punto di controllo UPnP può inviare una richiesta di ricerca SSDP (su HTTPMU) per
rilevare le periferiche e i servizi disponibili nella rete. Tale richiesta è contenuta in un
messaggio multicast di discovery (ssdp:discover). Il punto di controllo può impostare
criteri di ricerca più restrittivi, in modo da trovare solo periferiche di un certo tipo, ad
esempio videoregistratori, determinati servizi, ad esempio periferiche con servizi
orologio, o persino periferiche specifiche.
Le periferiche UPnP “ascoltano” la porta multicast. Dopo aver ricevuto una richiesta di
ricerca, la periferica esamina i criteri di ricerca per stabilire se soddisfa tali criteri. In
caso affermativo, al punto di controllo viene inviata una risposta SSDP unicast (tramite
HTTPU) all’interno di un messaggio unicast contenente un URL che rimanda ad un file
XML, descrittore del dispositivo stesso e delle sue capacità. Analogamente, quando una
periferica viene collegata in rete, invia una serie di annunci di presenza SSDP che
22
rendono noti i servizi offerti (meccanismo di service advertisement). Questi annunci
sono contenuti all’interno di messaggi multicast di advertisement (ssdp:alive).
Sia gli annunci di presenza sia i messaggi di risposta unicast delle periferiche
contengono un puntatore alla posizione del documento di descrizione della periferica,
che contiene le informazioni sull'insieme di proprietà e servizi supportati dalla
periferica (SDR).
Oltre a fornire le suddette capacità di rilevamento, il protocollo SSDP consente inoltre a
una periferica e ai servizi ad essa associati di disconnettersi in modo corretto dalla rete
(notifica bye-bye) e prevede una gestione di timeout della cache per l'eliminazione di
informazioni obsolete per l’"automanutenzione".
1.7.4 GENA
L'architettura GENA (Generic Event Notification Architecture) è stata realizzata per
consentire l'invio e la ricezione di notifiche utilizzando il protocollo HTTP su TCP/IP e
UDP multicast. L'architettura GENA definisce inoltre i concetti di sottoscrittori
(subscriber) e autori (publisher) di notifiche per la generazione di eventi.
I formati GENA sono utilizzati nella tecnologia UPnP per creare gli annunci di
presenza da inviare tramite il protocollo SSDP e per consentire di segnalare le
variazioni dello stato di un servizio per la generazione di eventi UPnP. Un punto di
controllo interessato a ricevere notifiche di eventi si registrerà presso un sistema che
origina i vari eventi inviando una richiesta che includa il servizio a cui è interessato, la
posizione in cui inviare gli eventi e il periodo di sottoscrizione per la notifica degli
eventi. Per continuare a ricevere le notifiche, la sottoscrizione dovrà essere rinnovata
periodicamente. La sottoscrizione potrà essere annullata mediante GENA.
23
1.7.5 SOAP
Il protocollo SOAP (Simple Object Access Protocol) definisce l'utilizzo degli standard
XML (Extensible Markup Language) e HTTP per l'esecuzione di chiamate a procedure
remote (RPC, Remote Procedure Call). Il protocollo SOAP sta diventando lo standard
per le comunicazioni basate su RPC in Internet. Sfruttando l'infrastruttura esistente di
Internet, questo protocollo è in grado di funzionare in modo efficace con firewall e
proxy. Il protocollo SOAP può inoltre utilizzare la protezione SSL (Secure Sockets
Layer) e le funzionalità di gestione delle connessioni del protocollo HTTP, rendendo in
tal modo la comunicazione distribuita in Internet un'operazione semplice quanto
l'accesso alle pagine Web.
Analogamente a una chiamata a una procedura remota, la tecnologia UPnP utilizza il
protocollo SOAP per recapitare messaggi di controllo alle periferiche e restituire
risultati o errori ai punti di controllo.
Ogni richiesta di controllo UPnP è un messaggio SOAP contenente l'azione da
richiamare più un insieme di parametri. Anche la risposta è un messaggio SOAP, che
contiene lo stato, il valore restituito ed eventuali parametri restituiti.
1.7.6 XML
Lo standard XML (eXtensible Markup Language) è, nella definizione del W3C, il
formato universale per dati strutturati sul Web. In altre parole, lo standard XML è un
modo per inserire praticamente qualsiasi tipo di dati strutturati in un file di testo.
Lo standard XML è simile all'HTML in quanto utilizza tag e attributi, ma differisce da
questo poiché il significato di tag e attributi non è definito globalmente, ma è
interpretato a seconda del contesto in cui vengono utilizzati. Queste caratteristiche
rendono lo standard XML particolarmente adatto allo sviluppo di schemi per vari tipi di
documenti. L'utilizzo dello standard XML come linguaggio per schemi è definito dal
W3C.
24
Lo standard XML è un componente principale della tecnologia UPnP, utilizzato nelle
descrizioni di periferiche e servizi, nei messaggi di controllo e nella generazione di
eventi.
1.8 Stack protocollare di UPnP
In questo paragrafo viene descritto come i protocolli illustrati in precedenza vengono
utilizzati all’interno dello standard UPnP. La figura 5 mostra come questi protocolli
sono organizzati all’interno dello stack protocollare di UPnP.
Figura 5: Lo stack dei protocolli UPnP.
25
Il documento "UPnP Device Architecture" definisce uno schema o modello per la
creazione di descrizioni per qualsiasi tipo di periferica o servizio.
I singoli comitati di lavoro dell'UPnP Forum definiscono successivamente gli standard
dei vari tipi di periferiche e servizi e creano un modello per ogni singolo tipo di
periferica o servizio.
Il produttore completa infine questo modello con informazioni specifiche della
periferica o del servizio, ad esempio il nome della periferica, il numero di modello, il
nome del produttore e l'URL che punta alla descrizione del servizio.
Questi dati vengono quindi incapsulati nei protocolli specifici UPnP definiti nel
documento "UPnP Device Architecture" (ad esempio il modello di descrizione delle
periferiche XML). Le informazioni specifiche UPnP necessarie vengono inserite in tutti
i messaggi prima che questi vengano formattati mediante i protocolli SSDP, GENA e
SOAP e recapitati via HTTP, HTTPU o HTTPMU.
Lo stack protocollare UPnP ricalca evidentemente il modello OSI dove troviamo per
ogni livello i seguenti protocolli:
Livello 7; protocolli UPnP definiti dal produttore.
Livello 6; protocolli UPnP definiti dai comitati di lavoro dell'UPnP Forum.
Livello 5; protocolli UPnP definiti dal documento “UPnP Device Architecture”.
Livello 3-4; HTTP (Unicast e Multicast) SOAP, GENA, SSDP.
Livello 2; TCP/UDP.
Livello 1; IP.
1.9 Fasi della connettività di UPnP
Il processo attraverso il quale qualunque dispositivo si collega alla rete è costituito da
diversi passi. L’esecuzione di questi passi permette al dispositivo di configurarsi in
modo automatico con la rete e con agli altri dispositivi presenti in quel momento.
26
1.9.1 Indirizzamento
L'elemento fondamentale su cui si basa la connettività in rete UPnP è la famiglia di
protocolli TCP/IP e la chiave per accedere a questi protocolli è l'indirizzamento. Ogni
periferica deve avere un client DHCP (Dynamic Host Configuration Protocol) e cercare
un server DHCP quando viene connessa per la prima volta alla rete. Se è disponibile un
server DHCP, la periferica deve utilizzare l'indirizzo IP che le viene assegnato. In caso
contrario, la periferica deve utilizzare il protocollo Auto IP per attribuirsi
automaticamente un indirizzo.
In breve, il protocollo Auto IP definisce il modo in cui una periferica sceglie
intelligentemente un indirizzo IP da un insieme di indirizzi privati riservati ed è in
grado di muoversi agevolmente tra reti gestite e reti non gestite.
È possibile che una periferica implementi protocolli di livello superiore al di fuori della
tecnologia UPnP, che utilizzano nomi descrittivi per le periferiche. In questi casi
diventa necessario risolvere i nomi host (di periferica) descrittivi, nel corrispondente
indirizzo IP. A questo scopo vengono generalmente utilizzati i servizi DNS (Domain
Name Services). Una periferica che richiede o utilizza questa funzionalità può includere
un client DNS e supportare la registrazione DNS dinamica per l’associazione del
proprio nome al rispettivo indirizzo.
1.9.2 Rilevazione
Dopo che le periferiche sono state connesse alla rete ed è stato assegnato loro un
indirizzo appropriato, può aver luogo la rilevazione. La rilevazione è gestita dal
protocollo SSDP discusso in precedenza. Quando si aggiunge una periferica alla rete, il
protocollo SSDP consente a tale periferica di rendere pubblici i propri servizi ai punti di
controllo della rete. Quando si aggiunge un punto di controllo alla rete, il protocollo
SSDP consente al punto di controllo di cercare nella rete le periferiche di interesse.
27
Lo scambio fondamentale, in entrambi i casi, consiste in un messaggio di rilevazione
che contiene poche specifiche essenziali relative alla periferica o al servizio, ad
esempio il tipo, l'ID e un puntatore al documento di descrizione della periferica XML.
I singoli passi della fase di rilevazione sono:
Annuncio (Advertising); Questo step consiste nell’inviare una serie di messaggi
di rilevazione multicast, che rendono note le periferiche e i servizi incorporati.
Questi messaggi sono incapsulati a livello 3 e 4 nei protocolli HTTPMU, SSDP,
GENA e inoltrati successivamente via UDP/IP. Un punto di controllo
interessato può rimanere in stato di ascolto sull'indirizzo multicast standard in
attesa di messaggi di notifica che segnalano la disponibilità di nuovi servizi.
Nella figura 6 viene mostrato la stack di protocolli utilizzato per i messaggi di
annuncio.
Figura 6: Stack di protocolli utilizzato per i messaggi di annuncio.
28
Ricerca (Discovery); Lo stack utilizzato per la ricerca è molto simile a quello
utilizzato per l’annuncio con l’unica differenza che i messaggi sono inviati
soltanto attraverso il protocollo SSDP e inoltrati successivamente tramite
UDP/IP, come mostrato in figura 7. Per evitare fenomeni quali la congestione
del traffico sulla rete, viene settato ad un valore preconfigurato il TTL (Time To
Live) relativo ad ogni pacchetto IP multicast inviato.
Figura 7: Stack di protocolli utilizzato per i messaggi di ricerca.
29
1.9.3 Descrizione
La fase successiva nella connettività di rete UPnP è rappresentata dalla descrizione.
Dopo aver rilevato una periferica, un punto di controllo dispone ancora di poche
informazioni su si essa. Per ottenere ulteriori informazioni sulla periferica e sulle sue
capacità o per interagire con la periferica, il punto di controllo deve richiamare la
relativa descrizione dall'URL fornito dalla periferica nel messaggio di rilevazione.
Le periferiche possono contenere altre periferiche logiche e altri servizi. La descrizione
UPnP di una periferica è in formato XML e include informazioni specifiche del
produttore, quali il nome e il numero del modello, il numero di serie, il nome del
produttore, URL a siti Web specifici del produttore e così via. Nella descrizione è
inoltre incluso l'elenco di eventuali periferiche o servizi incorporati, nonché URL per il
controllo, la generazione di eventi e la presentazione. La figura 8 mostra lo stack
protocollare relativo ai messaggi di descrizione.
30
Figura 8: Stack di protocolli utilizzato per la descrizione.
1.9.4 Controllo
Dopo aver richiamato la descrizione della periferica, un punto di controllo dispone di
tutte le informazioni necessarie per controllarla. Per ottenere ulteriori informazioni su
un servizio, un punto di controllo deve richiamare una descrizione UPnP dettagliata di
ciascun servizio. Anche la descrizione di un servizio è in formato XML e include
l'elenco dei comandi o delle azioni ai quali il servizio risponde e dei parametri o
argomenti per ogni azione. Nella descrizione di un servizio è inoltre incluso un elenco
di variabili che modellano lo stato del servizio in fase di esecuzione e che sono descritte
in termini di tipo di dati, intervallo e caratteristiche dell'evento.
31
Per controllare una periferica, un punto di controllo invia una richiesta di azione a un
servizio della periferica. A tal scopo, il punto di controllo invia un messaggio di
controllo adeguato all'URL di controllo del servizio, fornito nella descrizione della
periferica. I messaggi di controllo sono anch'essi espressi in formato XML utilizzando
il protocollo SOAP. In risposta al messaggio di controllo il servizio restituisce valori
specifici dell'azione o codici di errore. In questa fase della connettività UPnP i
messaggi sono formattati attraverso il protocollo SOAP e distribuiti via HTTP mediante
il protocollo TCP/IP, come indicato nella figura 9.
Figura 9: Stack di protocolli utilizzato per il controllo.
32
1.9.5 Gestione degli eventi
Nella descrizione UPnP di un servizio è incluso l'elenco delle azioni alle quali il
servizio risponde e l'elenco delle variabili che modellano lo stato del servizio in fase di
esecuzione. Quando il valore di queste variabili cambia, il servizio pubblica degli
aggiornamenti; un punto di controllo può sottoscrivere la ricezione di queste
informazioni.
Il servizio pubblica gli aggiornamenti inviando messaggi di notifica degli eventi che
contengono i nomi di una o più variabili di stato e il valore corrente di tali variabili.
Anche questi messaggi sono espressi in XML e formattati utilizzando GENA.
Quando un punto di controllo sottoscrive per la prima volta la ricezione di messaggi di
notifica degli eventi, viene inviato uno speciale messaggio iniziale che contiene i nomi
e i valori di tutte le variabili associate a eventi e consente al sottoscrittore di
inizializzare il proprio modello dello stato del servizio.
Per supportare più punti di controllo, a tutti i sottoscrittori vengono inviati tutti i
messaggi di notifica degli eventi, i sottoscrittori ricevono messaggi di notifica degli
eventi per tutte le variabili associate a eventi e i messaggi di notifica degli eventi
vengono inviati indipendentemente dalla causa del cambiamento della variabile di stato
(ovvero se il cambiamento è avvenuto in risposta a una richiesta di azione o a seguito di
una variazione dello stato). La figura 10 mostra lo stack dei protocolli utilizzato nella
fase di notifica.
33
Figura 10: Stack di protocolli utilizzato per la gestione degli eventi.
1.9.6 Presentazione
Se una periferica dispone di un URL per la presentazione, il punto di controllo può
richiamare una pagina da tale URL, caricarla in un browser e, in base alle capacità della
pagina, consentire a un utente di controllare la periferica e/o di visualizzarne lo stato.
La misura in cui questo è consentito dipende dalle capacità specifiche della pagina di
presentazione e della periferica. Raggiungere la pagina necessita di una semplice
richiesta HTTP che usa un sottoinsieme dello stack protocollare visto in precedenza e
che la figura 11 riassume di seguito.
34
Figura 11: Stack di protocolli utilizzato per la presentazione.
1.10 Analisi dello standard UPnP
In questo paragrafo verrà presentata un’analisi critica sugli aspetti più rilevanti di
UPnP, al fine di cercare le soluzioni adatte a migliorare questo standard. In particolare
verranno affrontati i pro e i contro di cui questa tecnologia dispone. Di seguito sono
riassunte le caratteristiche principali di un service discovery relative a UPnP. Si noti
come per UPnP non sono state previste particolari soluzioni in tutti i campi che
caratterizzano un service discovery e come questo renda UPnP uno standard ancora
oggi aperto a nuove soluzioni implementative. UPnP è infatti un'iniziativa aperta, che
ha l'obiettivo di rielaborare standard, tecnologie e conoscenze esistenti per adattarli alle
opportunità e alla promesse del futuro mondo globale.
35
1.10.1
Requisiti di UPnP per il service discovery
Per quanto riguarda l’architettura di sistema, ovvero la struttura dei registry, UPnP non
definisce in alcun modo se dovrà essere di tipo flat oppure di tipo gerarchico, né se
dovrà essere centralizzato o distribuito. Non specifica inoltre se dovrà esserci un certo
numero di copie di informazioni di servizio oppure se il meccanismo di aggiornamento
delle informazioni presso i registry dovrà essere di tipo soft oppure hard.
Come già detto in precedenza, UPnP prevede per lo scambio di messaggi entrambe le
modalità unicast e multicast, non necessita di un Directory Agent (come invece avviene
per il Service Location Protocol) e può notificare eventi e cambiamenti di stato sia
attraverso meccanismi di advertisement (annuncio), sia attraverso richiesta esplicita da
parte del punto di controllo (query). UPnP prevede la selezione dei servizi da parte
degli utenti (user selection) ma non prevede meccanismi di ricerca basati sul service
matching, né si preoccupa di fornire una selezione dei migliori servizi trovati
disponibili. Infine UPnP non indica nessuna restrizione in termini di Context-aware,
Scope-aware o QoS-aware.
1.10.2
Vantaggi di UPnP
I vantaggi introdotti da questo standard sono innumerevoli, i più importanti sono:
Standard aperto; ha protocolli relativamente semplici e standard simili a quelli
definiti dalla IETF (Internet Engeneering Task Force). Il TCP/IP su cui si basa,
permette la comunicazione tra molti tipi di piattaforme esistenti e da la
possibilità di essere compatibile con una vastità di dispositivi, siano essi PC o
elettrodomestici intelligenti.
Scalabilità; normalmente è adatto per lavorare con reti piccole ma nulla vieta di
poter utilizzare questo standard su reti di dimensioni maggiori, nel rispetto del
principio di boundary.
Plug and Play; la tecnologia UPnP offre un ambiente di comunicazione basato
su standard che consente ai dispositivi collegati in rete di configurarsi in
36
maniera automatica, dinamica e in perfetta compatibilità. L'interoperabilità è
garantita anche dal fatto che la tecnologia UPnP si adatta a qualunque tipologia
di supporto fisico (cablato o wireless), all'Internet Protocol (IP) e ad ogni genere
di device collegabili in rete, tra cui PC, sistemi di home entertainment,
dispositivi intelligenti di nuova concezione, sistemi di home automation,
periferiche di rete e servizi Web. L’XML descrive inoltre i servizi con grande
dettaglio.
Scarse Risorse; le risorse richieste al sistema sono di fatto ridottissime. Questo
permette a UPnP di poter lavorare sia su PC che su dispositivi dotati di limitate
capacità di calcolo e scarse risorse hardware.
Ambienti multipiattaforma; lo standard UPnP è stato concepito per permettere
l’interazione e lo scambio di informazioni tra diverse tipologie di applicazione.
Indipendente dal Sistema Operativo; UPnP nasce come protocollo operante
sotto Windows XP (Microsoft®), ma di fatto può girare sotto qualsiasi sistema
operativo.
Integrazione con applicazioni già esistenti e non basate su IP; la tecnologia
UPnP si basa su una serie di protocolli IP standard che le consentono di
rimanere del tutto indipendente dal tipo di supporto di rete utilizzato. La scelta
del protocollo IP tuttavia non impedisce a UPnP di integrarsi con quelle
tecnologie che non ne fanno uso. Per interconnettere periferiche in una rete
UPnP è possibile, infatti, utilizzare qualsiasi mezzo di comunicazione, incluse
connessioni a radiofrequenza (RF, senza fili), linee telefoniche, linee elettriche,
connessioni a infrarossi (IrDA), porte Ethernet e IEEE 1394. In altre parole, è
possibile utilizzare qualsiasi tecnologia di rete esistente, ma anche quelle
emergenti. L'unico requisito da rispettare è che il supporto di rete prescelto
supporti la larghezza di banda necessaria per l'utilizzo previsto.
Open source; UPnP è un’architettura di rete aperta e distribuita, definita dai
protocolli utilizzati, ed indipendente dal linguaggio di programmazione o dal
supporto fisico (ad esempio Internet). UPnP non specifica le API (Application
Program Interface) che verranno utilizzate dalle applicazioni e ciò consente ai
37
produttori di sistemi operativi di creare API in base alle specifiche esigenze dei
loro clienti.
Architettura non incentrata su PC; la configurazione di base di una rete UPnP
può essere basata su un’architettura peer-to-peer, il che vuol dire che una rete di
piccole dimensioni come una rete domestica può lavorare senza PC.
Non necessita di un Directory Agent; questa soluzione lo rende sicuramente più
robusto verso l’eventulità che il punto d’accesso centralizzato (ad esempio
Directory Agent di SLP) faccia crash. Molto adatto a contesti distribuiti
(asincroni). Con Universal Plug and Play un dispositivo può entrare in rete in
modo dinamico e ottenere un indirizzo IP senza il controllo di un Directory
Agent. I dispositivi e le periferiche possono, quindi, comunicare direttamente
fra loro, dando vita a reti peer-to-peer.
Larga Diffusione; un grande numero di aziende ne promuove lo sviluppo. Tra
queste citiamo: Microsoft, Intel, NEC, AT&T, Texas Instruments, Mitsubishi,
Canon, Motorola, Sony, ecc.
1.10.3
Svantaggi di UPnP
Purtroppo UPnP soffre di varie limitazioni che ne condizionano lo sviluppo futuro.
Queste limitazioni sono:
Assenza di service attributes; un servizio è descritto usualmente da diversi
attributi. La ricerca di servizio per un utente viene condotta attraverso il
confronto degli attributi di servizio che l’utente specifica nella richiesta.
Nell’UPnP, invece, sono le periferiche che offrono i servizi a notificare
all’utente la loro presenza e a fornirgli la relativa descrizione degli attributi di
servizio dei quali dispongono, limitando di fatto le modalità di ricerca dei
servizi stessi.
Assenza di un Directory Agent; l’eventuale assenza di un Directory Agent
renderebbe il sistema poco scalabile. Può però avere un UPnP Internet gateway.
Gli UPnP Internet gateway e il supporto UPnP di Windows XP permetteranno a
38
più PC e dispositivi collegati a una rete di piccole dimensioni di condividere un
unico indirizzo IP pubblico senza incorrere nei problemi di configurazione dei
dispositivi che oggi devono affrontare gli utenti Microsoft® e le aziende. La
maggior parte dei provider di connessioni in banda larga per privati e piccole
aziende fornisce un unico indirizzo IP che viene condiviso tramite un gateway
basato su tecnologia NAT (Network Address Translation). Lo standard UPnP
mette a disposizione automaticamente le singole applicazioni all'interno del
gateway.
Basso livello di sicurezza; il problema riguardava una falla di sicurezza di
Universal Plug & Play di Microsoft®, una funzionalità presente in varie
edizioni di Windows. Da un lato è un problema serio: questa vulnerabilità può
permettere a chiunque di prendere il controllo di un qualsiasi computer.
Dall'altro si tratta di una delle tante vulnerabilità che capitano in qualunque
software e per la quale non c'è un exploit in rapida diffusione.
Elevato costo computazionale; l’Universal Plug & Play è un set complesso di
protocolli per supportare un networking peer-to-peer ad hoc. Anche se nessuno
lo utilizza, esso viene installato in parecchi sistemi operativi Microsoft®. Anche
se a nessuno serve che sia attivo, a volte esso è attivo per default.
Nessuna specifica sul numero di copie con informazioni di servizio; ogni
servizio offerto è rappresentato dall’informazione di servizio che lo descrive
(service attributes). Questa informazione può essere disponibile in singola copia
oppure in copie multiple. Nei sistemi centralizzati questa informazione è
contenuta nel Directory Agent mentre in quelli distribuiti viene condivisa tra più
soggetti, rendendo il sistema sicuramente più robusto verso i guasti.
Architettura non gerarchica: L’UPnP non ha una struttura gerarchica, ma di
tipo flat, ovvero le varie periferiche che entrano nel sistema hanno tra loro
relazioni peer-to-peer. I registry relativi alle periferiche non formano una
struttura gerarchica dei servizi, rendendo la fase di discovery senza dubbio
meno performante.
Nessuna garanzia di delivery; come già detto, molte periferiche e punti di
controllo si basano sui protocolli di comunicazione TCP/IP oppure UDP/IP.
39
Entrambi i protocolli permettono di verificare l’integrità dei messaggi che
vengono recapitati ma non offrono alcuna garanzia sulla consegna del
messaggio inviato al destinatario. A causa di questa limitazione nessun utente,
all’interno di una rete basata su UPnP, può essere sicuro che il proprio
messaggio (di controllo, di notifica eventi, ecc…) sia stato consegnato dalla rete
al suo destinatario con evidenti ripercussioni sulle prestazioni complessive
dell’intero ambiente di comunicazione.
Non supporta context-aware; le reti wireless sono contraddistinte dalla loro
mobilità e dalla grande dinamicità con la quale cambiano gli utenti di una rete o
la tipologia della stessa. Tutta questa dinamicità può essere gestita solamente
dando alle applicazioni la capacità di ottenere e capire le informazioni di
contesto nel quale operano. Le applicazioni che hanno questa caratteristica
vengono definite applicazioni context-aware. L’efficienza e soprattutto la
qualità di un’applicazione aumenta notevolmente potendo individuare il
contesto nel quale opera e potendo adattare il suo funzionamento in conformità
di tali informazioni.
40
Capitolo 2
Descrizione del contesto applicativo
2.1 Introduzione
Con il termine home assett management ci si riferisce ad uno scenario in cui l’utente
può gestire le risorse disponibili in casa, siano esse dispositivi (computer, centraline,
stampanti, ecc…) oppure contenuti multimediali. In casa un utente si dedica
prevalentemente a servizi di entertainment, come filmati, foto e videogiochi e ad
attività di gestione dell’ambiente domestico, come il sistema di riscaldamento e
telecamere per la videosorveglianza. La disciplina che si occupa dell'integrazione delle
tecnologie che consentono di automatizzare questa serie di attività all’interno della casa
prende il nome di domotica. Tali attività possono essere eseguite anche da remoto. Ad
esempio, è possibile dall’ufficio connettersi a casa per utilizzare media disponibili
nell’ambiente domestico o per controllare il proprio ambiente domestico. Questo è
possibile se l’ambiente domestico è interconnesso alla rete pubblica tramite dispositivi
sicuri quali ad esempio i residential gateway. Essi funzionano da piattaforma per tutti i
servizi basati sulla comunicazione multimediale. Il residential gateway permette la
gestione di audio, video, dati Internet e multimediali provenienti dalla rete domestica o
ad essa destinati. Può inoltre funzionare come un application server per una vasta serie
di servizi ad alto livello come la gestione dell’energia, della sicurezza, della
manutenzione, del commercio elettronico ecc.
Durante il soggiorno in casa o in ufficio l’utente si può trovare a dover gestire una
molteplicità di risorse ed è in grado di accedere a servizi anche con elevata interattività.
41
L’ambiente di casa è caratterizzato da una molteplicità di dispositivi che permettono
all’utente di interagire in modo intelligente ed efficiente con il contesto (ambiente
indoor). Può anche usufruire facilmente di connessione a larga banda tra dispositivi
locali e l’esterno attraverso Internet. In questo scenario si possono distinguere terminali
di uso comune quali DVR (Digital Video Recorder), TV/schermi ad alta definizione,
PC (Personal Computer), ai quali si aggiungono terminali portatili di tipo laptop,
telefonini e palmari interconnessi in un’unica rete domestica di dispositivi. La rete è
accessibile internamente tramite interfacce LAN (Local Area Network) e WLAN
(Wireless
LAN)
ed
esternamente
tramite
rete
UMTS
(Universal
Mobile
Telecommunications System) o tramite accesso a larga banda fisso di tipo xDSL
(ADLS/HDSL/VDSL), cavo o fibra.
La casa è quindi il luogo dove l’utente si trova nel contesto più favorevole per usufruire
dei media, sia per la disponibilità di risorse vicine che per il tempo a disposizione.
Quando l’utente è fuori casa (ambiente outdoor), può ugualmente usufruire di molte
risorse se interconnesso al proprio ambiente domestico in modo opportuno (ad esempio
con residential gateway) sfruttando sensori di vario tipo, quali telecamere, sensori di
temperatura/umidità/gas/illuminazione per il monitoraggio e la gestione dell’ambiente
domestico.
In questo capitolo verranno mostrati alcuni possibili scenari nei quali si rende utile
l’uso di soluzioni tecnologiche come UPnP per la gestione dei servizi in ambiente
indoor e per l’accesso a tali servizi anche da posizione remota. Verrà presentato inoltre
un semplice tool per sviluppare e gestire applicazioni UPnP e per creare un semplice
esempio di rete UPnP, al fine di gestire in maniera automatica tutti i servizi disponibili
nel proprio ambiente domestico.
42
2.2 Contesto di gestione dell’ambiente domestico
Lo scenario è quello di un edificio in cui tutti gli impianti siano integrati e controllati
tramite un software personalizzabile, ad esempio UPnP. I dispositivi presenti
nell’ambiente vengono controllati tramite un unico punto d’accesso al sistema, per
esempio tramite PC, palmare, telefono cellulare ecc. Il controllo delle attività presenti
in casa è possibile, come già detto, anche da posizione remota. Le aree di automazione
che maggiormente interessano la domotica riguardano principalmente:
Gestione dell’ambiente,
Comunicazione e informazione.
Nella figura 12 viene mostrato un esempio di architettura UPnP riferita allo scenario in
esame.
Figura 12: Esempio di architettura UPnP.
43
I servizi di domotica relativi alla prima area sono:
Illuminotecnica; il sistema controlla contemporaneamente diverse fonti luminose e
rende consultabili i parametri relativi all’intensità luminosa in ogni stanza (luci
automatiche, temporizzate, a spegnimento ritardato, ecc).
Climatizzazione; il sistema è in grado di gestire temperature differenziate per ogni
singolo ambiente e per fascia oraria, modificabili attraverso interfacce interattive
dall’utente. Ogni ambiente ha la temperatura ideale in base al profilo utente.
Automatismi; il sistema attiva alcune funzioni, quali la chiusura di tutti gli infissi
quando si esce di casa o delle persiane in caso di pioggia.
Audio-Video e home-theatre; il servizio si basa su controllo audio e video a distanza,
ascolto di brani preferiti in diversi ambienti e con un unico impianto multi-room;
visione di video su multi-dispositivi (televisore, notebook, laptop, ecc). Inoltre, ascolto
di brani musicali all’esterno (in giardino ad esempio), con la gestione di diverse fonti
sonore.
Giardino intelligente; ovvero sistema di controllo irrigazione, piscine e giochi d’acqua.
Il sistema memorizza i dati e, sulla base delle condizioni micro-climatiche, gestisce
orari e tempi, per una perfetta irrigazione.
Domotica olfattiva; Il sistema attiva il termoconvettore, per creare in pochi minuti la
temperatura ideale e permette di percepire un odore sulla base dell’ambiente o del
profilo utente (ad esempio, l’odore della salsedine nella piscina coperta).
Tramite l’accesso della rete domestica a larga banda all’esterno l’utente potrà
controllare le risorse domestiche anche dall’ufficio. In particolare, sarà possibile:
videosorvegliare la casa da remoto;
controllare il sistema di riscaldamento, ad esempio per impostare un orario di
accensione anticipato nel caso in cui si preveda di tornare a casa prima del
solito;
scaricare contenuti multimediali da casa necessari per lavorare in ufficio e
caricare nel PC di casa alcuni file, dei quali si avrà bisogno nel fine settimana.
Per quanto riguarda la seconda area di automazione, possiamo dire che in questo
scenario un utente potrebbe essere interessato alla possibilità di gestire la migrazione di
una serie di servizi dal proprio PC, laptop, telefonino verso alcuni dispositivi presenti
44
nel proprio ambiente domestico. Ad esempio, mentre è in corso una videochiamata sul
proprio telefonino UMTS, un utente potrebbe desiderare di trasferire il contenuto video
della comunicazione verso lo schermo LCD presente nel soggiorno e quindi di godere
di una maggiore risoluzione video. Più semplicemente, l’utente potrebbe avere il
bisogno di stampare dei documenti dal proprio portatile su la stampante di casa,
inviando il file tramite un messaggio. L’operazione avrebbe luogo senza
necessariamente collegarsi alla stampante, ma comodamente seduti sul proprio divano.
2.3 Requisiti di una rete domestica
Le soluzioni tecnologiche che possono essere adottate per la realizzazione di un sistema
domotico sono caratterizzate da requisiti legati all’uso di dispositivi casalinghi. Questi
requisiti sono:
Semplicità; il sistema domotico è diretto ad un pubblico vasto e non professionale, per
questo deve essere semplice da usare mediante applicazioni software caratterizzate da
interfacce “user friendly”. Deve inoltre essere sicuro e non deve presentare pericoli per
chi non ne conosce o comprende le potenzialità.
Continuità di funzionamento; il sistema deve essere costruito pensando al fatto che
dovrà offrire un servizio continuativo e per questo praticamente immune da guasti o
semplice da riparare anche per personale non esperto o, nel caso, necessitare di tempi
brevi per la rimessa in funzione.
Affidabilità; il sistema funziona sempre, senza richiedere particolari attenzioni; anche in
caso di guasti esso deve essere in grado di fornire il servizio per il quale è stato
progettato o uno simile in caso di funzionamento ridotto. Deve essere inoltre in grado di
segnalarne il mancato funzionamento e di generare un report delle eventuali anomalie.
Basso costo; affinché un sistema domotico sia alla portata di tutti deve avere un costo
contenuto, inteso come economicità delle periferiche e della rete di interconnessione tra
i diversi moduli funzionali.
45
In base a queste considerazioni sui requisiti che dovrà possedere un sistema domotico,
risulta evidente che l’uso dei protocolli UPnP e in particolare di una rete UPnP può
senz’altro offrirci dei vantaggi significativi, soprattutto per quanto riguarda la
semplicità, l’affidabilità e il contenimento dei costi.
2.4 Modello di rete domestica UPnP
Per comprendere meglio lo scenario prospettato e per capire a fondo come e quando
hanno luogo le varie fasi della connettività in una rete UPnP, può essere utile definire
un semplice modello di rete domestica. Questa rete poggerà su una LAN e conterrà solo
alcune periferiche UPnP. Nella figura 13 riportata di seguito viene mostrata una rete
contenente le seguenti periferiche UPnP:
Un Access Point; Potrebbe trattarsi di una periferica gateway autonoma oppure di un
PC che funge da gateway. Questa periferica potrebbe essere un punto di controllo (ma
ciò non è necessario) e i servizi forniti potrebbero includere l'accesso a Internet, un
server DHCP (Dynamic Host Configuration Protocol), un proxy DNS e un servizio di
archiviazione. Il gateway sarà inoltre connesso a vari supporti di una LAN domestica e
fungerà da bridge per questi supporti. I supporti utilizzati includono connessioni IEEE
802.11 senza fili, una rete sui cavi di alimentazione elettrica, una rete telefonica e
connessioni IEEE 1394.
Alcuni devices; La rete conterrà vari dispositivi abilitati per UPnP, fra cui un lettore CD
e un lettore DVD collegato ad un televisore. La rete includerà inoltre una stampante
UPnP connessa alla LAN domestica.
Alcuni PoC; Tra questi troviamo un pocket PC i-mate™ jasjar con piattaforma
Microsoft® Windows Mobile™ 5.0 Phone Edition, un laptop computer e un telefonino
UMTS.
46
Figura 13: Modello di rete UPnP.
2.5 UPnP Script di una rete domestica
Nello scenario iniziale di figura 13, ammettiamo per ipotesi che tutti i componenti della
rete siano in funzione e si siano rilevati vicendevolmente attraverso i protocolli UPnP,
ad eccezione del palmare e della stampante. Nel nostro esempio immaginiamo che
entrambi siano spenti. A questo punto decidiamo di accendere la stampante connessa
alla LAN. Le fasi che avranno luogo d’ora innanzi descrivono brevemente tutte le fasi
della connettività di una rete UPnP:
47
Indirizzamento; la prima operazione che la stampante ha dovuto effettuare è stata
quella di ottenere un indirizzo per partecipare alla rete. Ogni periferica deve essere
dotata di un client DHCP e cercare un server DHCP quando viene connessa per la
prima volta alla rete. Questa operazione avviene tramite l’invio di messaggi DHCP
Discover. Se il client DHCP della stampante non ottiene un messaggio di risposta
DHCP Offer da un server dopo un breve periodo di tempo, avvia una nuova ricerca per
dare a un altro server la possibilità di rispondere. Se nella rete non è presente un server
DHCP in esecuzione, la stampante si attribuirà automaticamente un indirizzo IP
utilizzando il protocollo Auto-IP. Supponiamo che attraverso il protocollo Auto-IP la
periferica abbia scelto un indirizzo IP nell'intervallo 169.254/16. Il primo e gli ultimi
256 indirizzi di questo intervallo sono riservati e non devono essere utilizzati.
L’indirizzo selezionato deve essere testato, per verificare che non sia già in uso. Se
l'indirizzo è utilizzato da un'altra periferica, è necessario scegliere e testare un altro
indirizzo, per un numero massimo di tentativi che dipende dall'implementazione.
Se nella rete è presente un server DHCP, l'intero processo potrebbe richiedere meno di
un secondo. Se nella rete non è disponibile un server DHCP e la periferica deve
ricorrere al protocollo Auto-IP, il processo è leggermente più lungo. Se l'indirizzo viene
assegnato automaticamente tramite il protocollo Auto-IP, la stampante verificherà
periodicamente l'eventuale disponibilità di un server DHCP nella rete per assicurarsi
che venga mantenuta la connettività tra le periferiche.
A questo punto la stampante o dispone di un indirizzo assegnatogli dal server DHCP, e
tutte le altre periferiche della rete hanno un indirizzo nella stessa subnet, oppure la
stampante ha un indirizzo Auto-IP. In entrambi i casi, la stampante può comunicare con
le altre periferiche della rete via TCP/IP.
Dopo che alla stampante è stato attribuito un indirizzo IP valido, è possibile
individuarlo e farvi riferimento nella rete attraverso tale indirizzo. Potrebbero
verificarsi situazioni in cui l’utente abbia la necessità di individuare e identificare una
periferica. In questi casi, sarebbe preferibile l'utilizzo di un nome descrittivo per la
periferica anziché del corrispondente indirizzo IP, ma l'utilizzo del servizio DNS per il
mapping dei nomi agli indirizzi esula dall'ambito della tecnologia UPnP.
48
Rilevazione - Annuncio; ora che la periferica ha acquisito un indirizzo e può
comunicare in rete, deve rendere pubblica la sua disponibilità ai punti di controllo
UPnP già operanti in rete. Questo è il primo tipo di rilevazione che ha luogo nelle reti
UPnP. Quando si aggiunge una periferica a una rete, il protocollo di rilevazione UPnP
consente a tale periferica di rendere noti i servizi offerti ai punti di controllo della rete.
Ciò viene fatto inviando una serie di messaggi di rilevazione multicast chiamati
SSDP:alive, che rendono note le periferiche e i servizi incorporati e che sono creati con
il metodo NOTIFY, definito nel protocollo GENA, nel seguente formato:
NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL for UPnP description for root device
NT: search target
NTS: ssdp:alive
SERVER: OS/version UPnP/1.0 product/version
USN: advertisement UUID
Un punto di controllo interessato può rimanere in stato di ascolto sull'indirizzo
multicast standard in attesa di messaggi di notifica che segnalano la disponibilità di
nuovi servizi, come mostrato in figura 14.
Nei messaggi di rilevazione inviati dalla stampante dell’esempio è incluso un
timestamp (CACHE-CONTROL) che indica per quanto tempo è valido l'annuncio
(valore di default pari a 1800 secondi). Prima che sia trascorso questo tempo, la
stampante deve ripetere l’invio del suo annuncio. In caso contrario i punti di controllo
potrebbero presupporre che la periferica non sia più disponibile. Inoltre, prima di
passare alla modalità non in linea, la stampante deve inviare il messaggio SSDP:byebye
per comunicare esplicitamente alla rete che non sarà disponibile. Tale messaggio
assume il seguente formato:
49
NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
NT: search target
NTS: ssdp:byebye
USN: advertisement UUID
La stampante, dopo essere stata collegata alla rete, invierà annunci GENA per ogni
periferica e servizio offerto, rendendo pubblica la sua presenza. Poiché i messaggi
vengono recapitati via UDP, un trasporto non affidabile, è possibile che vengano inviati
più volte, in modo da garantirne la ricezione da parte di tutti i punti di controllo
interessati.
Figura 14: Schema della fase di discovery (annuncio e ricerca).
50
Rilevazione - Ricerca; dopo aver collegato la stampante, immaginiamo che venga per
la prima volta acceso il palmare. Anche il palmare utilizza la tecnologia UPnP. La fase
di indirizzamento e annuncio vengono pertanto eseguite come per la stampante. Adesso
anche il palmare è “visibile” all’interno della rete UPnP, connettendosi alla rete
domestica senza la necessità di alcuna configurazione aggiuntiva.
L’utente può a questo punto usufruire dei servizi messi a disposizione della rete e in
particolare della nuova periferica stampante. Se infatti volesse stampare dei documenti
senza dover per forza accendere il computer collegato alla stampante ma comodamente
seduto sul proprio divano, non dovrà far altro che utilizzare un'applicazione per il
controllo della stampante sul proprio palmare. Avviando questa applicazione, nella rete
si attiva un nuovo punto di controllo. Sul palmare vengono visualizzate tutte le
periferiche stampanti disponibili in rete. A questo punto l’utente selezionerà la
stampante desiderata e invierà la richiesta di stampa.
Nel frattempo, nella rete UPnP si sono concluse altre fasi. Per la prima volta è stato
attivato nella rete un nuovo punto di controllo. Quando un nuovo punto di controllo
viene aggiunto alla rete, vengono inviati messaggi di rilevazione multicast
SSDP:discover, alla ricerca di periferiche e servizi disponibili, come mostrato in figura
14. Di seguito è illustrato il formato del messaggio SSDP:discover.
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: seconds to delay response
ST: search target
Tutte le periferiche della rete devono rimanere in stato di ascolto sull'indirizzo multicast
standard in attesa di ricevere questi messaggi, a cui devono rispondere se le periferiche
e i servizi offerti corrispondono ai criteri di ricerca contenuti nel messaggio di
rilevazione. Nel nostro esempio, l'applicazione di controllo stampa avviata dall’utente
sta cercando in modo specifico tutte le periferiche per la stampa.
51
I messaggi di ricerca contengono informazioni specifiche del produttore, ad esempio il
tipo di periferica o servizio, e vari identificatori. A queste informazioni vengono quindi
aggiunti i tipi di periferica o servizi definiti da uno dei comitati di lavoro dell'UPnP
Forum per questi tipi di periferiche, in questo caso stampanti. I dati vengono infine
incapsulati in una richiesta SSDP inviata via HTTPMU. Le risposte a questi messaggi
di ricerca vengono inviate tramite messaggi UDP unicast con intestazioni SSDP. Tali
messaggi vengono chiamati Search:response e assumono il seguente formato:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age = seconds until advertisement expires
DATE: when response was generated
EXT:
LOCATION: URL for UPnP description for root device
SERVER: OS/version UPnP/1.0 product/version
ST: search target
USN: advertisement UUID
Le risposte ai messaggi di ricerca contengono le stesse informazioni contenute nei
messaggi di annuncio, con l'unica differenza che vengono inviate solo all'indirizzo IP
del punto di controllo che ha avviato la ricerca, in questo caso il palmare dell’utente.
Descrizione; il nuovo punto di controllo in esecuzione sul palmare ora è a conoscenza
di tutte le periferiche disponibili in rete. Per la prima volta in questo scenario un punto
di controllo ha bisogno di maggiori informazioni su una periferica. In altre parole,
siamo alla fase della descrizione.
Nelle risposte ai messaggi di ricerca è contenuto l'URL che punta alle descrizioni della
periferica. Per richiamare la descrizione di una periferica UPnP, il punto di controllo
indirizza una richiesta HTTP GET all'URL specificato nel messaggio di risposta e la
periferica restituisce la relativa descrizione, come si vede dalla figura 15. Gli URL che
consentono di richiamare le descrizioni dei servizi sono inclusi nella descrizione della
periferica, quindi le descrizioni dei servizi possono essere richiamate in modo analogo.
52
La descrizione UPnP di una periferica è un documento XML che contiene numerose
informazioni specifiche del produttore, le definizioni di tutte le periferiche incorporate,
gli URL per la presentazione della periferica e un'enumerazione di tutti i servizi, inclusi
gli URL per le fasi di controllo e generazione degli eventi. Nel nostro caso la
descrizione XML della periferica sarà identificata attraverso il nome: “urn:schemasupnp-org:device:printer:1”.
I produttori di periferiche UPnP possono ampliare la descrizione standard di periferiche
e servizi includendovi variabili di stato, azioni e persino interi servizi. In pratica,
all’interno di questo documento, sono specificate tutte le variabili e le azioni che
controllano il dispositivo di stampa. In questo modo la tecnologia UPnP consente la
massima flessibilità, pur aderendo a standard di base. Esempi di descrizioni di
periferiche e servizi sono contenuti nel documento UPnP Device Architecture.
Figura 15: Schema della fase di descrizione.
Gestione degli eventi; è possibile associare eventi alle variabili di stato contenute nella
descrizione di un servizio. Quando il valore di queste variabili cambia, il servizio
pubblica degli aggiornamenti. Un punto di controllo può sottoscrivere la ricezione di
queste informazioni inviando un messaggio di sottoscrizione Subscription request.
53
Questo messaggio è generato con il metodo SUBSCRIBE definito nel protocollo
GENA, ed assume il seguente formato:
SUBSCRIBE publisher path HTTP/1.1
HOST: publisher host:publisher port
CALLBACK: <delivery URL>
NT: upnp:event
TIMEOUT: Second-requested subscription duration
Il servizio che notifica l'evento (publisher) può accettare la sottoscrizione e rispondere
entro 30 secondi attraverso un messaggio di conferma, il cui formato è:
HTTP/1.1 200 OK
DATE: when response was generated
SERVER: OS/version UPnP/1.0 product/version
SID: uuid:subscription-UUID
TIMEOUT: Second-actual subscription duration
In questo messaggio viene comunicata la durata della sottoscrizione. Il sottoscrittore
può rinnovare la sottoscrizione oppure annullarla se non è più interessato. Nella figura
16 è mostrato lo schema di gestione degli eventi.
54
Figura 16: Schema della fase di gestione degli eventi.
Qualora il sottoscrittore volesse annullare il servizio di notifica eventi, dovrà inviare
esplicitamente il seguente messaggio di cancellazione di sottoscrizione:
UNSUBSCRIBE publisher path HTTP/1.1
HOST: publisher host:publisher port
SID: uuid:subscription UUID
In caso contrario riceverà periodicamente i seguenti messaggi di notifica eventi:
NOTIFY delivery path HTTP/1.1
HOST: delivery host:delivery port
55
CONTENT-TYPE: text/xml
CONTENT-LENGTH: Bytes in body
NT: upnp:event
NTS: upnp:propchange
SID: uuid:subscription-UUID
SEQ: event key
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<variableName>new value</variableName>
</e:property>
Other variable names and values (if any) go here.
</e:propertyset>
Presentazione; l'applicazione in esecuzione sul palmare può stabilire quali periferiche e
servizi presentare e come presentarli. In alternativa, se la stampante dispone di una
pagina Web di presentazione, tale pagina HTML potrebbe essere scaricata e utilizzata
per controllare la periferica.
L'URL che punta alla pagina di presentazione è contenuto nella descrizione della
periferica. Per richiamare questa pagina, il punto di controllo dovrà indirizzare una
richiesta HTTP GET all'URL di presentazione, e la periferica risponderà restituendo la
pagina di presentazione. Lo schema viene mostrato nella figura 17.
56
Figura 17: Schema della fase di presentazione.
Controllo; dopo che il punto di controllo ha ottenuto tutte le informazioni necessarie su
una periferica e i relativi servizi, può richiamare azioni da tali servizi, a cui i servizi
rispondono restituendo valori. Per invocare un’azione relativa ad un servizio presso una
periferica, il punto di controllo dovrà inviare il seguente messaggio chiamato
Control:Action:Invoke, generato tramite il metodo POST, definito nel protocollo
HTTP.
POST path of control URL HTTP/1.1
HOST: host of control URL:port of control URL
CONTENT-LENGTH: bytes in body
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
57
<s:Body>
<u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
<argumentName>in arg value</argumentName>
other in args and their values go here, if any
</u:actionName>
</s:Body>
</s:Envelope>
La periferica interessata dovrà rispondere entro un certo intervallo di tempo tramite un
messaggio che include il valore ritornato dell’azione. Nel nostro esempio il servizio di
stampa restituisce i risultati dell'esecuzione dell'azione o eventuali errori nel messaggio
Control:Action:Response, mostrato di seguito:
HTTP/1.1 200 OK
CONTENT-LENGTH: bytes in body
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: when response was generated
EXT:
SERVER: OS/version UPnP/1.0 product/version
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:actionNameResponse xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
<argumentName>out arg value</argumentName>
other out args and their values go here, if any
</u:actionNameResponse>
</s:Body>
</s:Envelope>
58
Un punto di controllo può inoltre interrogare tali servizi sul valore delle relative
variabili di stato allo scopo di monitorare gli effetti dell'azione, attraverso i
cambiamenti delle variabili di stato del servizio. L’interrogazione avviene tramite
l’invio del messaggio Control:Query:Invoke.
POST path of control URL HTTP/1.1
HOST: host of control URL:port of control URL
CONTENT-LENGTH: bytes in body
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:control-1-0#QueryStateVariable"
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:QueryStateVariable xmlns:u="urn:schemas-upnp-org:control-1-0">
<u:varName>variableName</u:varName>
</u:QueryStateVariable>
</s:Body>
</s:Envelope>
Lo scambio dei messaggi viene mostrato nella figura 18. Sebbene i cambiamenti delle
variabili di stato vengano notificati a tutti i punti di controllo interessati tramite il
meccanismo di controllo degli eventi, è comunque possibile interrogare esplicitamente
una variabile per verificarne lo stato. L'interrogazione di una variabile è una variante
della richiesta di controllo. La periferica deve rispondere all’interrogazione entro 30
secondi.
59
Figura 18: Schema della fase di controllo.
2.6 Sequence diagram dell’UPnP script
In questo paragrafo verrà mostrata una breve sintesi del nostro esempio nella notazione
UML (Unifield Modeling Language) sotto forma di sequence diagram, allo scopo di
rendere chiaro il succedersi delle diverse fasi della connettività UPnP.
Nella figura 19 viene presentata l’evoluzione nel tempo dello scenario descritto nel
paragrafo precedente. Occorre notare che, per semplicità, nella figura riportata di
seguito le varie fasi della connettività UPnP iniziano e terminano in modo da non
sovrapporsi.
60
Control
Point
Internet
Gateway
Printer
DHCP Discover
DHCP Offer
Indirizzamento
DHCP Discover
DHCP Offer
SSDP:alive
Time out
Annuncio
Time out
Time out
Rilevazione
SSDP:discover
Ricerca
Search:response
HTTP GET
Descrizione
urn:schemas-upnp-org:device:printer:1
Subscription request
Subscription
Gestione degli
Eventi
Event message
Presentation request
Presentazione
Presentation page
Control:Action:Invoke
Controllo
Control:Action:Response
Time
Time
Figura 19: Sequence diagram dello script.
61
Time
Questo, in realtà, non accade di solito a causa del fatto che la rete UPnP è di fatto un
sistema asincrono. Per un sistema asincrono, infatti, valgono le seguenti assunzioni:
1. nessun limite temporale imposto ad un processo (periferica o punto di controllo)
per eseguire un passo elementare,
2. nessun limite temporale imposto sulla consegna di un messaggio da sorgente a
destinazione,
3. nessuna assunzione sulla sincronizzazione fisica dei clock dei vari dispositivi
presenti sulla rete.
Quindi a partire dall’istante in cui entrambi i dispositivi, palmare e stampante,
ottengono un indirizzo IP, può accadere che le fasi possano sovrapporsi.
2.7 Come creare una rete domestica UPnP: il software Intel®
A questo punto siamo interessati a costruire di fatto una vera e propria rete UPnP. Per
far ciò sarà necessario avere a disposizione degli strumenti in grado di implementare
tutte le funzionalità che UPnP offre.
L’implementazione delle funzioni UPnP all’interno di dispositivi di rete come quelli
mostrati per descrivere lo scenario, prevede l’esecuzione di tre passi fondamentali:
1. la progettazione dell’interfaccia del control point o del dispositivo,
2. l’implementazione di uno stack UPnP che soddisfi questa interfaccia,
3. la validazione dello stack per la compilazione e l’interazione.
Questi step sono tutti supportati e resi possibili da tools di sviluppo ideati e distribuiti
gratuitamente da Intel®. Intel è una delle società fondatrici dell’UPnP Forum ed ha una
partecipazione attiva nello studio e nella realizzazione di nuove soluzioni software per
62
la creazione di device e control point basati sullo stack UPnP. All’indirizzo
www.intel.com vengono forniti liberamente i seguenti tre pacchetti:
Intel Authoring Tools for UPnP Technologies,
Intel Remote I/O for UPnP Technologies,
Intel Tools for UPnP Technologies.
Con questi tools possono essere progettati dispositivi di qualunque tipo basati sul
nucleo UPnP. Gli stack generati da questo software risultano essere molto meno
ingombranti e maggiormente specifici rispetto a quelli prodotti da altri software
disponibili sul mercato. L’elevato grado di specializzazione degli stack permette di
ottenere inoltre maggiori prestazioni e minori complicazioni sia in fase di sviluppo che
in fase di utilizzo. Il codice generato da questi tools è infine esportabile su qualsiasi tipo
di piattaforma, rendendo questo software altamente compatibile con le specifiche
progettuali di UPnP che, come già detto, è un protocollo multipiattaforma. L’ambiente
di sviluppo garantisce inoltre la più completa interoperabilità tra il dispositivo creato e
gli altri device basati su UPnP.
Un altro vantaggio di questa soluzione risiede nel notevole risparmio di memoria
introdotto. Infatti le dimensioni del codice generato dai tools della Intel si aggirano
tipicamente attorno ai 500K. Infine, per quanto riguarda la gestione della sicurezza,
attualmente è stata implementata soltanto all’interno dei dispositivi e non nei control
point.
2.8 Il software Intel® per la tecnologia UPnP™
In questo paragrafo verranno descritti brevemente i tre pacchetti forniti dalla Intel per
progettare device e control point basati su UPnP.
63
Intel Authoring Tools for UPnP Technologies; si tratta di un kit di strumenti, tra i quali
troviamo:
Intel Device Builder; Questo tool è la chiave di volta per creare le soluzioni di
UPnP. E’ in grado di generare, a partire da un set di descrizioni XML dei
servizi, lo stack scritto in qualsiasi linguaggio (C, C++, Java, …) di control
point e device. Il ruolo di Intel Device Builder è quello di aggregare
automaticamente dei Service Control Point Document (SCPD) per poi generare
il codice delle applicazioni. I SCDP sono file XML che descrivono il servizio e
che contengono informazioni come azioni, variabili di stato ed eventi disponibili
relativi al servizio.
Microstack; è il nome dato ai moduli generati in prima istanza dal Device
Builder. Al momento della generazione il Device Builder produce
un’applicazione di esempio completa nel linguaggio desiderato.
AV Microstack; è un insieme di stack Audio/Video generati dal Device Builder,
i quali rappresentano un buon punto di partenza per creare delle applicazioni
personalizzate.
Sample Applications; include una serie di esempi di applicazioni C/C++ per
varie piattaforme.
Intel Remote I/O for UPnP Technologies; insieme di strumenti che permette allo
sviluppatore di constatare come sia resa possibile la comunicazione tra i dispositivi che
compongono la rete UPnP. Basato sul framework .NET della Microsoft®, dimostra in
che modo la tecnologioa UPnP consente ad un computer, tramite un’interfaccia utente
in remoto, di interagire con un
altro dispositivo presente in rete. Al suo interno
troviamo:
Remote I/O Server; questa applicazione rileva nella rete la presenza di
dispositivi Remote I/O Client.
Remote I/O Client; incluso solo per piattaforme Microsoft Windows e Microsoft
PocketPC, scritto in linguaggio C.
Remote I/O Control; cataloga tutti i Remote I/O Client di una rete.
64
Sample User Interfaces; fornisce degli esempi di interfaccia utente per la TV
(640x480) e dispositivi palmari (240x320) in linguaggio C.
Intel Tools for UPnP Technologies; basato anch’esso sul framework .NET della
Microsoft® , questi tools consentono di velocizzare i tempi sia in fase di realizzazione,
sia in fase di testing e di apprendimento delle caratteristiche dei dispositivi, con
particolare attenzione verso i dispositivi audio/video (A/V). In questo pacchetto sono
inclusi:
Device Spy; rappresenta il punto di controllo universale, progettato con
un’interfaccia semplice e intuitiva. Permette di riconoscere i device UPnP,
visualizzandone le informazioni e di invocare azioni sui servizi messi a
disposizione. Esegue il monitor degli eventi e gestisce gli errori.
Service Author; consente la creazione dei documenti SCDP in XML che
descrivono i device attraverso le variabili di stato e le azioni.
Network Light; semplice applicazione a forma di lampadina che attraverso
alcuni comandi si accende e incrementa la luminosità. Usata per dimostrare le
potenzialità di Device Spy e Service Author.
Device Sniffer; consente di monitorare il traffico broadcast sulla rete.
Device Validator; è un tool ideato per testare i dispositivi UPnP creati.
Device Relay; replica i dispositivi UPnP di una rete all’interno di un’altra.
Device Scriptor; è un’applicazione di scripting che consente agli sviluppatori di
ideare script di scenario e di eseguirli sui dispositivi UPnP.
65
AV Media Server; è un AV UPnP Content Directory, che consente agli utenti di
fare il drag&drop delle cartelle e del loro contenuto al fine di rendere più facile
lo scambio di materiale multimediale.
AV Media Renderer; è un AV UPnP renderer il quale supporta l’esecuzione
contemporanea di play list, ricerca di traccie audio, ecc.
AV Media Controller; è un AV UPnP control point completo in ogni suo
aspetto, l’equivalente del Device Spy per gli AV. Controlla di fatto il contenuto
delle directory dei dispositivi di rete, visualizzandone il contenuto multimediale
e favorendone la ricerca.
AV Wizard; é un AV UPnP contol point che permette l’esecuzione dei contenuti
multimediali immagazzinati sul file system locale mediante riproduttori
disponibili. E’ un’applicazione integrata su Windows XP.
All’interno di Intel Tools for UPnP Technologies troviamo anche Intel Micro Tools for
UPnP Technologies. Questi tools sono inclusi sotto forma di codice sorgente generato
interamente con il Device Builder. Sono dei piccoli esempi di applicazione compilati
per PocketPC e per Windows.
2.9 Esempio di costruzione di un device: Micro Light Bulb
La progettazione e costruzione di device e servizi è resa piuttosto semplice grazie alla
presenza, nel pacchetto offerto dalla Intel, di tutto il software necessario alla
realizzazione passo passo di qualunque tipologia di dispositivo.
In questo paragrafo verrà offerto un esempio pratico di progettazione di un dispositivo
luci chiamato Micro Light Bulb (Micro lampadina) attraverso le specifiche contenute
66
nel documento “Lighting Controls V1.0” disponibile presso il sito www.upnp.org.
L’esempio segue le linee guida fornite direttamente dall’UPnP Forum.
L’identificatore del tipo di periferica che verrà utilizzata è: “urn:schemas-upnporg:device:BinaryLight:1” e dispone principalmente di due servizi: SwitchPower e
DimmingService.
2.9.1 Descrizione del dispositivo Micro Light Bulb
Si tratta di un semplice dispositivo luce UPnP, che può essere gestito attraverso un
qualsiasi control point. I servizi offerti da questo dispositivo includono, come già
accennato, SwitchPower e DimmingService. Il primo consente di accendere e spegnere
tramite controllo a distanza il dispositivo luci, mentre il secondo, sostanzialmente,
permette di regolare l’intensità luminosa emessa dal Micro Light Bulb. Entrambi i
servizi sono descritti attraverso le variabili di stato e le azioni di controllo che danno la
possibilità, ad un punto di controllo qualsiasi (PC, palmare, ecc), di gestire a distanza il
meccanismo di illuminazione della propria abitazione. Nella figura 20 in basso viene
mostrata la descrizione schematica del dispositivo, mentre la descrizione XML
completa del dispositivo può essere consultata all’interno del documento “Lighting
Controls V1.0”, identificata dal nome “urn:schemas-upnp-org:device:BinaryLight:1”.
Figura 20: Schema del dispositivo BinaryLight1.
67
2.9.2 Descrizione dei servizi Micro Light Bulb: SwitchPower
Per quanto riguarda il servizio SwitchPower, l’identificatore è: “urn:schemas-upnporg:service:SwitchPower:1”. Questo servizio utilizza due variabili di stato e due
comandi, che verranno descritti nel seguito. Le variabili sono:
Status; riflette lo stato attuale del dispositivo. E’ una variabile di tipo boolean e
vale 0 se il dispositivo è spento e 1 se è acceso (valore di default pari a 0).
Target; nel nostro esempio assume lo stesso valore di Status.
Mentre i comandi per controllare il servizio sono:
GetStatus; l’invocazione di questo comando restituisce lo stato attuale del
servizio (0 spento, 1 acceso).
SetTarget; configura lo stato del servizio. In pratica accende e spegne il
dispositivo.
2.9.3 Descrizione dei servizi Micro Light Bulb: DimmingService
Tra le variabili di stato relative al servizio DimmingService, citiamo:
LoadLevelStatus; rappresenta il livello attuale di intensità luminosa del
dispositivo. Assume valori compresi tra 0 e 100.
LoadLevelTarget; è il livello di intensità luminosità desiderata.
Tra i comandi citiamo, per brevità, soltanto i seguenti:
GetLoadLevelStatus; l’invocazione di questa azione restituisce nella variabile
retLoadLevelStatus, il valore LoadLevelStatus, ovvero il livello attuale di
intensità luminosità.
68
GetMinLevel; restituisce il livello minimo di intensità luminosa.
SetLoadLevelTarget; setta il valore LoadLevelTarget nel nuovo valore new
LoadLevelTarget.
2.9.4 Progettazione dei servizi di Micro Light Bulb
Innanzitutto verranno create le variabili di stato e le azioni che caratterizzano il
dispositivo, ovvero i servizi di cui dispone, attraverso il tool Service Author. Compito
del Service Author è quello appunto di creare dei documenti SCDP che definiscano i
servizi inclusi nel dispositivo. Sia le variabili di stato che le azioni del dispositivo sono
definite nel documento “Lighting Controls V1.0” relativo al dispositivo luci. Una volta
aperto Service Author possono essere inserite, rimosse o modificate le variabili e le
azioni cliccando con il tasto destro del mouse sull’interfaccia del tool oppure
importando direttamente la descrizione dei servizi dai documenti forniti dalla Intel.
Le figure 21 e 22 mostrano l’interfaccia del tool relativo alle variabili che descrivono i
servizi SwitchPower e DimmingService rispettivamente.
Figura 21: Interfaccia del tool Service Author riferito alle variabili di SwitchPower.
69
Figura 22: Interfaccia del tool Service Author riferito alle variabili di
DimmingService.
Le figure 23 e 24 mostrano, invece, l’interfaccia del tool relativo alle azioni che
descrivono i servizi SwitchPower e DimmingService rispettivamente.
Figura 23: Interfaccia del tool Service Author riferito alle azioni di SwitchPower.
70
Figura 24: Interfaccia del tool Service Author riferito alle azioni di DimmingService.
Al termine dell’operazione il salvataggio avrà come output lo schema XML della
descrizione del servizio offerto dal device. Questo documento XML verrà inserito dal
tool Device Builder all’interno del dispositivo che si vuole progettare. La descrizione
XML può essere consultata nel documento “Lighting Controls V1.0” disponibile presso
il sito www.upnp.org.
2.9.5 Generazione dello stack UPnP di Micro Light Bulb
Il tool Device Builder offre la possibilità di importare device da file oppure dalla rete.
L’aggiunta, la rimozione e la possibilità di importare nuovi servizi o device è
supportata da operazioni richiamabili dal menu presente sull’interfaccia, come mostrato
nella figura 25 in basso.
71
Figura 25: Interfaccia Device Builder, richiamo dei device presenti sulla rete.
Una volta richiamato il device è possibile aggiungere device nidificati alla radice (root)
oppure servizi semplicemente cliccando con il tasto destro sul device o sui servizi
rispettivamente. Nella figura 26 viene mostrata la schermata dell’interfaccia Device
Builder relativa al device Micro Light Bulb. Come si può notare è presente sulla sinistra
lo schema con il device root e i suoi servizi, mentre sulla destra viene mostrata la
descrizione del dispositivo.
72
Figura 26: Interfaccia Device Builder, visualizzazione del dispositivo luci.
Con questo tool i device possono essere salvati e riutilizzati in un secondo momento per
apportare modifiche o essere utilizzati all’interno di altri device. Le informazioni
relative al dispositivo includono un Friendly Name, attraverso il quale il dispositivo
viene intuitivamente riconosciuto dall’utente e il Root Device Type, che permette ai
control point di selezionare e riconoscere le specifiche funzioni di un dispositivo. Infatti
ogni device viene implementato secondo le specifiche progettuali dettate dall’UPnP
Forum e accessibili attraverso documenti identificati dal Root Device Type, che in
questo caso è urn:schemas-upnp-org:device:BinaryLight:1. Questo documento è
presente ovviamente nella directory “Lighting Controls V1.0”. Una volta terminata la
progettazione è possibile esportare lo stack del dispositivo o del control point mediante
la voce Export Device Stack o Export Control Point rispettivamente, come mostrato in
figura 27.
73
Figura 27: Interfaccia Device Builder, esportazione device stack.
L’operazione permetterà di visualizzare il Device Stack Code Generation o il Control
Point Stack Code Generation. Questa interfaccia, mostrata in figura 28 consente di
generare l’UPnP device stack e l’UPnP control point stack rispettivamente, cliccando
sul tasto che si trova nella parte inferiore dalla schermata.
74
Figura 28: Interfaccia Device Stack Code Generation.
Nel pannello General sono presenti tutti i principali settaggi, tra cui:
Target Platform; offre la possibilità di scegliere la piattaforma per la quale si
vuole progettare il dispositivo. Questa opzione rende ovviamente il software
della Intel altamente compatibile con i requisiti proposti da UPnP. Tra le
piattaforme supportate troviamo:
a) Intel C Stack per Microsoft® con Windows 98, Windows NT, Windows XP
nelle due versioni WinSock1 e WinSock2, e Windows 95 nella sola versione
WinSock1. L’esportazione per questa piattaforma genera un codice in
linguaggio C/C++ compatibile con il software Microsoft Visual Studio 7
(2005).
b) Intel C Stack per POSIX (Portable Operating System Interface for uniX) e
Linux standard sockets.
75
c) Intel C Stack per PocketPC 2002 (WinSock1); il codice generato per questa
piattaforma viene impiegato utilizzando come ambiente di sviluppo
Microsoft Embedded Visual Studio 3. Il codice generato è di dimensioni
molto ridotte ed è ottimizzato in modo da fare un uso moderato delle risorse
disponibili su un PocketPC quale potrebbe essere ad esempio il nostro imate jasjar.
d) Intel Java 1.3 Stack
Output Path; consente di selezionare la directory nella quale salvare il codice
generato.
Nel pannello Features troviamo invece la possibilità di impostare alcuni aspetti relativi
al protocollo di trasmissione, come ad esempio l’intervallo di tempo entro il quale
inviare di nuovo il messaggio di annuncio SSDP:alive (valore di default pari a 1800
secondi) e la dimensione degli header dei pacchetti trasmessi, come mostra la figura 29.
Figura 29: Interfaccia Device Stack Code Generation, Features.
76
Infine, nel pannello Advanced si possono settare alcuni parametri relativi alla gestione
degli errori e delle chiamate dirette a funzioni disponibili su device esterni.
2.9.6 Codice sorgente generato
Al termine dell’importazione dell’UPnP device stack e dell’UPnP control point stack
mediante il Device Builder vengono generati e salvati nella directory specificata
nell’OutputPath un certo numero di file. Tra questi troviamo “UPnPSample.vcproj”, il
quale rappresenta il file di progetto per il Microsoft Visual Studio 7 e il “Main.c”. dove
sono definite tutte le funzioni che agiscono sulle variabili di stato del dispositivo. Il
Main del progetto è di fatto un piccolo esempio di codice in linguaggio C/C++,
all’interno del quale vengono invocate una breve lista di azioni a cui il dispositivo
risponde. Occorre notare che verranno prodotti questi file se è stato opportunamente
selezionato Intel C Stack alla voce Target Platform. Visual rappresenta l’ambiente di
sviluppo all’interno del quale è possibile aprire i file di progetto relativi al control point
e ai device. Una volta aperti basterà avviare il debug per osservare, nella finestra di
output, lo scambio di messaggi, relativi alle diverse fasi della connettività, tra control
point e device.
2.10 Simulazione connettività UPnP: scenario 1
Alla luce delle conoscenze maturate fino a questo punto, siamo ora in grado di fornire
un piccolo esempio relativo alla costruzione di una rete LAN con caratteristiche UPnP,
attraverso il software della Intel. L’esempio pratico ricalca sostanzialmente il modello
di rete domestica UPnP prospettato nel paragrafo 2.4, salvo alcune eccezioni. La figura
30 mostra lo scenario reale che è stato creato al fine di produrre una simulazione reale
77
di connettività di una rete UPnP. La rete poggia su una LAN ed è costituita dai seguenti
dispositivi:
PoC (Point of Control); ovvero il punto di controllo della rete UPnP. E’ un
laptop computer fornito del pacchetto Intel Tools for UPnP Technologies. In
pratica il PoC possiede tutti gli strumenti per scoprire i dispositivi presenti sulla
rete e per accedere ai servizi che quest’ultimi mettono a disposizione. Al suo
interno è presente l’AV Media Renderer, ovvero un player in grado di
riprodurre i contenuti multimediali presenti sull’AV Media Server.
Access Point; dispositivo gateway capace di consentire la comunicazione tra i
vari dispositivi di rete. I servizi forniti da questo device includono l’accesso a
Internet, un server DHCP, ecc…
TwonkyVision; si tratta di un AV Media Server con funzionalità UPnP, istallato
su un laptop computer, contenente numerosi file multimediali come video, foto,
musica, ecc. Viene controllato dal PoC ed è in grado di inviare i file da
riprodurre verso l’AV Media Renderer. Il trasferimento dei file avviene al di
fuori del protocollo UPnP (fuori banda). I servizi disponibili inclusi in questo
dispositivo sono:
Content Directory; consente al PoC di visualizzare tutti i contenuti
multimediali dell’AV Media Server.
Connection Manager; questo servizio è utilizzato per gestire le connessioni
tra PoC e device.
78
Figura 30: Scenario 1 creato per la simulazione.
L’accesso alla rete e ai servizi da parte del PoC può verificarsi secondo entrambe le
modalità di connessione: wired e wireless. Nel nostro esempio, la condivisione dei
contenuti dell’AV Media Server, avviene in modalità wireless tramite l’access point
secondo lo standard 802.11g. Di seguito verranno illustrati i passi che descrivono come
sia stata realizzata la simulazione di connettività UPnP relativa allo scenario 1. Per
prima cosa, viene aperta sul PoC l’applicazione Device Spy. Questa operazione simula
di fatto l’accensione del PoC. A partire da questo istante viene aggiunto nella rete un
nuovo punto di controllo. Il Device Spy consente la ricerca dei devices presenti nella
rete e l’accesso ai servizi che essi mettono a disposizione. La figura 31 mostra
l’interfaccia del Device Spy attraverso la quale un utente è in grado sia di visualizzare i
servizi presenti nella rete, sia di invocare azioni su tali servizi.
79
Figura 31: Interfaccia Device Spy.
L’applicazione permette di visualizzare tutti i dispositivi attualmente presenti. Nel
nostro esempio è stato visualizzato il Media Server. E’ anche possibile monitorare il
traffico di pacchetti scambiati dai dispositivi attraverso il Device Sniffer. Infatti, una
volta acquisito un indirizzo di rete valido, ciascuna periferica tenta di rendere pubblica
la propria presenza ai PoC attraverso messaggi di notifica SSDP:alive. Viceversa il
PoC, appena acquisito un indirizzo di rete valido, tenta di scoprire i devices disponibili
nell’ambiente inviando messaggi di ricerca multicast ssdp:all verso tutti.
80
Figura 32: Interfaccia Device Sniffer.
Una volta visualizzato il device, si seleziona il servizio al quale si è interessati. In
questo caso siamo interessati ad accedere ai contenuti multimediali presenti sul Media
Server “TwonkyVision”. Per accedere a questo tipo di servizi risulta conveniente aprire
l’AV Media Controller. Come già accennato si tratta di un AV UPnP PoC completo in
ogni suo aspetto, l’equivalente del Device Spy per gli AV. Controlla il contenuto delle
directory del Media Server, visualizzandone il contenuto multimediale. Per usufruire
dei file multimediali occorre però disporre di un Media Player, verso il quale inviare il
contenuto del Media Server. Intel fornisce, come già indicato nei paragrafi precedenti,
un’applicazione in grado di venirci incontro: l’AV Media Renderer. Si tratta di un AV
UPnP renderer capace di supportare l’esecuzione di immagini e di tracce audio/video.
81
Figura 33: Interfaccia dell’AV Media Controller.
A questo punto basta inviare il file desiderato verso l’AV Media Renderer cliccando
con il tasto destro del mouse sul brano e eseguire il play sul proprio PoC. Si noti che il
trasferimento dei contenuti AV verso il Media Renderer avviene in modalità streaming.
Col termine streaming si identifica la modalità operativa di un’applicazione che
presenta dati multimediali, mentre il trasferimento di tali dati è ancora in corso.
Prima di terminare il capitolo, però, si rende necessario introdurre due precisazioni. La
prima delle quali è che la qualità della riproduzione è condizionata dalle capacità render
del proprio portatile ma ciò esula, ovviamente, dagli obiettivi di questa simulazione.
La seconda è che, affinché l’AV Media Controller veda l’AV Media Renderer,
quest’ultimo deve necessariamente essere aperto prima che avvenga il trasferimento dei
dati.
82
Figura 34: Interfaccia dell’AV Media Renderer.
2.11 Simulazione connettività UPnP: scenario 2
In questo paragrafo verrà mostrato uno scenario di rete molto simile a quello
precedente, caratterizzato dalla presenza del dispositivo jasjar al posto del portatile. Il
nuovo scenario prevede la presenza dei seguenti dispositivi:
PoC (Point of Control); si tratta, come già detto, dell’i-mate™ jasjar con
piattaforma Microsoft® Windows Mobile™ 5.0 Phone Edition, sul quale è stato
istallato l’applicativo “Rudeo Play & Control”. Questo software è allo stesso
tempo un controller e un player per Windows Mobile 5.0 equivalente all’AV
MediaController e all’AV MediaRenderer della Intel per Windows XP. E’
disponibile una versione di prova gratuita presso il sito www.rudeo.com ma
sfortunatamente è in grado di eseguire solo tracce audio.
83
Access Point;
TwonkyVision;
La figura 31 mostra lo scenario 2 creato per la nuova simulazione. Questo esempio ha
l’obiettivo di mostrare come le funzionalità UPnP possano essere portate anche al di
fuori dei dispositivi portatili i quali, come risulta evidente, rappresentano un vincolo
molto forte per quanto riguarda la praticità e la comodità d’uso.
Figura 31: Scenario 2 creato per la simulazione.
All’interno del PoC è sufficiente aprire il programma “Rudeo Play & Control” per
visualizzare i dispositivi AV presenti in rete e per accedere ai loro contenuti
multimediali. Anche in questo esempio, la condivisione dei contenuti dell’AV Media
Server avviene in modalità wireless tramite l’access point, secondo il protocollo
802.11g. La figura 32 mostra l’interfaccia del Rudeo attraverso la quale è possibile
accedere ai contenuti multimediali del TwonkyVision.
84
Figura 32: Interfaccia del Rudeo Play & Control.
85
Capitolo 3
Analisi e sviluppo del progetto
3.1 Introduzione
Nei capitoli precedenti è stata offerta una breve panoramica sul service discovery e in
particolare sul protocollo Universal Plug and Play. Inoltre sono stati mostrati alcuni
semplici scenari applicativi all’interno dei quali è risultato conveniente introdurre
questo standard, al fine di creare una piccola rete domestica. Il software della Intel è
stato, ovviamente, preziosissimo a tal riguardo, in quanto ci ha permesso di realizzare
un modesto ma significativo esempio di connettività UPnP. L’esempio, lo ricordiamo,
consisteva nel simulare un possibile scenario di rete domestica, caratterizzato dalla
presenza di un Media Server (TwonkyVision) e di un PoC (laptop e palmare). In questo
capitolo verrà mostrato un nuovo scenario applicativo che richiederà l’introduzione di
una nuova proposta di architettura Audio/Video. Analogamente agli esempi portati nel
capitolo precedente, anche questa architettura si basa sulla presenza di AV Media
Server e PoC. L’idea nasce, naturalmente, dagli standard proposti dall’UPnP Forum.
L’architettura di riferimento è consultabile presso il sito www.upnp.org ed in
particolare all’interno dei documenti “MediaServer V1.0 and MediaRenderer V1.0” e
“Quality of Service V1.0”, dove è possibile esaminare le versioni originarie presentate
dall’UPnP Forum sotto l’identificativo “UPnP AV Architecture:0.83” e “UPnP QoS
Architecture:1.0” rispettivamente. La proposta di architettura UPnP che verrà mostrata
86
in questo capitolo integra quelle proposte dall’UPnP Forum allo scopo di offrire, ad un
potenziale utente UPnP, maggiori servizi e funzionalità.
3.2 Scenario di riferimento
Supponiamo che un ipotetico utente (che chiameremo utente 1), dotato di un qualche
dispositivo portatile, stia cercando di visualizzare l’insieme dei servizi presenti su una
qualche rete, ad esempio quella mostrata negli scenari 1 e 2 del capitolo precedente.
Nel caso egli disponga della tecnologia UPnP per effettuare il service discovery troverà,
dopo un breve intervallo di tempo, un certo numero di dispositivi presenti, in grado di
offrire alcuni servizi. Immaginiamo ancora che l’utente sia interessato ad accedere ai
sevizi messi a disposizione da un AV Media Server, ovvero un dispositivo che include
al proprio interno diversi contenuti multimediali come foto, video, musica, ecc. La
condivisione dei contenuti presenti sull’AV Media Server avviene inviando questi
sull’AV Media Renderer, ovvero un dispositivo player (spesso presente all’interno del
terminale dell’utente, ma ciò non è necessario) capace di riprodurre i contenuti
multimediali dell’AV Media Server. Si ricorda che il trasferimento dei dati tra i due
dispositivi AV avviene in modalità streaming utilizzando la modalità trasmissiva
wireless 802.11g. Dopo che l’utente 1 ha rilevato la presenza dell’AV Media Server,
immaginiamo ancora che egli desideri riprodurre un determinato contenuto video
sull’AV Media Renderer selezionato, che chiameremo MediaPlayer1. Mentre sta
avendo luogo il trasferimento dei dati dall’AV Media Server verso il MediaPlayer1, si
supponga che un altro utente (chiamato utente 2), dotato anch’egli di dispositivo
portatile con incluso un AV Media Renderer (che chiameremo MediaPlayer2) abbia già
concluso la fase di rilevazione dei dispositivi. A questo punto l’utente 2 decide di
selezionare un video sull’AV Media Server e di trasferire il suo contenuto verso il
proprio AV Media Renderer (MediaPlayer2), mentre la fase di trasferimento verso il
87
MediaPlayer1 dell’altro utente sta ancora avendo luogo. La figura 33 mostra lo scenario
di riferimento. Gli attori in gioco sono:
Access Point; dispositivo router che consente la comunicazione tra i vari
devices presenti nella rete in modalità wireless, secondo lo standard 802.11g.
AV Media Server; dispositivo UPnP contenente video, foto, musica, ecc.
PoC utente 1; dispositivo portatile che include un AV Media Renderer chiamato
MediaPlayer1.
PoC utente 2; dispositivo portatile che include un AV Media Renderer chiamato
MediaPlayer2.
Figura 33: Scenario di riferimento.
88
3.3 Problema aperto: contese d’accesso
In base alle ipotesi illustrate nel paragrafo predente, siamo ora in grado di mostrare il
problema che questo nuovo scenario ha aperto: le contese d’accesso. Di seguito verrà
offerta una breve descrizione sull’argomento in questione.
La concorrenza delle richieste di servizio presentate da diversi PoC può determinare
condizioni di contesa. Queste si verificano quando tutte le risorse disponibili sono
occupate a favore di una certa attività di utilizzazione (come può essere, ad esempio, la
riproduzione AV di un Media Renderer) e vengono presentate nuove richieste di
sevizio. Le condizioni di contesa devono essere risolte adottando determinate tecniche
di scheduling. Lo scheduling è una disciplina in grado di decidere l’ordine di
esecuzione delle richieste di servizio che si presentano al fine di condividere una
qualche risorsa. Nel nostro caso, la risorsa condivisa è il mezzo radio messo a
disposizione dall’access point e le attività che entrano in conflitto a causa della contesa
del mezzo radio sono i due AV Media Renderer. Queste applicazioni necessitano di
scheduling allo scopo di ottenere determinati livelli di qualità di riproduzione. Come
già più volte ricordato, i dati trasferiti e poi riprodotti sugli AV Media Renderer sono
trasmessi in modalità streaming, ovvero vengono trasportati come flusso dati e non
necessitano di essere salvati interamente prima di poter essere riprodotti. I dati in arrivo
vengono messi in sequenza in un buffer dal quale il ricevente preleverà i dati da
visualizzare, consumando così i dati del buffer. Questo fa intuire che per usufruire di
servizi multimediali streaming (video, audio, ecc…) c’è bisogno di una determinata
qualità e continuità della comunicazione per evitare ritardi nella trasmissione, i quali
riducono di molto la qualità del servizio. La discontinuità porta facilmente a un ritardo
o nel caso peggiore al blocco dell’erogazione del servizio. Se, dunque, l’utente 1 non
intende percepire una qualità della riproduzione video inferiore alle proprie aspettative
a causa della concorrenza sul mezzo radio dell’attività dell’utente 2, deve
necessariamente richiedere una priorità più alta per i dati che intende trasferire verso il
proprio MediaPlayer. Da quanto esposto fino ad ora, risulta evidente che la nuova
89
architettura di servizio dovrà consentire agli utenti di gestire l’allocazione delle risorse
disponibili attraverso la classificazione dei flussi dati mediante QoS (Quality of
Service) differenziate. Ad ogni livello di QoS sarà associato, chiaramente, un
determinato livello di priorità.
3.4 Architettura AV UPnP: descrizione generale
Siamo dunque interessati a creare un’architettura in grado di offrire nuove soluzioni,
attraverso le quali superare le nascenti difficoltà incontrante in termini di contese
d’accesso. Questa nuova architettura integrerà i servizi messi a disposizione da due
distinte architetture di servizio: l’architettura AV UPnP e l’architettura QoS UPnP, al
fine di fornire ai diversi flussi dati, QoS differenziate e prestabilite. Nei paragrafi
seguenti verranno mostrati tutti i dettagli implementativi dell’architettura UPnP AV, i
quali definiscono in maniera completa le interazioni tra PoC e AV devices. Lo schema
grafico di questa architettura è rappresentato nella figura 34 e mostra tutti gli attori
coinvolti:
AV Control Point o PoC; dispositivo fisso o portatile in grado di scoprire gli
AV devices presenti nell’ambiente e interagire con essi.
AV Media Server; dispositivo che include al proprio interno diversi contenuti
multimediali come foto, video, musica, ecc. Viene controllato dal PoC ed è in
grado di inviare i file da riprodurre verso l’AV Media Renderer.
AV Media Renderer; dispositivo indipendente o integrato nel PoC, capace di
riprodurre i contenuti multimediali dell’AV Media Server.
90
Figura 34: Architettura AV UPnP.
3.5 Descrizione del dispositivo AV Media Server
L’AV Media Server è utilizzato per archiviare l’insieme dei contenuti multimediali
disponibili nella rete domestica. Questo dispositivo può includere altri devices come, ad
esempio, DVD, MP3 player, TV, radio, PC ed altro ancora. L’identificativo del
dispositivo è “urn:schemas-upnp-org:device:MediaServer:1” ed è caratterizzato dai
seguenti servizi descritti più avanti: Content Directory, ConnectionManager e AV
Transport (opzionale). Compito dell’AV Media Server è quello di condividere con i
PoC presenti nell’ambiente i propri file e di trasferirli verso un AV Media Renderer
fuori banda, ovvero al di fuori del protocollo UPnP. La figura 35 mostra lo schema
dell’AV Media Server.
91
Figura 35: Schema del dispositivo AV Media Server.
3.5.1 Descrizione servizi AV Media server: Content Directory
Il
servizio
Content
Directory,
il
cui
identificativo
è
“urn:schemas-upnp-
org:service:ContentDirectory:1”, comprende un set di azioni che consentono al PoC di
visualizzare tutti i contenuti multimediali dell’AV Media Server. L’azione principale di
questo servizio è:
Browse(); permette al PoC di ottenere dettagliate informazioni circa i contenuti
del Media Server, come ad esempio il nome, l’artista, la data e la dimensione
del file multimediale che si vuole condividere. Inoltre include il Tspec (Traffic
Specification) del flusso dati relativo al trasferimento di ciascun contenuto. Il
Tspec definisce le caratteristiche statistiche di questo flusso dati.
3.5.2 Descrizione servizi AV Media server: Connection Manager
Questo servizio è utilizzato per gestire le connessioni associate ad un particolare device.
L’identificativo a cui fa riferimento è “urn:schemas-upnp-org:ConnectionManager:1” e
92
dispone di alcune azioni di controllo che consentono all’AV Media Server di prepararsi
per il trasferimento dei contenuti multimediali. Le azioni principali relative a questo
servizio sono:
GetProtocolInfo(); questa azione consente al PoC di visualizzare la lista
completa dei protocolli e del formato dati supportato dall’AV Media Renderer
per il trasferimento dati dall’AV Media Server.
PrepareForConnection(); l’uso di questa azione permette al device di prepararsi
alla connessione sulla rete al fine di inviare o ricevere i contenuti AV.
ConnectionComplete(); L’utilizzo di questa azione consente al PoC di terminare
la connessione instaurata tra AV Media Server e AV Media Renderer.
3.5.3 Descrizione servizi AV Media server: AV Transport
Il servizio opzionale AV Transport consente al PoC di controllare il cosiddetto
“playback” dei contenuti multimediali presenti nell’AV Media Server. Il suo
identificativo è “urn:schemas-upnp-org:service:AVTransport:1” e include tra i propri
comandi le azioni che controllano direttamente il flusso dei contenuti riprodotti dall’AV
Media Renderer, come Play, Stop, Pause, Seek, ecc. I principali comandi sono:
SetAVTransportURI(); questa azione consente al PoC di indicare l’URI relativo
al contenuto multimediale da trasferire verso i Media Renderer.
Play(); L’invocazione di questa azione permette, ovviamente, al PoC di
riprodurre il contenuto dell’AV Media Server sull’AV Media Renderer.
93
3.6 Descrizione del dispositivo AV Media Renderer
L’AV Media Renderer viene utilizzato per riprodurre i contenuti multimediali
visualizzati sull’AV Media Server dal PoC. Questo dispositivo, identificato come
“urn:schemas-upnp-org:device:MediaRenderer:1”, può essere visto come un device
fisicamente distinto oppure incluso direttamente nel PoC, come risulta evidente dagli
esempi creati nel capitolo precedente. Anche l’AV Media Renderer, come l’AV Media
Server, può includere una serie di altri devices al proprio interno, come monitor TV,
impianti stereo, MP3 player, ecc. I servizi compresi in questo dispositivo sono:
RenderingControl, ConnectionManager, AVTransport (opzionale). Per quanto riguarda
ConnectionManager e AVTransport, valgono le stesse considerazioni fatte per l’AV
Media Server. Ci limiteremo a descrivere di seguito, quindi, soltanto il servizio di
RenderingControl. La figura 36 mostra lo schema dell’AV Media Renderer.
Figura 36: Schema del dispositivo AV Media Renderer.
94
3.6.1 Descrizione servizi AV Media renderer: Rendering Control
Il servizio, identificato come “urn:schemas-upnp-org:service:RenderingControl:1”,
prevede un set di istruzioni che consentono al PoC di controllare e gestire la
riproduzione dei contenuti multimediali presenti nell’AV Media Server. Queste
istruzioni includono la regolazione di alcuni aspetti relativi alla percezione visiva dei
video come la luminosità, il contrasto, la temperatura di colore, ecc. Le azioni principali
che caratterizzano questo servizio sono:
SetVolume(); l’azione consente al PoC di regolare il livello del volume sull’AV
Media Renderer.
SetBrightness(); l’azione consente al PoC di regolare il livello di luminosità
relativo al contenuto AV riprodotto sull’AV Media Renderer.
3.7 Architettura QoS UPnP: descrizione generale
L’architettura QoS UPnP proposta dall’UPnP Forum rappresenterà l’elemento
caratterizzante della nuova architettura integrata, in quanto consentirà ai futuri utenti
UPnP di assegnare diverse QoS ai contenuti multimediali che intendono trasferire verso
i propri Media Renderer. Questa architettura consiste di tre elementi (servizi)
rappresentati nella figura in basso: QoS Policy Holder, QoS Manager e QoS Device
Service.
95
Figura 37: Architettura QoS UPnP.
L’utente, attraverso il servizio QoS Manager, controlla l’assegnazione dei livelli di QoS
relativi ai diversi flussi dati, mediante l’azione Request QoS (1). Il servizio QoS
Manager, richiama il livello di QoS relativo ad un determinato flusso indicato con
Traffic Descriptor attraverso il servizio QoS Policy Holder (2). Il servizio restituisce
questo livello in Traffic Policy (3). Infine il servizio QoS Manager setta il valore di
QoS da assegnare al flusso dati definito in Traffic descriptor (4).
96
3.7.1 Descrizione servizi architettura QoS: QoS Policy Holder
Il servizio QoS Policy Holder permette al PoC di ottenere informazioni circa la QoS
assegnata a ciascun flusso dati che viene trasferito tra i dispositivi presenti nella rete
(AV
devices).
Questo
servizio,
identificato
come
“urn:schemas-upnp-
org:service:QosPolicyHolder:1”, è gestito e controllato dall’utente tramite le variabili di
stato:
A_ARG_TYPE_TrafficDescriptor;
include
informazioni
relative
ad
un
determinato flusso dati, come il Tspec.
A_ARG_TYPE_TrafficPolicy; questa variabile rappresenta il livello di QoS
assegnato ad un particolare flusso ed è caratterizzata dalle seguenti
informazioni:
AdmissionPolicy; varibile booleana, indica se la gestione della QoS è
abilitata oppure no.
TrafficImportanceNumber; valore compreso tra 0 e 7 ed indica il livello di
priorità assegnato. Questo valore segue lo schema delle classi di traffico
definito in 802.1D Annex G [IEEE].
UserImportanceNumber; se AdmissionPolicy è abilitato, questo intero
compreso tra 0 e 255 indica il livello di priorità assegnato dall’utente.
e l’azione:
GetTrafficPolicy(); permette al PoC di conoscere il livello di QoS assegnato ad
un
determinato
flusso
identificato
tramite
la
variabile
A_ARG_TYPE_TrafficDescriptor. L’invocazione di questa azione ritorna la
varibile A_ARG_TYPE_TrafficPolicy.
97
3.7.2 Descrizione servizi architettura QoS: QoS Manager
Questo servizio consente al PoC di configurare i vari flussi dati secondo differenti
livelli
di
QoS.
L’identificativo
di
questo
servizio
è
“urn:schemas-upnp-
org:service:QosManager:1” ed è rappresentato dalle seguenti variabili:
A_ARG_TYPE_TrafficDescriptor; questa variabile contiene informazioni
riguardanti il flusso dati, ad esempio il Tspec.
e dall’azione:
RequestTrafficQos(); l’invocazione di questa azione consente al PoC di settare
un determinato livello di QoS per un certo flusso dati, descritto mediante la
variabile A_ARG_TYPE_TrafficDescriptor.
3.7.3 Descrizione servizi architettura QoS: QoS Device Service
Questo servizio viene incluso in tutti i dispositivi che entreranno in gioco nel
trasferimento dei flussi dati, come l’AV Media Server e l’AV media Renderer. Il suo
identificativo è “urn:schemas-upnp-org:service:QosDevice:1” e ha il compito di
riservare le risorse necessarie per un determinato flusso dati, secondo la richiesta del
servizio QoS Manager. Le variabili utilizzate sono:
PathInformation; fornisce informazioni riguardanti indirizzi MAC dei
dispositivi.
QosDeviceInfo; include informazioni circa il numero di porta e il protocollo
utilizzato per uno specifico flusso.
QosDeviceState; indica il livello attuale di QoS relativo al device.
Mentre le azioni sono:
98
GetPathInformation(); ritorna la variabile PathInformation.
GetQosDeviceInfo(); ritorna la variabile QosDeviceInfo.
GetQosDeviceState(); ritorna la variabile QosDeviceState.
SetupTrafficQos(); questa azione consente all’utente di configurare il livello di
QoS
desiderato
per
il
flusso
dati
specificato
nella
variabile
A_ARG_TYPE_TrafficDescriptor.
3.8 Architettura AV/QoS UPnP: descrizione generale
Adesso che sono state descritte le due architetture, siamo in grado di fornire una prima
descrizione generale della nuova architettura integrata. Si tratta di un sistema di
distribuzione media basato su UPnP capace di supportare QoS all’interno di una rete
domestica. La nuova soluzione è caratterizzata dall’integrazione dei servizi messi a
disposizione dalle due architetture mostrate precedentemente: l’architettura AV UPnP e
l’architettura QoS UPnP. Di seguito viene mostrato lo schema rappresentativo di questa
soluzione integrata.
99
Figura 38: Architettura integrata AV/QoS UPnP.
3.9 Architettura AV/QoS UPnP: sequence diagram generale
Per descrivere il funzionamento dell’architettura AV/QoS UPnP, verrà mostrato un
semplice sequence diagram relativo alle varie fasi che caratterizzano la connettività
UPnP di questa nuova soluzione. L’esempio fa riferimento allo scenario introdotto
all’inizio di questo capitolo, che ricordiamo prevedeva:
Access Point; dispositivo router che consente la comunicazione tra i vari
devices presenti nella rete in modalità wireless, secondo lo standard 802.11g.
AV Media Server; dispositivo UPnP contenente video, foto, musica, ecc.
PoC utente 1; dispositivo portatile che include un AV Media Renderer chiamato
MediaPlayer1.
PoC utente 2; dispositivo portatile che include un AV Media Renderer chiamato
MediaPlayer2.
100
Lo scenario prevedeva l’instaurazione di una nuova connessione tra l’AV Media Server
e il MediaPlayer2 dell’utente 2, mentre il trasferimento del flusso dati dall’AV Media
Server verso il MediaPlayer1 non era ancora stato terminato. Per semplicità
mostreremo soltanto il dispositivo relativo all’utente 1, chiamandolo semplicemente
PoC, mentre supporremo che i due AV Media Renderer (MediaPlayer1 e
MediaPlayer2) siano fisicamente distinti dal PoC.
3.6.1 Fase 1: Scoperta dei device
Usando i meccanismi di ricerca UPnP, il PoC scopre gli AV device presenti nella rete e
visualizza i servizi che quest’ultimi offrono. Nel nostro esempio individua l’AV Media
Server e i due AV Media Renderer.
3.6.2 Fase 2: Visualizzazione dei contenuti AV
Attraverso l’invocazione dell’azione Browse() relativa al servizio Content Directory
(CD), il PoC è in grado di visualizzare tutti i contenuti multimediali desiderati presenti
sugli AV Media Server. Le variabili ritornate dall’azione Browse() includono:
informazioni dettagliate su ciascun contenuto AV (ad esempio il titolo, l’artista,
la durata, il tipo di file, la dimensione, il Tspec, ecc…),
il tipo di protocollo utilizzato e il formato dati supportato dall’AV Media Server
per il trasferimento verso l’AV Media Renderer.
La figura 37 mostra la sequenza di messaggi scambiati all’interno di questa fase.
101
AV Media
Server
AV Media
Renderer 1
PoC
AV Media
Renderer 2
CD: Browse()
Contenuti AV
Ora il PoC possiede tutte le
informazioni circa i contenuti
AV, la lista dei
protocolli/formato dati
supportati dal Server e il
Tspec relativo al flusso dati
Figura 39: Fase 2-Visualizzazione dei contenuti AV.
3.6.3 Fase 3: Visualizzazione protocolli/formato dati supportati
Attraverso l’uso dell’azione GetProtocolInfo() relativa al servizio Connection Manager
(CM), il PoC visualizza la lista completa dei protocolli e del formato dati supportato
dall’AV Media Renderer per il trasferimento dei dati dall’AV Media Server.
102
AV Media
Server
AV Media
Renderer 1
PoC
AV Media
Renderer 2
CM: GetProtocolInfo()
CM: GetProtocolInfo()
return
Ora il PoC
possiede la lista
dei
protocolli/formato
dati supportati dai
Renderer
return
Figura 40: Fase 3-Visualizzazione protocolli/formato dati supportati.
3.6.4 Fase 4: Matching protocolli/formato dati supportati
La lista dei protocolli/formato dati supportati dall’AV Media Server viene confrontata
con la lista dei protocolli/formato supportati dall’AV Media Renderer. Mediante questo
algoritmo il PoC seleziona la coppia protocollo/formato dati supportati da entrambi i
dispositivi (AV Media Server e AV Media Renderer). L’algoritmo di matching
coinvolge, ovviamente, entrambi gli AV Media Renderer. Al termine della fase 4 il
PoC ha selezionato una coppia protocollo/formato dati valida per la connessione tra AV
Media Server e AV Media Renderer 1 e un’altra coppia protocollo/formato dati valida
per la connessione tra AV Media Server e AV Media Renderer 2.
103
AV Media
Server
AV Media
Renderer 1
PoC
Algoritmo di
matching
protocolli /formato
dati supportati
AV Media
Renderer 2
Selezione
protocolli/formato
dati supportati dai
dispositivi
Figura 41: Fase 4-Matching protocolli/formato dati supportati.
3.6.5 Fase 5: Configurazione dispositivi AV
L’azione PrepareForConnection() del servizio Connection Manager (CM) informa
l’AV Media Server e gli AV Media Renderer che sta avendo luogo una connessione tra
loro, secondo il protocollo e il formato dati precedentemente selezionato dal PoC. In
funzione del protocollo selezionato, i dispositivi AV ritorneranno la variabile
InstanceID relativa al servizio AV Transport (AVT). Questa InstanceID viene usata in
unione al servizio AVT per controllare il flusso dei dati (ad esempio per il Play, Stop,
Pause, ecc…). In aggiunta, gli AV Media Renderer possono ritornare una InstanceID
relativa al servizio Rendering Control (RC) per consentire al PoC di gestire alcune
variabili come la luminosità, il contrasto, la temperatura di colore, ecc.
104
AV Media
Server
AV Media
Renderer 1
PoC
AV Media
Renderer 2
CM: PrepareForConnection()
AVT: InstanceID1
AVT: InstanceID1
Instaurazione
connessione tra
AV Media Server
e AV Media
Renderer1
CM: PrepareForConnection()
AVT: InstanceID2
AVT: InstanceID2
Instaurazione
connessione tra
AV Media Server
e AV Media
Renderer2
Figura 42: Fase 5-Configurazione dispositivi AV.
3.6.6 Fase 6: Selezione contenuti AV
Attraverso l’azione SetAVTransportURI() inclusa nel servizio AV Transport (AVT), il
PoC indica ai dispositivi l’URI relativo al contenuto multimediale da trasferire verso gli
AV Media Renderer. A questo punto, sia l’AV Media Server che gli AV Media
Renderer conoscono i contenuti AV che verranno trasferiti durante la fase di rendering.
105
AV Media
Server
AV Media
Renderer 1
PoC
AV Media
Renderer 2
AVT: SetAVTransportURI()
Selezione dei
contenuti AV
da trasferire
return
return
AVT: SetAVTransportURI()
return
Figura 42: Fase 6-Selezione dei contenuti AV.
3.6.7 Fase 7: Rendering control
Supponiamo che il PoC abbia scelto di riprodurre il file desiderato sull’AV Media
Renderer 1. Allora, attraverso il servizio AV Transport (AVT) e Rendering Control
(RC), il PoC può invocare una alla volta tutte azioni che consentono il controllo della
riproduzione del contenuto multimediale presso l’AV Media Renderer selezionato
(come ad esempio Play, Stop, Pause, ecc…).
106
AV Media
Server
AV Media
Renderer 1
PoC
AVT: Play()
return
AV Media
Renderer 2
AVT: Play()
return
Flusso dati 1 (stream)
RCS: SetVolume()
Riproduzione dei
contenuti AV
trasferiti
return
Figura 43: Fase 7-Rendering control.
3.6.8 Fase 8: Inizio contese
Immaginiamo che ad un certo punto della fase di rendering control avviata dal PoC
sull’AV Media renderer 1, avvenga una significativa e crescente degradazione della
qualità percepita dall’utente. Il flusso dati 1 relativo alla connessione tra AV Media
Server e AV Media renderer 1 subisce enormi ritardi di trasferimento a causa della
improvvisa comparsa di una nuova connessione (flusso dati 2) avviata dall’utente 2 tra
l’AV Media Server e l’AV Media Renderer 2, come mostrato in figura. Questa fase
termina con l’abbattimento della connessione relativa al flusso dati 1, dovuta ai forti
ritardi di trasferimento.
107
AV Media
Server
AV Media
Renderer 1
PoC
AVT: Play()
AV Media
Renderer 2
AVT: Play()
return
return
Degradazione
qualità percepita
sul flusso dati 1
Flusso dati 1 (stream)
Flusso dati 2 (stream)
Chiusura della
connessione
Figura 44: Fase 8-Inizio contese.
3.6.9 Fase 9: Richiesta QoS
In base alle nuove capacità offerte dalla nuova architettura integrata, l’utente decide di
conferire un livello di priorità maggiore al flusso dati relativo alla propria connessione
(flusso dati 1). Per far ciò invoca l’azione RequestTrafficQoS() relativa al servizio QoS
Manager
(QM)
per
il
flusso
dati
specificato
nella
variabile
A_ARG_TYPE_TrafficDescriptor. A sua volta, il servizio QoS Manager invoca
l’azione GetTrafficPolicy() del servizio QoS Policy Holder (QPH) per conoscere il
108
livello di QoS relativo al flusso dati specificato. Il valore attuale del livello di QoS è
contenuto nella variabile A_ARG_TYPE_TrafficPolicy.
PoC
QoS
Manager
QoS Policy
Holder
QM: RequestTrafficQoS()
QPH: GetTrafficPolicy()
A ARG TYPE TrafficPolicy
QD: GetPathInformation()
PathInformation
QD: GetQoSDeviceInfo()
DeviceInfo
QD: GetQoSState()
QoSDeviceState
QD: SetupTrafficQoS()
return
return
109
AV Media
Renderer 1
Figura 45: Fase 9-Richiesta QoS.
Fase : Chiusura della connessione
Quando la sessione è terminata e i dispositivi non sono più necessari, viene invocata
l’azione ConnectionComplete() relativa al servizio Connection Manager sull’AV Media
Server e sull’AV Media Renderer rispettivamente.
AV Media
Server
AV Media
Renderer 1
PoC
CM: TransferComplete()
return
CM: TransferComplete()
return
Chiusura
della
connessione
Figura 45: Fase 10-Chiusura della connessione.
110
AV Media
Renderer 2
111
112
113
114
Bibliografia
“System software for Ubiquitous Computing” Kindberg and Fox IEEE
computer society press 2002.
“Overview of Service Discovery Protocols” Antti Huopaniemi Dept. of
Computer Science University of Helsinki, Finland.
“QoS awareness support in Web-Service semantics” Dimitrios T. Tsesmetzis,
Ioanna G. Roussaki, Ioannis V. Papaioannou, Miltiades E. Anagnostou School
of Electrical and Computer Engineering, National Technical University of
Athens, Greece.
“Discovering device in Home Networks” IBM Corporation 1999.
“Service Discovery for M-Commerce Applications” Chakraborty, Perich,
Avancha, Joshi Department of Computer Science and Electrical Engineering,
University of Maryland 2001.
“Service Discovery in Pervasive Computing Environments” Feng Zhu and Matt
W. Mutka Michigan State University Lionel M. Ni Hong Kong University of
Science and Technology.
“Classification of Service Discovery in Pervasive Computing Environments”
Feng Zhu, Matt Mutka, and Lionel Ni,
Lansing.
115
Michigan State University, East
“ICrafter: A Service Framework for Ubiquitous Computing Environments”
Shankar R. Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan, and Terry
Winograd, Stanford University.
“Toward Distributed Service Discovery in Pervasive Computing Environments”
Dipanjan Chakraborty, Anupam Joshi, Yelena Yesha, and Tim Finin Senior
Member IEEE.
“A taxonomy for resource discovery” Koen Vanthournout, Geert Deconinck
and Ronnie Belmans.
“A Service Discovery Model for Wireless and Mobile Terminals in IPv6”
Bilhanan Silverajan, Jaakko Kalliosalo, Jarmo Harju Dept. of Information
Technology, Tampere University of Technology.
“A comparison of Service Discovery Protocols and implementation of the
Service Location Protocol” Christian Bettstetter, Christoph Renner Technische
Universität München (TUM), Institute of Communication Networks.
“Standards for Service Discovery and Delivery” Sumi Helal University of
Florida, USA.
“What is Service-Oriented Architecture?” Hao He 2003.
“UPnP™
Device
Architecture
Version
1.0”
08
Jun
2000
© 1999-
2000 Contributing Members of the UPnP™ Forum.
“Universal Plug and Play Machine Models” U.Glässer, Y.Gurevich, M.Veanes.
“Home Networking with Universal Plug and Play” Brent A. Miller, Toby Nixon,
Charlie Tai, Mark D. Wood.
116
“UPNP Service Discovery for heterogeneous network” José M. Sanchez
Santana, Marina Petrova, Petri Mähönen RWTH Aachen University,
Department of Wireless Networks.
“Understanding Universal Plug and Play: a white paper” Microsoft®
Corporation http://www.upnp.org.
Documenti
“TLAB CCC-arch-24-10-2006” Telecom Italia Group.
“TLAB CCC-prototyping-24-10-2006” Telecom Italia Group.
“Nuove tecnologie per l’accesso a edifici intelligenti” Iacopo Iacopini Tesi di
Laurea 2003.
Link
www.upnp.org
www.ieee.org
www.dlna.org
www.umatoday.com
www.wikipedia.org
117
www.intel.com
www.twonkyvision.de
www.microsoft.com
www.rudeo.com
118