Implementazione di Sistema
Nel seguito (fig. 5.1) si ripropone lo schema della pila protocollare per le due entità Mobile Host ed Access Point. Il livello RT_PS, per quanto detto nel ca-pitolo precedente, implementa l’algoritmo di scheduling dei pacchetti RTP dall’Access Point verso il Mobile Host, si occupa di stimare la banda disponibile sul canale di comunicazione, di valutare la durata degli intervalli di Sleep della scheda di rete del Mobile Host, di comandare a basso livello accensione e messa in Sleep della scheda di rete del Mobile Host.
Mobile Host Access Point fig. 5.1: Aspetto della pila protocollare presso Mobile Host ed Access Point.
Media Player RTP / RTSP RT_PS STP IP WMAC RTP / RTSP TFRC RT_PS UDP STP IP WMAC MAC
5.1 Architettura software presso il Mobile Host
Il modulo RT_PS presso il Mobile Host ha il compito di
· interpretare i comandi che arrivano dall’Access Point e rispondervi oppor-tunamente,
· gestire l’istante Start Point che decreta l’inizio della riproduzione aggior-nandolo secondo le indicazioni dell’Access Point e valutando even-tualmente la possibilità di spostarlo oltre l’attesa massima prevista per un utente medio,
· gestire la scheda di rete a basso livello impartendo i comandi di Sleep e di Wakeup,
· interagire con il Media Player.
Nell’esecuzione di queste funzionalità è necessario prevedere un continuo con-trollo temporale per garantire che, ad esempio, allo scattare dello Start Point
RT_PS
fig. 5.2: Moduli del livello RT_PS presso il Mobile Host. Gestore dei ritardi Interprete dei Comandi
Filtro RTSP/RTP Gestore della Scheda di Rete Interfaccia di Canale RTSP RTP STP
ga sollecitato il Media Player ad avviare la riproduzione, o che, terminato l’intervallo di Sleep, venga riattivata la scheda di rete per avviare la procedura di stima del throughput disponibile sulla connessione.
Si suddividono le funzionalità realizzate presso il Mobile Host fra i se-guenti moduli (fig. 5.2):
i. Interfaccia di Canale; ii. Interprete dei Comandi; iii. Gestore della Scheda di Rete; iv. Gestore dei Ritardi;
v. Filtro RTSP/RTP.
5.1.1 Interfaccia di Canale
Il modulo Interfaccia di Canale gestisce le comunicazioni con l’Access Point realizzando l’invio e la ricezione dei pacchetti RT_PS tramite STP. Per ri-cevere un pacchetto RT_PS in arrivo dall’Access Point, poiché non è nota a priori la sua lunghezza, è necessario procedere con due letture dal canale di ricezione: la prima per prelevare lo header del pacchetto (di lunghezza fissa) dal quale leggere le dimensioni di body e di trailer, la seconda per prelevare body e trailer insieme, se presenti. Analogamente, nelle trasmissioni, si procede con due scritture sul ca-nale di trasmissione: una per lo header e l’altra per la parte restante del pacchetto di cui stavolta si conosce però in anticipo la lunghezza. Non è possibile trasmette-re tutto il pacchetto insieme, pena la compromissione delle lettutrasmette-re lato Access Point. Il modulo Interfaccia di Canale non entra nel merito della semantica dei pacchetti RT_PS limitandosi a prelevare quelli in arrivo sul canale di ingresso per fornirli immediatamente al livello soprastante, e ad inviare subito quelli che gli vengono forniti dal livello soprastante attraverso il canale di uscita. L’unico tipo di pacchetto RT_PS che viene riconosciuto e gestito da questo modulo è il pac-chetto RTT_CHECK che serve alla stima della banda disponibile sul canale. Ogni
volta che viene riconosciuto in ingresso un pacchetto RTT_CHECK, viene resti-tuito dal modulo Interfaccia di Canale un pacchetto di ACK nel quale viene repli-cato il timestamp del pacchetto ricevuto (il RTT_CHECK). La procedura di
pro-bing, da intendersi come la sequenza di scambi fra Access Point e Mobile Host
(part. modulo Interfaccia di Canale) finalizzata alla stima del throughput disponi-bile sulla connessione tra i due, può essere sollecitata dall’Access Point in fase di valutazione della possibilità di procedere o meno alla schedulazione (invia diret-tamente un pacchetto RTT_CHECK) oppure dal Mobile Host (modulo Gestore
della Scheda di Rete) alla fine di un intervallo di Sleep (invia pacchetto CHECK).
Al modulo Interfaccia di Canale è circoscritta la dipendenza di RT_PS da STP. E’ possibile sostituire tutto il livello trasporto per testare protocolli alterna-tivi ad STP sostituendo unicamente questo modulo (basta cambiare il corpo delle funzioni che costituiscono il modulo lasciandone immutati i prototipi).
Nel seguito il dettaglio delle funzioni del modulo:
void leggi_pacchetto(struct RT_PS_header *header, void *buffer, int *quanti):
legge dal canale di ingresso l’intestazione di un pacchetto RT_PS e vi inizializza il parametro di ingresso/uscita *header; ne estrae quindi le lunghezze del body e del trailer e, quando diverse da zero, termina il prelievo del pacchetto dal canale ed inserisce in *buffer quanto letto ed in *quanti la dimensione in byte.
void invia(struct RT_PS_header *header, void *trailer, int trailer_len): la
tra-smissione di un pacchetto RT_PS prevede due fasi: la prima in cui si invia l’intestazione (memorizzata in *header), la seconda in cui si invia tutto il resto del pacchetto (memorizzato in *trailer e di lunghezza trailer_len). Questo perché la controparte esegue sempre due letture sul canale: con la prima preleva lo header da cui legge la lunghezza del resto del pacchetto, con la seconda preleva la parte residua del pacchetto qualora presente.
void probing_per_rtt(): riconosce l’arrivo sul canale di comunicazione dei
pac-chetti RTT_CHECK e, per ciascuno di essi, crea un pacchetto ACK di risposta all’interno del quale replica, nel campo timestamp, il valore del timestamp esibito dal pacchetto RTT_CHECK stesso. La procedura di probing termina con la rice-zione di un pacchetto di tipo RTT_STOP.
5.1.2 Interprete dei Comandi
Questo modulo implementa il cuore del protocollo RT_PS: riceve i pac-chetti RT_PS in arrivo dall’Access Point attraverso l’Interfaccia di Canale, ne in-terpreta il tipo e gestisce l’esecuzione dei comandi coinvolgendo all’occorrenza gli altri moduli attraverso le loro interfacce. Questo modulo è implementato da un thread. I pacchetti che arrivano all’Interprete dei Comandi sono:
AUDIO: l’Interprete dei Comandi preleva il pacchetto RTP contenuto nel body e lo consegna al modulo Filtro RTSP/RTP che gestisce il colloquio con il livello RTP, invia infine all’Access Point un pacchetto di ACK in risposta.
AUDIO_SP: come per il pacchetto AUDIO l’Interprete dei Comandi preleva il pacchetto RTP contenuto nel body e lo consegna al Filtro RTSP/RTP, provvede ad aggiornare lo Start Point con il contenuto del trailer e genera infine un pacchet-to ACK di risposta che invia attraverso l’Interfaccia di Canale.
PLAY: l’Access Point sollecita l’inizio della riproduzione perché si sono verifica-te delle condizioni che ne vogliono l’anticipo rispetto all’istanverifica-te Start Point calco-lato in precedenza. L’Interprete dei Comandi aggiorna lo Start Point con il valore dell’istante presente, invoca il Filtro RTSP/RTP perché solleciti il Media Player ad avviare la riproduzione, risponde all’Access Point con un pacchetto di START a confermare che la riproduzione è partita.
RST: si è verificato qualche errore ed è impossibile proseguire con la trasmissio-ne; l’Interprete dei Comandi sollecita il Filtro RTSP/RTP affinché faccia ter-minare il Media Player.
ASK_DILATION: l’Access Point propone un istante per l’inizio della riproduzio-ne; l’Interprete dei Comandi invoca il Gestore dei Ritardi affinché valuti l’opportunità di traslare l’inizio della riproduzione all’istante specificato nel trailer del pacchetto, attende una sua risposta ed infine risponde all’Access Point con un pacchetto di OK_DILATION se la proposta è accettata, di NO_DILATION in ca-so contrario. Nel caca-so in cui il ritardo venga rifiutato (NO_DILATION), l’Interprete dei Comandi invoca il Filtro RTSP/RTP per far terminare il Media Player ed il Gestore della Scheda di Rete affinché spenga la scheda.
SLEEP: l’Access Point comanda la messa in Sleep della scheda di rete; l’Interprete dei Comandi risponde con un pacchetto ASLEEP a conferma della ri-cezione del comando, invoca poi il modulo Gestore della Scheda di Rete ordinan-do la messa in Sleep della scheda per il tempo specificato nel trailer del pacchetto ricevuto.
DELAY: l’Access Point comanda la messa in Sleep della scheda di rete e l’aggiornamento dello Start Point (il Media Player non ha ancora cominciato a ri-produrre); l’Interprete dei Comandi risponde con un pacchetto ACK_DELAY a conferma della ricezione del comando, invoca poi il modulo Gestore della Scheda
di Rete fornendogli il comando assieme alla durata dell’intervallo di Sleep;
ag-giorna infine lo Start Point spostandolo più in là possibile.
WAKEUP: è terminata la fase di probing del throughput disponibile sulla connes-sione con l’Access Point e l’Access Point ha deciso di riprendere a trasmettere:
l’Interprete dei Comandi risponde inviando un pacchetto di AWAKE a conferma della ricezione.
END: la trasmissione del file è terminata. L’Interprete dei Comandi risponde con un pacchetto di QUIT ed invoca il Gestore della Scheda di Rete affinché la spenga ed il Filtro RTSP/RTP affinché faccia terminare il Media Player.
REQ: questo pacchetto arriva all’Interprete dei Comandi attraverso il Filtro
RTSP/RTP (si veda dopo) in seguito alla generazione di una RTSP SETUP request
da parte del Media Player; l’Interprete dei Comandi provvede ad inoltrarlo attra-verso l’Interfaccia di Canale all’Access Point.
CHECK: arriva all’Interprete dei Comandi dal Gestore della Scheda di Rete che vuole avviare la procedura di probing per il throughput. L’Interprete dei Comandi si limita ad inoltrarlo attraverso l’Interfaccia di Canale.
5.1.3 Gestore della Scheda di Rete
E’ il modulo che si occupa di impartire a basso livello i comandi di messa in Sleep e di riattivazione della scheda di rete. La sua interfaccia mette a disposi-zione degli altri moduli (Interprete dei Comandi) le funzioni
void to_On(): per riaccendere la scheda;
void to_Sleep(): per mettere in Sleep la scheda; void to_Off(): per spegnere la scheda.
5.1.4 Gestore dei ritardi
Implementa la politica in base alla quale il Mobile Host decide se accettare o meno il ritardo iniziale di riproduzione proposto dall’Access Point. Il modulo viene richiamato dall’Interprete dei Comandi cui mette a disposizione l’interfaccia:
int ok_dilazione(struct timeval requested_start_point): riceve in ingresso l’istante
assoluto di inizio riproduzione proposto dall’Access Point e restituisce 1 nel caso in cui il ritardo sia accettato, 0 altrimenti. La politica scelta per l’implementazione è molto semplice: viene concesso un ritardo a patto che non superi il doppio dell’attesa massima di riferimento pari a 3s.
E’ possibile scegliere di implementare politiche più sofisticate (che ad e-sempio prevedano una richiesta esplicita all’utente al terminale) modificando semplicemente questo modulo.
5.1.5 Filtro RTSP/RTP
Il Filtro RTSP/RTP deve interfacciarsi con i livelli RTSP ed RTP della pila protocollare ed implementare un protocollo che consenta l’inserimento trasparente del sistema di Power Saving negli scambi tra Media Player e Streaming Server. Questo modulo dunque è l’anello di congiunzione tra i protocolli classici per gli scambi audio/video e quello RT_PS.
La comunicazione fra Media Player e Streaming Server prevede che la tra-smissione di un file di contenuto audio/video avvenga nell’ambito di una sessione
RTSP tra Media Player e Streaming Server. Questa sessione viene instaurata fra
due entità: un Client RTSP che comunica con il Media Player ed un Server RTSP che comunica con lo Streaming Server.
Il comportamento classico del Client RTSP è quello della macchina a stati di cui segue la descrizione nella tabella 5.1 tratta da [28].
Stato messaggio spedito stato successivo alla ricezione della risposta Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
RECORD Recording
TEARDOWN Init
SETUP Ready Playing PAUSE Ready
TEARDOWN Init
PLAY Playing
SETUP Playing (changed transport) Recording PAUSE Ready
TEARDOWN Init
RECORD Recording
SETUP Recording(changed transport) Tabella 5.1: Descrizione del comportamento del Client RTSP
Gli stati che possono essere assunti dal Client RTSP sono:
· Init: il Client ha spedito la richiesta di SETUP ed attende la risposta; · Ready: il Client ha ricevuto la risposta alla richiesta di SETUP o alla
ri-chiesta di PAUSE inviata in stato Playing;
· Playing: il Client ha ricevuto la risposta alla richiesta di PLAY; · Recording: il Client ha ricevuto la risposta alla richiesta di RECORD. L’apertura della connessione con il Server RTSP (anch’esso ha il comportamento di una macchina a stati) è conseguente all’invio del messaggio di SETUP. Il Client può inviare dei comandi in remoto solo quando la connessione è stabilita e quindi dopo la ricezione della risposta al messaggio di SETUP. Dopo l’invio del comando di PLAY il Client attende la risposta, quindi passa in uno stato Playing in cui la riproduzione è in atto. Per terminare la sessione il Client invia un mes-saggio di TEARDOWN ed attende la risposta del Server RTSP per assumere nuo-vamente lo stato iniziale (Init).
I cambiamenti di stato avvengono sempre in seguito alla ricezione della risposta ad una richiesta inviata (sollecitata dal Media Player); può tuttavia accadere che il
Client RTSP cambi stato da Playing o Recording a Ready quando termini la ri-produzione o la registrazione del frammento di brano oggetto della richiesta.
Il comportamento del Server RTSP è ovviamente duale a quello del Client e descritto nella tabella 5.2 tratta anch’essa da [28]:
stato messaggio ricevuto stato successivo allo invio della risposta Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
RECORD Recording TEARDOWN Init
SETUP Ready Playing PAUSE Ready
TEARDOWN Init
PLAY Playing SETUP Playing Recording PAUSE Ready
TEARDOWN Init
RECORD Recording SETUP Recording
Tabella 5.2: Descrizione del comportamento del Server RTSP
Il Server RTSP può assumere gli stati:
· Init: è lo stato iniziale in cui non è ancora stata ricevuta alcuna richiesta di SETUP;
· Ready: assunto dopo la ricezione, nello stato Init, di una richiesta di SE-TUP e l’invio della risposta conseguente, oppure in seguito alla ricezione, nello stato Playing, di un comando di PAUSE ed il successivo invio della risposta;
· Playing: il Server ha ricevuto un comando di PLAY, ha inviato la risposta ed ha cominciato a spedire i pacchetti RTP;
· Recording: il Server sta registrando i dati.
In generale il Server RTSP cambia stato dopo l’invio di una risposta alla richiesta ricevuta.
Il Filtro RTSP/RTP deve intercettare la richiesta di SETUP del Client RTSP e gestirla lanciando l’Interprete dei Comandi affinché attivi i canali di co-municazione con l’Access Point. Terminata l’attivazione l’Interprete dei Comandi avvisa il Filtro RTSP/RTP il quale genera una risposta di SETUP per il modulo Client RTSP.
Successivamente, ogni comando impartito dal Media Player attraverso il modulo Client RTSP viene trasformato dal Filtro RTSP/RTP in una richiesta RT_PS e passata all’Interprete dei Comandi che provvede ad inoltrarla attraverso l’Interfaccia di Canale. L’Interprete dei Comandi gestisce il colloquio con l’Access Point ed al termine avvisa il Filtro RTSP/RTP che genera la risposta RTSP per il modulo Client RTSP.
Dunque il Filtro RTSP/RTP ha il compito di ricevere delle richieste RTSP dal Client RTSP e produrre delle richieste RT_PS per l’Interprete dei Comandi; le ri-chieste vengono gestite attraverso una sessione RT_PS appositamente attivata con l’Access Point che finalmente produce delle risposte RT_PS; il Filtro RTSP/RTP infine, riceve le risposte RT_PS dall’Interprete dei Comandi e genera le risposte RTSP per il Client RTSP simulando il comportamento di un Server RTSP.
Nel prototipo implementato si prevede un caso semplice di interazione tra Media Player e Client RTSP in cui il Media Player si limita a fare richiesta di SE-TUP di una sessione RTSP e successivamente di PLAY per un brano MP3. Il
Fil-tro RTSP/RTP trasforma il comando RTSP SETUP in una richiesta RT_PS di tipo
REQ che affida all’Interprete dei Comandi. Quando il Client RTSP genera la ri-chiesta di PLAY non viene generata alcuna riri-chiesta RT_PS perché la riri-chiesta REQ ha in realtà già avviato le azioni necessarie ad implementare il PLAY. Si as-sume implicitamente che il PLAY venga richiesto per l’intero brano. Il Filtro at-tende quindi di ricevere il pacchetto RT_PS PLAY dall’Interprete dei Comandi per poter generare la risposta RTSP PLAY e permettere l’avvio della riproduzione al Media Player. L’Interprete dei Comandi può ricevere il comando PLAY diret-tamente dall’Access Point oppure può generarlo esso stesso allo scattare dello
Start Point concordato con l’Access Point. Nelle tabelle 5.3-4 vengono riportate le conversioni di pacchetti operate dal Filtro RTSP/RTP.
pacchetto RTSP ricevuto dal Client RTSP
pacchetto RT_PS prodotto per l’Interprete dei Comandi
SETUP REQ PLAY - Tabella 5.3: Conversioni dei pacchetti RTSP in pacchetti RT_PS
pacchetto RT_PS ricevuto
dall’Interprete dei Comandi pacchetto RTSP prodotto per il Client RTSP
RST TEARDOWN END TEARDOWN PLAY PLAY Tabella 5.4: Conversioni dei pacchetti RT_PS in pacchetti RTSP
La parte RTP del Filtro RTSP/RTP riceve dall’Interprete dei Comandi i pacchetti RTP estratti dai pacchetti AUDIO ed AUDIO_SP e li accoda nel buffer da dove vengono prelevati dal Media Player dopo che il Client RTSP ha ricevuto il messaggio RTSP PLAY response.
Il modulo RTP, implementato solitamente all’interno del Media Player, provvede a riordinare i pacchetti, a mascherare eventuali errori e/o perdite, ad e-strarre i frame ADU; ripristina poi il meccanismo di bit reservoir all’interno del bitstream MP3 e ricava i frame MP3 standard che vengono prelevati direttamente dal decoder del Media Player (si vedano i Capitoli 3-4).
5.2 Architettura software presso l’Access Point
Il livello RT_PS dell’Access Point deve assolvere i seguenti compiti: · intercettare le richieste che vengono dal Mobile Host;
· individuare il file MP3 richiesto dal Mobile Host nel proprio file system e rielaborarlo per ottenere una sequenza di frame ADU adatti alla trasmis-sione (livello RTP embedded);
· calcolare la curva di playout;
· calcolare la curva di inviluppo ed il rate minimo in funzione della curva di playout e della dimensione del buffer disponibile presso il Mobile Host; · trasmettere i frame della sequenza;
· calcolare l’istante di inizio della riproduzione;
· monitorare il canale di comunicazione e calcolare il throughput al variare del tempo;
· decidere gli istanti in cui mandare in Sleep la scheda di rete del Mobile Host;
· seguire l’avanzamento dello schedule ed il livello di riempimento del buffer presso il Mobile Host.
RT_PS
fig. 5.3: Moduli del livello RT_PS presso l’Access Point. Gestore dei ritardi Interprete dei Comandi
Gestore dello Schedule
Trasmettitore
Interfaccia di Canale
Gestore dei file MP3
STP
RTP RTSP
E’ possibile suddividere le funzionalità dell’Access Point nei seguenti moduli (fig 5.2):
i. Interfaccia di Canale; ii. Gestore dello Schedule; iii. Gestore dei file MP3; iv. Interprete dei Comandi;
v. Gestore dei Ritardi; vi. Trasmettitore.
5.2.1 Interfaccia di Canale
Ha il compito di gestire i servizi di trasmissione e di ricezione in funzione del livello di trasporto presente e rende al livello RT_PS la possibilità di leggere dal canale di comunicazione e di inviare attraverso di esso i pacchetti RT_PS. Il livello di trasporto è gestito secondo le regole del protocollo STP. Invii e ricezioni dei pacchetti RT_PS avvengono, analogamente a quanto visto nel Mobile Host in due fasi: la prima coinvolge l’intestazione RT_PS del pacchetto, la seconda la par-te restanpar-te (eventuale). L’Inpar-terfaccia di Canale gestisce pure il servizio di monito-raggio della connessione con il Mobile Host e di stima del throughput disponibile su di essa. La procedura di probing per la stima del throughput prevede all’inizio una raccolta di dati in cui l’Interfaccia di Canale invia una serie di pacchetti di
probe (tipo RTT_CHECK) ed attende di ricevere in risposta dei pacchetti di tipo
ACK. La ricezione di un ACK consente di calcolare il RTT sperimentato dal pac-chetto di probe. I campioni di RTT così ottenuti vengono raccolti in una lista che associa ad ognuno di essi il numero di volte che è stato sperimentato durante le trasmissioni. Gli elementi raccolti vengono ordinati sia per valore crescente del RTT, sia per valore crescente del numero di occorrenze. Alla fine degli inserimen-ti la lista viene filtrata eliminando i campioni di RTT sperimentainserimen-ti meno volte (1% o meno del numero complessivo di trasmissioni eseguite) poiché sono da
conside-rarsi dei picchi ininfluenti. Dopo il filtraggio si esegue la media dei campioni ponderata sul numero di occorrenze e si ottiene il RTT medio, quindi si calcola il throughput facendo il rapporto fra la dimensione in bit del pacchetto di probe ed il RTT medio espresso in secondi. Le funzioni messe a disposizione dall’Interfaccia
di Canale sono:
void leggi_pacchetto(struct RT_PS_header *header, void *buffer, int *quanti):
legge dal canale di ingresso l’intestazione di un pacchetto RT_PS, ne estrae le lunghezze di body e trailer e, se diverse da zero, procede con la lettura dal canale della parte terminale del pacchetto. Le informazioni lette dal canale vengono re-stituite nei parametri di ingresso/uscita: l’intestazione in *header, body e trailer in
*buffer, la lunghezza complessiva del payload in *quanti.
unsigned int invia(int cur, struct RT_PS_header *header, void *trailer): riceve in
ingresso un pacchetto RT_PS suddiviso in intestazione (*header), trailer (*trailer) e body (frame di indice cur) e lo spedisce attraverso il canale di scrittura. Prima trasmette lo header, poi body e trailer insieme. Quando il pacchetto da spedire non ha contenuto audio il valore di cur è –1. Il valore di ritorno della funzione è la lunghezza del frame ADU spedito.
void probing_per_rtt(struct timeval *rtt, double *R): implementa la procedura di probing per valutare il throughput disponibile sul canale. Invia una successione di
pacchetti RTT_CHECK ed attende di ricevere per ciascuno un ACK in risposta. Chiude gli invii con un pacchetto RTT_STOP quindi stima il RTT medio fra tutti quelli sperimentati ed il throughput e li restituisce nei parametri di ingresso/uscita *rtt ed *R rispettivamente.
L’Interfaccia di Canale è l’unico modulo che richiama le primitive STP: qualora si voglia impiantare il sistema di Power Saving su di un livello di
tra-sporto diverso da STP, è sufficiente modificare l’implementazione delle funzioni di interfaccia di questo modulo.
5.2.2 Gestore dello Schedule
Questo modulo agisce sulla curva di playout associata al file MP3 da tra-smettere ed esegue una serie di operazioni che servono a supportare il progredire dello schedule. Data la curva di playout del file richiesto dal Mobile Host e data la dimensione del buffer disponibile presso di esso, calcola il rate minimo necessario a consentire uno schedule On-Off; dato un rate di trasmissione costruisce l’inviluppo alla curva di playout e calcola l’istante di inizio della riproduzione; avviata la trasmissione del file è in grado di seguire l’avanzamento dello schedule per calcolare il livello di riempimento del buffer del Mobile Host e riconoscere i casi di buffer pieno e di raggiungimento del livello di acqua bassa; è infine in gra-do di scegliere se trasmettere o meno un frame basangra-dosi sul throughput di-sponibile sul canale di comunicazione, sulla lunghezza del frame stesso e sul suo istante di playback. Le funzioni dell’interfaccia del modulo Gestore dello
Sche-dule sono:
int frame_da_trasmettere(int cur, int *next_frame_len, struct timeval start_point, double R, int in_riproduzione): riceve in ingresso l’istante di inizio della
riprodu-zione (start_point), il throughput disponibile sulla connessione (R) ed un valore booleano che indica se la riproduzione è già cominciata o meno (in_riproduzione); esamina il frame di indice cur, assegna al parametro di in-gresso/uscita *next_frame_len la sua dimensione e controlla se è trasmissibile (il suo playback time deve essere successivo all’istante previsto per l’arrivo presso il Mobile Host). Restituisce 1 in caso affermativo, 0 altrimenti.
unsigned int calcola_liberi(unsigned int spediti, unsigned int scartati, int in_riproduzione, struct timeval start_point): calcola il numero di byte liberi nel
buffer del Mobile Host e lo restituisce come valore di ritorno. I parametri di in-gresso indicano: il numero di byte complessivamente già spediti (spediti), il nu-mero di byte scartati perché appartenenti a frame non trasmessi (scartati), se la ri-produzione è già cominciata (in_riri-produzione), l’istante di inizio della riprodu-zione (start_point).
int buffer_pieno(int *cur, unsigned int *spediti, unsigned int *scartati, struct ti-meval start_point, int in_riproduzione, double R): riceve in ingresso l’istante di
inizio della riproduzione (start_point), il throughput disponibile sulla connessione (R) ed un valore booleano che indica se la riproduzione è già cominciata (in_riproduzione). Sceglie il frame da trasmettere (il primo che riesce ad arrivare dall’altra parte prima del suo playback time) e ne restituisce l’indice nel parametro di ingresso/uscita *cur (se nella scelta sono stati scartati dei frame la loro dimen-sione complessiva va ad incrementare il parametro di ingresso/uscita *scartati); calcola lo spazio ancora disponibile nel buffer del Mobile Host (pari alla quantità di dati già inviati, *spediti, meno la quantità di dati già riprodotti) e valuta se il frame individuato ha dimensione inferiore allo spazio disponibile nel buffer di ar-rivo del Mobile Host: restituisce 0 in caso affermativo, 1 altrimenti.
struct timeval intersezione_curva_di_playout(int scartati, int spediti, struct time-val start_point, double R): usata nei periodi di Sleep, risolve il problema illustrato
nel Cap. 4, fig. 4.7, della determinazione dell’intersezione fra la curva di invi-luppo ed il prolungamento dello schedule in atto definendo l’istante ultimo utile per ricominciare le trasmissioni (valore di ritorno). I parametri di ingresso indi-cano rispettivamente il numero di byte già scartati nella schedulazione (apparte-nenti a frame non trasmessi), il numero di byte già spediti complessivamente, ed ancora l’istante di inizio della riproduzione ed il rate attuale di trasmissione. La curva di inviluppo viene calcolata a rate R/2.
int acqua_bassa(int scartati, int spediti, struct timeval start_point, double R, struct timeval *pun_delta_to_check): controlla il livello del buffer del Mobile
Host e restituisce 1 se prossimo o inferiore al livello di acqua bassa LW, 0 altri-menti. Per quel che riguarda i parametri di ingresso: scartati indica il numero di byte già scartati nella schedulazione (appartenenti a frame non trasmessi), spediti il numero di byte complessivamente già spediti, start_point l’istante di inizio della riproduzione, R il rate attuale di trasmissione, *pun_delta_to_check l’intervallo temporale fino al prossimo risveglio del Mobile Host.
struct timeval calcola_start_point(double rate): riceve in ingresso il throughput
disponibile sulla connessione con il Mobile Host e restituisce in uscita la distanza temporale che intercorre fra l’inizio della trasmissione (ancora a venire) e l’inizio della riproduzione (Start Point). La procedura di calcolo costruisce la curva di in-viluppo alla curva di playout e divide infine il valore che assume nell’istante di i-nizio della riproduzione lato Mobile Host per il rate di trasmissione.
double rate_minimo(): calcola il rate minimo di trasmissione che rende possibile
uno scheduling On-Off per il file da trasferire e lo restituisce come valore di ri-torno. Segue l’algoritmo 3.3 descritto in [10] .
5.2.3 Gestore dei file MP3
Ha il compito di individuare il file MP3 richiesto dal Mobile Host ed adat-tarlo alla trasmissione attraverso Internet: traduce la sequenza di frame MP3 in una sequenza di frame ADU, produce la curva di playout che consiste nella suc-cessione delle dimensioni dei frame ADU, genera i pacchetti RTP. Nel seguito vengono dettagliate alcune scelte compiute per l’utilizzo del protocollo RTP ed implementate dal modulo Gestore dei file MP3 nel prototipo realizzato.
Ciascun pacchetto RTP viene spedito singolarmente all’interno di un pac-chetto di livello sottostante (RT_PS): è una soluzione tipica in base a quanto riportato nelle specifiche base di RTP [11] e nel profilo RTP per dati audio-video generici [12] e per MPEG Audio in particolare [13]. La lunghezza del pacchetto RTP non è presente nello header RTP ma si calcola indirettamente a partire dalla lunghezza del segmento di livello trasporto (presente questa nello header del seg-mento). La lunghezza massima di un pacchetto RTP è condizionata pertanto uni-camente dal valore di MTU che caratterizza il livello sottostante.
All’interno di un singolo pacchetto RTP viene inserita un’unica coppia de-scrittore ADU – frame ADU. In questo modo vengono soddisfatte:
· Le specifiche che descrivono il formato del payload di un pacchetto RTP in maniera da garantire la tolleranza alle perdite in rete [15]. Esse prescri-vono infatti che un pacchetto RTP contenga un numero intero di frame ADU e che una unità ADU possa trovarsi a cavallo di più pacchetti RTP solo quando più lunga della MTU del livello sottostante (nel descrittore ADU il meccanismo di frammentazione).
· Il profilo RTP per dati audio-video generici [12] per cui tutti i campioni che esibiscono lo stesso timestamp devono stare nello stesso pacchetto RTP: un frame ADU infatti, racchiude la codifica completa di 1152 cam-pioni audio comprensiva di entrambi i canali destro e sinistro (per modali-tà stereo): essi producono campioni contemporanei che hanno lo stesso ti-mestamp.
· Le “Linee guida per gli scrittori delle specifiche del formato del payload di un pacchetto RTP” [14] che suggeriscono che pacchetti RTP successivi e-sibiscano timestamp che crescono man mano di un valore costante (nume-ro costante di frame in ogni pacchetto) onde ottimizzare la compressione dello header del pacchetto RTP.
Non viene infine eseguito interleaving cosicché frame consecutivi vengono incap-sulati in pacchetti RTP consecutivi e spediti nello stesso ordine.
5.2.4 Interprete dei Comandi
Ha il compito di interpretare il contenuto dei pacchetti RT_PS che arrivano attraverso l’Interfaccia di Canale, di aggiornare lo stato dello schedule, di avviare al momento giusto la trasmissione dei pacchetti audio.
Lo stato dello schedule gestito dall’Interprete dei Comandi è la descrizione dell’avanzamento dello schedule in un dato istante e da esso è possibile dedurre se la trasmissione dei pacchetti audio è già cominciata ed ancora se, presso il Mobile Host, la riproduzione del brano è partita e se la scheda di rete è On oppure in Sle-ep. Gli stati previsti sono:
ST_INIZIALIZZAZIONE: è lo stato iniziale in cui si trova lo schedule subito do-po l’arrivo della richiesta di riproduzione da parte del Mobile Host e dura tutto il tempo della valutazione della possibilità di procedere allo scheduling tramite il si-stema di Power Saving. L’Interprete dei Comandi guida la fase di valutazione comandando al Gestore dei file MP3 di rintracciare il brano, adattarlo per la tra-smissione e calcolarne la curva di playout, al Gestore dello Schedule di calcolare il rate minimo per lo scheduling On-Off, all’Interfaccia di Canale di avviare la fa-se di probing per la stima del throughput iniziale, al Gestore dei Ritardi di con-trattare eventuali ritardi nella riproduzione con il Mobile Host; riserva infine per se la valutazione finale. Nel caso in cui la schedulazione sia possibile, infine, l’Interprete dei Comandi sollecita il Trasmettitore all’invio dei pacchetti audio.
ST_AVVIO_TRASMISSIONE: in questo stato si prevede che la fase di valuta-zione sia terminata concludendo la fattibilità della schedulavaluta-zione On-Off e che la trasmissione dei pacchetti audio (AUDIO_SP) sia partita mentre la riproduzione del brano ancora no. L’Interprete dei Comandi si occupa di ricevere i pacchetti di ACK che arrivano dal Mobile Host, calcolare i RTT sperimentati dai pacchetti audio sul canale di comunicazione ed aggiornare i valori del throughput corrente e
di quello medio; ricalcola inoltre ogni volta ed aggiorna l’istante di inizio della ri-produzione da comunicare al Mobile Host.
ST_DELAY: in questo stato dello schedule la riproduzione non è ancora comin-ciata, il Mobile Host (dietro comando dell’Access Point) ha messo in Sleep la sua scheda di rete per attendere un innalzamento della banda sul canale e le trasmis-sioni da parte dell’Access Point sono interrotte. L’Interprete dei Comandi attende di ricevere un pacchetto di CHECK dal Mobile Host dopo la riattivazione della scheda di rete per avviare la fase di probing, stimare il throughput ed eventual-mente stimolare la ripresa della trasmissione.
ST_ON: presso il Mobile Host la riproduzione del brano è cominciata e la scheda di rete è in stato On. Le trasmissioni dei pacchetti AUDIO dall’Access Point sono in corso e l’Interprete dei Comandi gestisce la ricezione dei pacchetti di ACK e l’aggiornamento del rate corrente e di quello medio.
ST_SLEEP: analogo allo stato ST_DELAY salvo che per il fatto che la riprodu-zione del brano è già cominciata. La scheda di rete del Mobile Host è infatti in Sleep e le trasmissioni dall’Access Point sono interrotte. L’Interprete dei
Co-mandi attende di ricevere un pacchetto di CHECK dal Mobile Host per avviare la
procedura di probing per il throughput e per riavviare le trasmissioni.
ST_FINE: La trasmissione è terminata e l’Interprete dei Comandi si predispone a gestire una nuova schedulazione.
Qualche nota sul calcolo del rate disponibile sulla connessione ed eseguito dall’Interprete dei Comandi negli stati ST_AVVIO_TRASMISSIONE ed ST_ON: siano R(n-1) ed RAVG(n-1) le ultime stime calcolate rispettivamente per il
rate di trasmissione relativo alla sessione corrente ed il rate di trasmissione medio relativo all’insieme delle connessioni passate; R(n) ed RAVG(n) siano le medesime
stime da aggiornare nell’istante corrente, r(n) sia invece il rate di trasmissione sperimentato dall’ultimo pacchetto spedito (dimensione del pacchetto / RTT spe-rimentato); si calcola:
n R
n
r n R ==× -1 + 1-= ×
n R
n
r n RAVG ==1× AVG -1 + 1-=1 ×
con 10< ==, 1 £ . Al fine di dare maggior peso alle stime pregresse piuttosto che a quelle attuali sono stati scelti dei valori piuttosto alti per a ed a1:
8 , 0 ; 9 , 0 1 = = =
= . Diversificando le due costanti a ed a1 si è scelto di diversificare
le dimensioni delle finestre temporali sotto osservazione per la stima di R ed RAVG
rispettivamente. La finestra più ampia è stata riservata alla valutazione di RAVG.
Nella tabella 5.5 sono descritte le transizioni degli stati in funzione dei pacchetti ricevuti dal Mobile Host. Alcune delle transizioni riportate sono scate-nate da eventi temporali quali lo scattare dello Start Point oppure il termine dell’intervallo di Sleep. Si tratta di eventi che non sono accompagnati dall’arrivo di pacchetti dal Mobile Host, quindi l’Interprete dei Comandi ha il compito di controllare il loro verificarsi.
Stato messaggio ricevuto Stato successivo
ST_INIZIALIZZAZIONE REQ ST_AVVIO_TRASMISSIONE
OK_DILATION ST_AVVIO_TRASMISSIONE
NO_DILATION ST_FINE
ST_AVVIO_TRASMISSIONE START ST_ON
ACK_DELAY ST_DELAY
ACK ST_AVVIO_TRASMISSIONE
…allo Start Point ST_ON
ST_ON ACK ST_ON
ASLEEP ST_SLEEP
QUIT ST_FINE
…fine riproduzione ST_FINE
ST_SLEEP CHECK ST_SLEEP
AWAKE ST_ON
…fine sleep ST_ON
ST_DELAY CHECK ST_DELAY
ACK_DELAY ST_DELAY
START ST_ON
…fine sleep ST_ON o
ST_AVVIO_TRASMISSIONE AWAKE ST_ON o
ST_AVVIO_TRASMISSIONE Tabella 5.5: transizioni dello stato dello schedule
L’Interprete dei Comandi è implementato da un thread che esegue perma-nentemente presso l’Access Point.
5.2.5 Gestore dei ritardi
Gestisce la situazione in cui dal calcolo del ritardo iniziale di riproduzione risulta un’attesa per il Mobile Host superiore a quella massima stabilita di default (3s); si occupa pertanto di inviare al Mobile Host una richiesta ASK_DILATION per dilatare i termini di attesa per l’inizio della riproduzione e di attendere una ri-sposta che può essere positiva (pacchetto OK_DILATION) se il Mobile Host ac-cetta, negativa (NO_DILATION) in caso contrario.
5.2.6 Trasmettitore
Il modulo Trasmettitore ha il compito di creare i pacchetti RT_PS e di tra-smetterli attraverso l’Interfaccia di Canale. I pacchetti in uscita possono essere pacchetti AUDIO_SP, AUDIO, DELAY, SLEEP, WAKEUP, PLAY, END. I pacchetti AUDIO ed AUDIO_SP vengono trasmessi se:
i. il rate disponibile sul canale di comunicazione è alto ed il buffer non è pieno (il frame successivo da trasmettere entra tutto nel buffer del Mobile Host);
ii. il rate disponibile è basso ed il livello del buffer è prossimo alla soglia di
acqua bassa.
Quando le condizioni per trasmettere non sono verificate il Trasmettitore invia un pacchetto di DELAY o di SLEEP sollecitando il Mobile Host a mettere in Sleep la scheda di rete per un certo periodo (la cui durata, opportunamente calcolata, è in-serita nel pacchetto stesso). Il pacchetto END viene inviato quando tutti i frame del file sono stati trasmessi. Il pacchetto PLAY viene inviato per sollecitare il
Mobile Host ad avviare la riproduzione prima dell’istante fissato per lo Start Point perché il buffer è pieno. Il modulo Trasmettitore fa uso dell’interfaccia offerta dal modulo Gestore dello Schedule per valutare le pre-condizioni di trasmissione. Il comportamento del Trasmettitore può essere schematizzato nella forma di una macchina a stati le cui transizioni sono influenzate dallo stato dello schedule (si veda sopra) e dal risultato della valutazione delle pre-condizioni (tabella 5.6).
stato buffer pieno acqua bassa rate basso pacchetto inviato ST_AVVIO_TRASMISSIONE True - - PLAY
True False - SLEEP
False False True DELAY
- True - AUDIO_SP
False False False AUDIO_SP
ST_DELAY True - - PLAY
True False - SLEEP
False False True DELAY
- True - WAKEUP+AUDIO o
WAKEUP+AUDIO_SP
False False False WAKEUP+AUDIO o
WAKEUP+AUDIO_SP
ST_ON - False True SLEEP
True False False SLEEP
- True - AUDIO
False False False AUDIO
ST_SLEEP - False True SLEEP
True False False SLEEP
- True - WAKEUP+AUDIO
False False False WAKEUP+AUDIO
