• Non ci sono risultati.

L'idea di assegnare ad holding time un valore molto elevato permetterebbe di ottenere al crescere del valore del jitter delle migliori prestazioni in termini di speech quality. Infatti iniziare a leggere i dati che sono ricevuti e memorizzati solo dopo un intervallo di tempo elevato permette di avere un maggior margine su quanto possano arrivare in ritardo i pacchetti e nonostante questo non essere scartati. Ovviamente una minore percentuale di pacchetti scartati porterà ad ottenere delle migliori performance in termini di qualità del segnale audio che l'utente potrà percepire. Il problema a cui si va incontro con questo tipo di soluzione è legato al fatto che non si sta tenendo conto dell'aumento del one way delay che viene introdotto dall'usare un valore alto dell'holding time. Questo potrebbe portare a una degradazione della conversational quality perché il one way delay potrebbe superare quei valori accettabili per l'applicazione (descritti in precedenza nel paragrafo 1.2.2.4.1) con la conseguente perdita della naturalezza della conversazione.

La soluzione utilizzata per costruire il buffer di dejitter dinamico è un compromesso tra la tendenza ad assegnare un valore alto all'holding time per risolvere i problemi legati alla presenza di jitter e l'esigenza di mantenerlo basso per non andare a degradare la conversational quality.

4 Buffer di dejitter statico e buffer di dejitter adattivo

Figura 4.2: Calcolo del tempo d'interazione

Supponendo che entrambi i partecipanti alla conversazione sfruttino la gestione del buffer di dejitter proposta in questa tesi possiamo calcolare il tempo di interazione, inteso come il tempo dopo il quale l'utente 1 può ottenere una risposta a un suo input da parte dell'utente 2 (situazione mostrata in figura 4.2), con la seguente formula :

Qt  = T1−2tT2−1tTh1t Th2tPLCdelay 1PLCdelay 2

dove con T1−2t è stato indicato il tempo che i dati impiegano all'istante t a passare dall'user

space dell'utente 1 al buffer di dejitter nell'user space dell'utente 2. Questo tempo è perciò comprensivo del tempo che i dati passano nel buffer in trasmissione presente a kernel space dell'utente 1, del tempo di attraversamento della rete e dell'ulteriore ritardo introdotto dal buffer in ricezione a kernel space dell'utente 2. Non sono stati presi in considerazione i tempi di context switch perché ovviamente sconosciuti e dipendenti dalla velocità della macchina usata; l'incertezza sulla misura che ne deriva è di soli pochi millisecondi e può essere trascurata. Con T2−1t è stato

4 Buffer di dejitter statico e buffer di dejitter adattivo

indicato il tempo che i dati impiegano per fare il percorso inverso (quindi dall'utente 2 all'utente 1) e con Th1t e Th2t il valore dell'holding time che caratterizza rispettivamente i buffer di dejitter

dell'utente 1 e dell'utente 2 all'istante t. Il tempo di interazione può essere visto come una sorta di indicatore della conversational quality misurata all'istante t ed è stato indicato con Qt  . Con

PLCdelay 1 e PLCdelay 2 sono indicati infine i ritardi introdotti rispettivamente dall'algoritmo di PLC sfruttato dall'utente 1 e dall'utente 2.

L'idea è quindi dimensionare il buffer di dejitter (cioè l'holding time) in modo proporzionale al jitter che subiscono i pacchetti ma in modo tale che Qt  rimanga al di sotto della soglia oltre la quale è considerato inaccettabile per l'applicazione. Definiamo Qmax il valore in ms di questa soglia.

Nelle misurazioni effettuate nel capitolo 6 Qmax è stato fissato a 400 ms basandosi sui valori del one-way-delay considerati accettabili per questo tipo di applicazione.

La stima dell'interarrival jitter, inteso come variazione del ritardo end-to-end sperimentata da pacchetti IP successivi di una stessa connessione, è quella suggerita nella RFC 1889 (Appendix A.8) [3] ed è riportata nel paragrafo 4.3.2. Il valore che l'holding time all'istante t dovrebbe assumere in base alle stime dell'interarrival jitter (senza tener conto della soglia Qmax ) viene calcolato come:

Tht  =

maxinterarrival jitterT

T

dove con T è stata indicata la lunghezza del segmento di speech signal contenuto in ogni pacchetto della comunicazione in corso e con max interarrival jitter si intende il massimo valore dell'interarrival jitter stimato alla fine dell'ultima finestra temporale della durata di Tw secondi.

