Integrazione di uno smartphone con una stazione - e-Lite

Transcript

POLITECNICO DI TORINO
III Facoltà di Ingegneria dell’informazione
Laurea Specialistica in Ingegneria Telematica
Tesi di Laurea Specialistica
Integrazione di uno smartphone con
una stazione multimediale attraverso
una rete Bluetooth
Realizzazione di un client VoIP per terminale mobile
Relatore:
Dott. Fulvio Corno
Candidato:
Christian G IORDANO
Supervisore Aziendale
Dott. Ferdinando Ricchiuti
Aprile 2007
Sommario
Il lavoro che viene presentato si pone l’obiettivo principale di mostrare in maniera dettagliata l’attività svolta durante il periodo di tesi presso il CSP - Innovazione nelle ICT, ed
approfondirne gli aspetti teorici che supportano l’attività svolta.
Il progetto BlueVoice realizzato si compone di un’applicazione per smartphone che
simula una chiamata telefonica e, mediante una connessione Bluetooth, veicola il traffico
voce e le opportune informazioni di segnalazione ad una stazione multimediale, ovvero
un PC su cui è presente un software VoIP che da un lato agisce da server Bluetooth per
accettare le richieste dei cellulari, e dall’altro è il punto terminale di una chiamata VoIP.
In questo modo è possibile sfruttare le potenzialità e i vantaggi offerti dai servizi di voce
su Internet, pur utilizzando uno strumento comune come un telefono cellulare.
Lo studio effettuato è partito, negli scopi iniziali, con l’obiettivo e l’approccio di un
analisi tecnica sulle possibilità di realizzazione dell’idea e si è conclusa con un prototipo
funzionale, nonostante qualche limite che non ne pregiudicano comunque la fattibilità.
Nel presente documento saranno perciò descritti gli obiettivi, le scelte progettuali e
l’implementazione realizzata durante il periodo di ricerca. Al termine sarà presentata
una valutazione finale d’insieme del lavoro svolto e verranno riportate le conclusioni con
relative considerazioni sugli utilizzi futuri del progetto.
I
Ringraziamenti
Ringrazio il Politecnico di Torino per la formazione accademica che ho ricevuto, l’istituto di ricerca CSP, il mio relatore Fulvio Corno, ed il mio tutore aziendale Ferdinando
Ricchiuti, per l’aiuto e la guida che mi hanno fornito durante lo sviluppo della mia tesi.
Un sentito ringraziamento va inoltre ai miei genitori, che, con il loro incrollabile
sostegno morale ed economico, mi hanno permesso di raggiungere questo traguardo.
II
Indice
Sommario
I
Ringraziamenti
II
1
Introduzione
1
2
Istituto di ricerca CSP
5
2.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Cos’è il CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Compagine societaria . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4
Organizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.1
Innovazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.2
Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.3
Reti Sociali . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4.4
Tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.5
Attività . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.6
Ubicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3
Piattaforma di Sviluppo
12
3.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2
Java vs Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2.1
Java 2 Micro Edition . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2.2
Java rincorre Symbian . . . . . . . . . . . . . . . . . . . . . . .
19
III
3.3
3.4
3.5
4
21
3.3.1
Symbian C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3.2
Architettura del Sistema Operativo . . . . . . . . . . . . . . . . .
24
3.3.3
Serie 60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Programmare con Symbian . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.1
Processo di sviluppo . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.2
Applicazioni Symbian . . . . . . . . . . . . . . . . . . . . . . .
41
3.4.3
Convenzione dei nomi . . . . . . . . . . . . . . . . . . . . . . .
46
3.4.4
Stringhe e descrittori . . . . . . . . . . . . . . . . . . . . . . . .
48
3.4.5
Gestione delle eccezioni . . . . . . . . . . . . . . . . . . . . . .
49
3.4.6
Gestione degli eventi asincroni . . . . . . . . . . . . . . . . . . .
52
Scelte implementative . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Tecnologie di comunicazione
56
4.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.2
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.2.1
Topologia della rete . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.2.2
Comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2.3
Pila Protocollare . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.2.4
Librerie BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.3.1
Differenze con la telefonia tradizionale . . . . . . . . . . . . . .
80
4.3.2
Qualità di servizio . . . . . . . . . . . . . . . . . . . . . . . . .
81
4.3.3
Protocolli VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.3.4
OPAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.3
5
Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analisi e design architetturale
89
5.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.2
Contesto applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.2.1
91
Scenario applicativo per cellulari . . . . . . . . . . . . . . . . . .
IV
5.3
5.4
5.5
6
93
5.3.1
Modalità Walkie-Talkie . . . . . . . . . . . . . . . . . . . . . . .
95
Visione generale del progetto BlueVoice . . . . . . . . . . . . . . . . . .
96
5.4.1
Applicazione lato client . . . . . . . . . . . . . . . . . . . . . .
96
5.4.2
Applicazione lato server . . . . . . . . . . . . . . . . . . . . . . 101
Requisiti progettuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.1
Ritardi e jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.2
Vincoli per la connessione Bluetooth . . . . . . . . . . . . . . . 107
5.5.3
Aspetti di usabilità . . . . . . . . . . . . . . . . . . . . . . . . . 108
Implementazione del progetto
110
6.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2
Architettura del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.3
7
Specifiche del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1
Classi client-side . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2.2
Struttura server-side . . . . . . . . . . . . . . . . . . . . . . . . 121
Analisi di una chiamata . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.3.1
Inquiry e connessione Bluetooth . . . . . . . . . . . . . . . . . . 125
6.3.2
Streaming della voce . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3.3
Protocollo di segnalazione . . . . . . . . . . . . . . . . . . . . . 131
6.3.4
Gestione del registro delle chiamate . . . . . . . . . . . . . . . . 133
Valutazioni finali
135
7.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.2
Considerazioni generali . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.3
Limiti tecnologici e problemi . . . . . . . . . . . . . . . . . . . . . . . . 136
7.3.1
Full duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.3.2
Qualità dell’audio . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.3.3
Virtualizzazione della scheda audio . . . . . . . . . . . . . . . . 139
7.3.4
Priorità delle chiamate . . . . . . . . . . . . . . . . . . . . . . . 140
7.3.5
Limitata portabilità . . . . . . . . . . . . . . . . . . . . . . . . . 141
V
8
Conclusioni
142
Bibliografia
145
Sitografia
146
VI
Elenco delle tabelle
3.1
Tipi fondamentali in Symbian OS . . . . . . . . . . . . . . . . . . . . .
5.1
Tabella di confronto ritardi tra standard telefonici e applicativi VoIP . . . 107
VII
47
Elenco delle figure
2.1
Sede CSP all’Environment Park . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Sede CSP in Villa Gualino . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1
Configurazioni e profili di J2ME . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Architettura di Symbian v8.0a OS . . . . . . . . . . . . . . . . . . . . .
27
3.3
Symbian OS: La Serie 60, UIQ e la Serie 80 . . . . . . . . . . . . . . . .
30
3.4
Generazione dei file di progetto specifici mediante file generici Symbian .
38
3.5
Framework applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.6
Archiutettura applicativa e MVC . . . . . . . . . . . . . . . . . . . . . .
46
4.1
Due piconet disposte a formare una scatternet . . . . . . . . . . . . . . .
59
4.2
Stati di un dispositivo Bluetooth . . . . . . . . . . . . . . . . . . . . . .
60
4.3
Stack protocollare Bluetooth . . . . . . . . . . . . . . . . . . . . . . . .
65
4.4
Emulazione di porte seriali . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.5
Interazione nel protocollo SDP . . . . . . . . . . . . . . . . . . . . . . .
71
4.6
Visione generale di BlueZ . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.7
Diagramma dei principali moduli di OPAL . . . . . . . . . . . . . . . . .
88
5.1
Scenario di utilizzo di BlueVoice . . . . . . . . . . . . . . . . . . . . . .
95
5.2
Architettura generale di client e server BlueVoice . . . . . . . . . . . . .
97
5.3
Schema logico della funzionalità full-duplex . . . . . . . . . . . . . . . . 100
5.4
Diagramma di flusso del ciclo di vita di una chiamata . . . . . . . . . . . 102
5.5
Schema di chiamata BlueVoice-telefono VoIP . . . . . . . . . . . . . . . 103
5.6
Rappresentazione della tratta totale tra utenti finali . . . . . . . . . . . . 105
6.1
Diagramma UML dell’applicazione BlueVoice . . . . . . . . . . . . . . 112
VIII
6.2
Diagramma UML della pubblicazione servizi a lato server e ricerca e
connessione di dispositivi Bluetooth a lato client . . . . . . . . . . . . . . 117
6.3
Rappresentazione grafica della struct TDeviceData che definisce un dispositivo remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.4
Fase 1: Ricerca dispositivi e servizi ; Fase 2: sistema connesso . . . . . . 126
6.5
Rappresentazione logica del buffer circolare e relative caratteristiche . . . 128
6.6
Evoluzione temporale del buffer circolare . . . . . . . . . . . . . . . . . 130
6.7
Ritardi minimo e massimo introdotti dal buffer (rappresentazione fisica) . 131
IX
Capitolo 1
Introduzione
L’attuale sviluppo delle applicazioni per la telefonia su Internet è di notevole interesse
per i principali sviluppatori di software, in quanto le attuali tecnologie di comunicazione
telefonica permettono di avere costi irrisori o addirittura nulli per l’utente finale e lasciano
perciò presupporre un mercato promettente ed in continua crescita ed evoluzione.
Recentemente infatti si è assistito ad un rapido sviluppo di mercato della telefonia
VoIP e dei servizi ad essa collegati, reso possibile dalla crescente diffusione delle connessioni Internet veloci, dette anche a banda larga, con abbonati che inviano e ricevono
chiamate in modo del tutto analogo a quello con cui il servizio veniva erogato attraverso
la vecchia rete analogica commutata. Allo stato attuale, la telefonia VoIP è destinata ad
affiancarsi a quella analogica tradizionale piuttosto che a rimpiazzarla, nonostante alcune
delle limitazioni attuali quali, ad esempio, l’impossibilità di instradare automaticamente
le chiamate di emergenza.
Bisogna aggiungere che la realizzazione di client VoIP che sfruttano una comunicazione wireless è di estrema attualità in quanto tra gli sviluppi tecnologici dello standard
Bluetooth figurano in prima linea i servizi di voce sul protocollo IP. Oggi tale tecnologia
viene già impiegata nei microfoni usati come estensioni wireless dei sistemi audio dei
cellulari e dei PC e, dato l’incremento in popolarità e nell’uso di VoIP, Bluetooth costituisce una parte fondamentale dello sviluppo di tipo telefonico volto all’utilizzo dei telefoni
cordless e cellulari per effettuare una chiamata VoIP.
1
1 – Introduzione
Ad oggi esiste un’innumerevole quantità di offerte per utilizzare in modo semplice la
telefonia su Internet, ed i prodotti spaziano dei cosiddetti kit VoIP Bluetooth ai telefoni
VoIP. Il kit comprende un auricolare o headset ed un adattatore USB per PC, entrambi
Bluetooth, che permette di collegare i due componenti in modalità senza fili, e vede tra i
principali produttori nomi come Sony Ericsson e Motorola. Di numero più ristretto sono
i telefoni VoIP, cioè soluzioni ad-hoc che integrano in genere tutte le funzioni classiche di
un telefono e che vengono collegati al PC tipicamente mediante la presa USB o grazie ad
una connessione Bluetooth (attualmente solo il ClearSky della TRENDNET).
L’idea del progetto nasce da un’esigenza per l’utente di utilizzare i due servizi telefonici, quello veicolato sulla rete Internet e quello che sfrutta l’infrastruttura telefonica
GSM o UMTS, servendosi del medesimo apparecchio telefonico, in modo da facilitare e
rendere accessibile a chiunque le potenzialità della nascente tecnologia VoIP. La parola
d’ordine che sta alla base del lavoro e che ne permea tutta la realizzazione è quindi la “trasparenza”, poiché idealmente il fruitore del servizio telefonico non è tenuto a conoscere i
dettagli di basso livello del mezzo usato per trasmettere la propria voce. L’indistinguibilità
tra le due modalità ne accresce indubbiamente l’accessibilità in quanto espande il range
di utenti oltre ai soli esperti dell’ambito, e risulta appetibile perché permette di abbassare
considerevolmente i costi.
Il progetto ha portato alla realizzazione di un’applicazione chiamata BlueVoice ed ha
come scopo principale la verifica di fattibilità di questa particolare ipotesi di utilizzo del
telefono cellulare all’interno di uno scenario che vede il suddetto come punto finale di
una chiamata VoIP inoltrata da una stazione fissa al dispositivo mediante una connessione
wireless Bluetooth. Dall’esito di questo studio si vuole fornire l’implementazione di un
prototipo che ne dimostri l’attuabilità e gli eventuali limiti, in modo da comprendere quali
punti necessitino maggiormente di migliorie in un eventuale passo successivo del lavoro.
Il periodo di tesi comprende, in una fase propedeutica, lo studio preventivo dei meccanismi di funzionamento di Bluetooth, in quanto mezzo scelto per la comunicazione e
quindi per l’integrazione del dispositivo mobile con la stazione fissa, e l’analisi delle piattaforme più adatte per realizzare un prodotto rispondente alle specifiche iniziali e coerente
2
1 – Introduzione
con gli scopi del progetto. In particolare la valutazione della piattaforma è stato un processo di fondamentale importanza per l’usabilità e l’efficienza del software finale, ed ha
accompagnato una significativa parte della durata della tesi.
Al termine di questa fase ha avuto luogo quella implementativa che ha portato alla
progettazione e realizzazione del sistema in grado di integrare il telefono e la stazione
multimediale. Essendo un lavoro di ricerca non è possibile prevedere a priori l’attuabilità concreta dell’idea iniziale proposta, ed è per questo che il processo di sviluppo è
proceduto per passi, in modo da assicurare la fattibilità di ogni tappa intermedia.
Si è pertanto realizzato il codice che implementa il client posto sul telefono cellulare. Esso deve essere in grado di ricercare dispositivi Bluetooth nel raggio di ricerca e
stabilire una connessione con uno di essi, registrare la voce dell’utente ed inviarla all’altra stazione in streaming, e contemporaneamente deve ricevere i pacchetti voce dall’altro
dispositivo per poterli riprodurre e farli ascoltare all’utente. Ovviamente tutte queste operazioni devono essere gestite e completate da un protocollo di segnalazione che fornisca
le necessarie primitive di controllo per inoltrare, accettare, rifiutare e terminare una chiamata voce, esattamente come succede nella telefonia classica a cui si è abituati. Come
già affermato la totale trasparenza rispetto al normale servizio telefonico offerto da GSM
vuole essere uno degli intenti principali dell’applicazione, in modo da rendere la fruizione
del software semplice ed immediata.
Una prima tappa a cui si è giunti è un’applicazione che permette di stabilire una chiamata voce tra due telefoni cellulari usando la connessione Bluetooth. La modalità di
utilizzo è molto simile a quella del Walkie-Talkie, con la differenza che non si ha un meccanismo Push-to-Talk, cioè un metodo di comunicazione lungo linee half-duplex1 che usa
un sistema in grado di commutare dalla modalità di trasmissione a quella di ricezione,
bensı̀ un meccanismo del tutto simile ad una telefonata tradizionale. Quest’ultima non
avrebbe quindi costi di traffico ma la portata decisamente ridotta, tipica degli standard
wireless per reti personali come Bluetooth.
1
L’half-duplex è una modalità di invio e ricezione di informazioni digitali in cui è possibile trasmettere
in entrambe le direzioni, ma non contemporaneamente.
3
1 – Introduzione
Questo ostacolo è superato nella tappa successiva dell’implementazione, mediante
l’interazione con la stazione multimediale, ovvero una macchina su cui è attivo un programma per chiamate VoIP, che porta al compimento conclusivo dell’applicazione. In
questo modo si ha il congiungimento del terminale mobile con la rete Internet e si “allunga” la tratta end-to-end in modo da risultare tra i due terminali mobili connessi ai PC,
piuttosto che tra i due PC.
In definitiva, nei disegni di progetto, il sistema permetterebbe di utilizzare un cosiddetto “telefono intelligente”, ovvero uno smartphone come terminale per chiamate voce,
sia in ingresso che in uscita, verso la stazione multimediale. Le chiamate vengono poi
inoltrate dalla stazione multimediale attraverso la rete Internet, facendo uso dei diversi
protocolli standard per la telefonia su IP (quali ad esempio SIP e H.323). Un sistema
di questo tipo è molto utile per usare uno strumento classico come il telefonino per poter comunicare attraverso sistemi innovativi e più economici disponibili grazie alla banda
larga.
4
Capitolo 2
Istituto di ricerca CSP
2.1
Introduzione
Il periodo di tesi che ha visto la progettazione e la realizzazione del lavoro presentato precedentemente e trattato nel dettaglio nei capitoli successivi, ha avuto luogo presso il CSP
- Innovazione nelle ICT, la struttura di Innovazione e ricerca della pubblica amministrazione piemontese nel campo delle tecnologie della Società dell’Informazione. In questo
capitolo viene fornita una rapida presentazione dell’istituto, della sua organizzazione interna e della struttura dei vari laboratori. Per ulteriori approfondimenti si rimanda al sito
ufficiale [1].
2.2
Cos’è il CSP
Avviato come una piccola struttura attiva all’interno dei locali storici del CSI Piemonte, è
cresciuto in modo significativo e oggi occupa stabilmente 40 persone in due diverse sedi.
CSP eroga inoltre ogni anno tra le 25 e le 30 borse di studio in collaborazione con gli
Atenei locali, ospitando più di 20 stage e tesi, a cui si aggiungono oltre 40 collaborazioni
professionali per lo svolgimento delle attività dei diversi settori.
CSP occupa ogni anno oltre 140 persone in maggioranza giovani ricercatori attivi nei
5
2 – Istituto di ricerca CSP
progetti di ricerca sviluppati in cooperazione con le Università e nei programmi di innovazione per i propri clienti. Ha annualmente oltre 70 contratti di consulenza e sperimentazione per oltre 25 soggetti pubblici e privati. Dal 1998 ad oggi il CSP ha sviluppato la
nuova missione affidata dai soci in seguito alla conclusione dell’esperienza di CSP quale
Centro Supercalcolo del Piemonte.
Il valore dell’operatività è cresciuto costantemente nel corso degli ultimi anni, attestandosi, nel corso del 2006, a oltre 4,5 milioni di euro, risultato di circa 100 diverse
attività svolte per più di 35 clienti, con più di 50 accordi di collaborazione attivi con
Atenei, Centri di ricerca, Enti pubblici.
CSP è Laboratorio di ricerca MIUR, certificato UNI EN ISO 9001:2000, e fa parte
di numerose associazioni e consorzi tra cui il Consorzio World Wide Web (W3C), e il
comitato del consorzio europeo Galileo.
2.3
Compagine societaria
I soci di CSP sono:
• Politecnico di Torino
• Università degli Studi di Torino
• Comune di Torino
• CSI-Piemonte
• Unione Industriale di Torino
• Confindustria Piemonte
• Iride Energia S.p.A.
CSP - Innovazione nelle ICT Società consortile a responsabilità limitata in forma
abbreviata CSP s.c. a r.l. le cui caratteristiche sono di seguito elencate:
6
Natura giuridica : Società Consortile a responsabilità limitata
Capitale sociale : e 52.000,00
Data di costituzione : 02/03/1989
Data di inizio attività : 27/05/1991
Durata : 31/12/2050
2.4
Organizzazione
CSP è organizzato in base a competenze specifiche e gruppi di lavoro che contemplano
alcuni ambiti di attività principali, all’interno dei quali si articola l’operatività specifica di
aree, gruppi e laboratori. La dimensione collegiale del lavoro, è integrata da partnership
con soggetti pubblici e privati e da una forte sinergia con il mondo accademico a livello
locale, nazionale e internazionale. Al fianco della Direzione generale che ha funzioni
di gestione e indirizzo sull’attività complessiva di CSP operano le aree descritte nelle
seguenti sezioni.
2.4.1
Innovazione
Idea e propone, coordina e gestisce programmi e progetti di innovazione a livello locale,
nazionale e internazionale, promuovendo la collaborazione trasversale di aree e direzioni.
A ciò si aggiunge il coordinamento e la gestione delle attività di marketing rivolte sia al
settore pubblico sia privato, le attività di comunicazione interna ed esterna, lo sviluppo di
progetti web e di gestione delle communities legate ai progetti, lo studio e il benchmarking
dello sviluppo della Società dell’Informazione a livello locale e internazionale.
2.4.2
Progettazione
Si occupa di proporre e coordinare progetti di carattere strettamente tecnologico verso
i soggetti locali, nazionali e internazionali del settore pubblico e privato. Il supporto
7
operativo alle altre aree di CSP viene attuato utilizzando le competenze che derivano dalle
attività di ricerca dei laboratori, coordinando e gestendo la fase realizzativa dei progetti ed
esportando le stesse competenze per la gestione delle infrastrutture tecnologiche di CSP.
Tra gli obiettivi, l’incremento dei progetti verso il settore privato, verso i prospect e
il rafforzamento dei rapporti con le public utilities, con competenze che spaziano dalla
gestione di Infrastrutture e tecnologie, all’internetWorking, al testing di piattaforme tecnologiche innovative, alla gestione sistemistica alla sperimentazione su Grid e architetture
distribuite.
2.4.3
Reti Sociali
Concentra la propria attività sulla sperimentazione e progettazione nell’ambito della condivisione della conoscenza, a cui si aggiungono e-business, analisi e monitoraggio dello
sviluppo della Società dell’Informazione e competenze sul fronte dei contenuti multimediali per la banda larga.
Tra gli ambiti di specializzazione spiccano lo sviluppo di modelli di formazione a
distanza attraverso la gestione di comunità di conoscenza e l’analisi di piattaforme tecnologiche per la gestione del lavoro cooperativo e dell’e-learning, lo sviluppo di progetti
legati all’universo del web 2.0, e la loro sperimentazione applicativa per lo sviluppo locale
e il mondo della scuola e dell’accademia.
I laboratori che svolgono la propria attività in cooperazione con l’Università di Torino
sono:
1. Keilab - Knowledge exchange laboratory
2. SmartLab - Social Media Application Research Laboratory
2.4.4
Tecnologie
Indaga e studia le tecnologie di base, infrastrutturali e applicative, e i nuovi processi resi
percorribili dal loro utilizzo. La Direzione si configura come un incubatore di attività
8
per “l’applicazione della ricerca” nel senso stretto di luogo in cui, attraverso laboratori
tematici, si apprendono i fondamenti scientifici e tecnici delle tecnologie emergenti e si
sviluppano attività pratiche calandole in scenari reali costruiti su “case study” attuali e
ipotizzati per il prossimo futuro. La Direzione è strutturata sulla base di quattro laboratori
di ricerca permanenti:
1. DTTLab - Digital Terrestrial Television Laboratory
2. SecureLab - ICT Security Laboratory
3. InLab - Integrated Networks Laboratory
4. W3Lab - World Wide Web Laboratory
2.5
Attività
CSP agisce a livello locale, nazionale e internazionale costruendo attività di ricerca applicata, accordi e progetti di cooperazione con enti pubblici, amministrazioni locali e grandi
imprese private.
La dimensione locale di CSP è caratterizzata da attività di sperimentazione e trasferimento tecnologico di soluzioni innovative e di sviluppo di progetti nell’ambito di programmi pluriennali dal forte contenuto sperimentale. Si tratta di attività svolte nel quadro
di Convenzioni e accordi pluriennali firmate con la Pubblica Amministrazione locale Regione, Province e Comuni -.
A livello nazionale CSP svolge attività di trasferimento tecnologico e sperimentazione di soluzioni innovative nell’ambito di convenzioni firmate con la Pubblica Amministrazione su tutto il territorio nazionale con progetti che spaziano da partner Regionali, a
partecipate ai Ministeri.
Sul piano internazionale, CSP partecipa a progetti co-finanziati dalla Commissione Europea e ad associazioni e gruppi di lavoro per la diffusione dell’innovazione e lo
sviluppo di una pubblica amministrazione su base europea.
9
In rappresentanza della Regione Piemonte, CSP fa parte di ERISA, la rete delle Regioni Europee Innovative, e partecipa al progetto IANIS+, la principale rete europea di
regioni impegnate nell’ambito della diffusione della Società dell’Informazione.
2.6
Ubicazione
Sede Legale e Operativa Environment Park Laboratori A1 via Livorno, 60 10144 Torino
Tel +39 0114815111 Fax +39 0114815001 E-mail: [email protected]
Seconda Sede Operativa Villa Gualino Viale Settimio Severo, 63 10133 Torino
Tel +39 0114815111 Fax +39 0114815001 E-mail: [email protected]
10
Figura 2.1.
Sede CSP all’Environment Park
Figura 2.2.
Sede CSP in Villa Gualino
11
Capitolo 3
Piattaforma di Sviluppo
3.1
Introduzione
Una volta stabilite le specifiche e gli obiettivi teorici che vogliono essere raggiunti dal
progetto, ci si è subito dovuto scontrare con una serie di problemi legati alla realizzazione
pratica e all’implementazione del codice relativo.
Innanzitutto una buona parte del periodo di tesi è stata dedicata allo studio delle due
principali tecnologie che permettono di realizzare il software in questione, cioè Java 2
Micro Edition e il sistema operativo Symbian. Questo indubbiamente ha rappresentato
uno degli scogli più difficili da superare poiché entrambe le piattaforme presentano vantaggi e svantaggi su aspetti diversi, trasformando cosı̀ il problema nella ricerca del giusto
compromesso tra efficienza e portabilità del software.
Le sezioni successive sono una descrizione dettagliata di quanto appreso in questa fase
della tesi, una spiegazione delle potenzialità e dei limiti di entrambi questi due approcci
che caratterizzano il mondo dello sviluppo delle applicazioni per cellulari. A queste informazioni si è giunti, oltre che mediante un approfondito studio della documentazione in
merito a tali tecnologie, anche attraverso una fase di test iniziali di confronto che hanno
poi determinato la scelta definitiva.
12
3 – Piattaforma di Sviluppo
3.2
Java vs Symbian
Lo sviluppo di applicazioni su dispositivi wireless, come visto nel paragrafo precedente,
può essere effettuato utilizzando diverse tecnologie. Per fornitori e programmatori è costante il confronto con le applicazioni basate su Symbian e quelle J2ME. A grandi linee si
può dire che Symbian è un potente sistema operativo utilizzato da diversi telefonini dell’ultima generazione, mentre J2ME (Java 2 Micro Edition) non è altro che una versione
ridotta del Java 2 Standard Edition.
Sviluppare applicazioni Symbian equivale a produrre software dall’elevata potenzialità ma solo per dispositivi con sistemi operativi Symbian, mentre, sviluppare applicazioni
J2ME, equivale a produrre software certamente meno potente ma in grado di funzionare
su tutti i dispositivi dove risiede una particolare Java Virtual Machine.
Senza entrare troppo nel dettaglio si osserva che con Symbian si punta molto su
potenza e flessibilità, mentre con J2ME si punta su portabilità e compatibilità.
Generalmente su tutti i telefonini Symbian è presente una particolare Java Virtual
Machine, ma non tutti i dispositivi che presentano al loro interno una Java Virtual Machine
sono dotati di sistema operativo Symbian.
Prima di entrare nell’analisi delle differenze tra le due tecnologie, verrà data una descrizione delle caratteristiche strutturali di J2ME, soffermandosi in particolar modo sull’evoluzione attraverso la quale tale piattaforma si è avvicinata di molto alle potenzialità
di Symbian. Di seguito sarà affrontata una completa trattazione di Symbian, con particolare riguardo alla piattaforma e a tutta una serie di funzionalità utilizzate nel lavoro
svolto.
3.2.1
Java 2 Micro Edition
Java Micro Edition (noto anche come Java ME o J2ME), è un runtime e una collezione
di API per lo sviluppo di software dedicato a dispositivi a risorse limitate come PDA,
telefoni cellulari e simili.
J2ME è la tecnologia più diffusa per lo sviluppo di giochi e utilities per i cellulari.
13
Come le altre edizioni di Java, J2ME è una piattaforma portabile. Il suo funzionamento
può essere emulato con un personal computer, cosa che semplifica l’attività di sviluppo e
di testing.
La Micro Edition, progettata dalla Sun Microsystems, è il sostituto per una tecnologia
simile chiamata PersonalJava, ed è diventata un popolare strumento di sviluppo poiché i
software possono essere emulati sul PC e facilmente installati sul dispositivo. J2ME è solo
una delle tre diverse edizioni (edition) di Java, che pur rimanendo basate grossomodo su
virtual machine compatibili ed un insieme di API di base, si sono differenziate a seconda
del loro target. Le “edition” sono state introdotte con il rilascio di Java2, e partizionano,
per cosı̀ dire, piattaforme, API, e strumenti di sviluppo in tre differenti gruppi ognuno dei
quali indirizzato ad un ben preciso segmento di mercato:
• Java 2 Enterprise Edition (J2EE), fornisce un insieme di API per la realizzazione di
architetture solide, complete e scalabili, dirette, soprattutto, ad applicazioni server;
• Java 2 Standard Edition (J2SE), rappresenta il nucleo del linguaggio Java ed è
indirizzata allo sviluppo di applicazioni ed applet sul lato client;
• Java 2 Micro Edition (J2ME), studiata appositamente per dispositivi embedded e
per l’elettronica di consumo;
J2ME non è indirizzata a singole piattaforme, come lo era PersonalJava ma, in generale, a tutto il settore embedded. La sua architettura e le sue specifiche sono ben delineate
ed essa stessa è una versione standard di Java.
Naturalmente il fatto che J2ME sia dedicata a tutto il mercato embedded non vuol
certo dire che possa essere utilizzata con qualunque tipo di apparecchiatura e in qualunque
contesto. La sua struttura modulare ed espandibile permette però di coprire una vasta
gamma di piattaforme (apparati) embedded: dai PDA ai cellulari, dai navigatori satellitari
a TV digitali con tutti i vantaggi che il linguaggio Java può portare.
Uno degli aspetti più interessanti e apprezzati di Java è sempre stato il suo alto grado
di portabilità e il suo livello di astrazione dall’hardware, che J2ME mantiene ed estende
ad un settore, quello dell’elettronica di consumo, davvero ricco di piattaforme differenti.
14
Architettura J2ME
Le caratteristiche di modularità e scalabilità vengono garantite in J2ME attraverso i concetti di Configurazioni e Profili:
• Configurazioni - definiscono le caratteristiche di base del linguaggio Java e della
Virtual Machine per un insieme di dispositivi, e forniscono un insieme di librerie di
base comuni per più categorie di apparati (es. Cellulari, PDA, smartphone);
• Profili - si basano su una configurazione, ne estendono le funzionalità di base, fornendo API addizionali e tools di sviluppo per una particolare categoria di dispositivi
(es. PDA). Le applicazioni scritte per un dato profilo sono portabili ed eseguibili su
qualunque dispositivo che lo supporti;
Le configurazioni, quindi, sono dirette ad un insieme di apparati e non ad una specifica categoria, mentre i profili sono qualcosa di più legato al dispositivo stesso. Prendendo
come riferimento l’intero settore embedded si può dire che, mentre le configurazioni eseguono un raggruppamento dei dispositivi in senso orizzontale, i profili lo fanno in senso
verticale.
Configurazioni
In base alle caratteristiche dei vari apparati possiamo distinguere dispositivi a uso esclusivamente personale, mobili, che necessitano di connessioni a reti in modo non continuo
e dispositivi condivisi, fissi, che necessitano di connessioni a reti in modo continuo.
Nella prima categoria rientrano i telefoni cellulari, i pager, i PDA, cioè tutti quei
dispositivi caratterizzate da un’interfaccia utente molto semplice, ridotte disponibilità di
memoria (tipicamente 128 KByte - 2 MByte), limitate capacità di elaborazione, basso
consumo di energia e connessioni a reti di telecomunicazione di tipo wireless con modesta
larghezza di banda.
15
Per la seconda categoria sono tipici esempi apparecchiature come Web TV, telefoni
capaci di accedere ad Internet, ricevitori televisivi satellitari, communicator, sistemi di navigazione per auto. Tutti questi dispositivi, essendo installati in modo fisso, non risentono
dei tipici problemi dei dispositivi portatili (o addirittura tascabili) come peso, dimensioni
e consumi di energia e possono, quindi, contare su dotazioni di memoria anche notevoli
(da 2 MByte a 32 MByte), processori veloci e performanti e connessioni continue a reti
con ampia larghezza di banda.
Pur non essendo netto il confine che separa queste due categorie, è necessario tenere
in considerazione alcune caratteristiche hardware fondamentali del dispositivo sul quale
il software dovrà funzionare quali:
- la potenza di calcolo e la disponibilità di memoria;
- la presenza o meno di un display e le sue caratteristiche;
- le tipologie di connessione a reti di TLC;
È proprio sulla base di questi parametri che J2ME ha implementato le sue due attuali
configurazioni, ossia:
• CLDC (Connected Limited Device Configuration) - è dedicata a dispositivi con memoria minima di circa 128 KByte (RAM e ROM), processori (RISC/CISC) a 16-32
bit, basso consumo e funzionamento tipicamente a batteria, connessioni non continue a reti eterogenee, sovente di tipo wireless con larghezza di banda limitata
(spesso uguale o inferiore a 9600 bps). La Virtual Machine prevista per questa
configurazione è la KVM (Kilobyte Virtual Machine), ossia una macchina virtuale
Java studiata per apparecchi con memoria totale dell’ordine dei KByte (il core della
KVM occupa da 32 a 80 KByte).
• CDC (Connected Device Configuration) - è studiata per dispositivi hardware che
dispongono di almeno 2 MByte totali di memoria (RAM e ROM), processori a
16
32 bit, di connessioni persistenti a reti TLC con ampia larghezza di banda e interfacce grafiche anche molto sofisticate. La virtual Machine utilizzata per questa
configurazione è la CVM (C Virtual Machine).
La CLDC può essere considerata come una versione “alleggerita” della CDC. Le configurazioni forniscono un set minimo di librerie di base: alcune di queste costituiscono un
sottoinsieme di package della Standard Edition altre, sono state realizzate appositamente
per la Micro Edition.
Profili
Le funzionalità di base garantite dalle configurazioni però non bastano per realizzare un
applicativo. Ad esempio la configurazione dedicata di un cellulare è la CLDC: questa ci
mette a disposizione un insieme di librerie di base che permettono di utilizzare Java (java.lang), di gestire gli stream di I/O (java.io), ci fornisce tutta una serie di classi di utilità
(java.util) e ci da la possibilità di comunicare (javax.microedition.io). Ma per operazioni
come l’iterazione con l’utente, la realizzazione di interfacce grafiche, il salvataggio dei
dati e la creazione dell’eseguibile per cellulare a partire dal classico .java è chiamato a risponderne il profilo. Esso si occupa di gestire tutte quelle problematiche più strettamente
collegate al tipo di apparato, come la gestione dei dispositivi di Input/Output, il salvataggio persistente dei dati nelle memorie non volatili, la realizzazione di UI e fornisce dei
tool di sviluppo per una determinata categoria di dispositivi (in questo caso i cellulari). I
profili si suddividono in base alla configurazione per la quale sono stati realizzati. Quelli
attualmente previsti (non tutti attualmente disponibili) sono:
1. Configurazione CDC:
• Foundation Profile : profilo per dispositivi che richiedono una completa implementazione della Java Virtual Machine e includono quindi tutte le API della
J2 Standard Edition;
17
• RMI Profile : questo tipo di profilo, come indicato dal nome, include un sottoinsieme di API RMI (Remote Method Invocation) della J2SE, in modo da
garantire un certo grado di interoperatività con altre virtual machine sia J2ME
sia J2SE;
• Personal Profile : è l’estensione dell’ambiente PersonalJava di Sun e garantisce una piena compatibilità con le applicazione sviluppate con le versioni
1.1.X e 1.2.X di PersonalJava Application Enviroment;
2. Configurazione CLDC :
• PDAP : il Personal Digital Assistant Profile è il profilo dedicato ai dispositivi
palmari. Tali apparati devono avere almeno 512 KByte di memoria (RAM +
ROM) e un display con risoluzione totale di almeno 20.000 pixel;
• MIDP : il MIDP (Mobile Information Device Profile) è un profilo dedicato a
dispositivi wireless come telefoni cellulari, smartphone e pager;
Nella figura 3.1 sono raffigurate le configurazioni e i profili di J2ME.
Figura 3.1.
Configurazioni e profili di J2ME
18
3.2.2
Java rincorre Symbian
Negli anni J2ME ha subito un’evoluzione che dimostra come essa sia andata spesso di
pari passo con quella di Symbian OS a cui va asintoticamente avvicinandosi.
Da subito l’idea di un Java “light”, strumento con il quale diffondere applicazioni sul
mercato di massa, risulta molto appetibile per i costruttori. Lo stesso consorzio Symbian
si accorge della forza di J2ME e include il MIDP 1.0 nel Symbian OS v6.0 realizzato nel
2002. Ma, sebbene MIDP 1.0 avesse entusiasmato non poco la Wireless Java Community,
fu subito evidente il collo di bottiglia di non poter accedere da una MIDlet1 alle funzionalità tipiche degli smartphone, cosa che era possibile utilizzando le API Symbian. Inoltre
la tanto sventolata portabilità, soprattutto con MIDP 1.0, fu un vantaggio solo teorico,
in quanto passando da un modello ad un altro di terminale mobile, non solo si dovevano apportare modifiche a livello di UI, ma spesso una semplice connessione HTTP non
funzionava più.
Di conseguenza si cominciò a lavorare al MIDP 2.0 e ad una serie di API aggiuntive.
Il MIDP 2.0 comincia ad essere uno strumento sufficientemente completo, in quanto offre
un meccanismo di sicurezza, nuove UI API, Game e Audio API, Push Registry. Accanto
al MIDP 2.0 package opzionali quali MMAPI (Mobile Media API), WMA (Wireless
Messaging API), JABWT (Java API for Bluetooth Wireless Technology), offrono nuove
funzionalità per il supporto di video e immagini e la gestione della videocamera, per
inviare e ricevere SMS e per accedere allo stack Bluetooth. Tutte queste API opzionali
insieme al MIDP 2.0 vengono offerte da Symbian OS v7.0.
Da questo momento in poi lo sviluppo di nuove funzionalità su J2ME subisce un’accelerazione, nascono di continuo nuove JSR2 che mirano non solo a colmare il gap con le
applicazioni native ma anche a rendere più facilmente programmabili alcune funzionalità.
Nascono cosı̀ Mobile 3D Graphics per la grafica tridimensionale, File Connection API per
1
Una MIDlet è un programma Java per dispositivi embedded, più specificatamente per la virtual machine
Java ME. Generalmente tali programmi sono giochi e applicazioni per cellulari.
2
Le JSR, ovvero le Java Specification Request sono documenti formali che descrivono delle nuove
specifiche proposte e tecnologie da aggiungere alla piattaforma Java. Una volta che tale JSR diventa “finale”
e viene votato dalla JCP Executive Committee, essa fornisce un’implementazione della tecnologia e un Kit
di compatibilità della tecnologia per verificare le specifiche delle API.
19
l’accesso al file system, Personal Information Management per l’accesso alle informazioni personali come la rubrica, Content Handler API, Web Services API (parsing XML,
RPC messaging, SOAP), Security and Trust Services API (sicurezza, crittografia, firma
digitale, accesso a Smart Card), SIP API (instant messaging, presence, chatting, gaming),
WMA 2.0 (oltre agli SMS supporto anche per MMS), Location API, ecc.
Le versioni 8.0 prima e 9.0 dopo del Symbian OS offrono man mano tutte queste
API, funzionanti sopra la CLDC 1.1 VM. Del resto all’interno dei gruppi di esperti che
si occupano delle JSR J2ME, la maggioranza sono ormai rappresentanti del consorzio
Symbian, Nokia in primis. Studiando l’evoluzione delle performance di J2ME in funzione
del Symbian OS si può vedere come le funzionalità di J2ME siano sempre maggiori col
passare degli anni e con il progredire di Symbian, che risulta essere ormai il maggior
aggregatore di risorse Java.
Intanto le implementazioni Java risultano ora totalmente compatibili con le specifiche
“Java Technology for the Wireless Industry” (JTWI, JSR 185). JTWI è un’iniziativa del
JCP per definire un set minimo di API e di funzionalità di cui ogni telefono deve disporre.
La release 1 di questa specifica prevede che il set minimo comprenda MIDP 2.0, CLDC
1.0, WMA e MMA. Anche le performance delle applicazioni Java sono andate migliorando nel tempo, grazie alla compilazione adattativa dinamica, all’accelerazione hardware
degli interpreti di byte code, all’ottimizzazione della grafica e dell’interfaccia nativa. Allo stesso tempo anche le velocità di clock sono aumentate. In poche parole le performance
di J2ME sono migliorate con l’evoluzione del sistema operativo Symbian OS, di circa 40
volte rispetto a quelle originali.
Recentemente Sun Microsystems ha annunciato che sono 250 milioni i telefoni nel
mondo che supportano la tecnologia Java. Dopo quello che è stato detto si può riassumere quella che è la storia delle differenze, se si vuole di vantaggi e svantaggi, nello
sviluppo di applicazioni J2ME e Symbian: inizialmente Symbian accanto alla flessibilità
e alla potenza, caratteristiche di un sistema operativo, presenta il punto debole di una scarsa diffusione sul mercato di massa; d’altro canto Java, grazie alla sua peculiare portabilità,
si pone come veicolo di diffusione delle applicazioni mobili su moltissimi dispositivi. A
20
creare difficoltà allo sviluppo di Java interviene da una parte l’impossibilità di poter creare
applicazioni che utilizzino le funzioni native del telefono, e dall’altra il fatto che la portabilità è solo virtuale, a livello di UI i telefoni sono diversi tra di loro e le implementazioni
proprietarie del MIDP risultano spesso differenti.
Possiamo cosı̀ sintetizzare i benefici che Symbian OS ha apportato a J2ME:
1. Robustezza : Symbian OS è pensato per essere attivo 24 ore al giorno, 7 giorni su
7. L’integrità dei dati è il vantaggio maggiore dei telefoni Symbian. Java si poggia
su queste solide basi.
2. Funzionalità : come detto prima molte delle funzionalità offerte da J2ME e implementate in diversi package sono incluse nel sistema operativo Symbian.
3. Performance : Symbian “precarica” le classi Java di sistema permettendo una diminuzione dei tempi di start-up delle applicazioni e rendendo disponibile alle applicazioni più memoria.
Nel corso degli anni J2ME tende a realizzare ciò che per Symbian è già realtà e, anzi,
laddove J2ME è supportato dal Symbian OS, si può notare come J2ME si avvantaggi dei
progressi del sistema operativo.
3.3
Symbian OS
Symbian OS è un sistema operativo aperto, prodotto dalla Symbian Ltd. e adottato come
standard dalle principali aziende mondiali produttrici di dispositivi per la telefonia mobile (cellulari, smartphone, PDA). Il sistema operativo è stato progettato per supportare i
requisiti specifici di trasporto dati per i dispositivi mobili di nuova generazione 2G, 2,5G
e 3G.
Le caratteristiche generali principali di Symbian OS sono la presenza di un microkernel a 32 bit robusto e adatto al multi-tasking con preemption (o diritto di prelazione3 ) e al
3
Si dice che lo scheduling è con preemption quando un thread a più elevata priorità può interromperne
21
multi-threading, il supporto integrato per la telefonia, diversi protocolli di comunicazione,
un avanzato supporto grafico e un framework di basso livello per l’interfaccia utente e una
varietà dei cosiddetti application engine4 .
Inoltre Symbian è un sistema operativo aperto, non nel senso di Open Source, in
quanto il codice sorgente non è disponibile pubblicamente, ma nel senso che le API sono
documentate e liberamente fornite ai produttori di telefoni e chiunque voglia sviluppare
software per Symbian ha la possibilità di scrivere e installare applicazioni, indipendentemente dai costruttori di dispositivi. Questo è in netto contrasto con i tradizionali sistemi
operativi dei cellulari nei quali tipicamente il software è prodotto unicamente dalla casa
produttrice, e non vengono accettati prodotti provenienti da terze parti.
L’idea di realizzare una piattaforma leggera e flessibile che potesse stare in un cellulare
nasce nel 1998 dai leader dell’industria della telefonia mobile Ericsson, Motorola, Nokia e
dal 1999 Panasonic. Il punto di partenza fu la creazione di un sistema operativo, chiamato
EPOC, sviluppato dalla Psion Software. Più tardi EPOC diventò Symbian OS e la Psion
Software diventò Symbian.
Il primo vero cellulare basato su Tecnologia Symbian era il modello di Ericsson R380
basato su Symbian Quartz versione 5.x, un sistema chiuso (cioè non programmabile al di
fuori della casa madre). Attualmente la piattaforma Symbian vanta una serie di terminali
sempre più vasta, per citarne solo alcuni si va dagli ultimissimi Nokia (N70, N71, N80,
N91, N92) al Samsung SGH-D720, al Sony Ericsson P990, ma comprende dispositivi
di molte altre case: BenQ, Motorola, Sendo, Jujitsu, Panasonic, Foma, Siemens, Arima,
Lenovo. Nella prima metà del 2005 i telefoni Symbian nel mondo sono arrivati a 39
milioni.
Symbian OS è quindi un sistema operativo ad-hoc per smartphone, cioè per quei telefoni “intelligenti” che si differenziano notevolmente da quelli tradizionali in quanto sono
terminali con elevate caratteristiche tecnologiche a metà strada fra PDA e cellulare, funzionalità di gestione di dati personali e di telefono, e soprattutto, hanno la possibilità di
un altro con priorità inferiore. I thread sono infatti schedulati in base alla loro priorità, o mediante un
round-robin se hanno la medesima priorità.
4
Gli application engine verranno illustrati nel paragrafo 3.3.2.
22
essere programmati. Questo si vede nell’impressionante insieme di caratteristiche tecniche fornite dalle ultime versioni di Symbian che, mediante una particolare gestione della
memoria e di un sistema multiprocesso, permette operazioni sicure e soprattutto efficienti considerando che le risorse di un cellulare sono ridotte sia in termini di batteria e di
potenza, che in termini di memoria.
3.3.1
Symbian C++
Symbian OS è stato sviluppato usando il linguaggio C++, che è perciò il linguaggio nativo
di programmazione in quanto fornisce pieno accesso alla piattaforma e alle funzionalità
del dispositivo di basso livello. Utilizzando tale linguaggio gli sviluppatori possono accedere non solo agli application engine, ma anche ad una moltitudine di tecnologie quali
Bluetooth, infrarosso, telefonia, funzionalità multimediali e cosı̀ via. Le applicazioni
possono anche essere sviluppate utilizzando Java MIDP 2.0 o Python, ma è il C++ che
permette allo sviluppatore di ottenere il massimo potenziale della piattaforma in quanto
a performance, e consente di produrre un’ampia gamma di applicazioni che vanno dalla manipolazione della fotocamera, all’invio di MMS o all’accesso delle funzionalità di
telefonia.
Il linguaggio C++ utilizzato dal sistema operativo Symbian non è esattamente lo stesso
usato in altri ambienti, in quanto è stato ottimizzato per dispositivi relativamente piccoli e
con vincoli di memoria. La Standard Template Library (STL) infatti non è supportata, ed
altre modifiche sono state applicate al C++ standard in quanto quest’ultimo implementa
caratteristiche non richieste da Symbian (come l’ereditarietà privata) o, viceversa, non
fornisce strumenti che questi richiede. Inoltre certi meccanismi del C++ standard, primo
fra tutti la cattura di eccezioni mediante l’uso di try-catch, non era disponibile nei
primi compilatori, e risulterebbe comunque troppo pesante in termini di computazione
per un dispositivo cellulare. Questo approccio generico di gestione degli errori è stato
quindi sostituito da altri meccanismi ad-hoc più efficienti in termini di memoria, oltre che
di CPU che verranno illustrati nel paragrafo 3.4.5.
La versione nativa della Symbian Ltd. di C++ utilizza la maggior parte dei costrutti
23
del linguaggio standard, è ad oggetti e permette quindi di sviluppare software basato su
componenti e su una architettura modulare, ma ha una sua nomenclatura e caratteristiche
ad-hoc.
3.3.2
Architettura del Sistema Operativo
Come si è gia affermato in precedenza, Symbian è nato per funzionare su dispositivi
cellulari che, in quanto tali, sono caratterizzati da un basso consumo di potenza e da
ridotte capacità di memoria. Questo fatto ha notevolmente influito sui disegni di progetto
e sull’architettura di questa piattaforma.
Risorse hardware
• CPU - Symbian OS è progettato per CPU a 32 bit e gira esclusivamente su processori ARM (Advanced Risk Machines), il processore RISC a 32 bit ampiamente
usato in svariati dispositivi embedded e, grazie alle caratteristiche di risparmio della
potenza, dominante nei dispositivi mobili. Tale CPU è però decisamente più lenta
se confrontata con quella di un normale PC.
• ROM - La ROM contiene il sistema operativo e le applicazioni, diversamente da
quella di un PC che contiene solo il boot loader a la BIOS, mentre il resto è posto
nell’hard disk. La ROM è mappata nel drive z: e i programmi vengono eseguiti in
ROM, invece di essere caricati in RAM ed eseguiti come su un PC.
• RAM - La RAM di sistema è usata per i programmi attivi e per il kernel, ed è usata
come un disco accessibile dal drive c:. Poiché la RAM totale su un dispositivo
tipico si aggira sui 16 MB, c’è la possibilità di avere errori di disco pieno o di
out-of-memory, anche se con il diminuire dei prezzi si ha un maggiore utilizzo di
memorie Flash (che hanno il vantaggio aggiuntivo di non richiedere una costante
alimentazione per conservare i dati).
24
• Dispositivi di I/O - Comprendono lo schermo, il tastierino (che può essere più o
meno compatto), memory-card slot, porte seriali, porte infrarosso e Bluetooth.
• Batteria - La gestione della potenza è critica in quanto ci si aspetta che un dispositivo cellulare funzioni per parecchie ore, se non giorni, tra una ricarica e
l’altra.
Viste queste premesse si può ribadire che Symbian è un sistema operativo ad-hoc per
cellulari, e che anzi il suo punto di forza sta proprio nell’essere pensato per dispositivi con
forti vincoli di risorse e che possono funzionare per mesi o anni senza essere spenti e senza
perdere i dati dell’utente. Questa forte enfasi di conservazione della memoria viene realizzata nei fatti mediante una programmazione specifica fatta di costrutti quali descrittori
e cleanup stack, che insieme ad altre tecniche, permettono di mantenere basso l’utilizzo
della memoria e di ridurre considerevolmente la frequenza dei cosiddetti memory leak5 .
Si hanno tecniche simili anche per una migliore conservazione dello spazio su disco,
poiché non si hanno hard disk (a parte recentemente memorie flash) e non si può certo
assumere di avere spazio infinito per immagazzinare programmi e dati utente. Inoltre tutta
la programmazione Symbian è basata ad eventi, in modo che la CPU non sia in esecuzione
ogni qual volta un’applicazione non sta direttamente interagendo con un evento. Questo
è realizzato grazie ad un costrutto di programmazione denominato active object (vedi
paragrafo 3.4.6).
Il corretto uso di queste tecniche, che verranno dettagliate ulteriormente in seguito,
permette di assicurare un tempo di vita della batteria più lungo.
Struttura
Symbian nasce come un sistema operativo completo in termini di funzionalità. Riassumendo le sue principali caratteristiche sono:
5
Un memory leak è un consumo di memoria da parte di un programma, dovuto al mancato rilascio di
risorse quando esse non sono più utili.
25
1. Performance : Symbian OS è progettato per massimizzare la durata della batteria
attraverso un’accurata gestione di potenza
2. Ambiente aperto : Symbian OS permette al telefono cellulare di essere una piattaforma aperta per installare applicazioni e servizi sviluppati in diverse lingue e
formati di contenuto
3. Interoperabilità : mediante un’implementazione flessibile e modulare, Symbian
fornisce un set di base di API (Application Programming Interfaces) e tecnologie
condivise da tutti i telefoni basati su tale sistema operativo. Inoltre l’utilizzo di
tecnologie basate sugli standard principali (Open Standards) consente di rendere le
applicazioni interoperabili con soluzioni di altri produttori
4. Multi-tasking : è fondamentale perché componenti essenziali come telefonia, messaggistica e comunicazioni sono progettati per funzionare in parallelo. Le API
Symbian C++ consentono alla gestione della memoria e al multi-tasking di essere estremamente efficienti, facendo in modo che operazioni pesanti in termini di
memoria come i context switching6 vengano minimizzate. Questo perché le applicazioni principalmente si basano su eventi invece di sfruttare il multithread, che è
possibile e di norma usato dal sistema operativo, ma generalmente evitato dalle applicazioni, in quanto potenzialmente crea parecchi kilobyte di overhead per thread.
Viceversa un approccio basato ad eventi non ha bisogno di context swhitching e può
avere un overhead dell’ordine di poche decine di byte
5. Interfaccia utente flessibile : usando un’interfaccia grafica flessibile e lo stesso
sistema operativo di base si facilita la portabilità di applicazioni per gli sviluppatori
6. Robustezza : Symbian OS assicura integrità dei dati anche in casi di carenza di
memoria, spazio e batteria, o in presenza di comunicazioni non affidabili.
6
Il context switch è quella parte del kernel del sistema operativo che cambia il processo correntemente
in esecuzione su una delle CPU permettendo a più processi di condividere una stessa CPU, ed è utile quindi
nei sistemi con un solo processore, perché consente di eseguire più programmi contemporaneamente.
26
Il cuore del sistema operativo Symbian consiste in una parte di base che comprende
il microkernel e i driver dei dispositivi, un middleware composto dai server di sistema
e dal framework applicativo e una parte per le comunicazioni come telefonia e Personal
Area Network. Questo nucleo del sistema operativo è comune a differenti dispositivi che
supportano Symbian OS, e naturalmente se il sistema operativo venisse adattato ad un
altro hardware, la parte di base necessiterebbe di essere modificata (mediante il processo
noto come base porting), ma questo non intaccherebbe i livelli superiori.
D’altro canto se due cellulari avessero librerie per l’interfaccia utente che forniscono
look and feel completamente diversi, avrebbero comunque ancora in comune la base sottostante costituita dal sistema operativo e questo permette l’interoperabilità, semplifica lo
sviluppo di applicazioni per diversi dispositivi e ne diminuisce il costo.
La generica struttura del sistema operativo Symbian versione 8.0a è riportata nella
figura 3.2. Analizzando tale struttura si vede che ai livelli più bassi, localizzati nel livello
base del sistema operativo si hanno il kernel, il file server, la libreria utente e i driver dei
dispositivi.
Figura 3.2.
Architettura di Symbian v8.0a OS
27
Il kernel di Symbian ha un’architettura a microkernel, il che significa che al suo interno vi è solamente il minimo necessario. Esso contiene uno scheduler e un gestore della
memoria, ma nessun supporto per il networking o per il file system, che sono forniti dai
server lato utente. Il kernel è eseguito direttamente nel processore in modalità privilegiata per poter avere accesso e gestire le risorse hardware come memoria e potenza, ed
è responsabile del time-slicing per quanto riguarda le applicazioni e i task di sistema. Il
controllo delle periferiche è quindi materia esclusiva del kernel in quanto la CPU svolge
determinate istruzioni privilegiate solamente per esso, mentre i programmi in modalità
utente non hanno privilegi per accedere direttamente alle risorse, se non usando le API
esportate dal kernel.
I driver dei dispositivi forniscono il controllo e l’interfaccia a specifiche periferiche come la tastiera, il display o le porte seriali. Rappresentano il livello di interfaccia
hardware-software necessario per accedere alle risorse.
La libreria utente invece consente di usare molte delle funzionalità come gestione
errori, livello di astrazione dell’hardware e architettura client-server, oltre che permettere
alle applicazioni lato utente di fare richieste al kernel.
Il file server fornisce una visione del file system sul dispositivo per cui ogni drive ha
una lettera, e i backslash vengono usati per delimitare i direttori. Vari file system sono
supportati tra cui FAT32 e NOR, e generalmente non sono esposti all’utente attraverso
l’interfaccia grafica.
Nei livelli superiori vi è una consistente parte dedicata al networking e ai sistemi
di comunicazione (TCP/IP, IMAP4, SMS e gestione database), che è sostanzialmente
costituita da tre server principali: ETEL (EPOC telephony), ESOCK (EPOC sockets) and
C32 (responsabile per comunicazioni seriali). Vi è inoltre una parte per comunicazioni di
basso raggio come Bluetooth, IrDA e USB. Quel che offre l’architettura di comunicazione
è l’infrastruttura e le pile protocollari dei più comuni standard.
Il framework applicativo è costituito da un set di librerie che forniscono i mezzi per
gestione testo, grafica e suono. Parte del framework è anche costituito dal window server
(provvede all’accesso e utilizzo di tastiera) e dal framework grafico.
28
Particolarmente importanti nell’architettura Symbian sono i server e l’architettura
Client/Server. Un server è un programma senza interfaccia grafica, eseguito in un processo separato, che gestisce una o più risorse. I client di tali server possono essere applicativi utente, altri server o processi di sistema. I server di sistema hanno un’alta priorità,
ma non possiedono privilegi di sistema, e possono essere usati solo attraverso particolari
interfacce.
Vi è infine una suite di application engine per applicazioni tipiche degli smartphone
come calendario, rubrica telefonica, registro, agenda e servizi multimediali.
3.3.3
Serie 60
La Serie 60 o S60 è la piattaforma per telefoni mobili che si appoggia sul sistema operativo
Symbian. È attualmente tra le piattaforme dominanti sul mercato, ed è stata sviluppata da
Nokia e concessa in licenza ad altri produttori quali Panasonic, Samsung, Sendo, Siemens,
Lenovo, LG Electronics, Panasonic e Samsung.
L’interfaccia grafica della Serie 60 è progettata per operazioni che possono essere
svolte con una mano e che permettono quindi di avere una tastiera ridotta, diversamente
da quella della Serie 80. Possiede uno schermo a colori con dimensione di 176 x 208
pixel, e la tastiera presenta dodici tasti numerici e tasti dedicati a particolari funzioni,
come i cosiddetti softkeys (per la scelta delle opzioni presentate a video) e un tastierino
con quattro direzioni.
Un importante caratteristica della Serie 60, del resto comune al sottostante sistema
operativo, è quella di permettere l’installazione di applicazioni dopo l’acquisto del cellulare, ed è per questo che viene fornito agli sviluppatori un insieme di componenti e
API usate dalle applicazioni che sono parte della piattaforma, ma utilizzabili anche da
sviluppatori e terze parti. Tra le applicazioni offerte dalla Serie 60 si hanno avanzate
applicazioni per telefonia, per la rubrica, calendario e album delle foto, sincronizzazione
(SyncML), messaggistica, browsing, e-mail ed un’applicazione per installare o rimuovere
altre applicazioni dalla piattaforma.
29
La Serie 60 è la base di cellulari come Nokia 7650, Nokia 3650, Nokia 6630 e Nokia
N-Gage.
Storia
Quando nacque Symbian ogni fondatore ebbe la propria idea in merito alla creazione di
una nuova era di terminali mobili. In particolare la principale differenza tra le parti in gioco stava nell’interazione con l’utente e, per superare queste divergenze, venne introdotto
il concetto di progetto di riferimento. I tre progetti originali erano Crystal, Quartz, e Pearl.
Crystal e Quartz sono dispositivi di tipo communicator, Crystal con display orizzontale a
640 x 200 pixel e Quartz con display ad orientamento verticale a 240 x 320 pixel e touch
screen. Pearl è il progetto di riferimento di cui la piattaforma Serie 60 è l’esempio più
significativo.
Con l’introduzione di Symbian OS v7.0, Quartz è stato rinominato UIQ ed è distribuito nelle versioni stretta (208 x 320) e normale (240 x 320) dalla UIQ Technology.
Crystal è ora chiamata Serie 80 dalla Nokia. L’attuale set di stili per l’interfaccia utente è
presentata in figura 3.3.
Figura 3.3.
Symbian OS: La Serie 60, UIQ e la Serie 80
Poiché il display è una delle parti più costose di uno smartphone, la Serie 60 risulta
30
essere alquanto appetibile ai costruttori di terminali per la sua risoluzione dello schermo da 176 x 208 pixel. UIQ fornisce un display leggermente più largo, con operazioni
eseguibili con penna; la Serie 80 ha la più grande dimensione dello schermo. Ogni stile
dell’interfaccia permette la personalizzazione del look and feel in termini di dimensione,
forma, colore della grafica, cambio dei menu e aggiunta di nuovi componenti, in modo da
adattarsi meglio al dispositivo in questione.
Edizioni della Serie 60
Le edizioni della Serie 60 ne rappresentano i passi di evoluzione caratterizzati dalle varie modifiche e caratteristiche aggiuntive rispetto alle versioni precedenti. Tipicamente
un’edizione è anche accompagnata da aggiunte e cambiamenti del sottostante sistema
operativo.
Il vantaggio di questo procedere sta chiaramente nella possibilità di aggiungere progressivamente nuove funzioni e potenzialità, ma allo stesso tempo nel mantenere una certa
continuità di compatibilità e interoperabilità dei software. Infatti chi sviluppa applicazioni
per un dispositivo cellulare si trova di fronte al compromesso tra i costi di portabilità del
prodotto ad un nuovo dispositivo e il mantenimento di una più larga fetta di acquirenti. La
Serie 60 permette di ottenere il massimo da questi due aspetti perché fornisce l’implementazione software per tutti i dispositivi basati su una particolare edizione della piattaforma.
Gli sviluppatori possono essere sicuri che le applicazioni create usando le caratteristiche
di un’edizione potranno essere facilmente trasferiti verso qualsiasi dispositivo basato su
quell’edizione.
Oltre le edizioni vi sono i Feature Pack, cioè distribuzioni di caratteristiche aggiuntive rese disponibili tra l’uscita di un’edizione e l’altra. Ad esempio la seconda edizione presenta tre Feature Pack, ognuno dei quali porta una crescita nelle capacità della
versione della piattaforma. Questo permette a quest’ultima di evolvere continuamente,
mantenendo una comune linea guida e coerenza attraverso le edizioni.
Le successive distribuzioni della Serie 60 e le rispettive versioni di Symbian OS su
cui si appoggiano sono:
31
• S60 1◦ Edizione - Symbian OS v6.1.
• S60 2◦ Edizione - Symbian OS v7.0s.
– S60 2◦ Edizione, Feature Pack 1 - Symbian OS v7.0s.
– S60 2◦ Edizione, Feature Pack 2 - Symbian OS v8.0a.
– S60 2◦ Edizione, Feature Pack 3 - Symbian OS v8.1a.
• S60 3◦ Edizione - Symbian OS v9.1.
– S60 3◦ Edizione, Feature Pack 1 - Symbian OS v9.2.
Com’è già stato ricordato in precedenza, l’edizione della Serie 60 utilizzata nel lavoro di tesi è stata la S60 2◦ Edizione Feature Pack 2, cioè quella che utilizza il sistema
operativo Symbian OS v8.0a, e quindi la trattazione si limiterà a esporre solamente le
caratteristiche tecniche e funzionalità di questa distribuzione nei successivi sottocapitoli.
Symbian OS v8.0a
Anche la versione 8.0a di Symbian è un sistema operativo ottimizzato per terminali mobili
ed è il sistema di base sotto il quale la Serie 60 2◦ edizione Feature Pack 2 è stata costruita.
Tale piattaforma è un affidabile ambiente progettato in modo che i dati utente non vengano
mai persi e in modo che il sistema non abbia mai bisogno di essere riavviato.
Come già visto in precedenza Symbian ha un approccio totalmente ad oggetti: tutti
gli oggetti di sistema, dalle applicazioni ai gestori di interrupt, sono definiti e trattati
come classi C++. Questo indubbiamente contribuisce in modo positivo alla flessibilità,
efficienza e riusabilità dei segmenti di codice. Inoltre un set di API consente alla comunità
di sviluppatori, inclusi i produttori di telefoni cellulari, di creare applicazioni che possono
essere facilmente scaricate, installate ed eseguite nativamente su terminali Symbian. È
cosı̀ possibile realizzare in modo efficiente il multitasking, la gestione della memoria
poiché operazioni pesanti come context switching sono minimizzate.
32
Symbian OS esporta altresı̀ librerie che consentono l’utilizzo e lo sviluppo per un
vasto insieme di tecnologie che includono, tra le altre, Bluetooth, grafica, infrarosso,
multimedia, messaggistica, networking e ovviamente telefonia.
I principali miglioramenti di Symbian v8.0a sono elencati di seguito:
1. K ERNEL REAL - TIME - è stato introdotto il supporto per due differenti kernel, uno
dei quali è real-time (chiamato EKA2). Il motivo principale per avere introdotto
una versione real-time del kernel è assicurare che un certo numero di API critiche
sia del kernel, che lato utente, operassero con garanzie real-time. In questo modo il
kernel è robusto e efficiente in termini di potenza.
2. S ICUREZZA - si ha totale crittografia, gestione dei certificati, protocolli sicuri come
HTTPS, SSL e TLS, e installazione delle applicazioni basata su certificati.
3. M ULTIMEDIA - astrazione hardware per audio, video, MIDI che permette un più
semplice sviluppo di applicazioni multimediali. Fotocamera da 1.3 megapixel con
zoom 6x.
4. G RAFICA - accesso diretto allo schermo e alla tastiera per un controllo più performante. Si sono inoltre introdotte API per accelerazione grafica.
5. C OMUNICAZIONI
TRA PROCESSI
- un framework più flessibile per messaggi
asincroni tra thread e processi; uno di questi è un buffer condiviso di I/O che permette ai driver dei dispositivi di condividere dati in modo diretto e sicuro senza la
necessita di copiare i dati.
6. JAVA - Java 2 Platform, Micro Edition (J2ME), Mobile Information Device Profile
(MIDP) 2.0 e migliorie alle capacità di MIDP 2.0. Inoltre sono state incluse le
API Java Mobile 3D Graphics API for J2ME (JSR-184), FileConnection API (JSR75), e PIM API (JSR-75) e il supporto per i più recenti standard wireless inclusi
CLDC 1.1, JTWI (JSR185), Mobile Media API (JSR135), Java API for Bluetooth
(JSR082) and Wireless Messaging (JSR120).
33
7. G ESTIONE DISPOSITIVO - aggiunto supporto per la gestione remota del terminale
che può essere effettuato attraverso qualsiasi tra i protocolli di sessione HTTP, WSP,
OBEX.
8. M ESSAGGI - messaggi multimediali (MMS), messaggi avanzati (EMS) e SMS;
gestione mail usando i protocolli POP3, IMAP4, SMTP e MHTML.
9. P ROTOCOLLI
DI COMUNICAZIONE
- stack protocollari come TCP/IP (sia IPv4
che IPv6) e WAP, supporto per personal area network inclusi infrarosso (IrDA),
Bluetooth e USB. Qualità di servizio per reti GPRS e UMTS.
3.4
Programmare con Symbian
Il processo di creazione applicazioni per Symbian è piuttosto lungo e laborioso e l’utilizzo dell’emulatore non sempre può aiutare lo sviluppatore. Infatti tale strumento può
essere essenziale e notevolmente utile nel caso, per esempio, di implementazione di interfacce grafiche, ma di scarso utilizzo se l’obiettivo è l’utilizzo di componenti hardware
come microfono o interfacce di rete. Per tale ragione questa sezione presenta in modo
sintetico i passi fondamentali per la compilazione e il deploy7 per la piattaforma Serie 60
su un dispositivo reale, piuttosto che per l’emulatore, oltre che fornire una descrizione dei
principali file di progetto.
Infine si analizzerà la struttura base di una qualsiasi applicazione Symbian, studiandone le classi principali e le relazioni che intercorrono tra esse e con il framework, nonché
una visione generale delle principali caratteristiche tecniche e implementative di Symbian.
3.4.1
Processo di sviluppo
Il processo di sviluppo si dipana attraverso una serie di passi che portano all’utilizzo
funzionale dell’applicazione sul terminale mobile. Essi sono:
7
Termine inglese usato per indicare il processo di caricamento dell’applicazione compilata sul
dispositivo finale.
34
1. Scelta del Software Development Kit (SDK)
2. Definizione dei componenti di progetto
3. Compilazione per cellulare
4. Deploy
Scelta del Software Development Kit
Vi sono numerose e diverse versioni di SDK disponibili, ognuna costruita su specifiche
distribuzioni di Symbian e quindi per specifici prodotti della Serie 60. Una SDK contiene
un buon numero di strumenti, API, librerie e documentazione per lo sviluppo di nuove applicazioni. È necessario scegliere la corretta versione del SDK per il particolare prodotto
scelto.
Nokia rilascia SDK adatte allo sviluppo di specifiche versioni della piattaforma Serie
60. Questo significa che ogni prodotto della Serie 60 è basato su una certa distribuzione
della piattaforma, e le SDK sono progettate e per essere appropriate allo sviluppo di quella
particolare versione. Una particolare SDK può altresı̀ essere adatta per versioni precedenti
della piattaforma, ma questa “backward compatibility”8 non è in linea di massima una
regola generale e dipende dalla versione del sistema operativo Symbian usato alla base
della piattaforma, dalle API usate dal programmatore e dalle modifiche che queste API
hanno subito tra una versione e la successiva.
Definizione dei componenti di progetto
Symbian dispone di un metodo per specificare i progetti in modo indipendente rispetto alla piattaforma e rispetto al compilatore. Tale metodologia consiste nella creazione di file di progetto universali chiamati nomeProgetto.mmp e bld.inf, in cui
nomeProgetto è il nome del componente o applicazione da sviluppare. Questi due
8
Letteralmente compatibilità all’indietro, cioè la possibilità di utilizzare vecchie applicazioni su nuove
piattaforme.
35
file di testo possono poi essere usati come punto di partenza per qualsiasi opzione di
compilazione, IDE (Integrated Development Environment) e variante di piattaforma.
Il file bld.inf specifica il nome di tutti i componenti del progetto che devono essere
compilati e cioè contiene il nome del file mmp, il quale contiene a sua volta le specifiche
del progetto. Entrambi i file sono in formato di puro testo, e spesso nel bld.inf si ha
semplicemente il nome del file mmp che definisce l’applicazione che si sta creando. Se il
progetto consiste di componenti multipli, come possono essere specifiche librerie, allora
ogni componente possiede il suo file di specifica mmp, ognuno dei quali è elencato nel file
bld.inf del progetto.
Tipicamente viene impiegato lo strumento della SDK Symbian bldmake che prende
come input questi due file e genera un file di comando chiamato abld.bat. Quest’ultimo può essere usato dal prompt dei comandi per eseguire un certo numero di operazioni
relative al progetto, come la generazione del makefile specifico per la piattaforma e
per l’IDE. Inoltre, se sono disponibili i codici sorgenti del progetto, il comando abld
permette di compilare l’applicazione per una o più piattaforme.
Il file mmp ha la seguente struttura
TARGET
BlueVoice.app
TARGETTYPE
UID
app
0x100039CE 0x101FF1C6
TARGETPATH \system\apps\BlueVoice
SOURCEPATH ..\src
SOURCE
BlueVoiceApp.cpp
RESOURCE ..\data\BlueVoice.rss
LANG
SC
USERINCLUDE .
SYSTEMINCLUDE
. \epoc32\include
LIBRARY euser.lib
AIF BlueVoice.aif path resource
[color-depth] source-bitmap-list
• Il campo TARGET specifica il file generato dal progetto. Sono necessari solamente
36
il nome del file e l’estensione perché il percorso dipende dalla piattaforma usata.
Il TARGETTYPE conferma quanto indicato nel campo precedente, specificando se
il progetto è un programma eseguibile (exe), un’applicazione grafica (app), una
libreria dinamica (dll) o un device driver fisico (pdd).
• L’ UID rappresenta l’identificatore unico del progetto.
• I file binari prodotti in output vengono posti nel percorso indicato da TARGETPATH.
• Il percorso dove trovare i sorgenti sono invece posti nella cartella SOURCEPATH,
mentre i singoli file sono specificati dal campo SOURCE che può essere usato più
volte.
• I campi USERINCLUDE e SYSTEMINCLUDE specificano le directory dove ricercare i file di inclusione rispettivamente dell’utente e di sistema. Tutti i progetti Symbian debbono specificare \epoc32\include\ nel percorso indicato da
SYSTEMINCLUDE.
• Il campo LANG permette di specificare il linguaggio usato per generare i file per le
risorse per ogni lingua indicata.
• Le risorse usate dal progetto sono indicate nei file definiti dal campo RESOURCE.
I file risorsa definiscono appunto tutte le risorse di un’applicazione, come stringhe,
menu, finestre e altri elementi del display personalizzabili. Esse sono gestite al di
fuori del codice sorgente dell’applicazione per rendere la localizzazione, e quindi
la traduzione in lingue diverse, più semplice.
• Ogni linea che inizia con LIBRARY indica una specifica libreria .lib a cui collegarsi.
• AIF definisce l’Application Information File, ovvero il file contenente l’icona bitmap e relativa didascalia dell’applicazione.
37
Poiché la maggior parte dei progetti vengono sviluppati nell’ambito di un IDE, è
conveniente creare file adatti per tale ambiente, in modo da permettere lo sviluppo, la
compilazione e il debug dell’applicazione con il totale supporto dell’IDE, ma è possibile
svolgere tali operazioni anche da linea di comando. La figura 3.4 illustra l’uso dei due
generici file di progetto per Symbian OS per la generazione degli altri file dipendenti dalla piattaforma, sia mediante l’uso di un IDE che con il semplice uso del comando dal
prompt.
Figura 3.4.
Generazione dei file di progetto specifici mediante file generici Symbian
38
Compilazione per cellulare
La compilazione per un dispositivo della Serie 60 mediante Visual C++ deve essere effettuata da linea di comando usando il file abld.bat, mentre IDE come CodeWarrior
permettono tale operazione all’interno dell’ambiente di sviluppo. Nel caso di dispositivi
Symbian l’hardware che esegue l’applicazione è un processore ARM ed è perciò necessario un compilatore per PC adatto9 per ottenere gli eseguibili in un formato binario
appropriato al processore ARM.
Il metodo più generale per eseguire questa operazione è da prompt dei comandi. È
necessario accedere alla cartella group del progetto dove è contenuto il file bld.inf ed
eseguire i seguenti comandi:
1. bldmake bldfiles per generare il file abld.bat
2.
• abld build armi urel per Visual C++ e CodeWarrior
• abld build armib urel per Borland C++
Questo farà si che abld invochi il comando di sistema “build” preposto alla crosscompilation10 e al linking11 per produrre i file richiesti per la creazione dell’applicazione,
inclusi i file delle risorse, e quindi per l’esecuzione sul terminale mobile.
Vi sono tre tipi diversi di binari eseguibili, o “Application Binary Interfaces” (ABI)
che possono essere generati per dispositivi basati sul processore ARM: ARMI, ARM4
e Thumb. ARM4 ha un lieve vantaggio di performance rispetto ad ARMI al costo di
una maggiore dimensione del binario, ma tuttavia non è interoperabile con Thumb che
è il minore in termini di dimensioni del codice poiché usa istruzioni su 16 bit piuttosto
che su 32 bit. L’unico binario che è interoperabile con le altre due varianti è ARMI
9
Come il compilatore GNU gcc C++ fornito dalla SDK della Serie 60
Un cross-compilatore è un compilatore in grado di produrre codice eseguibile per una piattaforma
diversa da quella su su cui tale compilatore viene eseguito. È un valido strumento se si vuole compilare per
una piattaforma a cui non si ha accesso, o perché è sconveniente la compilazione in tale ambito come nel
caso di sistemi embedded.
11
Il linking è il processo di integrazione dei vari moduli (da intendersi come sottoprogrammi o librerie)
referenziati da un programma in una singola unità eseguibile. Il linker (o link editor) è un programma che
prende uno o più oggetti generati dai compilatori e li assembla in un unico programma eseguibile.
10
39
(ARM Interworking), ed è per questo che è conveniente adottare questa scelta in modo da
garantire la compatibilità con il maggior numero di dispositivi fisici.
I passi della compilazione comprendono inoltre la compilazione delle risorse e la
creazione del file .aif.
Il trasferimento dei file può avvenire copiando questi ultimi sulla memory card, ma
tipicamente questo passo è preceduto dall’impacchettamento di tutti i componenti applicativi in un particolare file di installazione. Nella sezione successiva è sintetizzata questa
procedura.
Deploy
Il deploy consiste nel riunire i vari componenti di un’applicazione per trasferirli nel dispositivo della Serie 60 e mandarli in esecuzione. Le applicazioni vengono inviate sotto
forma di un file .sis ovvero Symbian Installation System, cioè un singolo file di archivio
compresso contenente tutti i file necessari per l’installazione, più qualche informazione
opzionale per il processo di installazione. Il file .sis fornisce una semplice e consistente
interfaccia utente per poter installare applicazioni, dati o informazioni di configurazione
su dispositivi basati sul sistema operativo Symbian.
Per produrre un file di installazione la SDK della Serie 60 di Symbian fornisce uno
strumento chiamato makesis.exe che prende come parametro di ingresso il file di package nomeProgetto.pkg ovvero il file definito in forma testuale e contenente informazioni sulla lingua, UID e versione dell’applicazione, un’identificativo per applicazioni
della Serie 60, ed infine i file compilati necessari per eseguire l’applicazione sul dispositivo. È quindi necessario accedere alla cartella contenente tale file (tipicamente denominata
install o sis) ed eseguire il comando:
makesis nomeProgetto.pkg
Una volta creato con successo il file .sis è sufficiente trasferirlo sul dispositivo per
40
poter usufruire dell’applicazione. Si hanno potenzialmente tre opzioni per l’invio, in base
al dispositivo che si usa e ai servizi disponibili. L’installazione può avvenire mediante
una sessione Bluetooth o infrarossa tra il PC e il cellulare stabilita via software (per esempio Nokia PC Suite), o gestita dalle applicazioni di messaggistica che intercettano il file
allegato al messaggio breve inviato. Infine il file .sis può essere inviato come allegato
di una mail e l’installazione è automaticamente iniziata all’apertura del documento.
Quel che rimane del file di installazione è una versione ridotta del .sis file, che rimane sul dispositivo per controllare un’eventuale disinstallazione dell’applicazione, mediante lo strumento “Manager”. Tale file contiene poche informazioni (solo quelle richieste
per la rimozione) ed ha infatti dimensioni significativamente minori rispetto all’originale.
3.4.2
Applicazioni Symbian
Le applicazioni possono seguire diversi processi di modellizzazione nello sviluppo, dipendentemente da molti fattori, come per esempio le piattaforme di utilizzo e le caratteristiche del software. Di seguito verrà presentato oltre che il framework applicativo che
gestisce il ciclo di vita di un’applicazione, anche i suoi componenti di base, senza i quali
non è possibile avere un prodotto Symbian.
Il framework applicativo
Il framework applicativo o application framework è costituito da un insieme di classi di
base e rappresenta il cuore di tutte le applicazioni. Tali classi formano la struttura di ogni
applicazione e incapsulano le interazioni tra esse e i server del sistema operativo, di cui è
già stato trattato nel paragrafo 3.3.2.
La figura 3.5 mostra, mediante un diagramma UML, il raggruppamento concettuale
delle classi dell’application framework, le API contenute in questi gruppi e le relazioni di
eredità.
Il primo livello nella gerarchia delle classi è diviso in due componenti fondamentali
denominati AppArc e CONE. AppArc significa “Application Architecture”, e fornisce la
41
Figura 3.5.
Framework applicativo
struttura di base delle applicazioni, i meccanismi per inviare informazioni di sistema alle
applicazioni e uso di dati persistenti mediante il File Server. Le classi appartenenti a tale
categoria possiedono il prefisso Apa.
CONE è l’abbreviazione di “CONtrol Environment”, e le classi di questo componente possiedono i meccanismi per gestire l’interfaccia utente, interagendo con il Window
Server12 . Le classi di tale componente sono caratterizzate dal prefisso Coe.
Il secondo livello di classi è rappresentato dal componente Symbian Uikon. Esso è
un livello Symbian di interfaccia utente grafica che fornisce controlli generici e implementazioni indipendenti dall’hardware per classi astratte e altamente funzionali. Fornisce
inoltre le librerie UI che sono comuni a tutte le piattaforme del sistema operativo Symbian. In questo livello possono essere creati alcuni controlli concreti della UI come list
12
Il Window Server è un server Symbian che controlla gli input dell’utente.
42
box e scroll bar, riferiti sovente come controlli Eikon13 . Conviene comunque usare i controlli Avkon14 perché garantiscono il corretto comportamento per le applicazioni Serie 60.
Le classi in questo componente hanno il prefisso Eik.
Il terzo livello consiste nell’insieme di classi Avkon, le quali rappresentano le funzionalità per l’interfaccia utente di base della Serie 60. Tale livello è un’implementazione
puramente per la Serie 60 e un’applicazione per questa piattaforma dovrebbe sempre derivare da tali classi piuttosto che quelle generiche Symbian. Le classi Avkon hanno il
prefisso Akn.
L’ultimo livello, quello specifico per le applicazioni, illustra come le classi di un’applicazione dovrebbero derivare dalle classi Avkon. Tali classi e le loro funzionalità saranno
dettagliate meglio nella sezione successiva. In definitiva si può riassumere che le classi
del primo livello sono astratte e definiscono semplicemente l’interfaccia alle API del framework; il secondo livello aggiunge un’implementazione comune, condivisibile con altre
piattaforme Symbian OS; il terzo fornisce una specifica implementazione al framework
per la Serie 60 e il quarto rappresenta il livello di implementazione dello sviluppatore.
Architettura applicativa
La terminologia architettura applicativa si riferisce ad una insieme di classi dell’application framework che collettivamente formano un’applicazione. Le applicazioni possono
avere sottili differenze architetturali basate sul progetto dell’interfaccia grafica richiesto,
ma in’ultima analisi le classi preposte alla costituzione dell’applicazione condividono
alcune funzionalità di base:
• Permettono l’interazione con l’utente rispondendo ad eventi come la scelta di un
opzione da un menu
13
EIKON consiste di un framework di programmazione e di un insieme di controlli concreti e finestre standard. EIKON è stato rimpiazzato in Symbian OS v6.0 da UIKON e da librerie specifiche per
piattaforma. Queste librerie UI sono chiamate Avkon per la Serie 60.
14
Librerie standard specifiche per la Serie 60. Sono sviluppate sulla tecnologia Symbian Uikon.
43
• Rispondono a eventi di sistema come l’aggiornamento dello schermo causato dal
Windows Server
• Salvano e ripristinano dati applicativi
• Identificano unicamente l’applicazione al framework e ne forniscono informazioni
come icone e didascalia
Il paradigma Modello-Vista-Controllo
Sarebbe buona norma dividere le applicazioni tra la parte che presenta i dati all’utente (l’interfaccia grafica) e quella preposta alla manipolazione dei dati e alle operazioni non visibili all’utente. Questa separazione può essere ottenuta mediante lo schema
Modello-Vista-Controllo o MVC, tipico delle applicazioni S60. Il paradigma MVC divide
l’applicazione in tre moduli distinti:
• Modello : contiene e manipola i dati nel programma.
• Vista : definisce come i dati del Modello vengono presentati all’utente, ed è quindi
la vista attraverso la quale l’utente vede il Modello. La Vista inoltra i comandi
ricevuti e le richieste al modulo di Controllo.
• Controllo : definisce come l’interfaccia utente reagisce alle richieste e ai comandi ricevuti. È quindi la parte del programma che aggiorna il Modello e che invia le richieste alla Vista per ridisegnare lo schermo in modo da mostrarne gli
aggiornamenti.
In questo modo la struttura MVC divide l’applicazione in moduli logicamente disaccoppiati l’uno dall’altro. Un componente disaccoppiato può essere modificato o rimosso
senza apportare modifiche agli altri componenti e questo va indubbiamente ad impattare
in modo positivo sulla manutenibilità, flessibilità e portabilità del software.
44
Classi di base dell’applicazione
Le applicazioni Serie 60 seguono il paradigma MVC poiché Symbian OS ne consiglia
l’uso. L’anatomia di base di un’applicazione consiste di un “motore”, a cui ci si riferisce col termine di engine, di un’interfaccia grafica e di un componente per il modulo
della Vista, in particolare si hanno le seguenti classi per fornire le funzionalità illustrate
precedentemente:
• classe Application : il suo ruolo è statico e, oltre a servire da entry point15 principale dell’applicazione, invia al framework informazioni relative all’applicazione
come icone e didascalie rappresentative (e questo si vede nel menu di avvio di telefoni Symbian Serie 60) e serve per definire le proprietà dell’applicativo. La classe
Application non si occupa minimamente dei dati applicativi né degli algoritmi che
li elaborano, ma possiede il compito di costruire un nuovo oggetto della classe
Document (vedi punto seguente) e fornire funzioni che permettono di ottenere la
didascalia della funzione, l’accesso al suo file .ini e il suo identificatore unico
(UID). Le classi di questa categoria derivano da CAknApplication
• classe Document : rappresenta il modello dei dati dell’applicazione ed è tipicamente usata per caricare i dati in file, permettendo cosı̀ all’applicazione di essere
persistente. Fornisce inoltre un metodo per costruire oggetti della classe AppUi ed
è derivata da CAknDocument.
• classe AppUi : è la principale classe per l’interfaccia utente dell’applicazione. Essa crea e gestisce i controlli per visualizzare i dati, centralizza la gestione degli
input da menu e toolbar ed è destinataria di numerose notifiche provenienti dal framework come la digitazione dei tasti da parte dell’utente o di eventi di sistema.
La classe AppUi tuttavia è totalmente invisibile, nel senso che delega le operazioni
di visualizzazione (drawing) alla classe AppView che viene creata appunto per le
interazioni con lo schermo. Le classi AppUi derivano da CAknAppUi.
15
È il punto d’ingresso invocato dal sistema operativo subito dopo il caricamento.
45
• classe AppView : ha lo scopo di visualizzare i dati dell’applicazione sullo schermo
e permetterne l’interazione. Tale classe eredita da CCoeControl.
• classe Engine : costituisce la componente Modello del paradigma MVC e non è
rappresentato da una specifica classe Symbian Serie 60, ma incapsula i dati dell’applicazione e i suoi algoritmi. L’Engine appartiene alla classe Document (o a quella
AppUi) che può usarne le funzionalità per caricare i dati.
Le classi presentate possono essere collocate nel paradigma MVC come viene rappresentato nella figura 3.6
Figura 3.6.
3.4.3
Archiutettura applicativa e MVC
Convenzione dei nomi
I programmatori Symbian utilizzano delle convenzioni per i nomi che hanno dei significati particolari in relazione alle funzionalità delle classi, all’appartenenza degli oggetti e
alle necessità di de-allocazione della memoria. Esse sono progettate per evitare errori di
46
programmazione e facilitano lo sviluppo di applicazioni, ed è quindi buona norma attenersi a tali vincoli, anche per permettere la manutenibilità del codice ed il suo riutilizzo
da parte di altri programmatori.
Si hanno i tipi fondamentali definiti da un insieme di typedef, il cui uso è da
preferirsi rispetto agli equivalenti tipi nativi di C++. Sono illustrati in tabella 3.1
Tabella 3.1. Tipi fondamentali in Symbian OS
Tipi di Symbian OS
TBool (ETrue/EFalse)
TUint8 (TInt8)
TUint16 (TInt16)
TUint32, TUint
TInt32, TInt
TUint64 (TInt64)
TReal64, TReal
TAny*
Descrizione
Valore Booleano su 32 bit
intero con segno (senza segno) su 8 bit
intero senza segno su 32 bit
intero con segno su 32 bit
Rappresentazione in floating point su 64 bit
Puntatore a un tipo non specificato
Le classi devono invece avere un nome descrittivo dell’oggetto e devono avere il
prefisso C, T, R, o M in base alle seguenti regole
Classi T : classi semplici che non possiedono nessun oggetto esterno o altre risorse, e
che non richiedono perciò un distruttore esplicito. Sono molto simili a quelli che in
C++ sono chiamati come tipi “built-in”, cioè quelle variabili definite dall’utente con
il comando typedef. Possono essere allocate sia sullo stack16 che sullo heap17 .
Classi C : classi derivanti da CBase e allocate sullo heap (non sullo stack). Dalla classe
CBase ereditano il costruttore che inizializza a 0 l’oggetto e il distruttore virtuale.
Queste classi hanno la responsabilità di de-allocare altri oggetti, cioè possiedono
puntatori ad oggetti costruiti sullo heap o gestori di risorse.
16
È adatto per oggetti dalla dimensione fissa il cui tempo di vita coincide con la funzione che li ha creati.
Gli oggetti allocati sullo stack non debbono essere troppo grandi e possono essere brevi stringhe o puntatori.
17
Viene utilizzato per oggetti che sono costruiti o manipolati durante l’esecuzione, o perché la loro
dimensione è troppo grande per lo stack.
47
Classi R : classi delle risorse che contengono dei gestori per una risorsa reale mantenuta
da un server o all’interno del kernel. Sono oggetti tipicamente istanziati sullo stack
e la cui de-allocazione è gestita da un metodo Close.
Classi M : dette anche classi “Mixin”, sono di fatto delle interfacce per descrivere definizioni astratte che vengono poi implementate dalle classi che derivano da esse. Rappresentano l’unico modo concesso dal sistema Symbian per effettuare l’ereditarietà
multipla.
Anche le funzioni hanno alcune regole sui nomi:
• I nomi delle funzioni iniziano con una lettera maiuscola
• Terminano con la lettera “L” se possono lanciare un’eccezione
• Terminano con la lettera “D” se cancellano un oggetto
• Terminano con la lettera “C” se lasciano un oggetto sul cleanup stack
3.4.4
Stringhe e descrittori
In Symbian OS la gestione delle stringhe è effettuata mediante particolari classi denominate descrittori, che in parte differiscono dalle tradizionali stringhe di C++ terminate dal cosiddetto “null-terminator”. I descrittori hanno infatti questo nome perché sono
auto-descrittivi, nel senso che tali oggetti incapsulano sia i dati veri e propri, sia informazioni come la loro lunghezza e la massima dimensione allocata. Questo significa che i
descrittori possono prevenire le scritture dei dati in aree di memoria non allocate.
In aggiunta, poiché non è necessario un terminatore della stringa, possono essere caricati in un descrittore anche dati puramente binari oltre che testuali, permettendo a queste
classi di offrire una consistente interfaccia per gestire entrambi i tipi di dati. Questo
è un chiaro esempio di come il codice in Symbian viene riutilizzato per diminuire la
dimensione dei programmi.
48
I descrittori sono manipolati grazie all’utilizzo di un insieme di metodi forniti dalle
due classi base TDesC (per funzionalità che non modificano i dati) e TDes (per funzionalità legate alla modifica dei dati). Come opzione predefinita i descrittori sono in formato
Unicode, e quindi ogni carattere è su 16 bit, ma possono essere analogamente usati descrittori su 8 bit specificandone esplicitamente il tipo. I principali tipi di descrittori e le
relative classi sono:
Astratti (TDes, TDesC) : sono le classi base da cui ereditano gli altri descrittori. Esse
non possono essere istanziate e vengono perciò usate nei parametri delle funzioni.
Letterali (TLitC, _LIT()) : usati per memorizzare stringhe e testo.
Buffer (TBuf, TBufC) : contengono dati memorizzati sullo stack e la dimensione è
definita in fase di compilazione.
Heap (HBufC) : contengono dati memorizzati sullo heap e la dimensione viene determinata in fase di esecuzione.
Puntatori (TPtr, TPtrC) : sono riferimenti a dati contenuti al di fuori della classe.
3.4.5
Gestione delle eccezioni
Fino alla versione 6 del sistema operativo Symbian il sistema di gestione delle eccezioni
mediante try, catch() e throw non era supportata dalla piattaforma per ragioni storiche18 e di efficienza19 . Per fornire un’alternativa al controllo degli errori, Symbian usa
un paradigma più leggero che funziona mediante le TRAP harness e le leave.
Una cosiddetta leave è l’equivalente in Symbian dell’eccezione nel C++ tradizionale,
ed è usata per propagare un errore all’indietro sullo stack delle chiamate fin dove esso
non venga “catturato” da una TRAP e gestito. Una TRAP harness non è altro che l’equivalente del blocco catch del C++ ed è più leggera in termini computazionali in quanto
18
Quando furono rilasciate le prime versioni di Symbian l’implementazione del meccanismo try-catch
non era ancora stato standardizzato
19
La gestione ANSI C++ degli errori incrementa notevolmente le dimensioni del codice
49
non viene lanciato un oggetto (come invece fa l’invocazione della throw in C++), ma
viene restituito un codice d’errore su 32 bit alla macro TRAP o TRAPD preposte alla
cattura. L’esecuzione del codice termina effettivamente ad ogni leave lanciata e riprende
all’interno della TRAP. Viene lanciata un’eccezione leave nei seguenti casi:
• chiamando il metodo statico User::Leave().
• mediante la chiamata alla versione di Symbian dell’operatore new che prende il
parametro ELeave e lancia una leave se non c’è sufficiente memoria per allocare
l’oggetto in fase di costruzione.
• in generale ogni qual volta una risorsa o della memoria non può essere allocata.
Poiché la gestione delle eccezioni di Symbian OS non fa parte della sintassi di C++,
non c’è modo per il compilatore di controllare se un metodo che può lanciare una leave sia
o meno all’interno di una TRAP. La soluzione è quella già introdotta nella sezione sulla
convenzione dei nomi per cui una funzione che può causare un’eccezione possiede una
“L” alla fine del nome. Inoltre, a meno che una funzione chiamante gestisce l’eccezione
con una TRAP, anch’essa dovrà avere una “L” aggiunta al suo nome per indicare che
indirettamente può lanciare una leave. In questo modo il programmatore che ha a che
fare con una funzione terminante in L deve considerare i potenziali effetti sulla memoria
allocata sullo heap se quel metodo dovesse fallire.
Diversi invece sono i panic, cioè errori che non possono essere gestiti da una TRAP,
ad esempio quando il programmatore eccede i limiti del descrittore. Non potendo essere
catturato esso risulta nella terminazione del thread che ha lanciato il panic; se tale thread
coincide col processo principale, anch’esso verrà terminato.
Le regole per creare oggetti sullo heap contengono fondamentalmente tre concetti:
costruttori non pubblici, cleanup stack e costruzione in due fasi.
Cleanup stack
Quando una funzione lancia un’eccezione tutte le variabili locali e i puntatori alle celle
di memoria vengono persi. Per evitare questo, Symbian OS fornisce un cleanup stack
50
nel quale lo sviluppatore carica i puntatori per tutto il tempo in cui vi è il rischio di
un memory leak nel caso in cui la funzione dovesse fallire. Se ciò dovesse accadere
i puntatori sono automaticamente estratti dal cleanup stack e le corrispondenti aree di
memoria sono rilasciate.
Normalmente tutte le risorse e le aree di memoria allocate sono liberate quando il
thread che li ha istanziati muore, ma ovviamente non è consigliabile usare la memoria in
questo modo poiché è possibile che certe applicazioni rimangano in esecuzione per mesi
prima che il terminale mobile venga riavviato. Una situazione in cui si può verificare
un memory leak è quella in cui si utilizzano variabili locali per mantenere i puntatori
alle aree di memoria sullo heap. Se però la funzione in cui sono definite tali variabili
dovesse lanciare una leave, essi verrebbero persi e non ci sarebbe modo per liberare e
quindi riutilizzare quelle celle di memoria. La soluzione offerta da Symbian è quella di
caricare tali puntatori nel cleanup stack, uno speciale stack per tenere traccia dei gestori
delle risorse e dei puntatori di memoria. Automaticamente, in caso di fallimento della
funzione, la memoria viene ripristinata senza dare adito a memory leak.
Costruzione in due fasi
Il bisogno della costruzione in due fasi sorge se un costruttore ha bisogno di allocare delle
risorse o puntatori ad altri oggetti o comunque se deve svolgere operazioni potenzialmente
pericolose in termini di allocazione della memoria e può quindi essere visto come uno
sforzo per prevenire che la creazione di un oggetto lanci un’eccezione. Il costruttore però
non deve mai trovarsi in questa situazione poiché il distruttore non verrebbe chiamato in
caso di mancata riuscita dell’allocazione.
La classe deve perciò esporre un metodo pubblico e statico NewL per la creazione
dell’oggetto. Lo sviluppatore non può usare il normale costruttore direttamente perché
esso è dichiarato protetto (cioè può essere utilizzata solamente da oggetti che derivano da
tale classe) o privato (non accessibile al di fuori della classe), mentre la funzione NewL si
occupa di gestire l’allocazione della memoria in modo da evitare memory leak. La classe
NewL incapsula l’uso del cleanup stack e segue i passi elencati:
51
1. L’oggetto viene creato usando una versione “overloaded”20 del’operatore new che
accetta come argomento ELeave il quale indica che la creazione dell’oggetto fallisce se la memoria necessaria non può essere allocata. Questa è la prima fase della
costruzione
2. Il puntatore all’oggetto creato viene inserito nel cleanup stack.
3. La seconda fase della costruzione include la creazione degli oggetti posseduti dall’oggetto appena creato. Secondo la regola delle due fasi questo viene implementato
dell funzione chiamata ConstructL.
4. Al termine, quando si è in una situazione sicura (un eventuale leave non causerebbe
la perdita dei puntatori), il puntatore dell’oggetto viene estratto dal cleanup stack.
Il codice relativo alla costruzione può essere ottimizzato mediante l’uso della funzione, anch’essa pubblica e statica, NewLC che chiama l’operatore new con la costante
ELeave, inserisce l’istanza temporanea della classe nel cleanup stack e chiama il metodo
ConstrucL lasciando l’oggetto nello stack da cui verrà estratto dalla NewL.
3.4.6
Gestione degli eventi asincroni
Per concludere questa parte dedicata al sistema operativo Symbian è doveroso menzionare, seppure brevemente, il meccanismo di gestione degli eventi asincroni mediante l’uso
degli Active Object. Innanzitutto bisogna tenere presente che i thread possono essere utilizzati per effettuare multi-tasking con preemption ma che il loro uso, sebbene frequente
da parte del sistema operativo, è scoraggiato poiché è difficile da sviluppare, è inefficiente
ed è pesante in quanto richiede context switching.
Un altro meccanismo è quello che sfrutta gli active object e porta ad un multi-tasking
cooperativo. Essi ereditano dalla classe CActive che fornisce funzioni virtuali e campi
usati dal framework. È importante notare che gli active object vengono eseguiti all’interno
20
L’overloading è una caratteristica dei linguaggi ad oggetti per cui è permesso avere più funzioni con lo
stesso nome, ma con parametri diversi e quindi funzionalità differenti
52
di un thread , il che significa che la loro schedulazione non necessita di un cambio di
thread o cambio di contesto (che ovviamente può succedere insieme alla schedulazione
degli active object, per altri scopi) e che rende questa tecnica più leggera se comparata a
quella dei thread.
Gli active object implementano invece un multi-tasking senza preemption o senza
diritto di prelazione21 cioè una richiesta è eseguita completamente, una volta che il framework l’ha iniziata.
Gli active object hanno un loro schedulatore denominato Active Scheduler che deve
essere installato all’interno del thread, al quale deve essere aggiunto l’eventuale active
object e che infine deve essere attivato. Tipicamente un active object sfrutta un servizio
asincrono fornito da un qualche server di cui possiede un “handle”, ovvero un oggetto per
poterne gestire l’uso e mediante il quale può avere accesso all’interfaccia del server per
potere rilasciare delle richieste asincrone. Caratterizzante lo stato della richiesta è il parametro iStatus che, una volta istanziata la richiesta, assume il valore corrispondente
alla costante KRequestPending. Per notificare all’active scheduler che l’oggetto è in
attesa di completamento di una risorsa viene chiamato il metodo SetActive, in modo
che l’event loop implementato nello schedulatore venga attivato grazie alla chiamata alla
funzione statica User::WaitForAnyRequest. In tal modo viene decrementato di
uno il valore associato al semaforo del thread e, se il valore diventa negativo, il thread si
mette in attesa di richieste completate dal server. Al termine del servizio, il server segnala
il completamento della richiesta al thread e, nel caso in cui il valore del semaforo diventi
nullo o positivo, lo schedulatore sceglie l’active object che ha fatto la richiesta e che ha la
priorità più alta e ne richiama la funzione RunL. Tale funzione è riscritta dallo sviluppatori a seconda delle esigenze e viene usata dallo schedulatore quando la richiesta è stata
soddisfatta. Se l’active object non ha intenzione di aspettare il completamento può chiamare la funzione Cancel la quale invoca la DoCancel opportunamente implementata
dall’utente, nella quale vengono rilasciate le risorse e chiusi i gestori dei server.
21
In questo caso lo scheduler deve attendere che il processo termini o che cambi il suo stato da quello di
esecuzione a quello di attesa o di pronto, a seguito, ad esempio, di una richiesta di I/O oppure a causa di un
segnale di interruzione (interrupt).
53
3.5
Scelte implementative
Dall’analisi che è stata effettuata in questo capitolo si può concludere che, allo stato attuale, J2ME è diventato uno strumento di sviluppo completo, che offre moltissime delle funzionalità messe a disposizione da Symbian OS. Inoltre risulta evidente uno dei vantaggi
derivanti dalla scalabilità e dalla modularità di J2ME, e cioè la possibilità di implementare nuovi profili senza modificare le configurazioni di base esistenti con una conseguente
riduzione dei tempi di sviluppo e dei costi di realizzazione.
È anche da evidenziare che J2ME si è appoggiato a Symbian traendone miglioramenti in termini di performance e robustezza, e che Symbian trae invece vantaggio dal fatto
che includere J2ME nel suo core rende il sistema operativo più “vendibile”. Non bisogna
dimenticare infatti che, ad esempio, per i leader del mobile gaming conviene, per diffondere i propri prodotti, realizzarli utilizzando una tecnologia indipendente dal sistema
operativo, e cioè Java.
D’altro canto C++ permette di avere le migliori performance in termini di lavoro svolto dalla CPU e facilita un più basso consumo di memoria e ovviamente di energia. Poiché Java vede tra gli obiettivi di progetto quello di poter essere compatibile su qualsiasi
dispositivo, è intrinsecamente caratterizzato da lacune e compromessi nelle sue funzionalità generali. Un’applicazione Java, ad esempio, non può avere controllo di tutte le
caratteristiche di un telefono cellulare come la rubrica telefonica o il calendario.
Poiché l’applicazione di client VoIP richiede l’utilizzo di hardware specifici come
l’auricolare e il microfono del telefono, necessita di utilizzi performanti delle capacità
multimediali per poter fornire un servizio full-duplex22 , e ha bisogno di application engine
particolari come ad esempio il registro delle chiamate per salvare le chiamate perse, lo
studio di fattibilità effettuato ha fatto vertere la decisione verso la scelta di un’applicazione
realizzata in linguaggio C++ per Symbian, piuttosto di una basata su Java.
Purtroppo questa decisione ha escluso in partenza la possibilità di usare un ambiente
22
Il full-duplex è una modalità di invio e ricezione di informazioni digitali, con funzione completamente
bidirezionale e indica, in questo caso, la modalità di conversazione in un sistema di comunicazione, che è
la modalità tipica di una conversazione telefonica tradizionale ovvero in cui i due utenti parlano e ascoltano
contemporaneamente.
54
di sviluppo potente e versatile come NetBeans che dispone, nelle ultime versioni, di strumenti avanzati per la produzione di software per terminali mobili, coadiuvato da un tool
per facilitare l’implementazione di interfacce grafiche.
Per quanto riguarda il mondo di Symbian tra gli IDE principali vi è CodeWarrior che
è però un software a pagamento. CodeWarrior è stato rimpiazzato nel 2006 da Carbide.c++, un IDE basato su Eclipse sviluppato dalla Nokia. Carbide.c++ è disponibile nelle
versioni Express, Developer, Professional e OEM con crescenti livelli di capacità, come
progettazione di interfacce grafiche e debug avanzato. Oltre a questi si aggiungono un
plugin di Visual Basic per lo sviluppo di Symbian, di grande potenzialità ma anch’esso
a pagamento, e una versione dell’IDE della Borland per Symbian OS. Poiché è possibile
realizzare software in modo semplice vista la somiglianza ad Eclipse e in modo gratuito
si è scelto come ambiente di sviluppo Carbide.c++ Express, di fatto meno performante di
altre scelte, ma indubbiamente più immediato da utilizzare.
Il pacchetto di sviluppo per applicazioni (SDK) scelto è stato invece quello relativa
alla versione 8.0a di Symbian, cioè quella per il cellulare Nokia 6630, attualmente di
largo utilizzo e disponibile al momento dell’inizio del lavoro.
55
Capitolo 4
Tecnologie di comunicazione
4.1
Introduzione
In questo capitolo verranno trattate le due tecnologie di comunicazione utilizzate per
realizzare le funzionalità dell’applicazione per cellulare sviluppata: Bluetooth e VoIP.
Per quanto riguarda Bluetooth, se ne esaminerà il funzionamento e si darà una descrizione della pila protocollare, limitandosi in particolare modo agli aspetti usati e sviluppati
nella realizzazione dell’applicazione, al fine di evitare una trattazione troppo dettagliata di
tale tecnologia che esula dagli intenti di questo lavoro1 . Si vedrà come i dispositivi si rendono visibili agli altri e si connettono tra di loro, quali tipi di connessione sono supportate
e le librerie usate, sia per la programmazione lato server (API sviluppate in linguaggio C
denominate BlueZ) che per quella lato client (API di sistema Symbian). Saranno perciò
tralasciati particolari legati ai livelli hardware e caratteristiche di basso livello (come il
formato dei pacchetti o le modulazioni usate), trasparenti a livello applicativo.
Analogamente per VoIP verrà fornita una descrizione esaustiva di ciò che si intende
per telefonia sulla rete Internet e, per quanto riguarda i protocolli che VoIP utilizza, ci
si concentrerà prevalentemente su SIP in quanto ha giocato un ruolo determinante nella
definizione del protocollo per la gestione della chiamata del software sviluppato e verrano
1
Per eventuali approfondimenti in materia si rimanda al sito ufficiale [10].
56
4 – Tecnologie di comunicazione
quindi tralasciati gli altri protocolli. Inoltre verrà presentata una particolare implementazione di un’applicazione per PC adatta ad iniziare, gestire e terminare una chiamata VoIP:
SimpleOPAL.
4.2
Bluetooth
Bluetooth è uno standard per comunicazioni radio wireless con corto raggio di copertura
(da 10 a 100 metri), progettato per avere caratteristiche di bassi consumi e transceiver a
basso costo. Nasce nel 1994 sviluppato da Ericsson per rimpiazzare il cablaggio, ed è
oggi disponibile in moltissimi tipi di dispositivi come PDA, cellulari, PC, mouse e cosı̀
via. Nel 1998 Ericsson ha unito i propri sforzi con Intel , IBM, Nokia e Toshiba per
formare il Bluetooth Special Interest Group (SIG). Nel 1999 si sono aggiunte 3Com,
Lucent/Agere e Microsoft, garantendo a Bluetooth di svilupparsi come standard aperto
assicurandogli un’accettazione rapida e piena compatibilità con il mercato.
La prima versione dello standard è la 1.0 (Luglio 1999) che è uscita in tre varianti 1.0,
1.0a e 1.0b. In particolare le versioni 1.0 e 1.0b erano afflitte da molti problemi soprattutto
nell’interoperabilità fra dispositivi di diversi costruttori. La seconda versione è la 1.1
(Febbraio 2001) le cui differenze dalla versione precedente sono legate sostanzialmente
alla correzione di alcuni problemi specifici evidenziatisi durante l’uso, una ottimizzazione
delle prestazioni, e la possibilità di comunicazione su canali non cifrati.
Nel Giugno 2002, l’IEEE ha prodotto una propria versione dello standard 1.1 denominata 802.15 WPANs o IEEE 802.15.1, per indicare il primo “task” delllo standard
802.15 che si occupa di sviluppare uno standard per Wireless Personal Area Network
basato sulle specifiche Bluetooth. Nel novembre 2003 esce quindi la versione 1.2 che
è retrocompatibile con la 1.1 a cui aggiunge miglioramenti per diminuire le interferenze
in zone sovraffollate mediante selezione adattativa della sottobanda, per avere velocità
di trasmissione più elevate e migliore qualità dei collegamenti voce grazie alla extended
Synchronous Connections (eSCO) che in caso di perdita dei dati si ha ritrasmissione. Ma
57
il maggior miglioramento si ha con la versione 2.0 di Bluetooth che permette trasmissioni
da 3 a 10 volte più veloci, copertura a 100 metri e un minor consumo energetico.
Il protocollo Bluetooth lavora sulle frequenze libere di 2,45 Ghz. Per ridurre le interferenze il protocollo divide la banda in 79 canali e provvede a commutare tra i vari canali
1600 volte al secondo (meccanismo denominato Frequency hopping o FH). La versione
1.1 e 1.2 del Bluetooth gestisce velocità di trasferimento fino a 723,1 kbit/s. La versione
2.0 gestisce una modalità ad alta velocità che consente fino a 2,1 Mbit/s. Questa modalità però aumenta la potenza assorbita. La nuova versione utilizza segnali più brevi e
quindi riesce a dimezzare la potenza richiesta rispetto al Bluetooth 1.2 (a parità di traffico
inviato).
4.2.1
Topologia della rete
Due o più dispositivi Bluetooth che stabiliscono una connessione e condividono un canale
radio, formano una piccola rete wireless ad-hoc denominata piconet che ha una capacità
complessiva fino a 1 Mbit/s. In questa configurazione un terminale Bluetooth agisce come
master, controllando il traffico della piconet, mentre tutti gli altri dispositivi si comportano
da slave. Il master è definito come colui che iniziala procedura di connessione per stabilire
la piconet, ed è unico all’interno della rete. Il master stabilisce l’accesso alla rete degli
slave mediante un meccanismo a polling, cioè dando la possibilità di “parlare” agli altri
nodi. All’interno di una piconet possono essere attivi fino a 7 slave (8 se si considera
anche il master), ma è possibile comunque avere fino a 255 ulteriori dispositivi che però
devono essere nello stato inattivo parked, cioè non possono trasmettere, ma mantengono
la sincronizzazione con il master e possono essere riattivati in qualunque momento dal
master.
Due piconet spazialmente sovrapposte possono essere collegate tra loro tramite un dispositivo Bluetooth (gateway o bridge) per formare una scatternet, illustrata in figura 4.1.
Gli slave possono appartenere a diverse piconet, utilizzando la multiplazione a divisione
di tempo, mentre il master di una piconet può essere slave in un’altra piconet.
Le piconet interconnesse all’interno della scatternet formano la struttura portante per
58
Figura 4.1.
Due piconet disposte a formare una scatternet
la Mobile Area Network (MANET), che permette a dispositivi che non comunicano direttamente o che sono fuori dalla loro portata di scambiarsi dati tramite diversi passi nella
scatternet. Le attuali implementazioni di Bluetooth sono rappresentate principalmente da
semplici collegamenti punto a punto tra i dispositivi che sono nel raggio di copertura dell’altro. Le specifiche Bluetooth permettono anche soluzioni di connessioni e topologie più
complesse. È possibile formare Bluetooth scatternet che realizzano una comunicazione
efficiente in più passi con risposte e consumi accettabili per soluzioni end-to-end.
4.2.2
Comunicazione
Quando due dispositivi Bluetooth entrano nello spazio di comunicazione, provano a comunicare tra loro. Se non c’è una piconet disponibile si precede alla negoziazione. Un
dispositivo diventa master (di solito quello che inizia la comunicazione) e l’altro diventa
slave. Ogni dispositivo Bluetooth può funzionare all’interno di una piconet come master,
slave o bridge. I ruoli sono temporanei e cessano con l’esistenza della piconet. Il dispositivo master seleziona la frequenza, i tempi (quando ci sono più passi) e l’ordine degli
slave. Il master è responsabile di alternare slave inattivi verso altri slave in periodi di
inattività.
Master e slave devono scambiarsi indirizzo e clock per permettere allo slave di unirsi
alla piconet. I dispositivi Bluetooth hanno un identificativo unico (Global ID) che viene
59
usato per creare uno schema a più passi. Il master condivide il suo Global ID e clock
con ciascuno slave della sua piconet. Lo slave si deve sincronizzare con il master. Un
bridge o gateway Bluetooth collega due o più piconet per una comunicazione a più passi.
Il bridge comunica con tutte le piconet a lui connesse sincronizzando il proprio clock
con ciascuna piconet, tuttavia può comunicare con solo una piconet alla volta. Il bridge
introduce overhead spostandosi da un clock di una piconet al clock di un’altra piconet e
può diventare un collo di bottiglia. Un bridge può essere slave in tutte le piconet a cui è
connesso, o può essere master in una e slave nelle altre. L’interconnessione di due o più
piconet via bridge determina, come specificato nella sezione precedente, la formazione di
una Bluetooth scatternet.
Un dispositivo Bluetooth può essere nei seguenti stati: Standby, Inquiry, Page, Connected, Transmit, Hold, Park o Sniff come mostrato in figura 4.2. Un dispositivo è in
modalità Standby quando è acceso, ma non è collegato a una piconet. Va nello stato Inquiry quando invia richieste per trovare altri dispositivi a cui potersi collegare. Un master
di una piconet esistente può essere nello stato di Page quando invia messaggi per la ricerca
di dispositivi che può associare alla sua piconet.
Figura 4.2.
Stati di un dispositivo Bluetooth
60
Quando la comunicazione tra il master e il nuovo dispositivo ha successo, il nuovo
dispositivo assume il ruolo di slave, entra nello stato Connected e riceve un indirizzo
attivo. Lo slave mentre è connesso, può trasmettere dati quando il master lo interroga.
Durante la trasmissione dei dati lo slave è nello stato Transmit. Alla fine della trasmissione
ritorna nello stato Connected. Lo stato Sniff è uno stato di basso consumo in cui lo slave
“riposa” per un predeterminato lasso di tempo. Lo stato Hold è un altro stato di basso
consumo in cui lo slave non è attivo per un certo intervallo di tempo. Non c’è trasmissione
dati durante lo stato di Hold. Quando un dispositivo slave non ha dati da trasmettere, il
master può decidere se metterlo nello stato Parked. Lo slave rilascia il suo indirizzo attivo
nella piconet. L’indirizzo sarà dato a un altro slave nella piconet che il master ha riattivato
dallo stato Parked.
Indirizzo e nomi
Ad ogni chip Bluetooth costruito viene assegnato in modo permanente un indirizzo di 48
bit globalmente unico, del tutto simile agli indirizzi MAC Ethernet, e di fatto entrambi gli
spazi di indirizzi sono gestiti dalla stessa organizzazione, l’Autorità di Registrazione dell’IEEE. Questi indirizzi vengono cablati nel dispositivo in fase di costruzione e rimangono
statici per l’intero tempo di vita del chip.
Per la comunicazione con un altro dispositivo Bluetooth, bisogna disporre di un qualche metodo per determinarne l’indirizzo, poiché esso viene utilizzato in tutti i livelli della
pila protocollare Bluetooth, dai protocolli radio di basso livello a quelli applicativi, diversamente da quanto accade per le reti TCP/IP dove l’indirizzo hardware su 48 bit viene
sostituito da quello IP.
Un dispositivo Bluetooth può trasmettere le seguenti informazioni:
• DeviceName
• DeviceClass
• Lista di servizi
61
• Informazioni tecniche, come funzionalità, costruttore, specifiche Bluetooth, ecc.
Qualunque dispositivo può inviare una richiesta per cercare altri dispositivi in visibilità
a cui connettersi e qualunque dispositivo può essere configurato se rispondere o meno a
queste richieste. Se il dispositivo richiedente conosce già l’indirizzo dell’altro questo
risponderà immediatamente inviando le informazioni sopra riportate.
Spesso però gli indirizzi sono sostituiti da nomi assegnati dagli utenti o preimpostati dal produttore con la marca ed il modello, e saranno questi ad apparire quando si fa la
scansione dello spettro. Questo perché per un umano risulta notevolmente complesso avere a che fare con numeri di 48 bit (cosı̀ come lo è per gli indirizzi IP) e quindi nonostante
l’indirizzo fisico sia poi quello che viene effettivamente usato nella comunicazione, si preferisce mostrare all’utente un nome “user-friendly” per identificare una stazione remota.
Questo nome è il DeviceName dell’elenco precedente.
Per quanto riguarda l’informazione DeviceClass, essa fa riferimento alle classi di potenza. I dispositivi Bluetooth vengono infatti suddivisi in tre categorie distinte, a ciascuna delle quali corrisponde una potenza di trasmissione radio ed un range d’azione del
dispositivo Bluetooth, illustrate nell’elenco successivo:
Classe 1 : per dispositivi a lungo raggio (50-120 metri), con potenza massima in uscita
tra 0 dBm (1 mW) e 20 dBm (100 mW);
Classe 2 : per dispositivi a raggio medio (10-30 metri), con potenza massima in uscita
tra -6 dBm (0,25 mW) e 4 dBm (2,5 mW);
Classe 3 : per dispositivi a breve raggio (1-10 metri), con potenza in uscita tra 0 dBm (1
mW) e 0 dBm (1 mW).
In merito alla classificazione enunciata e con riferimento ai dispositivi di classe 1 si
deve dire che la distanza coperta è del tutto teorica poiché la portata è profondamente influenzata dall’hardware USB utilizzato e, cosa del tutto palese, dagli ostacoli posti
tra i diversi dispositivi Bluetooth, e in modo minore dai disturbi creati da altre sorgenti
62
di segnali radio quali cellulari o reti wi-fi. Inoltre, ogni classe Bluetooth determina diversi consumi di corrente del dispositivo. Attualmente la maggior parte dei dispositivi
appartiene alle Classi 2 e 3.
Inquiry e Paging
Le procedure necessarie per creare la piconet sono la inquiry e la paging. La procedura
di ricerca dispositivi e di connessione comincia quando un dispositivo Bluetooth entra
nello stato inquiry di cui le specifiche Bluetooth ne definisce dei codici di accesso per
specificare il tipo di dispositivo che si sta cercando. La procedura di inquiry permette
di identificare i dispositivi (e i relativi indirizzi) nel raggio di copertura, ed è attivata da
un potenziale master sollecitato da una applicazione o periodicamente da una master già
attivo. Il potenziale master invia i pacchetti di inquiry (pacchetti ID contenenti l’Inquiry
Access Code, IAC) su una particolare sequenza di frequency hopping (cioè una sequenza
di frequenze su cui saltare) che copre un sottoinsieme di 32 canali, derivata dal clock del
terminale e dal codice scelto, e attende le risposte.
Periodicamente i dispositivi nel raggio di ricerca entrano nel sotto-stato Inquiry Scan,
nel quale utilizzano la sequenza di frequency hopping del master. Se il dispositivo che
esegue l’inquiry riceve un messaggio di inquiry, entra nel sotto-stato Inquiry Response e
invia un relativo messaggio di risposta che include l’indirizzo del terminale remoto (cioè
il proprio) e il suo clock di sistema, entrambe informazioni necessarie per stabilire una
connessione Bluetooth. Tutti i dispositivi disponibili nel raggio di 10 metri risponderanno
perciò all’inquiry del master, il quale non risponde bensı̀ continua la fase di inquiry fino al
termine di un certo timeout. I potenziali slave che hanno risposto ai pacchetti di inquiring
possono decidere di passare allo stato di Page Scan nel caso decidano di connettersi alla
nuova piconet.
Questo tipicamente richiede che l’utente selezioni manualmente il dispositivo Bluetooth desiderato da una lista che la fase di ricerca ha fornito. Quindi, al tempo speso per
cercare terminali nell’area di ricezione, si somma un tempo indeterminato necessario per
permettere all’utente la scelta del dispositivo.
63
Terminata questa fase e ottenuto l’indirizzo remoto, il dispositivo locale (cioè il potenziale master) entra nello stato di page e comincia a realizzare il paging delle stazioni
che hanno risposto nella fase precedente, per realizzare una connessione con esse e creare
cosı̀ la piconet. Tale procedura viene realizzata una stazione alla volta usando l’indirizzo
dello slave raccolto nella fase di inquiring (o già noto) e il tempo di clock stimato, per
generare una sequenza di frequency hopping (detta appunto page frequency hopping) mediante la quale invia ripetutamente un pacchetto ID che contiene il Device Access Code,
DAC (ricavato dai 24 bit meno significativi dell’indirizzo dello slave). Se una stazione
permette ad altre di connettersi ad esso, entrerà periodicamente nello stato di Page Scan
nel quale viene generata una sequenza basata sul proprio indirizzo locale e clock (e sarà
quindi sincrona con la page frequency hopping).
Da questo stato si passa a quello di Slave Response nel caso in cui lo slave ricevesse
il pacchetto ID con il giusto codice DAC. Ad esso può rispondere con un pacchetto Page
Response, che farà entrare il master nello stato Master Response in cui questi invia alla
stazione un pacchetto FHS (requency Hopping Synchronization) che include il clock e
l’indirizzo del master. La destinazione invia un secondo pacchetto ID identico ai precedenti per conferma e commuta sulla sequenza di hopping indicata dal pacchetto FHS del
master entrando nello stato connesso. Il dispositivo che effettua la procedura diventa definitivamente il master della piconet che viene a costituirsi, e continua eventualmente con
il paging delle altre stazioni.
Una volta che la connessione è stabilita, la comunicazione inizia con un Poll da parte
del master per verificare che la transizione dalla sequenza di hopping della fase di paging
alla nuova sequenza abbia avuto buon esito, e per verificarne il corretto utilizzo, a cui lo
slave risponde con un qualsiasi tipo di pacchetto come conferma. Se la procedura è stata
terminata correttamente i due dispositivi continuano il frequency hopping seguendo uno
schema pseudo-casuale condiviso per tutta la durata della connessione.
4.2.3
Pila Protocollare
Le specifiche Bluetooth dividono lo stack di protocolli Bluetooth in tre gruppi:
64
1. Transport Protocol group
2. Middleware Protocol group
3. Application group
Essi sono raffigurati nella figura 4.3
Figura 4.3.
Stack protocollare Bluetooth
Il Transport Protocol group permette ai dispositivi Bluetooth di individuare altri dispositivi Bluetooth e di gestire la connessione a livello fisico e logico con i protocolli e
applicazioni soprastanti. È da notare che l’uso della parola “transport” nel Trasport Protocol group non indica la coincidenza con il livello di trasporto nel modello di riferimento
OSI, piuttosto corrisponde al livello di collegamento e fisico. I livelli Radio, Baseband,
Link Manager, Logical Link Control and Adaptation (L2CAP) e Host Controller Interface
(HCI) sono raggruppati nel Transport Protocol group. Questi protocolli supportano sia la
trasmissione sincrona che asincrona. Tutti i protocolli in questo gruppo sono necessari
alla comunicazione tra dispositivi Bluetooth.
Il Middleware Protocol group include protocolli di terze parti e standard industriali.
Questi protocolli permettono ad applicazioni esistenti e a nuove applicazioni di operare su
collegamenti Bluetooth. Protocolli standard industriali comprendono i protocolli Pointto-Point Protocol (PPP), Internet Protocol (IP), Transmission Control Protocol (TCP),
65
wireless application protocol (WAP), e Object Exchange (OBEX), adottati da Infrared
Data Association (IrDA). I protocolli Bluetooth sviluppati da SIG includono:
• Emulatore di porta seriale (RFCOMM) che permette ad applicazioni legacy di
operare sul protocollo di trasporto Bluetooth;
• Protocollo basato su pacchetti Telephony Control Signaling (TCS) per gestire operazioni di telefonia.
• Protocollo di Service Discovery (SDP) che permette a un dispositivo di ottenere
informazioni sui servizi disponibili sugli altri dispositivi.
L’Application group comprende applicazioni che utilizzano collegamenti Bluetooth. Possono essere applicazioni legacy sia applicazioni realizzate nell’ottica di essere
utilizzate con Bluetooth.
Più nel dettaglio i livelli del Transport group sono :
• Livello Radio : Le specifiche di questo livello riguardano principalmente le modalità fisiche di trasmissione. Il modulo radio di un dispositivo Bluetooth è responsabile della modulazione e demodulazione dei dati in segnali a radiofrequenza per la
trasmissione senza fili.
• Livello Baseband : Questo livello definisce come un dispositivo Bluetooth cerca e
si collega ad altri dispositivi. I ruoli master e slave che un dispositivo può assumere vengono definiti qui, come il passo di frequenze e la sequenza da utilizzare. Il
dispositivo usa per interfacciarsi il time division duplexing (TDD), schema di polling basato su pacchetti. Master e slave comunicano ciascuno nello slot di tempo
concordato. Inoltre a questo livello sono definiti i tipi di pacchetti, le procedure
di processamento dei pacchetti e le strategie per il rilevamento e correzione degli
errori, sbalzi di segnale, cifratura, trasmissione e ritrasmissione di pacchetti. Tutti
i pacchetti di livello applicativo vengono frammentati in unità dati Baseband per
avere una trasmissione efficiente.
66
Il livello Baseband supporta due tipi di collegamenti: Synchronous Connection
Oriented (SCO) e Asynchronous Connection-Less (ACL). I collegamenti SCO sono
caratterizzati da un invio periodico di pacchetto in singolo slot, ed è principalmente
usato per trasmissioni voce che richiedono un trasferimento veloce e continuo. Un
dispositivo che ha stabilito un collegamento SCO, ha riservati e garantiti certi time
slot. I suoi pacchetti sono trattati come pacchetti prioritari e saranno gestiti prima di
ogni pacchetto ACL. Un dispositivo con collegamento ACL può inviare pacchetti
di lunghezza variabile di 1, 3 o 5 time slot, ma non ha time slot riservati.
• Livello Link Manager : Questo livello protocollare implementa il Link Manager
Protocol (LMP), che gestisce le proprietà di interfacciamento via radio tra i dispositivi e serve per tradurre i comandi provenienti dal HCI in operazioni per il livello
baseband. LMP gestisce l’allocazione di banda per i dati, gestisce le piconet (link
set-up), si occupa dello switch master-slave se fosse necessario, gestisce l’allocazione di banda e riserva di risorse per traffico audio, effettua l’autenticazione usando
un sistema di negoziazione, si occupa del pairing tra dispositivi (utilizzo di un codice concordato), della cifratura dei dati e controlla la potenza utilizzata. Il controllo
della potenza include la negoziazione di modalità in low power activity e determina
il livello di potenza del segnale.
• Livello HCI : L’Host Controller Interface (HCI) definisce un’interfaccia standard
per le applicazioni di più alto livello per accedere ai livelli più bassi dello stack.
In altre parole è un’interfaccia comune tra hardware e software, in quanto i livelli
sottostanti sono cablati fisicamente nel dispositivo (denominati modulo Bluetooth),
mentre quelli sovrastanti sono implementati in software (denominati host Bluetooth). Questo livello non è richiesto dalle specifiche: il suo scopo è di permettere l’interoperabilità tra dispositivi e l’uso di protocolli e applicazioni a livello superiore
già esistenti.
67
• Livello L2CAP : Il livello Logical Link Control and Adaptation Protocol fornisce l’interfaccia tra i protocolli a livello superiore e i protocolli di livello di trasporto. L2CAP supporta il multiplexing di diversi protocolli di alto livello, come
RFCOMM e SDP. Questo permette a una molteplicità di protocolli di condividere
l’interfaccia. L2CAP è anche responsabile di segmentazione dei pacchetti e riassemblaggio e per il monitoraggio e mantenimento del livello di qualità stabilito del
servizio.
Al di sopra di L2CAP, i restanti livelli dello stack protocollare di Bluetooth non sono
più ordinati in modo cosı̀ lineare. Di particolare rilevanza per quanto riguarda l’applicazione sviluppata sono il protocollo di emulazione della porta seriale RFCOMM e il
protocollo di ricerca servizi SDP.
RFCOMM
Le interfacce seriali sono di fondamentale importanza nelle telecomunicazioni e nell’elaborazione di dati dove i dispositivi come portatili, PDA o sistemi a comunicazione
infrarossa fanno normalmente uso di porte seriali.
Il protocollo RFCOMM è un protocollo di trasporto che fornisce per l’appunto l’emulazione delle porte seriali sopra il protocollo L2CAP garantendo un formato comune
per consolidare i diversi formati di comunicazione seriale in uno standard unico. Tale
protocollo è spesso riferito come protocollo di rimpiazzo del cavo, essendo specifico per
i collegamenti seriali, ed ha il vantaggio chiave di permettere agli sviluppatori di software di usare applicazioni che utilizzano porte seriali con poche modifiche o addirittura
nessuna. Questa virtualizzazione della porta COM porta con se operazioni come frammentazione, multiplexing e altre caratteristiche tipiche delle seriali. Il nome del protocollo
deriva proprio da emulazione RF-oriented della porta seriale COM.
RFCOMM è basato sullo standard dell’ETSI TS 07.10 (usato dai telefoni cellulari
GSM per multiplare diversi stream dati in un cavo seriale fisico), anche se in realtà solo
una parte dello standard viene effettivamente usato, e si hanno alcuni adattamenti del
protocollo riferiti nelle specifiche di RFCOMM. È importante ricordare che il protocollo
68
in questione è in grado di supportare fino a 30 connessioni simultanee tra due dispositivi.
Quanto enunciato fin’ora è schematizzato nella figura 4.4
Figura 4.4.
Emulazione di porte seriali
Il protocollo RFCOMM fornisce approssimativamente gli stessi servizi ed affidabilità che garantisce TCP. In generale le applicazioni che usano TCP hanno a che fare con
connessioni punto-punto sui quali possono inviare stream di dati in modo affidabile. A
parte le varie proprietà di emulazione di porte seriali che per la maggior parte non interessano ai programmatori, RFCOMM ha all’incirca le stesse principali caratteristiche che
caratterizzano il protocollo TCP. Inoltre, mentre le applicazioni che usano L2CAP come
protocollo di trasporto devono rispettare una certa unità massima di trasferimento (Maximum Transfer Unit o MTU), una connessione RFCOMM è costituita da un flusso di dati,
il che semplifica notevolmente la programmazione.
La più grande differenza tra questi due protocolli, dal punto di vista dello sviluppatore
è senz’altro la scelta del numero di porte: mentre TCP supporta fino a 65535 porte aperte
su una stessa macchina, RFCOMM ne permette solamente 30. Questo ha un impatto significativo su come scegliere quale porte utilizzare per le applicazioni server. Il fatto che
69
tale protocollo di trasporto sia stato progettato con poche porte disponibili significa che
non si possono scegliere arbitrariamente le porte al momento del progetto. La conseguenza di questo è che c’è più del 50% di possibilità di collisione tra numeri di porta con sole
7 applicazioni server. In questi casi, per evitare questo inconveniente, lo sviluppatore non
deve scegliere in modo arbitrario il numero delle porte, ma utilizzare una risorsa Bluetooth per risolvere tale problema, e cioè il protocollo di ricerca servizi o SDP di cui si parla
nel paragrafo successivo.
Service Discovery Protocol
I protocolli di service discovery permettono a dispositivi ed applicazioni di cercare servizi
offerti da altri dispositivi ed applicazioni. Per servizio si intende un’entità in grado di
fornire informazioni, eseguire un’azione o controllare una risorsa per conto di un’altra
entità. Un servizio può essere implementato in software, hardware o una combinazione
dei due.
Il Service Discovery Protocol (SDP) fa parte dello stack di protocolli Bluetooth e
affronta il problema del service discovery in modo ottimizzato per la natura altamente
dinamica delle comunicazioni Bluetooth. Il protocollo SDP si occupa essenzialmente di
scoprire i servizi resi disponibili da o attraverso dispositivi Bluetooth; non definisce, invece, metodi per accedere ai servizi. Una volta che un servizio è stato trovato tramite SDP,
può essere utilizzato mediante altri protocolli definiti dalla specifica Bluetooth; le modalità d’accesso dipendono dal particolare servizio. Analogamente una stazione che offre
un servizio Bluetooth, pubblica, in un apposito registro, la descrizione di tale servizio ed
i parametri necessari ad utilizzarlo.
Il meccanismo di service discovery, schematizzato in Figura 4.5, permette ad un’applicazione client di scoprire l’esistenza e gli attributi dei servizi forniti da applicazioni
server.
Per quanto concerne strettamente il Service Discovery Protocol, l’interazione avviene
tra un client e un server SDP in una o più transazioni, ognuna formata da una richiesta
70
Figura 4.5. Interazione nel protocollo SDP
e una risposta. Ciascuna richiesta o risposta consta a sua volta di un’unica PDU (Protocol Data Unit). Un dispositivo Bluetooth può agire sia da client sia da server SDP; se
non fornisce servizi, non c’è bisogno del server. Ciascun dispositivo può avere un solo
server e un solo client, che però possono operare per conto di diverse applicazioni. Le
informazioni fornite da un server SDP riguardano solo i servizi offerti dal dispositivo su
cui risiede: le specifiche vietano la possibilità che un dispositivo interroghi un altro per
cercare i servizi presenti su un terzo dispositivo.
Record di servizio
Per ciascun servizio che un dispositivo Bluetooth è in grado di offrire, il server SDP
possiede uno e un solo record di servizio (service record), che contiene tutte le informazioni ad esso relative. Un record di servizio SDP è costituito unicamente da un elenco
di attributi di servizio. Ogni attributo di servizio descrive una singola caratteristica di un
71
servizio ed è composto da due elementi:
1. un identificativo (ID) di attributo a 16 bit;
2. un campo di lunghezza variabile, il cui formato e significato sono specificati dall’identificativo di attributo e dalla classe di servizi a cui il particolare servizio
appartiene.
Ogni servizio, infatti, appartiene almeno ad una classe di servizi. Una classe di servizi
identifica una particolare tipologia di servizi e definisce quali attributi possono essere
presenti nel service record per descrivere il servizio, il valore degli identificativi di tali
attributi, il loro significato e formato. Il Bluetooth SIG si occupa di standardizzare le
classi di servizi.
Non è necessario che ogni service record contenga effettivamente tutti gli attributi
previsti dalla classe; se però contiene uno degli attributi previsti, il suo formato e il suo
significato devono rispettare la specifica. Un fornitore di servizi può indicare ulteriori
attributi di servizio, non previsti dalla specifica della classe di servizi, usando uno degli
ID liberi.
Ad ogni classe di servizi è associato anche un UUID (Universally Unique Identifier,
identificativo universalmente univoco). Un UUID nella specifica SDP è definito come un
numero intero a 128 bit di cui si assume garantita l’univocità ovunque e senza limiti di
tempo. Non esiste un registro centralizzato di UUID, ma possono essere creati indipendentemente in maniera distribuita. La specifica prevede degli alias abbreviati a 16 o 32 bit
per un intervallo di UUID riservato dal Bluetooth SIG, che ha definito anche l’algoritmo
di traduzione di tali alias in UUID completi a 128 bit. Alcuni dei più comuni attributi di
servizio sono elencati di seguito.
• ServiceRecordHandle
• ServiceClassIDList
• ServiceID
72
• ProtocolDescriptionList
• BrowseGroupList
• ServiceAvaliability
• IconURL
• ServiceName
• ServiceDescription
• ProviderName
I primi due dell’elenco sono gli unici due attributi che devono esser presenti in tutti i
service record. L’attributo ServiceRecordHandle identifica ciascun record di servizio in
un server SDP mediante un handle a 32 bit. Il valore di un handle è univoco solo all’interno di un singolo server. Un unico handle ha il medesimo significato in ogni server SDP,
quello che vale 0x00000000 e si riferisce al server SDP stesso. Nel corrispondente service record possono essere presenti attributi che indicano la versione di protocollo SDP
supportata e i protocolli di livello inferiore utilizzabili per la comunicazione. I valori di
handle da 0x00000001 a 0x0000FFFF sono inoltre riservati. L’attributo ServiceClassIDList, invece, è una sequenza di UUID che identificano le classi di servizi a cui il servizio
appartiene.
Come detto, quindi, l’obiettivo di SDP è permettere ai dispositivi Bluetooth di cercare
cosa hanno da offrire gli altri dispositivi in termini di servizi. SDP permette il reperimento
dei servizi di interesse in due modalità di ricerca, una per trovare uno specifico servizio
(Searching), l’altra per vedere quali servizi sono offerti in quel momento (Browsing).
• Searching : è la transazione di ricerca di un servizio a partire dal valore di uno o più
dei suoi attributi. Non è consentita la ricerca per qualsiasi tipo di attributo, ma solo
per quelli di tipo UUID, che generalmente sono usati per denotare le caratteristiche
distintive di un servizio. Il client effettua una ricerca inviando un search pattern
73
costituito da uno o più UUID. Il criterio di ricerca si considera soddisfatto dai record
di servizio che contengono tra i loro attributi tutti gli UUID specificati, a prescindere
da quali attributi effettivamente li contengano e dall’ordine.
• Browsing : è la modalità di ricerca adatta a scoprire quali tipi di servizi sono offerti
da un server SDP senza avere alcuna conoscenza a priori. Il meccanismo si basa
su un’organizzazione ad albero di gruppi di servizi. Ciascun gruppo può contenere
servizi o sottogruppi di servizi forniti dal server SDP.
Il protocollo SDP può essere usato per diversi scopi, tra cui descrivere quale protocollo di trasporto un server utilizza, per dare informazioni come una descrizione del servizio
fornito, chi fornisce tale servizio, oppure il nome del sevizio stesso. Ma l’utilizzo principale per cui viene usato SDP è quello preannunciato nella sezione precedente: assegnare
in modo dinamico le porte per stabilire una connessione.
Nella programmazione per Internet, gli applicativi server fanno tradizionalmente uso
di porte conosciute che sono pre-stabilite e concordate in una fase precedente, durante
il progetto, e i client utilizzeranno gli stessi numeri di porta per connettersi al server. Il
più grande svantaggio di questo approccio è che non è possibile avere due server attivi
che utilizzano la stessa porta, ma a causa della relativa gioventù di TCP/IP e grazie al
grande numero di porte disponibili, questo non ha ancora rappresentato una considerevole
preoccupazione.
Come già ricordato in precedenza i protocolli di trasporto di Bluetooth non hanno
molte porte disponibili, in particolar modo il protocollo RFCOMM (L2CAP ha all’incirca
15.000 porte non riservate) che ne dispone di 30. Perciò, invece di concordare sulla porta
da usare in fase di progetto, l’approccio che prescrive Bluetooth è quello di assegnarle dinamicamente durante l’esecuzione seguendo un modello publish-subscribe, ovvero
“pubblica e sottoscrivi”. L’host gestisce una applicazione server, chiamata per l’appunto SDP server e che usa una delle poche porte L2CAP riservate. Alle altre applicazioni
server vengono assegnati i numeri di porta durante la loro esecuzione, e registrano una
descrizione del servizio che forniscono (oltre che ovviamente i numeri di porta assegnati)
74
sul server SDP. Le applicazioni client interrogheranno tale server su un certo dispositivo
utilizzando la porta riservata per ottenere le informazioni di cui hanno bisogno.
Questo solleva la questione di come facciano i client a sapere qual è la descrizione che
stanno cercando. Il modo standard stabilito da Bluetooth è di assegnare un numero su 128
bit durante il progetto dell’applicazione, chiamato, come già illustrato, UUID. Seguendo
questa metodologia standard di scelta dell’UUID garantisce la scelta di un numero unico
rispetto a quelli scelti da chiunque altro che ha seguito questo modo. Cosı̀ client e server,
entrambi progettati con lo stesso identificativo, possono fornire quest’ultimo al server
SDP come vincolo di ricerca.
Un ultimo punto che vale la pena di menzionare è il fatto che il protocollo SDP non
è affatto richiesto per creare una applicazione Bluetooth. È perfettamente possibile comportarsi secondo l’approccio di TCP/IP e assegnando in modo statico i numeri di porta e sperare di evitare conflitti, e questo potrebbe essere fatto per risparmiare tempo in
ambienti con impostazioni controllate, per esempio in un laboratorio. In ultima analisi,
comunque, per creare un’applicazione portabile che sia compatibile con la maggioranza
degli scenari possibili, essa deve usare SDP e assegnare le porte dinamicamente.
4.2.4
Librerie BlueZ
Il progetto BlueZ si propone come obiettivo generale la realizzazione di un’implementazione delle specifiche standard di Bluetooth per Linux. BlueZ venne originariamente
sviluppato da Qualcomm Incorporated ed è ora parte di un progetto Open Source con
numerosi contributori da tutto il mondo. Il codice è autorizzato sotto la licenza GNU
General Public License (GPL), ed è ora incluso nei kernel Linux 2.4 e 2.6.
BlueZ fornisce il supporto per i livelli di base e i protocolli di Bluetooth. È inoltre
flessibile, efficiente, usa un’implementazione modulare e possiede le seguenti caratteristiche:
• Processamento dei dati in multithread
• Supporto per più dispositivi Bluetooth
75
• Astrazione di hardware
• Interfaccia per socket standard a tutti i livelli
• Supporto per sicurezza
Inoltre attualmente BlueZ consiste di numerosi moduli (illustrati anche in figura 4.6):
• moduli Bluetooth di base per il kernel
• HCI
• driver per HCI UART, USB, PCMCIA e Virtual HCI
• modulo del protocollo L2CAP
• utility per configurazione e test
• implementazioni di RFCOMM, BNEP, CMTP e HIDP
• librerie per SDP
I moduli del kernel, le librerie e le utility funzionano perfettamente su molte architetture supportate da Linux incluse piattaforme multi processore:
• Intel e AMD x86
• AMD64 e EM64T (x86-64)
• SUN SPARC 32/64bit
• PowerPC 32/64bit
• Intel StrongARM e XScale
• processori Hitachi/Renesas SH
BlueZ trova supporto in numerose distribuzioni Linux ed è in generale compatibile
con qualsiasi sistema Linux presente attualmente:
76
Figura 4.6.
Visione generale di BlueZ
• Debian GNU/Linux
• Ubuntu Linux
• Fedora Core / Red Hat Linux
• OpenSuSE / SuSE Linux
• Mandrake Linux
È possibile sviluppare software mediante le librerie BlueZ utilizzando diversi linguaggi come Python, Java e C.
Python è un versatile e potente linguaggio ad oggetti che fornisce chiarezza sintattica e un meccanismo incorporato di gestione della memoria in modo da permettere al
programmatore di focalizzarsi maggiormente sull’algoritmo vero e proprio piuttosto che
77
preoccuparsi di memory leak, dettagli sintattici e analisi di complesse strutture dati. Sebbene Pyhton abbia una grande ed esaustiva libreria standard, il supporto per Bluetooth
non fa ancora parte della distribuzione standard.
Un buon insieme di API C ben documentate permette agli sviluppatori di creare moduli per estendere le potenzialità del linguaggio e fornire accesso a risorse del sistema
operativo che altrimenti non sarebbero accessibili con Python. PyBluez è un’estensione
modulare di Python scritta in C che provvede al’accesso di risorse di sistema con un approccio modulare e ad oggetti. È scritta sia per Windows XP (stack Bluetooth Microsoft)
che per GNU/Linux (stack BlueZ).
Vi è inoltre un buon numero di API Java per la programmazione Bluetooth attualmente disponibili, standardizzate nelle specifiche chiamate JSR-82, a cui praticamente tutti
le implementazioni Java fanno riferimento. Questo rende la portabilità di applicazioni
Bluetooth da un dispositivo all’altro molto più semplice.
Uno svantaggio di usare Java è che JSR-82 è decisamente limitato in quanto non
fornisce praticamente nessun controllo sul processo di ricerca dei dispositivi o sulle connessioni dati stabilite. Per esempio, JSR-82 non permette di regolare le semantiche di
trasferimento e ottenere informazioni sulla potenza del segnale. Perciò, sebbene JSR-82
sia accettabile per creare semplici applicazioni Bluetooth, non è adatto per la ricerca e per
progetti accademici.
Tuttavia ci sono svariate ragioni per sviluppare applicazioni Bluetooth in C piuttosto
che utilizzando un linguaggio di alto livello come Python:
• L’ambiente Python potrebbe non essere disponibile.
• Requisiti applicativi vincolanti relativi alla dimensione del programma, velocità e
utilizzo della memoria potrebbero precludere l’uso di un linguaggio interpretato
come Python.
• Il programmatore potrebbe desiderare un controllo più fine sul dispositivo Bluetooth rispetto a quello che Python fornisce.
78
• Gli obiettivi del progetto potrebbero essere quelli di produrre una libreria condivisa
per essere utilizzata da altre applicazioni invece di avere un applicativo a sé stante.
Per quanto riguarda lo sviluppo in C, BlueZ è un potente stack di comunicazione con
API che permettono all’utente di sfruttare completamente tutte le risorse Bluetooth, ma
non dispone di una documentazione ufficiale. Gli sviluppatori che intraprendono la programmazione Bluetooth con BlueZ utilizzano le mailing list ufficiali, dove sovente vengono reindirizzati al codice sorgente di BlueZ per capire le API a disposizione2 . Questo è
però un processo svantaggioso in termini di tempo poiché permette di rivelare solo poche
informazioni per volta, ed è spesso un ostacolo che scoraggia potenziali sviluppatori.
4.3
VoIP
VoIP è l’acronimo per Voice over IP (ovvero voce tramite protocollo Internet), ed è una
tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione Internet o un’altra rete dedicata che utilizza il protocollo IP, anziché passare
attraverso la rete telefonica tradizionale (PSTN). Ciò consente di eliminare le relative
centrali di commutazione e di economizzare sulla larghezza di banda occupata. Vengono
instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati in forma
digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti collegati
sta parlando.
Fra gli altri vantaggi rispetto alla telefonia tradizionale si annoverano:
• minore costo per chiamata, specialmente su lunghe distanze
• minori costi delle infrastrutture: quando si è resa disponibile una rete IP nessun’altra infrastruttura è richiesta
• nuove funzionalità avanzate
• l’implementazione di future opzioni non richiederà la sostituzione dell’hardware
2
Per approfondimenti si veda [14].
79
Le conversazioni VoIP non devono necessariamente viaggiare su Internet, ma possono
anche usare come mezzo trasmissivo una qualsiasi rete privata basata sul protocollo IP,
per esempio una LAN all’interno di un edificio o di un gruppo di edifici. I protocolli usati
per codificare e trasmettere le conversazioni VoIP sono solitamente denominati Voice over
IP protocols.
4.3.1
Differenze con la telefonia tradizionale
Per capire il fenomeno della telefonia su Internet è necessario prendere confidenza con
i principi fondamentali che stanno dietro Internet e con le principali differenze di IP rispetto alla cosiddetta rete telefonica fissa (altresı̀ detta PSTN: Public Switched Telephon
Network) o quella mobile degli standard di seconda e terza generazione come GSM e
UMTS.
Sebbene infatti Internet condivida molti aspetti della PSTN, presenta alcune caratteristiche peculiari. La rete telefonica (PSTN) è una rete a commutazione di circuito
ottimizzata per le comunicazioni vocali in sincrono e in tempo reale con una qualità di
servizio garantita (QoS:Quality of Service). Quando una sessione di comunicazione viene
iniziata, si stabilisce un circuito fra la parte chiamante e quella chiamata. La PSTN garantisce la qualità del servizio (QoS) dedicando alla conversazione un circuito full-duplex
con una larghezza di banda di 64KHz. Tale larghezza di banda rimane inalterata indipendentemente dal fatto che le parti siano in conversazione attiva o in silenzio. Dato che
l’ampiezza sopracitata è costante, il costo di una chiamata tramite PSTN è strettamente
basato sulla distanza e sul tempo.
Internet, invece, è una rete a commutazione di pacchetto e, storicamente, è sempre
stata usata per applicazioni dove una QoS variabile poteva essere un parametro tollerabile
(e-mail, FTP). Le reti a commutazione di pacchetto non dedicano un circuito (a meno
di non considerare i circuiti virtuali) tra le parti in conversazione e perciò non possono
garantire la qualità del servizio (sebbene, allo stato attuale delle cose, ci siano numerose
iniziative intraprese per raggiungere questo scopo).
Per come sono strutturati i protocolli di comunicazione e per come è stata concepita
80
la rete Internet, il meccanismo primario di costo per un’applicazione di telefonia IP non
è né la distanza né il tempo, ma l’ampiezza di banda usata nella comunicazione. In ogni
caso, tale costo è trasparente all’utente finale, ditta o privato che sia. Il servizio a tali
utenti viene infatti fornito solitamente dagli ISP (Internet Service Provider) che gestiscono
direttamente il costo delle connessioni. Per quanto riguarda l’utente finale, la telefonia
IP diventa dunque il mezzo per comunicare a distanze intercontinentali ai prezzi di una
telefonata all’interno della locale rete PSTN. Soprattutto per questo motivo il mercato
VoIP promette una crescita esponenziale per i prossimi anni in tutti i suoi principali settori
(ovvero la telefonia PC verso PC, PC verso telefono, telefono verso PC, e quella classica
telefono verso telefono).
4.3.2
Qualità di servizio
Il problema fondamentale che sta alla base della comunicazione vocale su una rete come
Internet è che la gestione dei pacchetti da parte del protocollo IP destinatario non comporta una ricomposizione di questi nell’ordine originale. Se alcuni subiscono errori di
trasmissione o ritardi vari si capisce come il processo di ricomposizione possa risultare
rallentato. Per applicazioni classiche, come ad esempio la posta elettronica, tale ritardo
non acquista particolare significato, ma per applicazioni di telefonia, dove l’interazione
real-time tra le parti è fondamentale, questo può provocare un degradamento notevole
nella qualità di conversazione.
In generale, il tipo di qualità nella comunicazione che un utente di VoIP si può aspettare dipende in parte dalla velocità della connessione ad Internet che ciascun lato della comunicazione possiede e in parte dal traffico complessivo della rete. Ci sono due
fondamentali caratteristiche che determinano la qualità di una connessione telefonica su
Internet.
La prima caratteristica è il tempo di latenza (Latency). Tale grandezza misura il ritardo
che intercorre dal momento che certe parole sono pronunciate da un lato, al momento che
queste sono effettivamente sentite dall’altro lato, ed è importante mantenere il tempo di
latenza dei pacchetti sufficientemente basso, in modo che l’utente non debba aspettare
81
troppo tempo prima di ricevere le risposte durante la conversazione. Spesso gli utenti di
VoIP rapportano tale latenza ai ritardi che le normali telefonate subiscono quando parte del
circuito è fatto da collegamenti satellitari. La latenza è qualcosa a cui gli utenti possono
in genere abituarsi e compensare di conseguenza.
L’altra importante caratteristica che determina la qualità di una connessione telefonica su Internet è, semplicemente, il grado di rispondenza della voce trasmessa rispetto
alla voce naturale di chi parla, ovvero l’integrità dei dati. Se certi pacchetti vocali risultano ritardati oltre una certa soglia, il software di telefonia IP cercherà in genere di
interpolare i dati mancanti tramite i contenuti dei pacchetti adiacenti. Inoltre durante la
trasmissione può cambiare la sequenza dei pacchetti e che alcuni pacchetti possono aver
subito perdite o danneggiamenti delle informazioni contenute, ed è perciò compito del
software assicurare che lo stream audio (flusso audio) mantenga la corretta coerenza temporale. Naturalmente, più il software ricorre a questa tecnica interpolativa, più la qualità
del software risulterà compromessa (distorsione del messaggio vocale).
TCP/IP, in sostanza, non garantisce agli utenti la trasmissione di un certo numero di
dati in un preciso periodo di tempo. Le prestazioni della rete possono fluttuare di momento in momento. A volte i dati sono trasmessi immediatamente, a volte subiscono ritardi o
non sono inviati affatto. Per molti aspetti, i problemi che i progettisti hanno sono simili a
quelli incontrati nella progettazione di reti cellulari digitali, dove non ci sono garanzie che
i dati arrivino intatti. Quindi i progettisti devono ipotizzare che i livelli sottostanti siano
inaffidabili, e compensare gli eventuali errori con le sopracitate tecniche di interpolazione
e correzione. Dunque è in genere arduo predire la QoS che ci si può aspettare da una
sessione di telefonia in rete, ma, di solito, questa è direttamente correlata all’ampiezza di
banda che viene sfruttata per la conversazione più che al traffico di rete. Alcune organizzazioni dispongono già da ora di connessioni ad Internet a larga banda. Tali connessioni
sono capaci di garantire la qualità sufficiente per fare del VoIP il mezzo standard nelle
comunicazioni inter-ufficio a lunga distanza. In definitiva, la qualità nel campo della telefonia IP presenta dei notevoli margini di miglioramento.
82
4.3.3
Protocolli VoIP
La tecnologia VoIP richiede per poter funzionare due tipi di protocollo di comunicazione
in parallelo: uno per trasportare la voce sottoforma di dati, in questo caso viene adottato il protocollo RTP (Real-Time Transport Protocol), l’altro per la segnalazione e per
la sincronizzazione cronologica. In questo caso si possono utilizzare diversi protocolli
standard:
• SIP (Session Initiation Protocol) della IETF;
• H.323 della ITU;
• Skinny Client Control Protocol, protocollo proprietario della Cisco;
• Megaco (conosciuto anche come H.248);
• MGCP;
• MiNET, protocollo proprietario della Mitel;
• IAX, usato dai server Asterisk open source PBX e dai relativi software client.
Session Initiation Protocol
Il protocollo Session Initiation Protocol (SIP) gestisce in modo generale una “sessione”
di comunicazione tra due entità, ovvero fornisce meccanismi per instaurare, modificare
e terminare (rilasciare) una sessione. Esso trova applicazione nella telefonia su IP e nei
servizi telefonici supplementari, nella video-comunicazione, nei giochi interattivi, nella
messaggistica istantanea. Il protocollo è stato sviluppato, ufficialmente, a partire dal 1999
(RFC 2543 e 3261) per iniziativa di IETF e fa parte della Internet Multimedia Conferencing Suite. Ad oggi l’utilizzo prevalente è nella telefonia su IP, per cui SIP è spesso
sinonimo di un sistema dedicato a questa applicazione.
SIP usa la porta standard 5060, ed è indipendente dal protocollo di trasporto essendo
possibile utilizzare sia UDP che TCP, sebbene sia preferibile UDP. SIP è un protocollo
83
text-based, cioè i messaggi di SIP per il controllo delle chiamate sono in formato testo, e
sono molto simili a quelli usati da HTTP per lo scambio di pagine web. Ha una struttura
client-server, ma è impiegabile anche in contesti peer to peer, e in entrambe le modalità
per instaurare una sessione viene effettuato un three-way handshaking (concettualmente
simile a quello che avviene con il protocollo TCP).
Per identificare un utente vengono usate le SIP-URI (o indirizzi SIP) che rappresentano lo schema di indirizzamento SIP per chiamare un altro soggetto attraverso il protocollo
in questione. In altre parole, un SIP URI è il recapito telefonico SIP di un utente. Il SIP
URI assomiglia ad un indirizzo e-mail scritto nel seguente formato:
SIP URI = sip:nomeUtente@host:porta
dove nome utente può essere rappresentato dal numero telefonico o da un identificativo
riconosciuto, mentre host è il dominio o l’indirizzo IP.
Le cinque funzionalità primarie per stabilire e terminare comunicazioni multimediali
sono :
1. User Location : determinazione dei terminali usati nella comunicazione.
2. User Availability : controllo della disponibilità di un utente a partecipare ad una
comunicazione.
3. User Capabilities : identificazione dei media e parametri utilizzati.
4. Session Setup : avviso, instaurazione dei parametri di una sessione per entrambi i
lati.
5. Session Management : trasferimento e terminazione di una sessione, modifica dei
parametri della sessione e invocazione dei servizi.
È utile ricordare che SIP (cosı̀ come H.323) è un protocollo “open” e quindi chiunque
84
può sviluppare (gratuitamente e senza autorizzazioni) applicazioni di telefonia, messaggistica e rilevamento della presenza. La stessa cosa non può invece avvenire con il protocollo utilizzato da Skype che, essendo “proprietario”, è plasmabile soltanto da chi ha
prodotto quel codice e programma. Questo purtroppo fa del più diffuso sistema di VoIP
Skype appunto, un software veloce e all’avanguardia, ma chiuso nel proprio recinto, a
meno che non decida un giorno di aprirsi verso altri protocolli di comunicazione. Questo
è uno dei motivi per cui si è scelto come software per la terminazione di una chiamata
VoIP l’applicazione SimpleOPAL, facente parte di un progetto Open Source, denominato
OPAL, di cui si tratterà nella sezione successiva.
4.3.4
OPAL
OPAL (Open Phone Abstraction Library) è una libreria di classi Open Source per lo sviluppo di applicazioni che impiegano H.323 o SIP come protocolli per implementazioni
VoIP. Esso rappresenta la nuova generazione di OpenH323, il progetto dedicato allo sviluppo collaborativo di una pila protocollare Open Source del protocollo di segnalazione
H.323, presentando un’architettura diversa. Inoltre non è compatibile solo con H.323 e
SIP, ma anche con i nuovi protocolli VoIP, in quanto progettato per essere un’infrastruttura per ogni protocollo di segnalazione delle chiamate. OPAL è sviluppato da VoxGratia,
un gruppo di programmatori con supporto di altre compagnie, è scritto in C++ e può essere utilizzato sia su Windows che Unix. Per eventuali approfondimenti sul progetto si
consiglia di consultare il sito[18].
Il progetto OPAL è stato necessario per superare diversi problemi riscontrati in OpenH323 quali:
1. Inquinamento dello spazio dei nomi o collisione di nomi, problema che si presenta
quando lo sviluppatore di una libreria di classi è ostacolato dall’uso di nomi simili
in un’altra libreria.
2. Struttura delle classi poco favorevole e difficoltà di decidere da quale classe far
ereditare un discendente necessario per l’applicazione.
85
3. Supporto possibile solo per il protocollo H.323.
4. Codec con molti parametri, spesso poco chiari.
OPAL è stato estratto da OpenH323 dopo l’astrazione di numerose classi e dopo avere
lasciato le specifiche dei protocolli (come H.323 o SIP) alle classi discendenti. Il risultato
è caratterizzato da un’architettura stream-based e soprattutto espandibile, cioè è presente
un supporto esplicito per l’aggiunta di nuovi protocolli. Attualmente i progetti OPAL e
OpenH323 vanno in parallelo poiché molte applicazioni utilizzano ancora OpenH323, che
quindi non è ancora stato deprecato. Un’applicazione sviluppata nell’ambito del progetto
OPAL è SimpleOPAL e permette di ricevere ed effettuare chiamate VoIP.
Struttura interna di SimpleOPAL
I principali moduli nella parte della segnalazione sono
• OpalManager : il Manager è la radice dell’albero di appartenenza e gestisce diversi punti terminali (endpoint) ed è responsabile del meccanismo di creazione delle
chiamate. Tutti gli endpoint sono logicamente collegati a tale classe.
• OpalEndPoint : è la classe padre dei vari endpoint divisi dipendentemente dal
protocollo. Attualmente sono implementati i seguenti punti di terminazione:
1. H323 End Point per il protocollo H.323
2. SIP End Point per il protocollo SIP
3. PCSS End Point per PC Sound System
4. PSTN End Point come gateway
5. POTS Endpoint per la telefonia tradizionale
Sono incluse funzioni di callback che possono essere re-implementate dalle classi
discendenti per tenere traccia e controllare i flussi di chiamata.
86
• OpalCall : appartiene a OpalManager ed ha lo scopo di unire due o più connessioni
in una chiamata. OpalCall ottiene la connessioni dagli endpoint.
Un’istanza della classe OpalManager può avere un infinito numero di endpoint, ma
ad un’applicazione è permesso avere un solo OpalManager. In sintesi i passi svolti per
l’instaurazione di una chiamata sono:
1. La classe EndPoint ascolta su una specifica porta in attesa di chiamate entranti.
2. SIPEndPoint riceve una chiamata.
3. OpalManager cerca un PCSSEndPoint o un SIPEndPoint e gli demanda di creare
una connessione.
4. OpalManager infine unisce gli endpoint in una istanza di OpalCall.
La figura 4.7 mostra come i vari attori della comunicazione interagiscano tra loro.
Per stabilire un trasferimento Audio/Video, vengono invece usate istanze di classi
che ereditano dalla classe OpalMediaStream. Esse permettono di trasferire dati da e per
sessioni RTP, file e dispositivi video.
La classe OpalMediaPatch è invece il thread di controllo che effettivamente trasferisce i dati da un’istanza sorgente di OpalMediaStream a un “sink”, ovvero destinazione.
OpalMediaPatch è anche incaricata di richiamare i codec necessari, controllando se il sink
supporta quelli utilizzati.
87
Figura 4.7.
Diagramma dei principali moduli di OPAL
88
Capitolo 5
Analisi e design architetturale
5.1
Introduzione
Nei capitoli precedenti sono state poste le basi teoriche ed esposti i dettagli tecnici che
permettono di comprendere gli aspetti del progetto descritto in seguito. I prossimi tre
capitoli sono infatti dedicati ad un descrizione il più possibile esaustiva del lavoro prodotto
ed hanno l’obiettivo di spiegare in modo chiaro ed accessibile l’applicazione, considerata
la sua piattaforma ed il contesto legato alla comunicazione telefonica su Internet.
Questo capitolo si colloca in una fase propedeutica di presentazione del software nella
quale si pone quest’ultimo nell’attuale scenario di applicativi per la telefonia su Internet,
ovvero VoIP. Inoltre in esso vengono esposte le modalità di utilizzo e le specifiche del
progetto maturate nella fase precedente al progetto ed affinate in seguito a questo stadio,
esaminando i vincoli e le caratteristiche in un prospetto generale che comprende sia il
programma a lato client, che quello a lato server.
Infine si conclude il capitolo introducendo i principali requisiti tecnici e di usabilità
che si è cercato di soddisfare nella successiva implementazione, per quanto riguarda lo
streaming multimediale, la connessione Bluetooth ed altri aspetti inerenti.
89
5 – Analisi e design architetturale
5.2
Contesto applicativo
Ad oggi il numero di applicazioni VoIP che vengono offerte è innumerevole. Non passa settimana senza che venga lanciato un nuovo servizio di telefonia VoIP pubblicizzato
come il migliore al prezzo più basso, anche se al di là di questa patina pubblicitaria le differenze possono essere notevoli. Effettivamente la possibilità di integrazione con altri servizi (instant messaging, posta elettronica ecc.), la flessibilità dei dati digitali (permettere
compressione, criptazione e maggiore robustezza) e soprattutto i costi competitivi rispetto
alla telefonia fissa sono fattori che risultano essere piuttosto appetibili per i consumatori e
permettono cosı̀ un rigoglioso fiorire di applicazioni per la telefonia su protocolli Internet,
come Skype, Ekiga, Google Talk, Asterisk PBX per citare i più famosi.
Gli scenari di utilizzo variano in base al tipo degli endpoint della chiamata VoIP, e cioè
se i punti terminali della sessione sono dei personal computer o dei telefoni. Naturalmente
ogni applicativo permette di effettuare una chiamata voce o dati tra due client su PC, ma
non sempre due applicativi sono compatibili tra loro e questo può essere un problema
vista la costellazione di proposte al riguardo. Nonostante questa problematica e quelle
legate alla QoS dovute alla natura non orientata alla connessione di Internet, sembra essere
comunque in crescita l’utilizzo di queste applicazioni per i costi decisamente bassi.
Il leader indiscusso in termini di notorietà e diffusione è Skype che ha guadagnato la
prima posizione con campagne marketing milionarie e bombardamenti mediatici giornalieri, ma che per quanto riguarda il servizio SkypeOut non è certo il più competitivo. Tra
tutti gli innumerevoli servizi che sono apparsi negli ultimi 2-3 anni, Skype si é nettamente
distinto dagli altri perché é stato il primo a offrire chiamate gratuite per un certo numero
di destinazioni, riuscendo con questa strategia di marketing a accaparrarsi una consistente
fetta di mercato.
Ciò che è di interesse è notare come nel tempo sono aumentate le offerte di telefoni USB che permettono di utilizzare i vantaggi della telefonia su Internet pur utilizzando
uno strumento domestico a cui l’utente medio è ormai abituato da anni, e cioè un apparecchio telefonico. La quasi totalità di questi apparecchi è compatibile con Skype, essendo
90
quest’ultimo il più diffuso tra i client VoIP. Più di 100 milioni di persone, infatti, hanno
installato Skype sui propri PC o Mac, ma proprio il software VoIP più conosciuto e apprezzato per facilità d’uso e funzionalità avanzate rischia di arrivare in ritardo dove alcuni
concorrenti sono già da tempo: i telefoni cellulari.
5.2.1
Scenario applicativo per cellulari
Mentre Skype continua a ritardare l’uscita della propria versione per cellulare, diversi
produttori di software hanno lanciato soluzioni VoIP per dispositivi mobili, cellulari o
smartphone (in generale è richiesto quantomeno un telefono compatibile con le reti di
seconda o terza generazione, UMTS o GPRS). Alcuni offrono funzionalità aggiuntive
come instant messaging e compatibilità con i software VoIP più diffusi (Skype, Google
Talk, Gizmo...), altri si limitano ad offrire prezzi bassi per chiamate internazionali.
Recentemente Jajah ha lanciato Jajah Mobile Suite, estensione mobile del proprio
servizio, che solitamente funziona attraverso una pagina web dalla quale inserire il proprio numero e quello del destinatario della chiamata (Jajah fa squillare il cellulare del
chiamante e lo mette in contatto con l’altra parte). Oggi è possibile attivare una chiamata
direttamente dal cellulare con una piccola applicazione Java o Symbian (tramite una connessione dati UMTS o un semplice SMS). Conveniente solo per le chiamate da o verso
l’estero (una chiamata dall’Italia a New York costa meno di 2 euro contro i 6,5 di Vodafone, TIM e Wind), il servizio si rivela una valida alternativa all’utilizzo di calling-cards ed
altre soluzioni che consentono di evitare le costosissime tariffe di roaming degli operatori
mobili.
Talkster è un servizio VoIP per cellulari simile a Jajah, ma non richiede l’installazione
di alcun software (basta dirigersi su m.talkster.com con il browser del proprio cellulare).
Il servizio, ancora in fase di sviluppo iniziale, permette di chiamare utenti MSN, Gizmo,
Google Talk e telefoni tradizionali, con il consueto risparmio se si chiama all’estero.
A differenza di Jajah, permette anche di chiamare un numero nazionale invece di farsi
richiamare sul cellulare ed integra funzionalità di presence management (la possibilità di
vedere quando i propri contatti sono online).
91
Jajah e Talkster non sono gli unici a voler portare il VoIP sui cellulari: se Skype affronta problemi relativi alle ridotte capacità di calcolo di alcuni dispositivi e problemi di
latenza derivanti dall’utilizzo di reti 3G, Fring è riuscito nell’impresa e ha reso disponibile un software per telefoni con sistema Symbian che sfrutta protocolli proprietari, per
garantire qualità della chiamata e ridotti consumi energetici, e permette di chiamare utenti
Fring, Skype e Google Talk. Fring offre un client VoIP vero e proprio, con funzionalità di
instant messaging, gestione della presenza, compatibilità con due tra i software VoIP più
diffusi e la possibilità di fruire del servizio quasi ovunque, grazie alla copertura 3G.
Le soluzioni proposte da EQO e SoonR, permettono di usare Skype su molti telefoni
cellulari, rispettivamente tramite un’applicazione Symbian e tramite un browser WAP.
Questi servizi richiedono ai propri utenti di installare un apposito software sui propri
computer collegati a Skype e sfruttano il loro credito SkypeOut per metterli in contatto
con i destinatari delle chiamate (in sostanza attivando una conference call tra il proprio
account Skype collegato sul PC, il telefono cellulare del chiamante ed il destinatario della
chiamata).
Leggermente diverso l’approccio di iSkoot, che ha sviluppato un’applicazione ed una
soluzione client-server proprietaria che permette di usare Skype dai telefoni cellulari. Come per i servizi appena descritti, è necessaria una connessione dati 3G (o WiFi, per la
nuova versione in beta) per mantenere aggiornata la contact list, le informazioni sulla
presence dei contatti ed avviare una conversazione. Quando si chiama un contatto Skype o SkypeOut, il cellulare chiamerà il numero del gateway di iSkoot, che lo collegherà
all’utente Skype desiderato. Per le chiamate in entrata, invece, iSkoot sfrutterà il credito
SkypeOut del proprio utente per richiamarlo sul suo telefono cellulare. A differenza di
EQO o SoonR, non è necessario tenere il PC acceso e collegato a Skype, tuttavia una
chiamata tramite iSkoot costerà tanto quanto una normale chiamata da cellulare.
Se è necessaria una connessione dati 3G, e quindi un piano tariffario flat per non
incorrere in spese esorbitanti per pochi minuti di attività, molti potrebbero trovare più interessante la proposta di Fring, senza dubbio più economica visto che, una volta collegati,
le chiamate ad utenti Skype (o Google Talk) viaggiano su Internet e sono quindi gratuite
92
(escluso chiaramente il costo del collegamento 3G).
Tuttavia, per quanto Fring sia una delle poche soluzioni VoIP mobile in grado di definirsi completo in termini di esperienza di comunicazione (soprattutto se confrontate con
altre orientate esclusivamente ad offrire prezzi vantaggiosi), rimane difficile immaginare
che software simili possano raggiungere un pubblico di massa utilizzando esclusivamente
collegamenti 3G. Sarà attratto da soluzioni simili solo chi è fornito dal proprio operatore
di un piano tariffario dati flat, in mancanza del quale una chiamata tra utenti Fring o Skype potrebbe costare oltre 3 euro al minuto. Piani tariffari di questo tipo sono ancora poco
diffusi nel nostro paese e non raggiungono grandi numeri nemmeno negli Stati Uniti.
Oltre alla scarsa convenienza, il problema è la facilità con cui gli operatori di telefonia
mobile possono impedire o scoraggiare l’utilizzo di applicazioni VoIP sulle loro reti dati,
sulle quali sono in grado di esercitare un controllo assoluto, senza alcuna garanzia per
l’utente ed alcun rispetto per la neutralità della rete.
5.3
Specifiche del progetto
Il progetto sviluppato durante la tesi si colloca in questa costellazione di strumenti per la
comunicazione telefonica attraverso la rete Internet. La principale differenza che emerge
confrontando le attuali soluzioni con gli obiettivi e i disegni progettuali di questo lavoro
sta nel fatto che le applicazioni viste nel paragrafo 5.2.1 richiedono copertura 3G per
effettuare una chiamata VoIP in quanto sfruttano, a tale scopo, la connessione Internet da
cellulare offerta dallo standard di terza generazione. Questo comporta chiaramente dei
costi di connessione, ma il vantaggio di potere chiamare, utilizzando la tecnologia VoIP
in qualsiasi momento e soprattutto in qualsiasi luogo.
L’applicazione che viene presentata nasce invece in un’ottica di integrazione di tecnologie che consentono di automatizzare una comunissima operazione quale può essere
l’effettuazione di una chiamata telefonica, e rientra perciò in un ambito domestico che è
tipico della domotica. Lasciando ad altre trattazioni i dettagli di questa scienza, è interessante notare come questo progetto permette da un lato di sfruttare i vantaggi legati al
93
risparmio economico sulle tariffe delle chiamate tipico di VoIP, e dall’altro di utilizzare
un oggetto personale come il proprio cellulare a cui si è abituati ormai da anni.
Se già le applicazioni attuali facevano affidamento sulla dimestichezza che un utente
medio ha con un telefono fisso, è facile intuire che nel caso di telefonia mobile oltre
che avere un maggiore livello di familiarità dovuto alla più recente esplosione dell’uso di
cellulari, è anche possibile evitare l’acquisto di un apparecchio ad-hoc per la fruizione di
determinati servizi. È sufficiente infatti essere dotati di un telefono cellulare compatibile
con il software sviluppato1 e senza alcun costo si è in grado di chiamare un altro client
VoIP veicolando la voce su Internet.
In definitiva si vuole fornire uno strumento per sfruttare la tecnologia VoIP in modo
“friendly”, cioè rivolto a quegli utenti non troppo abituati all’uso di un PC, e per rendere
più utilizzabile tale servizio anche per i più esperti, permettendo di disaccoppiare l’applicazione VoIP presente sul PC dall’utente, il quale si ritroverebbe semplicemente ad avere
a che fare con un semplice applicativo sul proprio cellulare Symbian. Come è mostrato in
figura 5.1 il terminale mobile e il PC sono connessi e comunicano mediante una connessione Bluetooth che fornisce il canale per veicolare le informazioni multimediali come la
voce, e quelle di segnalazione per gestire e controllare la chiamata. Ad oggi una soluzione
del genere è del tutto innovativa, e renderebbe il cellulare un device remoto per parlare
e dialogare via VoIP pur rimanendo lontani dal proprio PC poiché, grazie alla tecnologia di trasmissione Bluetooth, è teoricamente possibile allontanarsi fino a 100 metri dal
computer su cui è installato il software VoIP.
Un importante specifica che si propone di garantire una maggiore usabilità e familiarità con il software è la trasparenza. L’obiettivo è, come già è stato detto, è semplificare
l’approccio dell’utente, mostrandogli e dandogli le funzionalità tipiche a cui è già abituato
quali:
• Finestra di dialog e suoneria all’ingresso di una chiamata.
• Informazione sulla durata della chiamata.
1
cioè la cui piattaforma è la stessa su cui è stato implementato il client.
94
• Aggiornamento del registro di chiamate in caso di chiamata persa.
Inoltre è importante ricordare che al telefono cellulare viene inoltrata la voce dal PC
che è il vero terminatore e gestore della sessione VoIP. In questo modo il cellulare non ha
bisogno di una connessione 3G e quindi può funzionare anche senza carta SIM.
Figura 5.1.
5.3.1
Scenario di utilizzo di BlueVoice
Modalità Walkie-Talkie
In fase di sviluppo, per ragioni implementative che verranno chiarite nel capitolo 6, è
stata sviluppata una funzionalità aggiuntiva o, per meglio dire, una diversa modalità di
utilizzo che vede il telefono cellulare collegato, non ad un’applicazione che risiede su un
PC, bensı̀ ad un altro terminale mobile su cui è installata l’applicazione Symbian. Essa è
stata definita modalità Walkie-Talkie per l’evidente analogia con gli apparecchi di ricetrasmissione portatili, anche se di fatto non ha la caratteristica, per lo meno in fase di design,
del metodo di comunicazione Push-to-Talk, in quanto non è un canale half duplex commutato di volta in volta dalla pressione di un tasto. Ciò che rappresenta questa modalità è
una chiamata telefonica (e quindi full-duplex) di basso raggio, in quanto basata sulla connessione Bluetooth e quindi, stando alle classi di potenza specificate nel paragrafo 4.2.2,
95
dell’ordine di qualche decina di metri indoor (considerando che tipicamente un cellulare
monta un dispositivo Bluetooth di classe 2).
Ovviamente la casistica di utilizzi di questa funzione è decisamente ridotta considerata
la ristretta portata che garantisce Bluetooth, ma avrebbe il vantaggio di essere totalmente
gratuita e quindi potrebbe fungere da servizio “home oriented” come controllo remoto
degli ambienti o appunto come Walkie-Talkie.
5.4
Visione generale del progetto BlueVoice
Il software sviluppato è denominato BlueVoice, e si compone di un’applicazione Symbian
per la piattaforma Serie 60 2◦ Edizione, Feature Pack 2, ovvero per il sistema operativo
Symbian v8.0a installata su un relativo telefono cellulare, ed un server lato PC. Quest’ultimo ha il compito di accettare le connessioni provenienti dal client VoIP sull’apparecchio
mobile e richiamare le opportune primitive per iniziare ed in generale gestire la chiamata
verso un altro end-point. La generica architettura, schematizzata in componenti funzionali
e di struttura, è illustrata in figura 5.2
Nei successivi paragrafi verrano presentate le caratteristiche funzionali dei due moduli
del progetto stabilite in fase di design ed eventualmente modificate e formate in corso d’opera. Verranno tralasciati i dettagli implementativi in quanto se ne fornirà una trattazione
esaustiva nel capitolo 6.
5.4.1
Applicazione lato client
In questa sezione viene presentata l’applicazione client dal punto di vista funzionale e
architetturale, quindi enunciandone le diverse potenzialità che in fase di progetto vogliono
essere raggiunte.
96
Figura 5.2.
Architettura generale di client e server BlueVoice
Installazione e avvio
L’applicativo client è di facile installazione e utilizzo, e necessita semplicemente di un
dispositivo Bluetooth montato sul cellulare e di un adattatore Bluetooth sul PC per stabilire un canale di trasmissione col terminale. Per installare il client è sufficiente seguire le
istruzioni elencate nel paragrafo 3.4.1 e cioè inviare il file BlueVoice.sis al telefono
mediante un messaggio dal PC o utilizzare lo strumento Nokia PC Suite cliccando su “Installazione applicazioni” e selezionare l’appropriato dispositivo mobile su cui installare il
file. Queste due operazioni possono essere svolte mediante Bluetooth oppure mediante il
cavo PC-cellulare fornito in dotazione all’acquisto del telefono.
Una volta terminato l’invio, un wizard di semplice utilizzo verrà avviato sul cellulare; è necessario seguire le istruzioni per portare a compimento l’installazione. Ultimata
questa procedura l’applicazione si troverà sul menu principale, riconoscibile per l’icona e
97
il nome BlueVoice a fianco, e sarà avviabile semplicemente premendo il tasto centrale su
tale icona.
Modalità client e server
Nel paragrafo 5.3.1 è già stato preannunciata la possibilità del client VoIP presente sul
telefono di collegarsi con un altro cellulare simile che abbia un dispositivo Bluetooth. In
pratica il telefono può agire anch’esso secondo due diverse modalità:
Client : in questo caso il cellulare diventa l’iniziatore della connessione nel senso che
assume il ruolo attivo di ricerca di possibili server, cioè di dispositivi Bluetooth che
forniscono il servizio richiesto, appositamente pubblicato mediante il meccanismo
publish-subscribe visto nel paragrafo 4.2.3. Se la ricerca dei dispositivi va a buon fine il client verifica che, tra tutti i dispositivi Bluetooth trovati, vi sia un server BlueVoice. In caso affermativo stabilisce la connessione con esso aprendo due canali
Bluetooth RFCOMM unidirezionali, uno per il traffico da cellulare a PC e l’altro
per il cammino inverso, creando in questo modo un canale virtuale bidirezionale.
Questa modalità viene attivata accedendo alle opzioni offerte dall’applicazione e
premendo su ‘Discover devices’.
Server : è possibile fare funzionare il telefono come server BlueVoice premendo su ‘Start
slave’, il che permetterà ad altri cellulari in fase di scansione del canale wireless
di rilevare il suddetto terminale disponibile per una connessione. Esso inizia una
procedura di apertura di due socket Bluetooth su cui si mette in ascolto e una di
pubblicazione del servizio BlueVoice che è in grado di fornire, al termine della
quale si mette in attesa di una richiesta da parte di un eventuale client. In questo
modo è possibile attuare il tipo di comunicazione cellulare-cellulare che consente
l’interazione tra i due dispositivi sfruttando semplicemente il canale Bluetooth e
non la tratta sulla rete Internet.
Al termine di entrambe queste procedure, colui che ha cominciato la fase di inquiry,
cioè di ricerca dei dispositivi, diventerà Master della comunicazione, mentre l’elemento
98
passivo che subisce la ricerca sarà lo Slave (vedi paragrafo 4.2.2). Di fatto questi ruoli,
come si vedrà in seguito, sono tutto sommato interscambiabili e paritetici una volta effettuato il collegamento e non sono discriminanti di particolari funzionalità. Dopo la connessione del cellulare con una stazione fissa o mobile viene notificato all’utente l’avvenuto
collegamento e il tipo di modalità (Walkie-Talkie o telefonata VoIP), e sono modificate le
opzioni mediante le quali ci si interfaccia al software. A questo punto è possibile iniziare
e ricevere chiamate.
Ciclo di vita di una chiamata
Una volta avviato BlueVoice e al termine di una connessione con un dispositivo server,
l’applicazione agisce come un demone attivo in background in ascolto sui canali Bluetooth utilizzati, in modo che sia comunque possibile utilizzare l’apparecchio normalmente
accedendo a tutte le risorse del cellulare e alle sue funzionalità per altri scopi ed utilizzi.
Nel caso l’utente voglia iniziare la chiamata è sufficiente accedere alla funzione ‘Start
call’ presente nel menu delle opzioni. Nella modalità telefonata VoIP la scelta di inizio
chiamata causerà la visualizzazione di un dialog2 di richiesta del numero telefonico da
digitare. Se si sta usando il programma per dialogare con un altro cellulare, essendo
questi l’unico end-point presente, non è necessario chiedere all’utente di immettere un
numero telefonico, e pertanto tale fase sarà omessa.
Una volta stabilita la connessione audio l’utente può comunicare con l’altro terminale
in quanto la sua voce viene registrata dal microfono incorporato sul dispositivo ed inviata
sul canale Bluetooth in uscita, mentre l’altro canale riceve i pacchetti voce inviati e li
manda all’hardware dell’altoparlante come in una telefonata normale, e come illustrato in
figura 5.3
Al termine della conversazione l’utente può decidere di interrompere la chiamata premendo su ‘Stop call’ o vedersi interrotta la comunicazione da un evento di fine chiamata
2
I dialog sono finestre usate dal programma o dal sistema operativo per visualizzare informazioni
all’utente, o per ottenere risposte e input se richiesti.
99
Figura 5.3.
Schema logico della funzionalità full-duplex
causato dall’altro host. In entrambi i casi l’interruzione provoca la visualizzazione di una
finestra che indica la durata della telefonata in termini di ore, minuti e secondi.
Chi riceve verrà invece notificato dell’ingresso di una chiamata mediante lo squillo del
telefono e da un dialog che visualizza il nome del chiamante e fornisce la possibilità di
accettare o rifiutare la connessione. È da notare che tale finestra viene presentata all’utente
anche se questi non sta usando l’applicazione, poiché BlueVoice è attivo in background e
l’arrivo di una chiamata scatena l’evento di notifica. In caso di risposta affermativa si entra
nello stato connesso di cui si è già parlato in precedenza, in caso contrario il chiamante è
informato del rifiuto della chiamata.
Se l’utente chiamante termina la chiamata prima che dall’altro lato qualcuno possa
rispondere, o in alternativa se il chiamato non risponde entro 20 squilli, al chiamato verrà
100
presentato un dialog che lo informa del numero di chiamate perse e lo interroga circa
la volontà di visualizzare i dati delle chiamate perse. Se viene premuto il softkey3 ‘Visualizza’, ciò che appare all’utente è una lista di nomi rappresentanti l’identificativo dei
chiamanti a cui non è stata data una risposta. Inoltre questi nominativi vengono aggiunti
nel registro di sistema delle chiamate perse e accessibili usando l’opportuna applicazione
presente sul menu generale del telefono.
Seguendo uno schema a blocchi logico il ciclo di vita della chiamata può essere raffigurato nel diagramma 5.4. Si noti come tale flusso è del tutto analogo a quello di una
chiamata sulla rete telefonica mobile. Questa analogia è uno degli obiettivi del progetto in modo da minimizzare la differenza con una procedura a cui si è familiari e da
massimizzarne l’usabilità e la trasparenza.
Usabilità
Una delle considerazioni più significative da esprimere in merito all’usabilità del software è legata all’impossibilità di accedere alle librerie di sistema di un cellulare Symbian.
Questo comporta l’impossibilità di avviare l’applicazione al boot del cellulare (come è
possibile col file initrd di Linux), il che renderebbe ancora più efficiente e trasparente
l’utilizzo del programma.
5.4.2
Applicazione lato server
Il programma che gira sul PC è in realtà la modifica del progetto Open Source SimpleOPAL già introdotto nel paragrafo 4.3.4. Tale software deve essere opportunamente
compilato in ambiente Linux e permette, in quanto fornisce i sorgenti di tutta l’applicazione, di essere modificato e migliorato. SimpleOPAL è un programma avviabile da riga
di comando e senza interfaccia grafica che permette di ricevere e inoltrare chiamate VoIP
fornendo come “numero telefonico” un’opportuna SIP-URI, il cui formato è esposto nel
paragrafo 4.3.3.
3
Vedi paragrafo 3.3.3
101
Figura 5.4.
Diagramma di flusso del ciclo di vita di una chiamata
In questa sezione non si tratterà delle caratteristiche di base di SimpleOPAL (sebbene
102
ne verrano citate alcune e se ne darà una rapida introduzione), bensı̀ saranno analizzate
le modifiche riportate al software al fine di realizzare una struttura coerente e funzionale
con quella creata per il telefono cellulare.
L’obiettivo è quello di integrare SimpleOPAL con il client del cellulare, in modo che
funga da tramite tra i due soggetti della comunicazione, uno in contatto con SimpleOPAL
attraverso Internet, l’altro mediante Bluetooth. Il sistema complessivo di BlueVoice è
illustrato in una sua topologia nella figura 5.5
Figura 5.5.
Schema di chiamata BlueVoice-telefono VoIP
La questione più immediata da risolvere è indubbiamente quella legata all’implementazione di meccanismi basati sulla tecnologia Bluetooth per permettere la comunicazione
tra il soggetto dotato di dispositivo mobile (vedi soggetto 2 in figura 5.5) e il PC, o meglio
l’applicativo VoIP SimpleOPAL. Quest’ultimo fornisce semplicemente le primitive per
gestire una chiamata attraverso Internet (cioè la comunicazione col soggetto 1). A tale
scopo è necessario avere due thread paralleli all’esecuzione di SimpleOPAL, ognuno dei
quali gestisce uno dei due canali Bluetooth unidirezionali che sono portatori dei pacchetti
voce da e per il telefono cellulare.
In questo modo SimpleOPAL da un lato diventa server Bluetooth in attesa delle connessioni dall’utente mobile esattamente come avveniva nel caso in cui l’applicazione lato
client fungeva da server (vedi 5.4.1), e dall’altro lato agisce da client e server per le chiamate VoIP. Anche in questo caso si mette in ascolto sui canali Bluetooth e pubblica il
servizio BlueVoice che è in grado di fornire e i numeri di porta, per poi mettersi in attesa
di una richiesta da parte di un eventuale client.
103
In definitiva BlueVoice lato server è sostanzialmente costituito da SimpleOPAL senza
alcuni aspetti non utili al progetto, come la trattazione del segnale video, e con l’aggiunta
dei due thread.
5.5
Requisiti progettuali
L’applicazione BlueVoice è di tipo multimediale, e in quanto tale deve sottostare a determinati vincoli legati al corretto funzionamento e all’usabilità delle sue funzionalità. Inoltre sono da tenere in conto alcune considerazioni di altra natura che vanno ad impattare
sull’uso più o meno “user-friendly” del prodotto finale.
5.5.1
Ritardi e jitter
Con streaming di contenuti multimediali si fa riferimento ai media, audio e video, che
vengono ricevuti in un flusso continuo e tipicamente “consumati” dall’utente finale (cioè
visualizzati, riprodotti o elaborati) mentre il fornitore del servizio li sta inviando in tempo
reale. Di fatto quindi il nome streaming si riferisce più al metodo di trasmissione piuttosto
che al contenuto stesso, e tende a sottolineare l’idea di flusso che è legata all’invio dei dati,
poiché se questi ultimi non vengono utilizzati secondo precise scadenze temporali sono
da considerarsi inutili e quindi scartati.
Questo paradigma di trasmissione è quindi palesemente in contrasto con le metodologie adottate, per esempio, per il trasferimento di file, dove l’utilizzo del media è possibile
solo al termine dell’invio. Ciò è impensabile per servizi video o, come ci si focalizza
in questa trattazione, per servizi di telefonia in cui i ritardi di trasmissione possono avere serie ripercussioni sull’interattività della comunicazione e sulla corretta fruizione dei
contenuti da parte dell’utente.
I ritardi tra la produzione dei pacchetti voce e l’effettiva riproduzione a lato del ricevitore possono avere molteplici cause e, se non controllati, possono arrivare a livelli
intollerabili a scapito dell’intellegibilità del discorso in atto. Per assicurare una buona
104
qualità audio si sono quindi dovuti considerare tutti i ritardi presenti nella totalità della
tratta tra i due utenti terminali.
Figura 5.6.
Rappresentazione della tratta totale tra utenti finali
Facendo riferimento alla figura 5.6 è possibile evidenziare lungo ogni tratto tutti i
possibili tipi di ritardi che vanno ad incidere su quello complessivo end-to-end:
• Ritardi di Propagazione : tempi dovuti alla trasmissione effettiva dei pacchetti
dati e di controllo sui canali fisici:
– Canale Bluetooth, ovvero i tratti 1 e 3 della figura.
– Rete Internet che nella figura è schematizzata nel segmento 2 e che è causa di
ritardi fortemente variabili.
• Ritardi di Elaborazione : tempi di sintesi dei dati oppure tempi causati dal trattamento dei dati e da operazioni compiute su di essi e quindi legati ai tempi di
elaborazione del sistema operativo:
– Tempi di sintesi vocale legati alla frequenza di campionamento nei punti A e
B
– Tempi di codifica della voce nei punti A1 e B1 o eventualmente agli estremi
della comunicazione (punti A e B)
105
• Ritardi di Buffering : tempi derivati dalla memorizzazione a lato ricevitore (e
quindi nei punti A o B) di un certo numero di pacchetti ricevuti prima che ne
avvenga effettivamente l’utilizzo.
In particolare l’introduzione di memoria presso il ricevitore e di un ritardo iniziale
prima della riproduzione ha lo scopo di eliminare i problemi causati dal jitter4 . Il fatto che
i pacchetti sperimentino in rete dei ritardi differenti (i pacchetti possono seguire percorsi
differenti gli uni dagli altri), causa dei problemi quando si vogliano riprodurre i pacchetti
immediatamente dopo l’arrivo (“on the fly”) a causa dei rigidi vincoli di riproduzione da
rispettare.
Con l’introduzione di un buffer nel quale i pacchetti vengano accumulati all’arrivo e
dal quale vengano prelevati, dopo un certo ritardo, con frequenza costante per essere avviati alla riproduzione, si riesce a svincolare la velocità di arrivo da quella di riproduzione
(quest’ultima coincidente con la velocità di prelievo dal buffer). La probabilità che, in
corrispondenza dell’istante di riproduzione di un campione, il pacchetto che lo contiene
sia effettivamente presente presso il Client aumenta, mentre il jitter è responsabile semplicemente di tempi di attesa differenti per i pacchetti nel buffer: i pacchetti che arrivano
in anticipo sperimentano tempi di attesa maggiori, quelli in ritardo inferiori.
Il ritardo iniziale di riproduzione serve a spostare in avanti tutte le deadline di riproduzione e ad assorbire, di fatto, il jitter. Ovviamente, ritardi iniziali eccessivi sono mal
tollerati dall’utente che abbia richiesto la riproduzione; i limiti consentiti variano a seconda del tipo di applicazione, ma in generale il ritardo al di sopra del quale un utente
percepisce una cattiva qualità del servizio si aggira intorno ai 400 ms, anche se è meglio,
perché riscontrato essere percettivamente tollerabile, se rimane attorno o sotto i 150-200
ms. Per avere un’ idea dei ritardi medi e massimi in alcuni dei servizi di telefonia basti
pensare osservare la tabella 5.1
Considerate queste tempistiche è obiettivo principale del progetto contenere al massimo i ritardi di bufferizzazione della voce ricevuta sul dispositivo mobile. Se si tiene
4
Il jitter si riferisce alla variazione statistica nel ritardo dei pacchetti, causata dalle code interne ai router
congestionate.
106
Tabella 5.1. Tabella di confronto ritardi tra standard telefonici e applicativi VoIP
Applicazioni e Standard
Ritardi
GSM
0,233 ms
UMTS
max 150 ms
SimpleOPAL
50-250 ms
Skype
100-200 ms, max 500 ms
conto che i ritardi medi introdotti da SimpleOPAL si aggirano sui 150 ms e che il vincolo
temporale complessivo è di 400 ms, si ha un margine di ritardo che può essere sfruttato
per il buffering che arriva fino ad un massimo di 250 ms. Nel caso peggiore, cioè quello
in cui SimpleOPAL tocca i massimi ritardi (250 ms) il vincolo per il buffering si abbassa
a 150 ms. Si vedrà nel capitolo 6 come è stato rispettato questo vincolo temporale.
5.5.2
Vincoli per la connessione Bluetooth
Considerato il fatto che si tratta di una comunicazione streaming e che i contenuti devono
essere fruiti in tempo reale, conviene avere come supporto per la comunicazione un protocollo che abbia le caratteristiche di UDP5 . Come già visto nella trattazione del protocollo
RFCOMM (paragrafo 4.2.3), esso ha un comportamento simile a TCP, mentre L2CAP
viene generalmente scelto per canali su cui verrebbe usato UDP. Tuttavia L2CAP è un
protocollo orientato alla connessione che invia in modo affidabile datagram con lunghezza massima fissa, ma che può essere “personalizzato” con configurazioni a diverso livello
di affidabilità.
Sebbene però Bluetooth permetta alle applicazioni di usare comunicazioni best-effort
piuttosto che affidabili, si ha comunque un problema legato a L2CAP: adattare le semantiche di trasmissione per una connessione L2CAP verso un altro dispositivo va ad
influire su tutte le restanti connessioni L2CAP, se presenti. Inoltre, poiché RFCOMM usa
5
UDP è un protocollo di trasporto a pacchetto best-effort, privo di connessione, ma in compenso molto
rapido ed efficiente per le applicazioni time-sensitive. Viene infatti usato spesso per la trasmissione di informazioni audio o video, dato che le applicazioni in tempo reale richiedono un ritmo minimo di spedizione,
non devono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di
dati.
107
L2CAP come livello di trasporto, anche le connessioni di questo tipo sono interessate.
Sarebbe perciò uno svantaggio in quanto si andrebbe a disturbare altre applicazioni su
quel dispositivo che hanno delle connessioni aperte.
Per quanto riguarda invece gli aspetti di tipo pratico sulla ricerca dei dispositivi sono
necessari alcuni accorgimenti per evitare malfunzionamenti causati da disturbi di collisione delle porte dei canali e per semplificare l’utilizzo dell’applicazione all’utente.
Dal momento che durante l’uso dell’applicazione BlueVoice altri servizi Bluetooth
potrebbero essere presenti e attivi non solo sul dispositivo stesso, ma anche nelle immediate vicinanze, è indispensabile aprire dei socket e quindi instaurare delle connessioni
su canali Bluetooth il cui numero di porta sia assegnato in modo dinamico piuttosto che
scegliere staticamente tale numero in fase di progetto. Questa seconda possibilità causerebbe possibili collisioni con altre applicazioni server messe in ascolto sugli stessi canali
e di conseguenza un malfunzionamento dell’applicazione. L’eventualità di collidere sui
canali non è di fatto cosı̀ remota in quanto il protocollo RFCOMM non ha a disposizione
di un numero elevato di canali.
Analogamente è opportuno che il server, sia quello presente sul PC che quello sul
cellulare, presenti ad eventuali client il servizio di telefonia VoIP che è in grado di offrire.
In questa maniera i client che ricercano il server BlueVoice scelgono e selezionano in
modo intelligente solo i dispositivi o stazioni fisse con il particolare servizio che stanno
cercando, discriminandoli da tutti gli altri host trovati.
Sia la notifica delle porte che il servizio offerto vengono effettuati pubblicando le
relative informazioni sul Service Discovery Protocol, già descritto nel paragrafo 4.2.3.
5.5.3
Aspetti di usabilità
All’interno di questa parte dedicata ai requisiti è doveroso elencare alcune questioni meno stringenti dei vincoli visti in precedenza che non vanno ad impattare tanto sul corretto funzionamento o meno dell’applicazione, quanto sull’usabilità finale percepita dal
fruitore del software:
108
• Il server ha il compito di dare all’utente non solo gli avvisi tipici della telefonia
(chiamata rifiutata, chiamata terminata, tempo della chiamata ecc.), ma lo deve
informare ugualmente di anomalie di rete come caduta del link, codec non comuni,
banda insufficiente, errori di trasporto, host non raggiungibile nella rete o host non
in linea.
• Il sistema deve essere in grado di funzionare indipendentemente dalla modalità di
utilizzo (Walkie-Talkie o telefonata VoIP) senza differenze di funzionalità, e l’utente deve essere informato se il server a cui si è connesso è un altro telefono cellulare
o un PC connesso ad Internet.
• Se l’applicazione client dovesse essere terminata per carenza di batteria o semplicemente per un errore di digitazione dell’utente, questi non deve ogni volta riavviare
il server per ristabile una connessione. Il server deve essere perciò in modalità
“always-on” e deve rilevare ogni caduta di connessione con il client, in modo da
mettersi nuovamente in ascolto perché l’utente possa ripristinare la connessione.
• Aggiunta di una entry nel registro delle chiamate per notificare al cliente la presenza di un chiamata non risposta. È preferibile utilizzare il log di sistema poiché
l’utente è maggiormente abituato a consultarlo e può reperire informazioni anche
sulle chiamate provenienti dalla rete GSM o UMTS.
109
Capitolo 6
Implementazione del progetto
6.1
Introduzione
La trattazione svolta in questo capitolo è la conseguenza degli obiettivi, vincoli e requisiti
esposti in quello precedente in quanto ne descrive l’implementazione pratica nell’applicazione BlueVoice finale.
È perciò rivolta ad un lettore che abbia una qualche dimestichezza con il sistema operativo Symbian e che abbia intenzione di affrontare uno studio del codice sviluppato con
l’eventuale intenzione di apportarne migliorie tecniche o aggiunte. Verranno infatti dettagliati con maggiore precisione tutti i componenti e le classi dei programmi server e client
facenti parte dell’applicazione, fornendone le caratteristiche funzionali viste nell’ambito
della struttura applicativa di cui si è fatto riferimento nei precedenti capitoli.
6.2
6.2.1
Architettura del progetto
Classi client-side
L’applicazione BlueVoice eseguita sul telefono cellulare è stata realizzata utilizzando
l’IDE Carbide C++ ed è costituita da dodici classi, cinque delle quali rappresentano i
110
6 – Implementazione del progetto
componenti principali di un’applicazione Symbian come visto nel capitolo 3 (paragrafo 3.4.2), mentre le rimanenti sono le classi che implementano specifiche funzioni come
l’instaurazione del canale Bluetooth o i passi per l’acquisizione della voce.
La figura 6.1 sintetizza graficamente la struttura implementativa di BlueVoice fornendone un chiaro diagramma UML che evidenzia per ogni classe le funzioni e gli attributi
principali.
Di seguito verrà fornito un dettagliato elenco delle classi implementate, ad esclusione
delle classi BlueVoiceApp, BlueVoiceDocument e BlueVoiceView per la cui
trattazione si rimanda al paragrafo 3.4.2 in quanto non presentano particolari significativi
al fine dell’apprendimento dellle caratteristiche specifiche di BlueVoice.
Classe BlueVoiceAppUi
La classe eredita da CEikAppUi ed implementa le funzioni DynInitMenuPaneL e
HandleCommandL. Quest’ultima viene richiamata dal framework e serve per gestire
i comandi forniti dall’utente in forma di pressione dei tasti del tastierino del cellulare.
In base alla scelta dei tasti o delle opzioni che le risorse dell’applicazione mostrano in
forma di menu o dialog, vengono richiamate opportune funzione per espletare i comandi
richiesti.
La funzione DynInitMenuPaneL inizializza dinamicamente il pannello del menu,
ed è anch’essa richiamata dal framework Uikon. In questo modo, sulla base dello stato
e di valori relativi all’applicazione, è possibile presentare all’utente diverse opzioni del
menu coerenti alla macchina a stati attraverso la quale passa il processo di chiamata;
questo consiste nel nascondere o mostrare le opzioni, aggiungerne dinamicamente delle
altre o modificarne i testi.
Il costruttore della classe BlueVoiceAppUi istanzia ed inizializza anche oggetti di
classe BlueVoiceEngine, VoiceInput, VoiceOutput e BlueVoiceView che
verranno usati in seguito anche da altre classi, per le quali BlueVoiceAppUi fornisce
un interfaccia di funzioni pubbliche che permettono di ottenere tali oggetti.
Una funzione degna di nota è BringToForeground in quanto ha il compito di
111
Figura 6.1. Diagramma UML dell’applicazione BlueVoice
riportare l’applicazione che sta girando in background (per esempio se è in attesa di una
chiamata) in primo piano, ovvero in foreground e quindi visibile all’utente. È utilizzata
per rendere visibile BlueVoice in modo che l’utente possa consultare l’elenco di eventuali
112
chiamate perse.
Classi VoiceInput e VoiceOutput
Sono le classi preposte all’acquisizione, alla trattazione e alla riproduzione del segnale
vocale. Le operazioni di Input/Output della voce, cioè la fase di “recording” che dall’apparato di fonazione umano all’hardware del cellulare permette di salvare le informazioni
registrate in pacchetti vocali dal formato digitale, e quella di “playing” che segue il percorso inverso dall’altoparlante all’orecchio e veicola all’utente i pacchetti audio provenienti
dalla connessione Bluetooth, sono interamente gestite nell’ambito rispettivamente delle
classi VoiceInput e VoiceOutput.
La classe VoiceInput si occupa della registrazione vocale ed avvia il processo di
Input audio mediante la funzione Record. Il compito espletato dalla funzione di registrazione risulta essere più semplice di quello per la riproduzione, in quanto non appena viene
acquisito un frame vocale mediante la funzione CMdaAudioInputStream::ReadL,
esso viene inviato sul canale Bluetooth richiamando le apposite primitive che la classe BlueVoiceEngine mette a disposizione. La classe VoiceInput implementa le
funzioni definite nell’interfaccia MMdaAudioInputStreamCallback, una classe di
callback1 che notifica il client sul processo di input streaming controllato grazie alla classe
CMdaAudioInputStream. Queste funzioni sono:
• MaiscOpenComplete : indica l’avvenuta apertura del buffer su cui sarà caricato
il contenuto multimediale registrato dal microfono, consente di svolgere operazioni
antecedenti il processo di input come impostazioni del guadagno, della codifica e
della priorità del flusso e da il via alla registrazione vera e propria.
• MaiscBufferCopied : notifica che un frame audio è stato copiato nel buffer (a
seguito dell’avvenuta registrazione), che viene passato come riferimento nei parametri della funzione. Esso viene inviato all’host remoto mediante la SendFrame
1
Le clasi di callback forniscono funzioni richiamate dal framework per avvertire dell’avvenuto
compimento di funzioni di sistema.
113
del motore dell’applicazione. Se non ci sono stati errori viene richiamata la funzione per acquisire il prossimo pacchetto di voce che richiamerà in modo ricorsivo
questa funzione fino al termine della registrazione.
• MaiscRecordComplete : richiamata al termine della registrazione a seguito
dell’invocazione della funzione Stop.
La classe VoiceOutput gestisce invece il buffer di playout2 e si incarica di riprodurre i dati ricevuti. Analogamente alla classe per l’input, essa implementa l’interfaccia di
callback MMdaAudioOutputStreamCallback la cui riscrittura dei metodi permette di aprire il buffer, copiare via via i frame nei registri hardware e terminare il processo,
in un meccanismo del tutto simile a quello illustrato nell’elenco precedente per la classe
VoiceInput. I passi principali dell’output streaming vengono effettuati dalla classe
CMdaAudioOutputStream di cui le callback ne catturano i risultati e notificano gli
effetti del processo al framework. In aggiunta tale classe si occupa di caricare i frame audio ricevuti in un buffer di playout secondo una procedura che verrà illustrata nel
paragrafo 6.3.2.
In ultima analisi è utile ricordare che la frequenza di campionamento della voce è
di 8 kHz e che nella seconda edizione della Serie 60 la funzione ReadL della classe
CMdaAudioInputStream restituisce i dati in frame da 320 byte. Sapendo che vengono prodotti campioni PCM di 16 bit è semplice calcolare la durata di ogni frame audio.
Per fare ciò si calcola la velocità di campionamento:
vc = fc · Nbyte /campione = 16 kB/s
(6.1)
E quindi il tempo di durata del frame risulta essere:
Tf rame =
Nbyte /f rame
= 20 ms
vc
Dove
2
Vedi 5.5.1
114
(6.2)
fc = f requenza di campionamento [Hz]
Questo calcolo è particolarmente utile nel conteggio del ritardo introdotto dal buffer di
playout per contrastare gli effetti del jitter. Infatti, più frame vengono memorizzati prima
della riproduzione, maggiormente viene contenuto questo problema, ma altresı̀ aumentano i ritardi end-to-end a scapito della qualità e dell’interazione della comunicazione. Se,
d’altro canto, si vuole ridurre il ritardo complessivo si rischia di non avere pacchetti nel
buffer (a causa di un eccessivo ritardo di questi) quando essi sono necessari. Bisogna
perciò trovare un giusto compromesso tra questi due aspetti.
In definitiva si può affermare che le classi VoiceInput e VoiceOutput sono classi appartenenti al componente Modello del paradigma MVC, e cioè sono classi di tipo Engine. Il motivo per cui sono separate dall’altra classe del Modello BlueVoiceEngine
è per disaccoppiare gli algoritmi dedicati al trattamento audio da quelli per la gestione
della connessione Bluetooth e della telefonata. Questa scelta è stata adottata in quanto è
possibile modificare o rimuovere separatamente una delle due parti senza intaccare l’altra, il che semplifica lo sviluppo e aumenta la flessibilità dell’applicazione. Sono stati
inoltre separati processi di registrazione e riproduzione perché in questo modo è possibile svolgere queste due operazione in contemporanea, garantendo cosı̀ la funzionalità di
full-duplex prescritta negli obiettivi.
Classe BlueVoiceEngine
La classe BlueVoiceEngine è sicuramente una delle classi principali del progetto in
quanto coordina tutta la procedura di inquiry e di connessione Bluetooth, controlla la trasmissione e ricezione dei dati delegando le classi VoiceInput e VoiceOutput per il
corretto utilizzo dei dati multimediali e gestisce le informazione di segnalazione necessarie per l’instaurazione, la conservazione e l’abbattimento della chiamata telefonica.
Nel costruttore vengono istanziati due oggetti della classe Listener per i due socket
115
Bluetooth ai capi dei due canali da e per l’altro end-point, e tre oggetti rispettivamente delle classi DeviceDiscoverer, ServiceAdvertiser e ServiceDiscoverer.
L’utente può scegliere se fare comportare il proprio cellulare come client o come slave/server premendo rispettivamente i comandi ‘Discover Devices’ oppure ‘Start Slave’.
Nel primo caso viene lanciata la funzione DiscoverDevicesL della classe Engine,
nel secondo StartSlaveL. Quest’ultima ottiene due porte per i due canali mediante il
metodo StartListenerL richiamato su due distinti oggetti della classe Listener
e usa la classe ServiceAdvertiser per pubblicare queste informazioni sul database
distribuito mediante il protocollo SDP. A questo punto il telefono è un server Bluetooth
posto in attesa di eventuali connessioni.
La funzione DiscoverDevicesL demanda invece i servizi di ricerca dispositivi
alla classe DeviceDiscoverer e al completamento dell’inquiry viene fornita all’Engine la lista dei dispositivi trovati nel raggio d’azione mediante la funzione di callback
HandleDeviceDiscoveryCompleteL. Essa si occuperà inoltre di valutare se tra
gli host reperiti ve n’è qualcuno che fornisce il servizio BlueVoice mediante la funzione DiscoverServicesL che sfrutta a tale scopo le potenzialità offerte dalla classe
ServiceDiscoverer e in caso affermativo viene attuata la connessione vera e propria
grazie alla funzione ConnectDevicesL. Per fare ciò sono utilizzate due istanze delle
classi Connector, e al termine si invoca la funzione ShowConnectedDevicesL per
mostrare all’utente il nome dell’end-point a cui è connesso. Ciò che è stato presentato or
ora a parole per le ricerca dei dispositivi è meglio illustrato nel diagramma di figura 6.2.
Stabilita la connessione, l’Engine coordina anche l’invio e la ricezione di dati attraverso i canali Bluetooth mediante la SendFrame e una serie di funzioni di callback tra
cui basti citare le due sfruttate per la ricezione pacchetti da parte dello slave e del master:
HandleListenerDataReceivedL e HandleConnectorDataReceivedL. Esse si appoggiano entrambe alla funzione helper DataReceivedL che “smista” il traffico
voce da quello di controllo per la segnalazione e rende totalmente identico e paritetico il
ruolo di master e slave.
Bisogna ricordare inoltre che BlueVoiceEngine eredita da CActive, la classe
116
Figura 6.2. Diagramma UML della pubblicazione servizi a lato server e ricerca e connessione di dispositivi Bluetooth a lato client
base per l’astrazione di un active object, ed implementa infatti la funzione RunL per gestire i vari casi del completamento di una richiesta asincrona. Questa viene usata in tutti
117
quei casi in cui all’utente viene mostrato un dialog che lo interroga su determinate questioni (ad esempio se rispondere o meno ad una chiamata entrante) mentre uno o altri
processi sono comunque in corso. La scelta dell’utente causerà diversi comportamenti controllati e gestiti opportunamente. Si considerino a tale proposito tutte le funzioni
di gestione della chiamata che hanno la duplice funzione di fare evolvere lo stato della
telefonata e, al tempo stesso, notificare visivamente tale stato.
Queste primitive per la chiamata sono:
• StartCall : inizia la chiamata inviando un opportuno messaggio di segnalazione
all’altro cellulare o al PC e si mette in attesa di risposta dell’host remoto.
• StopCall : termina la chiamata e informa l’altro soggetto della comunicazione di
tale scelta. Inoltre richiama la funzione CallDuration per calcolare il tempo
trascorso durante la conversazione e visualizzare una nota informativa al riguardo.
• HandleControlMessageL : è richiamata dalla funzione DataReceivedL quando
riconosce di aver ricevuto un’informazione di controllo. In questo caso la passa
a HandleControlMessageL che si occupa di analizzarla e gestire le dovute
operazioni.
• ReceiveCallData : anch’esso è invocato da DataReceivedL nel caso duale in
cui ciò che riceve è un pacchetto di voce. La ReceiveCallData coordina la
riproduzione del segnale passando i pacchetti alla classe VoiceOutput.
Quando entrambi gli host sono intenzionati ad instaurare una comunicazione telefonica tra loro, e cioè in seguito all’accettazione del chiamato nei confronti del chiamante,
su entrambi i dispositivi viene avviata la registrazione demandando, a tale scopo, le risorse offerte dalla classe VoiceInput che immediatamente invia all’host remoto i dati
acquisiti e che verranno gestiti, come visto, dalla funzione ReceiveCallData.
Questa classe si occupa anche di aggiungere le entry nel registro delle chiamate perse
in un processo che viene spiegato nel paragrafo 6.3.4.
118
Classe DeviceDiscoverer
Questo componente è piuttosto semplice e si occupa della scansione wireless alla ricerca
di dispositivi Bluetooth presenti all’interno del raggio d’azione. La funzione principale
della classe è infatti DiscoverDevicesL che opera la fase di inquiry usando la classe
Symbian RHostResolver, un’interfaccia per servizi di risoluzione nomi, simile a DNS,
che può essere usata con diversi protocolli. Ad esso viene infatti passato il nome del
protocollo e l’Inquiry Access Code (vedi 4.2.2) e si avvia il processo asincrono che, dati
gli indirizzi, si occupa della risoluzione dei nomi degli host.
Ad ogni dispositivo trovato vengono aggiornati i campi relativi al nome e indirizzo
della struct TDeviceData che incapsula le informazioni di ogni apparecchio reperito ed è definita nel file header Common.h del progetto BlueVoice(vedi figura 6.3).
La funzione di inquiry è chiamata da BlueVoiceEngine e ad essa viene passato il
riferimento ad una lista di tipo TDeviceData, che in caso di dispositivi trovati, viene
riempita con le informazioni di tutti gli host.
Classi ServiceAdvertiser e ServiceDiscoverer
Le classi ServiceAdvertiser e ServiceDiscoverer forniscono un servizio
duale: la prima accede al database SDP per aggiungere un record che, quando il terminale
mobile agisce da server, informa eventuali client del servizio offerto e di attributi utili per
effettuare la connessione, la seconda invece è usata in modalità client per esaminare se
tra tutti i dispositivi Bluetooth elencati nella lista di TDeviceData ve n’è qualcuno che
fornisce il servizio BlueVoice. È facile intuire come queste due classi vengano utilizzate
in modo esclusivo a seconda della modalità in cui il terminale mobile sta operando: se
esso è server della comunicazione avrà bisogno di comunicare i servizi disponibili per
potersi mettere in ascolto e userà a tale scopo ServiceAdvertiser; analogamente
se il telefono è client si troverà nella necessità di ricercare il server BlueVoice fra tutti i
dispositivi Bluetooth trovati e utilizzerà ServiceDiscoverer.
La funzione più di rilievo di ServiceAdvertiser è StartAdvertiserL che
119
crea un service record e in esso scrive il valore delle porte che terminano i canali di
ricezione dal client (aChannelMS) e quello di invio al client (aChannelSM), oltre che
ovviamente il tipo della modalità. Quest’ultimo è definito da un valore intero che può
assumere i valori 0 e 1; nel primo caso il server che pubblica questo service record è un
PC con una connessione Internet, nel secondo caso è un cellulare che sta funzionando da
server. Nella presente classe il tipo è perciò staticamente settato a 1.
La classe ServiceDiscoverer presenta la funzione DiscoverServicesL la
quale, in base alla lista fornita da DeviceDiscoverer, scandisce ogni singolo host
per vedere se è del tipo cercato in base al identificativo unico del servizio pubblicato dal
server che nel caso di BlueVoice assume il valore 0x10ff. Mediante la visita del record
e dei suoi attributi vengono riempiti i campi della struttura TDeviceData rimanenti,
cioè non ancora caricati nella fase di inquiry. La figura 6.3 mostra la struct che definisce
l’host remoto.
Figura 6.3.
Rappresentazione grafica della struct TDeviceData che definisce un dispositivo remoto
Classi Listener e Connector
La classe Listener è una particolarizzazione di CActive in quanto ha bisogno di gestire i socket Bluetooth ai capi dei canali instaurati con l’altro end-point, ed è usata nella
modalità server del terminale mobile. È quindi una sorta di “thread” che costantemente
120
ascolta la porta in attesa di pacchetti in arrivo, e gestisce ogni evento asincrono richiamando la funzione RunL che in base allo stato in cui si trova la comunicazione svolgerà
determinate operazioni e completerà le richieste dei client.
La funzione che si occupa di inizializzare il server e di metterlo in condizione di ascoltare le richieste di connessione è StartListenerL che apre un socket sul protocollo
RFCOMM destinato ad accogliere richieste di connessione, ottiene la porta per il canale
di ascolto e lo pone in fase di attesa mediante la funzione RSocket::Listen(). Essa
crea una coda per conservare le richieste che verranno poi accoppiate usando la Accept
ad un socket “vuoto” che gestisce la connessione vera e propria. Il socket è ora pronto per
ricevere dati e ciò viene eseguito mediante la funzione ReceiveData che, non appena ricevuto un pacchetto richiama HandleListenerDataReceivedL per avvertire
l’Engine dell’arrivo dei dati, e si rimette in ascolto del dato successivo. Analogamente è
possibile inviare dei dati sul socket grazie alla funzione SendDataL a cui l’Engine passa
opportunamente il pacchetto da inoltrare sul canale, quando se ne presenta l’occasione.
Cosı̀ come i due oggetti Listener istanziati da BlueVoiceEngine rappresentano l’astrazione dei due canali Bluetooth e ne gestiscono l’evoluzione in due active object
separati quando il terminale agisce da server, cosı̀ la classe Connector controlla i socket della comunicazione nel caso in cui il cellulare ricerca un server e, trovato il servizio
BlueVoice, usa due oggetti di tale classe per effettuare la connessione. Per fare ciò viene
utilizzata la funzione ConnectL a cui sono passati i parametri rappresentanti l’oggetto
remoto (nome, indirizzo e porta) e una volta connessi i due oggetti (uno per canale di
trasmissione) essi si comportano come visto per la classe Listener disponendo delle
funzioni WaitAndReceiveL e SendDataL per ricevere ed inviare dati.
6.2.2
Struttura server-side
Il server BlueVoice è un programma C++ lanciato da riga di comando ed eseguito su
una macchina Linux, ed è sostanzialmente una modifica di SimpleOPAL a cui sono state
apportate modifiche per interfacciare tale software con il client presente sul terminale
mobile. La struttura di SimpleOPAL è piuttosto semplice e verrà esposta brevemente
121
nel paragrafo successivo, mentre una maggiore attenzione sarà rivolta ai dettagli aggiunti
durante la realizzazione del progetto di tesi. Non è intenzione di questo testo dedicare
troppa attenzione a SimpleOPAL e sono infatti tralasciati aspetti poco rilevanti quali, per
esempio, la trattazione del segnale video.
Breve descrizione di SimpleOPAL
Per lanciare SimpleOPAL è necessario compilare la Portable Windows Library3 (PWLib),
le librerie del progetto OPAL e digitare simpleopal -l, in modo da potere effettuare
e ricevere chiamate.
SimpleOPAL si compone di un metodo Main che viene lanciato all’avvio del processo. Esso mostra sullo standard output tutte le possibili opzioni disponibili, e in caso di
parametri impostati da riga di comando li elabora mediante la funzione Initialise. A
questo punto viene lanciata la funzione Main dell’oggetto MyManager che eredita dalla
classe OpalManager già discussa nel paragrafo 4.3.4. Tale funzione interroga l’utente
relativamente ai comandi disponibili e li svolge mediante una serie di funzioni coadiuvate
da altre di callback che avvertono l’utente di eventi come l’arrivo di una chiamata, l’accettazione della richiesta o la terminazione della connessione da parte dell’utente remoto.
Alcuni dei comandi possibili sono:
• M : invia un messaggio di testo all’utente remote
• C : si connette all’host remoto di cui si fornisce la URI SIP
• S : visualizza le statistiche
• H : termina la chiamata
Integrazione di SimpleOPAL con un server Bluetooth
Per poter permettere il collegamento con il cellulare è necessario implementare un server
BlueVoice che si interfacci con un dispositivo Bluetooth montato sul PC o eventualmente
3
PWLib è una classe di librerie originariamente progettata come metodo per produrre applicazioni in
grado di essere eseguite sia in sistemi Microsoft Windows che Unix/X11, e su cui SimpleOPAL si appoggia.
122
un adattatore USB. Per fare ciò sono state usate le librerie BlueZ secondo un meccanismo
del tutto simile a quello seguito per realizzare il server sul telefono cellulare. All’avvio
della funzione Main infatti, è stato creato un thread principale rappresentato dalla funzione btManager parallelo al normale funzionamento di SimpleOPAL che quindi non
è stato alterato e può essere utilizzato normalmente.
La gestione degli aspetti legati alla connessione Bluetooth è affidata ad un ciclo infinito (while(1)) all’interno del quale sono creati altri due thread, ognuno per il controllo
dei socket in ascolto di connessioni da parte di client BlueVoice. La scelta di un ciclo
infinito è motivata dal fatto che il server Bluetooth deve essere un demone attivo per tutta
la durata del programma, e ogni volta che rileva la perdita di connessione BlueVoice da
parte di un client, deve rimettersi in ascolto su altre porte per consentire allo stesso client,
o eventualmente ad altri, di poter ristabilire un collegamento tra le due parti. In questo
modo si garantisce la persistenza del server, mentre il thread principale cesserà di esistere
solo con la terminazione di SimpleOPAL.
Una volta creati i due thread all’interno di quello parallelo al processo principale, se
ne pubblicano i numeri di porta dei canali in ascolto mediante il protocollo SDP, grazie alla funzione register_service che sfrutta le API BlueZ per creare un service
record dagli opportuni parametri e pubblicarlo sul database. Il ciclo infinito risulterebbe, da quanto visto finora, in un interminabile creazione di thread e conseguentemente
di apertura socket, se esso non fosse fermato su un semaforo mediante una wait; la
signal che sblocca tale semaforo viene invocata ogni qual volta un client termina il processo BlueVoice sul terminale mobile, causando in questa maniera la reinizializzazione
del server.
I due thread lanciano, al momento della creazione, due funzioni simili denominate
receivingBTSocket e sendingBTSocket. Entrambe queste funzioni allocano
un socket Bluetooth RFCOMM e gli assegnano dinamicamente un indirizzo locale grazie
alla dynamic_bind_rc che richiama la bind sul socket tante volte quante sono le porte
disponibili con il protocollo RFCOMM, e per ognuna controlla il valore di ritorno iterando
finché essa non si completa con successo. Di seguito i due thread vengono bloccati con la
123
listen che mette i socket in ascolto di eventuali connessioni.
Come suggerisce il nome, la receivingBTSocket controlla il socket in ricezione
dal client e implementa, a tale scopo, un ciclo continuo che va a leggere i dati ricevuti sull’interfaccia Bluetooth e ne interpreta il significato legato alle informazioni di controllo,
richiamando opportunamente le primitive di SimpleOPAL che gestiscono i vari casi della
telefonata.
Per notificare il client dello stato della connessione e in generale per inviare dati al dispositivo mobile, viene invece usata la funzione del secondo thread, ovvero la
sendingBTSocket. Il thread di ricezione tuttavia è normalmente in ascolto sul canale
e l’evento scatenante una reazione è l’arrivo asincrono di un pacchetto di dati, mentre
quello di invio dipende dallo stato della chiamata VoIP e necessita perciò di una sincronizzazione tra il thread in questione ed il processo principale di SimpleOPAL. Quest’
obiettivo è raggiunto mediante l’utilizzo delle funzioni wait e signal che, rispettivamente, bloccano e rilasciano il thread su un particolare semaforo. Non appena il socket è
connesso si blocca il thread sul semaforo e viene sbloccato ogni qual volta succede qualche evento da parte della rete Internet ed è necessario informare il client di tali eventi. Si
sfrutta a questo scopo una dettagliata macchina a stati per inviare al dispositivo il giusto
messaggio di controllo e bloccarsi nuovamente sul semaforo.
È importante far notare che il server potrebbe potenzialmente soddisfare le richieste
di più di un client, ma poiché solo un utente alla volta può effettuare una chiamata VoIP,
il server BlueVoice smette di pubblicare il servizio dopo la prima connessione e riprende
a fornirlo dopo la terminazione della sessione Bluetooth.
6.3
Analisi di una chiamata
Una chiamata BlueVoice si dipana attraverso una serie di passi e usa diverse risorse e
formalismi mirati a garantire la connessione di tutte le parti in gioco e ad assicurare un
utilizzo semplice e funzionale del sistema. Le caratteristiche principali che permettono di
raggiungere tali obiettivi sono elencati di seguito:
124
1. Inquiry e connessione Bluetooth
2. Streaming della voce
3. Protocollo di segnalazione
4. Gestione del registro delle chiamate
6.3.1
Inquiry e connessione Bluetooth
Rappresenta la fase propedeutica per stabilire un canale bidirezionale (di fatto costituito da due singoli canali unidirezionali) che collega il processo residente sulla macchina Linux a capo della gestione della chiamata VoIP e quello attivo come applicazione
Symbian sullo smartphone rappresentante il vero punto terminale della chiamata. Una
volta terminata questa fase è possibile usare l’applicazione fino all’abbattimento della
connessione.
Tutte le funzioni utilizzate per portare a compimento questo passo sono già state
esaminate esaustivamente nel paragrafo 6.2.1 e forniscono il supporto per attuare la:
1. Ricerca dei dispositivi o Inquiry
2. Ricerca del servizio BlueVoice tra i dispositivi trovati
3. Connessione del client con il server BlueVoice
4. Utilizzo dei canali Bluetooth per invio e ricezione dei dati
La figura 6.4 sintetizza graficamente le fasi di advertising, discovery dei dispositivi
e dei servizi e lo stato di connessione con i due canali Bluetooth unidirezionali. La figura rappresenta il sistema connesso con una stazione fissa, ma è del tutto analogo se la
connessione fosse in modalità Walkie-Talkie.
125
Figura 6.4.
6.3.2
Fase 1: Ricerca dispositivi e servizi ; Fase 2: sistema connesso
Streaming della voce
La riproduzione e l’acquisizione della voce che deve essere poi mandata in streaming sul
canale Bluetooth e successivamente su Internet sono compiti esclusivi delle due classi
VoiceOutput e VoiceInput. Esse permettono da una parte di registrare la voce dell’utente rappresentando il segnale analogico in pacchetti dal formato digitale PCM che
126
verranno mandati “on the fly” verso l’altro dispositivo, e dall’altra di mandare in riproduzione quelli ricevuti. Per potere garantire la funzionalità full-duplex le due operazioni devono essere svolte in parallelo, in modo che l’utente possa parlare e contemporaneamente
sentire il soggetto all’altro capo della comunicazione.
Buffer di playout e riproduzione
Come è già stato ampiamente trattato in precedenza è necessario avere un buffer di playout
a lato ricevitore per evitare problemi legati ai ritardi variabili che causerebbero situazioni
in cui la cadenza temporale di riproduzione dei pacchetti audio non venga rispettata con
inevitabili cadute della qualità. In questo progetto è stato risolto il problema implementando un buffer circolare che memorizza un certo numero di pacchetti voce ricevuti prima
di poterne avviare la riproduzione.
L’algoritmo per la bufferizzazione è implementato nella funzione PlayData della
classe VoiceOutput a cui viene passato il frame voce ricevuto dall’interfaccia Bluetooth, sfruttando le funzioni LoadBuffer e GetFrame, la prima per inserire un pacchetto
nel buffer, la seconda per ottenere i dati da inviare all’hardware per la riproduzione vera e
propria. Per capire meglio il meccanismo e le variabili in gioco si osservi la figura 6.5.
Le variabili iLoadPointer e iPlayPointer, inizialmente impostate a 0, sono i
puntatori alle celle di memoria del buffer di playout che indicano rispettivamente la prima
cella libera che può essere riempita con un pacchetto in ingresso, e la cella già occupata
da dei dati che sarà la prossima ad essere estratta per la riproduzione. L’algoritmo stabilisce che ad ogni arrivo di un frame venga richiamata la funzione LoadBuffer che lo
inserisce nel buffer nella posizione corretta (in base al puntatore iLoadPointer incrementato ad ogni arrivo) e gestisce la circolarità del buffer azzerando il puntatore per la
memorizzazione ogni qual volta esso giunge all’ultima cella. Inoltre vengono effettuati
due controlli:
1. Il buffer presenta una soglia interna denominata KPlayoutThreshold il cui
superamento da parte del puntatore di memorizzazione iLoadPointer causa
l’inizio della riproduzione dei pacchetti fino a quel momento caricati nel buffer.
127
Figura 6.5.
Rappresentazione logica del buffer circolare e relative caratteristiche
2. Se i due puntatori di caricamento e di riproduzione dovessero andare a coincidere,
ci si troverebbe nella situazione in cui viene riprodotto ciò che è in fase di memorizzazione, con un inevitabile e comprensibile degrado della qualità. Bisogna
aggiungere che questa eventualità, non è cosı̀ remota poiché a causa di ritardi di
trasmissione i puntatori possono avere degli shift notevoli e addirittura andare a
coincidere. Per evitare questo inconveniente viene controllata ogni volta la posizione relativa dei due puntatori, e nel caso puntassero alla stessa area di memoria si
provvede a spostare il puntatore iLoadPointer di un certo numero di frame in
avanti.
La riproduzione è preceduta dall’apertura del buffer, operazione che causa l’invocazione della funzione di callback MaoscOpenComplete4 . In essa si imposta il volume
e la priorità del flusso, si stabilisce il tipo di codifica e si richiama la funzione WriteL
4
Vedi 6.2.1
128
che riproduce i dati e richiama la callback MaoscBufferCopied. In quest’ultima invece si richiama ricorsivamente la WriteL che riceve i pacchetti dalla GetFrame e
autoalimenta il processo di riproduzione poiché viene nuovamente invocata la funzione MaoscBufferCopied e cosı̀ via. La riproduzione di un dato frame all’interno
del buffer è immediatamente seguita dalla sua cancellazione caricando al suo posto il
frame iZero che, come suggerisce il nome, è completamente nullo. In questo modo
si evita di avere il buffer carico di informazioni vecchie, cioè già riprodotte, che potrebbero impattare negativamente sulla qualità percepita dall’utente nel caso di mancata
ricezione di pacchetti dall’interfaccia Bluetooth in quanto, in questo caso, il puntatore iPlayPointer, ciclando sul buffer di playout, causerebbe la riproduzione ripetuta
degli ultimi frame ricevuti e non cancellati.
Nella funzione MaoscBufferCopied viene inoltre incrementato il valore dell’indice iPlayPointer, che sarà azzerato in GetFrame una volta giunto al valore massimo coincidente con la dimensione del buffer. Il processo può essere visualizzato come
mostrato in figura 6.6.
Acquisizione voce
Il processo di acquisizione voce è iniziato quando l’utente avvia la chiamata e la sua voce
viene registrata, e segue un processo del tutto simile a quello esaminato per la riproduzione dei pacchetti vocali. La funzione Record apre il buffer e al termine di ciò la callback
MaiscOpenComplete imposta il guadagno e la codifica e chiama la ReadL che effettivamente imposta il microfono in modalità di acquisizione voce, passandogli il puntatore
all’area di memoria dove scrivere i campioni. Come nel caso precedente, al termine del
riempimento del buffer questo viene passato alla callback MaiscBufferCopied che
si occupa di inviarlo grazie alla funzione SendFrame dell’Engine, e richiama la ReadL
per registrare il successivo frame vocale e cosı̀ via.
129
Figura 6.6.
Evoluzione temporale del buffer circolare
Valutazioni
Considerati i ritardi introdotti da SimpleOPAL illustrati nella tabella 5.1 si vede che nel
caso peggiore il ritardo di playout non può superare i 150 ms se si vuole rimanere al di
sotto di 400 ms di ritardo complessivo. Dalla formula 6.2.1 si evince che ogni frame
da 320 byte ha una durata di 20 ms e da ciò si deriva facilmente che non possono essere
memorizzati più di 7 frame. Conservativamente si è scelto di allocare un buffer di 6 frame,
il che permette di avere ritardi dovuti alla memorizzazione dei dati che variano da 20 a
100 ms. Infatti la posizione dei due puntatori all’interno del buffer è variabile e la figura
6.7 mostra il buffer fisico nei due casi estremi.
130
Figura 6.7.
Ritardi minimo e massimo introdotti dal buffer (rappresentazione fisica)
In quest’ottica la soglia dopo la quale inizia la riproduzione dell’audio è stata impostata dopo i primi tre pacchetti ricevuti, in modo da avere in fase iniziale un ritardo decisamente basso, cioè di circa 40 ms in modo da avere basse latenze anche nella modalità
Walkie-Talkie.
Per quanto riguarda il full-duplex si è impostata la classe BlueVoiceEngine in
modo che coordini l’inizio della registrazione della voce e l’inoltro sul canale Bluetooth sia nel caso di inizio chiamata che di ricezione, in modo da assicurare un flusso
bidirezionale.
6.3.3
Protocollo di segnalazione
Per potere simulare una chiamata telefonica sono necessarie delle informazione di overhead, al di là del traffico voce, per poter controllare il processo e segnalare all’utente gli
eventi in corso. Questi eventi comprendono la richiesta di chiamata da parte di un altro
utente, l’accettazione o il rifiuto di tale richiesta e tutte quelle informazioni fornite dalla
rete nel corso di una normale telefonata. A tale fine si sono codificati, mediante un numero intero, una serie di messaggi di segnalazione, alcuni per la gestione della chiamata
telefonica vera e propria, altri legati a situazioni anomale della rete e perciò relativi al
tratto sulla rete Internet. L’elenco riportato di seguito ne da una visione esaustiva:
1. Messaggi di segnalazione telefonica
131
• EInit : messaggio di inizializzazione del pacchetto di segnalazione;
• EIncomingCall : ingresso di una chiamata;
• EAcceptedCall : chiamata accettata;
• ERejectedCall : chiamata rifiutata;
• EMissedCall : chiamata non risposta per terminazione da parte dell’iniziatore
(es. squillo);
• ENotAnswering : chiamata non risposta per non disponibilità del ricevitore;
• EStopCall : chiamata in corso terminata;
2. Messaggi di segnalazione di rete
• EAbnormalEnd : terminazione dovuta a cause sconosciute;
• ENoCommonCodec : mancanza di codec di compressione comuni tra i due
soggetti della comunicazione;
• ENoUser : il server SIP non trova l’utente o non è registrato;
• ENoBandwidth : banda insufficiente sul canale;
• EUnreachableHost : host remoto non raggiungibile;
• ENoEndPoint : nessun telefono disponibile per il determinato host remoto;
• EHostOffline : host non connesso;
• EConnectFail: errore di trasporto.
Questi messaggi di controllo sono bidirezionali, cioè possono essere inviati dal PC
al cellulare mediante il canale di ritorno (gestito dalla funzione sendingBTSocket
sul PC e dall’oggetto Connector sul terminale mobile) e gestiti adeguatamente in base
al tipo dalla funzione HandleControlMessageL di BlueVoiceEngine, oppure
seguire il cammino inverso sull’altro dei due canali unidirezionali e vengono mappati sui
messaggi di controllo SIP mediante le primitive offerte da SimpleOPAL che virtualizzano
la segnalazione e la rendono trasparente.
132
6.3.4
Gestione del registro delle chiamate
Il registro delle chiamate è un’applicazione di sistema che tiene traccia delle più recenti
chiamate effettuate, ricevute e non risposte. La ragione per cui si è pensato di implementare un log delle chiamate perse è poiché esso è uno strumento decisamente versatile e a
cui l’utenza attuale è tipicamente abituata. Per rendere minore la differenza con la telefonata classica è stato realizzato un meccanismo che va ad aggiungere una entry in tale
registro ogni qual volta l’utente si trova una chiamata non risposta proveniente dal server
BlueVoice. Si ha una chiamata persa nei due seguenti casi:
1. Colui che inizia la chiamata interrompe la richiesta di connessione prima che il
destinatario risponda, ad esempio per fare uno squillo.
2. Il ricevitore raggiunge il numero massimo di squilli effettuati e si interrompe il tentativo di chiamata. Questa situazione è controllata mediante la funzione callback
MapcPlayComplete che dopo ogni squillo incrementa un contatore continuando a riprodurre il tono della suoneria finché la chiamata non è aperta o quando il
contatore raggiunge il valore massimo (impostato a 20). A questo punto informa
l’altro end point della mancata risposta inviando un messaggio di controllo di tipo
ENotAnswering.
Quando si verificano queste due situazioni viene richiamato a lato destinatario la funzione AddMissedCall nella quale viene incrementato il numero delle chiamate perse e
si invoca la AddEventL. Questa funzione crea un evento per il registro nel quale vengono
inserite le informazioni dell’utente che ha effettuato la richiesta di chiamata, e si aggiunge
tale record ad una lista usata dalla classe, ed ovviamente al registro del cellulare mediante
un metodo asincrono. Il completamento di tale metodo richiama la ShowMissedCall
che si occupa di mostrare sullo schermo il numero di chiamate perse e la possibilità di
vederne i dettagli.
Per chiamate entranti e uscenti il meccanismo è lo stesso in quanto è sufficiente modificare, all’atto della creazione dell’evento, quella che è definita come la “direzione” del
133
record, impostandola opportunamente per indicare le chiamate ricevute o effettuate piuttosto che, come in questo caso, quelle perse. Essendo il progetto un semplice prototipo
di studio di fattibilità si è scelto di implementare solo la notifica delle chiamate non risposte in quanto più direttamente utile, ma è piuttosto semplice ampliare le funzionalità
dell’applicazione in questo senso in eventuali prodotti futuri.
134
Capitolo 7
Valutazioni finali
7.1
Introduzione
Al termine della presentazione delle specifiche e requisiti progettuali e la loro relativa
implementazione è necessario, in ultima analisi, valutare gli obiettivi raggiunti e i limiti
riscontrati. Il seguente capitolo si propone di valutare quanto si discosta il progetto effettivamente realizzato dai disegni iniziali del software, per trarre cosı̀ delle conclusioni sul
lavoro svolto durante il periodo di tesi. Verranno perciò illustrate le difficoltà incontrate
e i limiti tecnologici, nonché le relative soluzioni proposte o le ragioni per cui è stato
impossibile risolvere determinate questioni.
7.2
Considerazioni generali
Il progetto è in definitiva conforme alle specifiche e agli obiettivi iniziali in quanto realizza ciò che era stato previsto in fase di progetto e adempie alle idee iniziali. Essendo
un prototipo sviluppato per studiare caratteristiche di fattibilità, la sua realizzazione non
è stata accompagnata da un adeguata implementazione dell’interfaccia grafica, che è stata trascurata per migliorare aspetti operativi legati al buon funzionamento del software.
Tuttavia si è cercato di curare al meglio l’usabilità e di rendere minime le differenze con
135
7 – Valutazioni finali
la normale telefonata, in modo che l’approccio all’utilizzo non presupponga conoscenze
tecniche e che la fruizione dell’applicazione possa quindi coinvolgere il più gran numero
di persone possibile.
Per quanto riguarda la tratta Bluetooth, si può osservare che la banda utilizzata in upstream e downstream è decisamente bassa e adattabile ai bit-rate massimi consentiti dallo
standard Bluetooth. Infatti quest’ultimo prevede, per il traffico dati di tipo asimmetrico,
un bitrate di 723,2 kbps, mentre l’applicazione BlueVoice, producendo un frame voce da
320 byte ogni 20 ms, risulta avere una velocità pari a 128 kbps equivalente a un quarto
della banda telefonica per il downstream, e una velocità identica per l’upstream. Questo
ha permesso, in fase di scelta del tipo di connessione Bluetooth da utilizzare, di optare
per un collegamento basato sul protocollo RFCOMM che ha molte delle caratteristiche
di TCP. Nonostante sia un protocollo connesso e affidabile, e quindi non adatto in linea
teorica per un’applicazione di streaming della voce, si ha avuto comunque un buon esito
poiché la banda non è eccessiva.
È utile inoltre valutare le potenzialità del prodotto che, nella sua fase intermedia di
sviluppo, quella che ha poi dato origine alla modalità di funzionamento in Walkie-Talkie,
può essere considerata come interfaccia applicativa che può essere presa in considerazione
per l’integrazione con altri software per VoIP laddove questo fosse possibile mediante API
pubbliche.
7.3
Limiti tecnologici e problemi
Nonostante le specifiche siano state rispettate, sono stati riscontrati, in corso d’opera,
alcuni problemi e limiti che ne compromettono l’uso, senza comunque andare ad intaccare
la fattibilità del sistema. In particolare i principali limiti sono:
1. Difficoltà di realizzare una conversazione full-duplex mediante le sole API pubbliche offerte dalla SDK Symbian.
2. Qualità della voce accettabile, ma presenza di echi.
136
3. Difficoltà di veicolare i pacchetti voce provenienti dal canale Bluetooth al server
BlueVoice sul PC.
4. Interruzione della chiamata sul canale Bluetooth a causa di una chiamata entrante.
5. Portabilità verso altre piattaforme limitata.
7.3.1
Full duplex
Il primo dei problemi è legato al fatto che Symbian OS non supporta la funzionalità di
full-duplex poiché la politica audio è stata progettata per essere semplicemente di tipo
“one-shot” (come suggerisce la sezione delle domande frequenti e consigli tecnici del
sito di Symbian [5]). Ciò significa che un’applicazione può avere un flusso audio per
volta, nel senso che la registrazione e la riproduzione avvengono in modo esclusivo, e
l’apertura di uno stream quando un altro è già attivo causa normalmente un errore di tipo
KErrInUse.
Attualmente solo il Nokia 6630 (cioè il dispositivo basato su Symbian OS 8.0a usato
per il progetto di tesi) include una politica di audio full-duplex, ma questa è comunque
ristretta e deve essere inizializzata e impostata in modalità “full-duplex” mediante una richiesta proprietaria. Per ottenere quindi le informazioni per realizzare una conversazione
bidirezionale gli sviluppatori devono rivolgersi direttamente alla Nokia che può decidere
o meno di rilasciare tali informazioni.
Stando alle informazioni trovate sul Forum della Nokia [8], è possibile infatti implementare un’applicazione che permetta il full-duplex solo sul processore omap1710 che è
quello del Nokia 6630, ma, come detto, bisogna chiederne autorizzazione alla Nokia. In
particolare ciò che è necessario è specificare i corretti valori di priorità e preferenze audio
ai flussi di output e input stream mediante la funzione SetPriority. Per quanto riguarda gli altri dispositivi, le API per l’implementazione della suddetta funzionalità sono
private, e sono accessibili solamente sul Forum Nokia PRO. Esso è rivolto alle compagnie
che operano nell’ambito dello sviluppo per terminali mobili e che lavorano su piattaforme
Nokia in quanto permette agli sviluppatori di accelerare la crescita delle rendite e ridurre
137
i costi di investimento fornendo ai suoi membri le più recenti risorse tecniche. Per essere
membri di tale forum è però necessario pagare una quota annuale pari a 4000 e.
Di fatto per quanto riguarda i codici da assegnare al cellulare Nokia 6630 sono stati
reperiti in modo non ufficiale sul Forum Nokia ed hanno permesso di realizzare il fullduplex senza ricorrere a thread paralleli decisamente dannosi per quanto riguarda l’utilizzo della memoria. Mediante queste priorità dei flussi di input e output si può realizzare
un parallelismo di due attività in quanto vengono usati simultaneamente due dispositivi
hardware differenti, il microfono e l’altoparlante. In particolare è necessario distinguere le due modalità di riproduzione di contenuti audio: attraverso i cosiddetti earpiece e
sound speaker. Il primo è l’altoparlante da cui viene percepita la voce in una normale
conversazione telefonica, mentre il sound speaker viene tipicamente usato per riprodurre le suonerie o in generale contenuti audio mediante un player. I valori delle priorità
menzionati hanno la duplice funzione di impostare l’hardware per eseguire il full-duplex
e di instradare i dati ricevuti all’earpiece piuttosto che al soundspeaker, dove verrebbero
invece inviati di default.
Se si considera un generico cellulare Nokia e non nella fattispecie un Nokia 6630, si
può affermare che è possibile realizzare la contemporaneità della riproduzione e registrazione vocale, ma occorre avere la licenza dal produttore del dispositivo e quindi operare
una scelta aziendale mirata all’investimento sullo sviluppo di applicazioni per cellulari.
7.3.2
Qualità dell’audio
La qualità dell’audio percepita è in generale buona all’interno del raggio di copertura del
dispositivo Bluetooth presente sul cellulare. Il principale motivo di degrado della qualità
è la presenza di echi che disturbano la conversazione in uscita dal terminale mobile, cioè
chi parla sente l’eco della propria voce. Questo fatto è causato da una sorta di fenomeno
di risonanza in senso lato poiché la propria voce inviata e riprodotta dall’host remoto
viene nuovamente acquisita, ridotta di potenza, dal microfono sul cellulare destinatario
e rimandata al mittente. Questo processo di retroazione è ciò che causa la presenza di
una singola copia della voce ad una distanza dall’originale pari a due volte il tempo di
138
propagazione sul canale Bluetooth (in andata e ritorno, ma è una tempistica trascurabile
perché dell’ordine di pochi microsecondi) sommato al tempo di permanenza della voce
nel buffer di playout del terminale remoto (ordine del centinaio di millisecondi).
In ambiente indoor la lunghezza effettiva del raggio di azione Bluetooth è più bassa di
quella nominale per i dispositivi di classe 2 (è la classe dei dispositivi presenti sui cellulari
Nokia 6630) e di fatto ad una distanza di 6-7 metri si accusano perdite di pacchetti che
influenzano notevolmente la qualità della conversazione. Questo è chiaramente dovuto
agli ostacoli posti tra i due utenti che causano una perdita di potenza della connessione
Bluetooth e, nel caso di ambienti interni, tali elementi schermanti sono in primo luogo
i muri dell’abitazione. Se si fa un testing dell’applicazione all’aperto si constata che le
distanze raggiunte sono maggiori, anche fino ad una ventina di metri.
Di fatto però BlueVoice vede come applicazione dominante quella della telefonata
VoIP in cui l’utente si trova vicino alla stazione multimediale e quindi in un ambiente
indoor. In questo scenario la ricezione è ottima e la qualità è buona se si rimane nell’ambito della stessa stanza o in quello di camere contigue, per degradare fino alla perdita del
segnale man mano che ci si allontana.
7.3.3
Virtualizzazione della scheda audio
Una volta che il client ha avviato la chiamata, il server deve re-direzionare il traffico
ricevuto da Internet sul canale Bluetooth in modo che esso venga ricevuto e riprodotto
dall’utente e analogamente instradare al punto terminale della telefonata VoIP i pacchetti
vocali acquisiti dall’applicazione client e inviati al server. Per fare queste due operazioni è però necessario by-passare la scheda audio in quanto SimpleOPAL ottiene i contenuti multimediali a basso livello dall’hardware audio del PC e utilizza lo stesso per la
riproduzione.
Di fatto queste operazioni sono del tutto trasparenti se si esamina il codice di SimpleOPAL poiché all’avvio della chiamata viene invocata una funzione di callback denominata
OnOpenMediaStream che notifica dell’avvenuta apertura dei flussi audio senza però
specificarne i dettagli implementativi. La cattura dei pacchetti a monte e a valle della
139
scheda audio sarebbe possibile andando a studiare e modificare opportunamente le API
di basso livello facenti parte della libreria OPAL, ma quest’operazione avrebbe richiesto
parecchio tempo oltre quello disponibile considerate le tempistiche concesse al periodo
di tesi. Accedendo alle aree di memoria contenenti i dati multimediali e operando, rispettivamente per le due direzioni dei flussi, un processo di “impacchettamento” RTP e uno
inverso di estrazione dati dal pacchetto, sarebbe infatti possibile ottenere le informazioni
da consegnare al client BlueVoice.
Un’altra valida alternativa sarebbe quella di definire dei driver per il dispositivo Bluetooth presente sul PC e passare le adeguate opzioni a SimpleOPAL per utilizzare tale
dispositivo fisico invece della scheda audio. In questo modo non verrebbe neppure utilizzata la scheda audio e le informazioni sarebbero direttamente ricevute e inviate mediante
il canale Bluetooth.
Ad ogni modo queste soluzioni possono rappresentare i passi conclusivi dell’applicazione e non un ostacolo alla sua realizzazione.
7.3.4
Priorità delle chiamate
I valori assegnati agli stream di input e output hanno la massima priorità, tuttavia possono
essere interrotti da una chiamata entrante, che rappresenta l’unico evento in grado di arrestare la connessione vocale di BlueVoice, escludendo ovviamente le situazioni di errore.
All’ingresso di una chiamata si presentano i seguenti casi:
1. Se si usa un profilo silenzioso e quindi non è impostata nessuna suoneria allora
la chiamata entrante non va ad intaccare la conversazione BlueVoice. L’utente può
quindi decidere di non rispondere e continuare tranquillamente la telefonata in corso
senza problemi.
2. Se l’utente risponde alla nuova chiamata, indipendentemente dal fatto che la suoneria sia attiva o meno, al termine di essa il terminale dove è stata ricevuta la telefonata
eseguirà normalmente la registrazione e l’invio della voce, ma non sarà più in grado
di riprodurre l’audio ricevuto, risultando perciò in una chiamata half-duplex.
140
3. Se è impostata una qualsiasi suoneria, indipendentemente dalla risposta alla chiamata entrante, si avrà una situazione identica al punto 2, in quanto il dispositivo
audio è stato comunque usato per il tono di chiamata.
Di fatto quando una chiamata arriva durante uno streaming full-duplex i flussi vengono
fermati con un codice d’errore KErrDied e devono essere re-inizializzati.
7.3.5
Limitata portabilità
In accordo ai principi di compatibilità tra le piattaforme Symbian stabiliti da Nokia, tutti
i dispositivi basati su una certa edizione sono compatibili con il software di base di tale
versione. Le edizioni successive possono introdurre nuove funzionalità, ma non possono
in alcun modo interrompere la compatibilità con le caratteristiche principali dell’edizione.
Tipicamente gli aspetti peculiari aggiunti da un particolare Feature Pack alla versione
di base diventano caratteristiche fondamentali della successiva edizione. In pratica solo
alcune piccole modifiche sono permesse, e in ogni caso devono essere documentate e
comunicate.
Interruzioni della compatibilità binaria sono permesse solo con l’introduzione di una
nuova edizione della piattaforma poiché essa può corrispondere a cambi notevoli per
quanto riguarda l’interfaccia grafica e la struttura applicativa. In particolare la migrazione dalla seconda alla terza edizione, che non è retrocompatibile, comporta un buon
numero di modifiche da apportare a livello del codice sorgente, rendendo tale processo
non banale, tuttavia non impossibile.
Per tale motivo si parla appunto di portabilità limitata in quanto il software presenta
compatibilità con i dispositivi della seconda edizione a fronte di modifiche minimali del
codice mentre, per quanto riguarda l’edizione successiva, è necessario un discreto lavoro
di riscrittura di porzioni del progetto per permettere a BlueVoice di essere eseguito su
dispositivi basati sulla terza edizione della Serie 60.
141
Capitolo 8
Conclusioni
Sono passati ormai quasi vent’anni dall’uscita del primo telefono cellulare realmente portatile prodotto dalla Motorola, e ad oggi la telefonia mobile è stabilmente affermata come
uno dei principali mezzi di comunicazione personale utilizzata da centinaia di milioni di
persone in tutto il mondo. Con il tempo la tecnologia è andata evolvendosi e si è assistito ad un miglioramento nella qualità e nel comfort degli apparecchi prodotti quali,
ad esempio, la progressiva diminuzione delle dimensioni dei terminali mobili, ed un crescente sviluppo di servizi dati e voce a cui se ne sono man mano aggiunti altri sempre più
competitivi ed innovativi.
Con l’avvento di Internet e la possibilità di trasferire facilmente i dati e soprattutto la
voce senza costi aggiuntivi, al di là di quelli necessari per la connessione alla rete, si è resa
concreta la capacità di effettuare conversazioni telefoniche applicando tariffe molto basse
o addirittura nulle se il percorso dei dati fosse completamente contenuto all’interno della
rete Internet. Inoltre la possibilità di integrare quest’ultima con il mondo della telefonia in
modo da permettere di effettuare chiamate verso telefoni fissi, ha indubbiamente allargato
gli scenari applicativi ed ha dato origine a numerosi software, tra cui figura in prima linea
Skype che è attualmente uno dei più usati.
In questo contesto si può affermare che l’applicazione realizzata compie un ulteriore
passo nell’integrazione tra la tecnologia VoIP e la telefonia poiché consente all’utente di
usufruire dei servizi voce su Internet interagendo con essi mediante il proprio telefono
142
8 – Conclusioni
cellulare e quindi in maniera più economica delle soluzioni proposte fin’ora in cui l’uso
di VoIP è possibile grazie ad una connessione UMTS ad Internet alla tariffa del proprio
operatore telefonico, ma sicuramente meno versatile in quanto il cellulare ha il vincolo di
rimanere entro il raggio Bluetooth dalla stazione multimediale.
In generale l’attuazione di BlueVoice dimostra che l’idea, negli obiettivi e scopi iniziali, è fattibile nonostante alcune difficoltà riscontrate a lato server, cioè quella parte
dell’applicazione in esecuzione sul PC. Infatti la modalità che vede i due terminali mobili
comportarsi come Walkie-Talkie è stata testata ed è perfettamente funzionante, mentre
non è stato possibile eseguire un’adeguata fase di testing nel caso i due telefoni siano i
terminatori di una chiamata VoIP, poiché l’applicazione server non è in grado di ottenere i dati registrati dall’utente piuttosto che quelli registrati dalla scheda audio del PC. Il
mancato completamento del lavoro è stato causato dal termine della durata del periodo di
tesi, e ciò non ha permesso di concludere alcuni aspetti con la conseguenza che, di fatto,
quel che si è ottenuto è un controllo remoto da cellulare della chiamata VoIP cominciata,
gestita e terminata sul PC, anche se in realtà i pacchetti vocali inviati sul canale Bluetooth
non vengono considerati dal server che, attraverso meccanismi di basso livello, opera la
registrazione audio dal microfono del computer.
Per concludere il progetto è pertanto ancora necessario questo passo che non comporta ulteriori modifiche al client, né tanto meno alla configurazione architetturale della
segnalazione, già presente e funzionante nell’infrastruttura generale ed in grado di gestire
la chiamata end-to-end in remoto dal cellulare. Quest’ultimo aspetto è stato ampiamente
testato in quanto indipendente dalla provenienza del contenuto multimediale inviato come
traffico dati, e ha dato buoni risultati.
Ad ogni modo la cosiddetta modalità Walkie-Talkie può essere vista come un sistema
interfacciabile con altri programmi VoIP di uso comune per poterne favorire un utilizzo
su più larga scala. Gli eventuali sviluppi futuri legati a BlueVoice potrebbero appunto
interessare l’integrazione con Skype che da una parte ne favorirebbe senza dubbio l’uso
vista la popolarità di Skype, e dall’altra apporterebbe un nuovo scenario di utilizzo al
software VoIP.
143
8 – Conclusioni
In quest’ottica è utile ricordare che i produttori di Skype mettono a disposizione degli sviluppatori una SDK e delle API che permettono di scambiare comandi in semplici
messaggi di testo tra Skype e le applicazioni client (ovvero programmi che estendono le
funzionalità di Skype) o i “device” (dispositivi hardware o software quali telefoni USB).
Poiché le API permettono di poter connettere e controllare dispositivi esterni e consentono alle applicazioni di accedere alle funzionalità Skype, l’integrazione con BlueVoice
può essere realizzabile e può portare buoni risultati in un contesto commerciale.
Questa unione dei due software è per altro in sintonia con il ritardo che sta avendo
Skype a distribuire il proprio client per cellulari a causa di difficoltà tecniche e di problemi
legati agli alti costi delle tariffe dati proposte dagli operatori mobili che raramente offrono
piani flat per la connessione Internet. Il servizio Skype è infatti gratuito, ma il traffico
generato per le chiamate voce è notevole e potrebbe portare ad alti costi di connessione se
non si dispone di una tariffa forfettaria. Una soluzione proposta, del tutto simile a quella
presentata in questo testo, è la possibilità per quei cellulari dotati di funzionalità Wi-Fi di
connettersi alle reti Internet senza fili, soluzione che rappresenterebbe la quadratura del
cerchio, ma che andrebbe a scontrasi frontalmente con gli interessi degli operatori mobili
che ovviamente tendono ad osteggiare tale sistema. La ragione di questo sta nel fatto che
la telefonata via Wi-Fi non transiterebbe sulla rete dei tradizionali gestori mobili i quali,
in questo modo, si vedrebbero sottratto gran parte del traffico.
Per concludere si può dire che la portabilità limitata di BlueVoice verso la terza edizione di Symbian è solo apparente in quanto è necessario apportare poche modifiche ai file
di progetto e delle risorse, riscrivere le porzioni di codice che utilizzano le API modificate, e il software può essere eseguito anche su cellulari di ultimissima generazione. In tale
maniera si espande la possibilità di utilizzo di questo prototipo di applicazione che potrebbe potenzialmente rappresentare la base di partenza che permetterebbe un considerevole
miglioramento dell’usabilità della tecnologia VoIP.
144
Bibliografia
[1] Leigh Edwards, Richard Barker, Developing Series 60 Applications: A Guide for
Symbian OS C++ Developers, Addison Wesley, Marzo 2004
[2] Autori Vari, Nokia Developer training - Symbian OS basics, Nokia Official
Courseware
[3] Autori Vari, Programming for the Series 60 Platform and Symbian OS, 1 ed.,
Chichester, John Wiley & Sons Ltd
[4] Richard Harrison, Symbian OS C++ for Mobile Phones, 2 ed., Chichester, John
Wiley & Sons Ltd
[5] Jo Stichbury, Symbian OS Explained - Effective C++ Programming for
Smartphones, 1 ed., Chichester, John Wiley & Sons Ltd
145
Sitografia
[1] CSP, “Sito ufficiale”, Gennaio 2007
http://http://www.csp.it/it
[2] Viola Vincenzo, “ J2ME vs Symbian - Evoluzione e confronto ”, MokaByte, Dicembre 2005
http://www2.mokabyte.it/cms/
[3] Tomà Marco, “ Il mondo java embedded ”, MokaByte, Marzo 2002
http://www.mokabyte.it/2002/03/
[4] Sun, “The Java ME Platform”, Gennaio 2007
http://java.sun.com/javame/
[5] Symbian, “Symbian OS - the mobile operating system”, Gennaio 2007
http://www.symbian.com/developer/
[6] NewLC, “Symbian tutorials”, Gennaio 2007
http://www.newlc.com/-Tutorials[7] Nokia, “Symbian C++ documentation”, Gennaio 2007
http://www.forum.nokia.com/main/resources/technologies/
symbian/documentation/
[8] Nokia, “Symbian Developer Discussion Boards”, Gennaio 2007
http://discussion.forum.nokia.com/forum/
[9] Geoff Lawday, “Implementing Bluetooth in an Embedded Environment”, Techonline, Gennaio 2007
http://techonline.com/article/192200576
146
Sitografia
[10] Sito ufficiale Bluetooth, “Bluetooth Specification Documents”, Gennaio 2007
https://www.bluetooth.org/spec/
[11] Floriano Scioscia, “Service Discovery Protocol (SDP) Bluetooth”, Politecnico di
Bari, Gennaio 2007
http://sisinflab.poliba.it/scioscia/resources/
Bluetooth_Service_Discovery_Protocol.pdf
[12] Palowireless, “RFCOMM protocol”, Gennaio 2007
http://www.palowireless.com/infotooth/tutorial/rfcomm.
asp
[13] Eugene A. Gryazin, “Service Discovery in Bluetooth”, Helsinki University of Technology, Gennaio 2007
http://www.cs.hut.fi/˜gryazin/SD_in_Bluetooth.pdf
[14] BlueZ, “Documentazione BlueZ”, Gennaio 2007
http://www.bluez.org/documentation.html
[15] Università di Firenze, “Introduzione alla Telefonia su IP network (VoIP)”, Gennaio
2007
http://telemat.die.unifi.it/book/1998/VoIP/grp_1.htm
[16] Luca Schiavoni, “VoIP oltre Skype, con SIP”, Punto Informatico, Luglio 2005
http://punto-informatico.it/p.aspx?id=1262697&r=PI
[17] Pietro Saccomani, “Niente Skype sui cellulari? Non mancano le alternative”, Punto
Informatico, Ottobre 2006
http://punto-informatico.it/p.aspx?id=1692913&r=PI
[18] Vox Gratia, “Sito ufficiale”, Ottobre 2006
http://www.voxgratia.org/modules/news/
147

Integrazione di uno smartphone con una stazione - e-Lite

Transcript

Documenti analoghi

• JC900 Caratteristiche Tecniche • Android 4.4+ Systema Operativo

rilevatore onde celebrali portatile con bluetooth fascia

Clicca qui - Audio Reference

L6 MOTOROLA - agenzia di rappresentanza bettancini tiziano

Navigatore 2-Din con LCD da 7”, TV, USB e Bluetooth

SoundMax BT-102

DacomPad RW420 Zebra

USB Bluetooth Adapter Class 2 Supporting EDR

Adattatore Bluetooth - Mh-Int

Il consumatore MOTOROLA W510: il prodotto Punti di forza