Next: Il prototipo unicast Up: Il lavoro sviluppato Previous: Il lavoro sviluppato Contents Index
Questo lavoro si pone come obiettivo principale la realizzazione di un sistema di comunicazione video accessibile alla platea più ampia ed eterogenea possibile di utenti. Il sistema deve quindi risentire il meno possibile delle eventuali limitazioni che caratterizzano i singoli utenti, sia dal punto di vista della capacità del canale d'accesso che da quello della potenza di calcolo disponibile.
Si desidera permettere l'accesso sui più svariati canali trasmissivi, da quelli a banda larga, caratteristici di reti ATM o delle reti locali, a quelli a banda più limitata, che si possono ad esempio incontrare nella trasmissione su reti geografiche (si pensi all'accesso via modem su doppino telefonico o al canale radio delle reti cellulari).
Decidendo poi di rendere disponibile il servizio anche per utenti che dispongono di terminali con limitata potenza di calcolo bisogna che la complessità computazionale sia molto ridotta, sia per quanto riguarda la codifica che la decodifica.
L'algoritmo di codifica utilizzato è fortemente scalabile e di bassa complessità, le caratteristiche salienti possono essere riassunte così:
Innanzitutto l'algoritmo di codifica è stato modificato per consentire di variare i parametri che influenzano il tasso trasmissivo (e quindi la qualità), in modo da rispettare i vincoli imposti dal terminale trasmittente.
Tuttavia non è detto che questi vincoli siano propri anche del terminale ricevente.
In un'ottica unicast questo però importa poco, l'host ricevente dovrà adattarsi
ai parametri scelti dal terminale trasmittente (o comunque i due terminali potranno
accordarsi sui parametri da utilizzare). Il discorso diviene più delicato in
un contesto multicast. In questo caso ci saranno più host
riceventi, ciascuno caratterizzato dai propri vincoli che difficilmente coincideranno
con quelli degli altri host. Utilizzando un semplice sistema di codifica con
tasso variabile il trasmettitore dovrebbe scegliere i parametri di codifica
che producono il flusso che si adatta alle caratteristiche dell'host dalle prestazioni
peggiori . In figura ![[*]](crossref.png)
è mostrata una situazione di questo tipo:
accanto ai link in grassetto è indicata la loro capacità, le linee tratteggiate
invece rappresentano il flusso prodotto dal codificatore ed il valore accanto
a esse è l'ampiezza di banda occupata da questo flusso.
Come si vede tutti gli host sono costretti a ricevere un flusso a 128kbit/s anche se la loro rete di accesso permetterebbe di sostenere tassi superiori4.1.
Una possibile soluzione a questa situazione è rappresentata dalla tecnica MMG (Multiple Multicast Group). Abbiamo anticipato che il codificatore è dotato di tre diversi tipi di scalabilità ed è in grado di combinarli in un flusso codificato embedded; l'idea allora consiste nel suddividere questo flusso in più sottoflussi, di cui uno è indispensabile mentre gli altri contengono le informazioni di miglioramento. Associando ciascuno di questi sottoflussi ad un diverso gruppo multicast si rendono possibili situazioni nelle quali ciascun host sceglie quali gruppi sottoscrivere (indipendentemente da quelli scelti dagli altri host) e quindi sceglie a quale tasso ricevere. Uno schema di questo tipo è anche indicato con il nome di Receiver-driven Layered Multicast (RLM) [20], in quanto la scelta è appunto effettuata dal ricevitore e non più dal trasmettitore che in questo caso trasmetterà sempre alla massima qualità possibile senza nemmeno sapere cosa hanno scelto i ricevitori.
In figura è mostrata una situazione in cui si applica la tecnica
MMG. Come si vede ogni host è libero di decidere la qualità del flusso ricevuto
in modo indipendente da quanto hanno scelto gli altri. Sebbene la scelta sia
lasciata ai ricevitori non è ancora ben chiaro in che modo quest'ultimi dovrebbero
scegliere quali gruppi sottoscrivere.
Sono stati presentati molti lavori nei quali viene sfruttata la tecnica MMG e probabilmente il punto su cui si differenziano maggiormente è proprio quello dei criteri che spingono alla sottoscrizione dei vari gruppi. In [19], ad esempio, si propone che i ricevitori effettuino un controllo (non meglio precisato) per stabilire la banda disponibile sulla loro rete d'accesso; contemporaneamente la sorgente spedisce ai vari ricevitori delle informazioni sui vari gruppi, come il tasso prodotto ed il posizionamento del particolare flusso nello stream embedded. Il ricevitore a questo punto ha tutte le informazioni sufficienti per scegliere i gruppi da sottoscrivere senza congestioncosiddettiare la sua rete di accesso. Il controllo sulla banda disponibile può essere fatto periodicamente in modo da adattarsi ai cambiamenti della rete.
Nell'articolo [24] invece si introducono i cosiddetti Thin Streams, ovvero i vari layer prodotti dall'algoritmo di codifica vengono a loro volta suddivisi in più stream dal tasso costante che poi vengono trasportati su più gruppi multicast, in questo modo si ha una separazione tra il livello di codifica e quello di rete. Calcolando la differenza tra il throuput effettivo e quello stimato, il ricevitore è in grado di stabilire se è possibile sottoscrivere altri Thin Streams oppure se è il caso di abbandonarne alcuni.
In [20] viene introdotta la tecnica RLM già anticipata, nella quale il ricevitore effettua i cosiddetti join experiments, in pratica, periodicamente tenta di sottoscrivere un ulteriore layer, e se riscontra che ci sono perdite lo abbandona, salvo poi ritentare successivamente, il tempo di attesa però cresce ogni volta che si hanno dei fallimenti, in questo modo si evita di sovraccaricare inutilmente la rete.
Infine in [25] viene proposta una tecnica basata sulle informazioni trasportate da RSVP, quindi si combina la scelta dei gruppi da sottoscrivere con i meccanismi per la gestione della qualità del servizio.