Dall'inizio della comunicazione vengono cioè considerate una serie di finestre temporali consecutive (ognuna della durata di Tw secondi) ed alla fine di ognuna di queste viene calcolato il massimo tra i

valori dell'interarrival jitter stimati all'arrivo di ogni pacchetto RTP durante i Tw secondi; con

questo valore viene determinato Th . Quest'ultimo viene sfruttato per determinare la lunghezza del

buffer di dejitter dinamico per la durata della successiva finestra temporale durante la quale viene stimato un nuovo max interarrival jitter e perciò un nuovo Th . Nelle misurazioni effettuate nel

capitolo 6 Tw è stato fissato a 10 secondi.

Il valore dell'holding time usato ( Tht  ) però, come detto in precedenza, deve essere tale da non

4 Buffer di dejitter statico e buffer di dejitter adattivo

T1−2tT2−1t , cioè come il tempo che impiega un pacchetto per andare dal punto della rete in

cui si trova l'utente 1 (dal suo user space) a quello in cui è situato l'utente 2 (al suo user space) e tornare indietro senza attraversare i buffer di dejitter e supponiamo T1−2t  = T2−1t  . Supponiamo inoltre che entrambi i partecipanti alla conversazione sfruttino la gestione del buffer di dejitter proposta in questa tesi e che stiano utilizzando lo stesso algoritmo di PLC (perciò che

PLCdelay 1 sia uguale a PLCdelay 2 ). Quest'ultima ipotesi non sarà ovviamente sempre verificata

ma introduce un'incertezza nella misura di pochi millisecondi visti i bassi ritardi introdotti in genere dagli algoritmi di PLC. Ognuno dei due utenti potrà calcolarsi al generico istante t il valore massimo che l'holding time può assumere ( Th maxt ) come:

Th maxt =

Qmax 2 − RTT t 2 −PLCdelay T

T

Prendo la parte intera inferiore multipla di T così da evitare di calcolare un Th maxt che mi

possa portare a superare la soglia Qmax . Ovviamente l'utente dovrà essere in grado di fare una stima

del RTT t che la comunicazione in corso sta sperimentando. Per eseguire questa stima vengono utilizzati alcuni campi dei pacchetti RTCP come descritto nel paragrafo 4.3.3.

Problema che può verificarsi è che il Round Trip Time sia così elevato da far risultare il valore di

Th maxt molto basso (o persino negativo) e di conseguenza il buffer di dejitter così piccolo da

portare ad avere un numero rilevante di pacchetti scartati anche per valori bassi del jitter. Nell'implementazione del sistema di dejitter dinamico realizzata è stata fissata perciò anche una soglia minima al valore che Tht  può assumere ed è stata definita Th min . È stato scelto inoltre di

assegnare a Tht  il valore Th min anche se il valore Tht  calcolato è inferiore a Th min . Nelle

misurazioni effettuate nel capitolo 6 Th min è stato fissato a 60 ms.

Riassumendo il tutto si può perciò dire che il sistema di dejitter adattivo prevede che durante la conversazione vengano dinamicamente stimati i valori dell'interarrival jitter e del RTT t indotti dalle condizioni della rete che si stanno sperimentando e che venga dinamicamente mutato il valore dell'holding time in modo tale che:

Tht  =

Th maxt se Tht ≥Th maxt e Th maxt Th min

Th min se Tht≤Th min o Th maxt≤Th min

4 Buffer di dejitter statico e buffer di dejitter adattivo

dove Tht  e Th maxt sono calcolati secondo le formule riportate in precedenza mentre

Th min è un valore fissato dal progettista.

L'ipotesi che la rete sia tale da introdurre un ritardo identico nelle due direzioni, dall'utente 1 all'utente 2 e vice versa, in alcuni casi può non essere verificata. In questa situazione la stima del one way delay effettuata come la metà del RTT t non sarà esatta. Supponiamo ad esempio che T1−2t sia maggiore di T2−1t . L'utente 1 andrà a stimare Th1 maxt come maggiore di

quanto sarebbe dovuto essere e potrà costruire un buffer di dejitter più grande di quello teoricamente corretto. L'utente 2 stimerà invece Th2 maxt come minore del valore effettivo e potrà costruire un

dejitter buffer più piccolo del valore teorico. Il tempo di iterazione Qt  tra i due utenti si manterrà in ogni caso al di sotto della soglia Qmax a meno che il Round Trip Time sia tale da far ottenere un valore Th maxt così piccolo da costringere ad usare Th min come valore dell'holding time.

Documenti correlati