Capitolo 4

Capitolo 4
Sorgente streaming
Con l’evoluzione delle applicazioni multimediali e delle tecnologie di rete,
anche nel mondo della telefonia cellulare è cresciuta l’esigenza di poter
comunicare con un’integrazione sempre più ampia fra dati, voce,
animazioni e filmati portando a prodotti di rete multimediali quali la
telefonia, la televisione o la videoconferenza semplificando eventuali
applicazioni quali ad esempio l’apprendimento a distanza, la simulazione
distribuita, il telelavoro.
Per sviluppare questo settore è necessario occuparsi quindi della
comunicazione in tempo reale.
4.1 Protocolli per il traffico real time
Il trasferimento di dati in tempo reale pone di fronte a diverse
problematiche:
•
si richiede una larghezza di banda disponibile notevolmente più
elevata rispetto al tradizionale invio di testo e grafica;
•
non è permesso un tempo di latenza superiore ai 250 ms per non creare
disagio agli utenti, ma questo è complicato anche dal fatto che in caso
di congestione si è spesso costretti a perdere del tutto delle
informazioni generando fastidiosi “gap”;
58
4 – Sorgente streaming
•
le informazioni sono di tipo “bursty” e quindi non basta aumentare la
banda, ma va fatto un accurato dimensionamento dei buffer;
•
la disponibilità delle risorse necessarie non è sicura in ogni momento.
C’è da notare che per i dati in tempo reale l’affidabilità non è così
importante quanto invece la tempestività della consegna: in caso di
congestione della rete alcuni pacchetti possono andare persi e la qualità,
seppur inferiore, sarà in ogni caso accettabile, mentre se il protocollo
insiste nell’assicurare l’affidabilità, i pacchetti che vengono ritrasmessi
possono aumentare la congestione stessa e rallentare o bloccare del tutto
l’applicazione ricevente.
Per la comunicazione real time in Internet è stato introdotto un modello
avanzato chiamato “Integrated Services” che si basa essenzialmente su
cinque protocolli:
•
•
RSVP (Resource reSerVation Protocol): provvede a riservare le
risorse necessarie alla trasmissione;
SIP (Session Initiation Protocol): si occupa dell’apertura e della
chiusura delle connessioni;
•
RTP (Real-time Transport Protocol): gestisce l’effettivo trasferimento
dei dati;
•
RTCP (Real-time Control Protocol): consente
informazioni sulla qualità della trasmissione;
•
RTSP (Real Time Streaming Protocol): consente di controllare il
flusso delle informazioni trasmesse.
di
ottenere
4.1.1 Resource reSerVation Protocol (RSVP)
Il protocollo RSVP [15] ha la funzione di trasmettere le informazioni sulle
prenotazioni, da un nodo della rete all’altro. In ogni nodo, (computer o
router nel caso delle reti fisse), è installato un daemon (programma sempre
in esecuzione) RSVP che assegna le risorse di rete nel controllore di
59
4 – Sorgente streaming
traffico. Nel protocollo RSVP ci sono due tipi di messaggi importanti: i
messaggi Path ed i messaggi Resv. I primi sono trasmessi dalla sorgente
verso la destinazione, contengono informazioni sul flusso da trasmettere e
servono a stabilire il percorso che seguiranno i dati. Opzionalmente,
possono servire a reperire informazioni sulle caratteristiche del percorso
seguito dalla sorgente verso la destinazione, per dare maggiori
informazioni al ricevitore sul tipo di prenotazione da eseguire. I messaggi
Resv sono trasmessi nel senso contrario e servono ad eseguire la
prenotazione stessa.
4.1.2 Session Initiation Protocol (SIP)
SIP [16] è un protocollo di segnalazione di livello applicazione introdotto
dalla IETF. Esso è utilizzato per instaurare, modificare o chiudere
chiamate in tempo reale, come videoconferenze, attraverso reti di tipo IP,
cui possono partecipare anche parecchi utenti.
E’ un protocollo di tipo testuale che eredita molto da altri protocolli di
Internet, come SMTP (Simple Mail Transfer Protocol) e HTTP (Hypertext
Transfer Protocol).
Una caratteristica fondamentale di SIP è che è indipendente dal tipo di
protocollo utilizzato a livello trasporto, ma soprattutto è molto veloce:
impiega circa 1,5 roundtrip per instaurare una chiamata. In particolare,
quando sovrapposto al protocollo UDP, consente di ottenere particolari
semplificazioni per quanto riguarda il traffico multicast.
SIP si basa su di un’architettura di tipo client/server. Le entità principali
che costituiscono questo protocollo sono:
•
User Agent (UA);
•
SIP Proxy Server;
•
SIP Redirect Server;
•
Registrar.
60
4 – Sorgente streaming
Gli User Agent costituiscono i punti terminali (endpoints) dell’architettura
in esame e, nel momento in cui viene inviata una richiesta di servizio alla
rete, esso si comporta da client mentre funge da server quando deve
rispondere ad una richiesta pervenutagli dalla rete stessa.
I server intermedi tra i due User Agent sono in grado di svolgere le
funzioni di un Proxy o di un Redirect Server.
Nel primo caso il server riceve la richiesta avanzatagli dallo User Agent e
la inoltra a quello successivo (o eventualmente allo User Agent di
destinazione); inoltre, queste entità sono in grado di mantenere
informazioni circa l’accredito del costo del servizio che viene fornito.
Nel caso del Redirect Server, quest’ultimo non fa altro che rispondere alle
richieste avanzategli da un certo User Agent fornendo l’indirizzo del
server di destinazione. Inoltre i SIP server sono in grado di contattare
entità esterne per chiedere informazioni per il routing, o anche relative a
chi ha richiesto un certo servizio.
Il Registrar è l’entità presso cui uno User Agent si registra fornendo le
opportune informazioni; sia la richiesta di registrazione sia la conferma
della stessa avvengono secondo un protocollo non SIP.
La segnalazione che questo protocollo genera è costituita da messaggi che
possono essere di due tipi:
a) di richiesta;
b) di risposta.
Un messaggio di richiesta è costituito da:
•
tipo di richiesta (Request Line);
•
intestazione (Header);
•
corpo del messaggio (Message Body).
Un messaggio di risposta è costituito da:
•
stato in cui il server si trova (Status Line);
61
4 – Sorgente streaming
•
intestazione (Header);
•
corpo del messaggio (Message Body).
Nei messaggi di richiesta il tipo di richiesta e l’intestazione specificano le
caratteristiche del servizio, del protocollo utilizzato e gli indirizzi; il corpo
del messaggio può anche essere vuoto.
Per specificare il tipo di richiesta il protocollo utilizza la seguente
terminologia:
•
Invite: per invitare un utente a partecipare ad una chiamata;
•
Bye: per terminare una chiamata;
•
Option: viene utilizzato per richiedere al server informazioni circa le
sue capacità;
•
Ack: conferma che il client ha ricevuto la richiesta precedentemente
inviatagli;
•
Register: fornisce la mappa di risoluzione degli indirizzi in modo tale
che un server possa sapere dove si trova un certo utente;
•
Cancel: annulla una richiesta in precedenza avanzata ma senza
abbattere la connessione.
4.1.3 Real-time Transport Protocol (RTP)
Il terminale di trasmissione di un’applicazione multimediale aggiunge
sempre un campo di intestazione ai dati audio e video che intende
trasmettere, prima di passarli al protocollo di trasporto. Questi campi di
intestazione comprendono numeri di sequenza, etichette temporali di
sincronizzazione e altre informazioni utili; poiché quasi tutte le
applicazioni di rete multimediali hanno bisogno di informazioni di questo
tipo per offrire un servizio accettabile, è risultato utile definire una
struttura di pacchetto standardizzata, in modo da garantire
l’interoperabilità fra sistemi di videoconferenza prodotti da case differenti.
Tale standard è RTP [17] e fornisce informazioni di trasporto adatte a
62
4 – Sorgente streaming
quelle applicazioni che trasmettono dati audio, video o di simulazione in
tempo reale, offrendo servizi di rete unicast o multicast. RTP non richiede
allocazione di risorse e non garantisce qualità di servizio per i servizi in
tempo reale.
Inoltre, ammesso che i pacchetti arrivino a destinazione, non è comunque
detto che giungano nell’ordine con cui sono stati spediti.
Si consideri, ad esempio, l’uso di RTP per il trasporto della voce. Si
supponga che la sorgente vocale sia codificata con lo standard PCM a 64
kbps, sia cioè campionata, quantizzata e digitalizzata e inoltre che
l’applicazione raccolga i dati codificati in blocchi della durata di 20
millisecondi, ossia 160 byte a blocco. L’applicazione fa precedere ogni
unità dati da un’intestazione RTP, la quale contiene la codifica audio
utilizzata, un numero di sequenza e un’etichetta temporale (timestamp).
I dati insieme all’intestazione formano il pacchetto RTP.
Infine RTP fa sì che ogni sorgente, come videocamera o microfono, venga
assegnata un proprio flusso indipendente di pacchetti (stream).
4.1.4 Real Time Streaming Protocol (RTSP)
RTSP [18] è un protocollo di livello applicazione e il suo obiettivo è di
fornire dei servizi su audio e video allo stesso modo di come HTTP fa con
testo e grafica.
La sua struttura è per l’appunto simile a quella di HTTP, anche se ha
bisogno di alcune caratteristiche che si differenziano, fra cui:
•
ha bisogno del mantenimento di STATI (init, ready, playing,
recording);
•
sia il client sia il server possono fare delle richieste; non è quindi
asimmetrico.
RTSP consente di controllare la trasmissione sia di singoli flussi di dati
real time, sia di insiemi di flussi sincronizzati che compongono un unico
contenuto multimediale (ad esempio audio + video).
63
4 – Sorgente streaming
Come tutti i protocolli di comunicazione, anche in RTSP è possibile
distinguere due tipi differenti di messaggi, che godono di particolari
proprietà: richiesta dal client al server e risposta dal server al client.
Le richieste contengono i metodi, gli oggetti su cui stanno lavorando
questi ultimi e dei parametri che hanno lo scopo di descrivere
ulteriormente i metodi i quali risultano fra loro idempotenti a meno che
non sia esplicitato altrimenti. L’uso dei metodi inoltre permette di
richiedere che il media server conservi lo stato della comunicazione.
4.1.5 Real Time Control Protocol (RTCP)
Il protocollo RTCP [19] viene utilizzato nelle applicazioni di rete
multimediali insieme al protocollo RTP. L’uso di RTCP è particolarmente
utile nel caso di applicazioni multicast, in cui uno o più trasmettitori
inviano dati audio e video ad una molteplicità di ricevitori. I pacchetti
RTCP, data una sessione RTP, vengono trasmessi da ciascun partecipante
alla sessione a tutti gli altri.
I pacchetti RTCP si distinguono da quelli RTP in quanto non trasportano
dati di tipo audio o video, ma vengono spediti periodicamente e
contengono rapporti di trasmissione e ricezione. Tali rapporti forniscono
informazioni relative alla qualità di servizio della sessione, alla sorgente
dei dati e delle informazioni di tipo statistico utili all’applicazione, tra cui
il numero di pacchetti mandati, il numero di pacchetti perduti e il jitter di
interarrivo. In ogni caso, RTP non specifica cosa l’applicazione dovrebbe
fare con queste informazioni di feed-back. I trasmettitori, ad esempio,
potrebbero sfruttare le statistiche per modificare la loro frequenza di
trasmissione; i ricevitori invece per scopi diagnostici.
Per ogni flusso di pacchetti RTP che riceve, il partecipante ad una sessione
genera un rapporto di ricezione (Receiver Report). Quindi raggruppa tali
rapporti in un singolo pacchetto RTCP che viene poi inoltrato nella rete.
Per ogni flusso di pacchetti RTP che trasmette, il partecipante ad una
sessione crea e trasmette un pacchetto RTCP contenente un rapporto di
trasmissione (Sender Report). Infine per ogni flusso di pacchetti RTP
64
4 – Sorgente streaming
trasmesso, il trasmettitore crea e trasmette anche un pacchetto di
descrizione della sorgente (Source DEScription).
Infine, tutti i pacchetti RTCP possono essere concatenati in modo da
contenere rapporti di trasmissione, di ricezione o di descrizione delle
sorgenti.
4.2 Modelli di traffico
Esistono molti tipi di applicazioni ognuna con caratteristiche differenti;
esse generano flussi di dati che verranno poi trasmessi attraverso la rete.
Nel momento in cui si progetta una specifico sistema di comunicazione,
per simularne le prestazioni, si utilizzano tipi di traffico di differenti
applicazioni, modellati statisticamente.
Benché sia molto difficile emulare esattamente la generazione dei
pacchetti di tutte i possibili servizi e tutte le possibili applicazioni, esistono
alcuni modelli di traffico per le più importanti applicazioni IP.
Di particolare interesse sono le nuove applicazioni multimediali in virtù
delle loro caratteristiche di adattabilità (alle condizioni della rete mediante
opportune variazioni della codifica) e di interattività.
Il modello del traffico vocale, ad esempio, può essere descritto mediante
una catena di nascita e morte in cui il processo casuale degli arrivi delle
richieste di servizio abbia legge di distribuzione di Poisson e la durata
della connessione sia un ulteriore processo casuale con distribuzione
esponenziale.
La conversazione vocale può essere descritta da una sequenza di tratti di
segnale vocale (talkspurt), separati da impulsi di silenzio. Durante un
discorso si può assumere che ciascuno degli interlocutori rimanga in
silenzio per più del 40% della durata della conversazione stessa.
In altre parole una sorgente di traffico vocale può essere descritta da un
modello markoviano a due stati impulsivi: silenzio e parlato.
65
4 – Sorgente streaming
Durante il periodo di silenzio la sorgente, com’è intuitivo, non genera
pacchetti, mentre durante il periodo di parlato genera pacchetti con
velocità costante.
Questo tipo di traffico può essere più semplicemente simulato mediante
una sorgente di tipo ON-OFF in cui, la durata dei periodi di attività e di
silenzio, siano delle variabili casuali con distribuzione esponenziale e
valore medio rispettivamente TON e TOFF.
La dimensione dell’unità dati dipende sostanzialmente dal tipo di codifica
utilizzato. In particolare esistono delle codifiche adattative (AMR) in cui il
bit rate della sorgente può variare all’interno di un ben preciso intervallo,
in modo tale da offrire un servizio di trasmissione del segnale vocale ad
elevata qualità.
In generale, con il massimo valore di bit rate, le unità dati sono costituite
da circa 32 byte; a questi bisogna aggiungere le intestazioni dovute a RTP,
UDP e IP di dimensioni che vanno da 40 a oltre 60 byte (a seconda della
versione di IP utilizzata).
La correlazione è un’importante caratteristica di alcuni tipi di flussi di dati
come quello cui darebbe luogo una videoconferenza o comunque un
servizio real time.
La complessità del traffico generato da una videotelefonata deriva, in
modo del tutto naturale, dall’integrazione, su di un singolo canale di
comunicazione, di un certo numero di sorgenti di tipo diverso (voce,
video) che differiscono tra loro, in modo anche significativo, a causa dei
requisiti richiesti.
Più in dettaglio, le varie sorgenti che condividono il medesimo canale di
comunicazione differiscono per il fatto che, mentre alcune generano
traffico con bit rate costante (CBR, come la voce), altre generano traffico
con bit rate variabile (VBR, come il video).
Le applicazioni real time producono un flusso continuo di dati che
vengono codificati e pacchettizzati ma, a differenza delle applicazioni non
real time, in questo caso non ha più senso parlare di pacchetti; è più
ragionevole parlare di flusso continuo o streaming di dati.
66
4 – Sorgente streaming
Il traffico video è per sua natura a bit rate costante che diviene variabile
nel momento in cui viene compresso.
Di tecniche di compressione ve ne sono molte e non se ne discuterà in
questo contesto, tuttavia va precisato che tutte quante si basano su tipi di
codifica differenziale: si trasmette un’immagine e quindi, per un certo
intervallo, si trasmettono le differenze tra quest’ultima e quelle successive.
Ciò è possibile grazie a due importanti caratteristiche del traffico video di
seguito elencate.
La prima è costituita dalla forte correlazione tra due frame successivi; il
valore tipico della lunghezza di correlazione è compreso tra 10 e 20 frame.
La seconda caratteristica è che il segnale video ha un bit rate che si
mantiene attorno ad un certo valore e solo molto raramente cresce in modo
drastico per poi ritornarvi dopo un breve intervallo di tempo (uno o due
frame).
Quest’ultimo effetto si deve al cambiamento della scena che comporta
numerosissime differenze tra due immagini successive.
4.2.1 Traffico Streaming
Per streaming s’intende “un flusso di dati continuo”.
I vari media possono essere trasmessi come semplici file; spesso, però,
questi hanno dimensioni consistenti e di conseguenza i tempi di attesa
iniziali sarebbero molto lunghi. Questo tipo di trasmissione non è adatto
alla maggior parte delle applicazioni: per esempio non si può pensare di
scaricare un film per vederlo.
D’altro canto, sorgenti come la radio o la televisione vogliono raggiungere
prima possibile i loro ascoltatori o telespettatori: in questo caso viene
prodotto un flusso di pacchetti, campionando periodicamente.
In quasi tutti i casi si utilizza una tecnica nota come streaming che opera
nel modo seguente:
•
i pacchetti vengono trasmessi uno di seguito all’altro con tempo di
interrarivo nullo;
67
4 – Sorgente streaming
•
viene stimata la qualità della trasmissione;
•
i pacchetti che giungono correttamente al ricevitore vengono inseriti in
un buffer;
viene riprodotto il media prelevando i pacchetti dal buffer di cui sopra,
mentre si continua a ricevere PDU dello stesso flusso.
•
Il media non è più in un file ma in uno stream.
Il mezzo di trasporto, per la distribuzione dei flussi multimediali, deve
garantire requisiti tecnici e funzionali che possono essere impliciti
nell’architettura della rete di telecomunicazione oppure possono essere
ottenuti attraverso l’utilizzo di uno o più protocolli cooperanti, ma devono
sussistere:
•
•
ampiezza di banda garantita;
latenza ridotta;
•
jitter limitato;
•
perdite limitate;
•
conservazione dell’ordinamento del flusso.
I flussi multimediali sono generalmente contraddistinti da esigenze di
banda rilevanti, perlomeno rispetto alle applicazioni informatiche
classiche: la loro ampiezza è legata al tipo di medium utilizzato, nonché
allo schema di codifica e compressione adottato, e comunque può variare
da 8 kbps per una trasmissione audio vocale, ai 2 Mbps per una
trasmissione audio-video di elevata qualità.
La rete dovrebbe poter smaltire, in ogni caso, il flusso di dati generati
dalle singole sorgenti: invece, sebbene i valori minimi di banda necessaria
sono particolarmente bassi si rileva la difficoltà di ottenere dei buoni
risultati alla prova dei fatti.
Ciò è dovuto ad un requisito fondamentale del traffico multimediale: la
banda deve essere costantemente garantita, almeno ad un livello minimo.
Questa caratteristica è facilmente dimostrabile con esempi concreti:
durante la ricezione di un filmato risulta estremamente penalizzante
68
4 – Sorgente streaming
l’interruzione della proiezione in attesa della ricezione dei fotogrammi in
ritardo; lo stesso disagio si avverte se la voce non è ben coordinata con le
immagini.
Le stesse considerazioni possono valere per l’audio: è addirittura
preferibile che la qualità si deteriori a causa di una maggiore compressione
del segnale, piuttosto che la ricezione risulti spezzata, ma questo si evita
disponendo sempre di un minimo di banda garantita.
Occorre pertanto, al fine di rendere possibile la trasmissione di un flusso
multimediale, garantire un’allocazione preventiva della banda, sia essa
statica o variabile tra due valori i cui limiti sono dipendenti dalle varie
possibilità di codifica e dal numero di media utilizzati.
Con il termine latenza si definisce il tempo che intercorre tra l’invio dei
dati da parte del mittente e la ricezione da parte del destinatario: essa
dipende da diversi fattori che sommano i loro effetti durante il percorso.
Analizziamo un’architettura client/server per verificare dove e come questi
fattori agiscano.
•
Server: quando i dati sono disponibili, il mittente deve codificarli,
eventualmente comprimerli ed infine trasmetterli. Il tempo richiesto
per queste operazioni è variabile ed è legato al tipo ed alla complessità
degli algoritmi impiegati, ma in ogni caso non è nullo. Gli schemi di
codifica operano, infatti, solitamente in intervalli temporali dell’ordine
della decina di millisecondi.
•
Rete: qualunque sia la tipologia utilizzata, essa introduce dei ritardi
variabili in funzione della distanza da coprire e dal numero di nodi
attraversati. Possibili cause di ritardo sono, infatti, costituite
dall’accomodamento e dalla sincronizzazione dei flussi che avvengono
all’interno dei buffer delle macchine di rete (switch e router).
•
Client: al ricevimento dei dati dalla rete, il client deve decomprimerli
per ricostruire il flusso originario e poi riprodurlo. I problemi sono
all’incirca speculari a quelli del mittente.
69
4 – Sorgente streaming
La latenza ricopre un ruolo di primaria importanza soprattutto per le
applicazioni interattive, nel qual caso non deve superare i 250 ms per non
compromettere la naturalezza della comunicazione: alcuni algoritmi
sfruttano protocolli di trasporto non affidabili (quali UDP) che tuttavia non
aggiungono ritardi alla trasmissione.
Con jitter s’intende la variazione del ritardo avvertito in ricezione rispetto
al tempo d’invio dei dati: tali oscillazioni alterano il normale flusso dei
dati, creando discontinuità e/o sovrapposizioni all’atto della riproduzione
del flusso originale.
Per semplificare il fenomeno possiamo pensare all’ascolto di un disco in
vinile su un piatto che non abbia una velocità di rotazione costante, bensì
che subisca delle brusche variazioni: ne consegue che la frequenza con cui
i campioni audio vengono riprodotti non è più la stessa con cui sono stai
registrati, generando interruzioni o distorsioni fastidiose per l’ascoltatore.
Il jitter rappresenta quindi un disturbo per il ricevente soprattutto nel caso
di comunicazioni strettamente legate al tempo, come quelle audio, in cui
provoca continue interruzioni che portano alla non intelligibilità dei
contenuti.
Gli effetti si possono eliminare compensando le variazioni del ritardo
tramite l’utilizzo di buffer in ricezione che agiscano da polmone tra i dati
in arrivo e quelli da riprodurre: aumentando la dimensione dei buffer
cresce il ritardo ma diminuisce il numero di pacchetti persi; il contrario
accade se tali dimensioni diminuiscono.
Condizione ottimale, per ottenere una comunicazione di buona qualità, è
che il jitter sia il più basso possibile (pochi millisecondi) o al limite nullo.
Le cause di questo fenomeno generalmente sono da ricercarsi nella
variabilità del traffico in rete e nelle congestioni che si formano.
Benché il trasporto di dati multimediali richieda generalmente prestazioni
superiori rispetto al normale traffico informatico, per alcuni requisiti,
come l’esattezza della riproduzione, è possibile fare delle diverse
considerazioni.
Nelle applicazioni di trasferimento di file, è fondamentale che ogni
singolo byte giunga al ricevitore, affinché la trasmissione abbia un buon
70
4 – Sorgente streaming
esito: per questo motivo la gestione del problema è demandata ai
protocolli di trasporto, mentre le applicazioni non prevedono controlli
sull’affidabilità della connessione.
Lo stesso vincolo non è di solito valido nella gestione di flussi
multimediali: se in un filmato manca un fotogramma, oppure se in una
conversazione si perdono alcuni millisecondi di audio, l’effetto è
trascurabile se non addirittura inavvertibile.
La quantificazione percentuale di perdita limite consentito dipende dal
metodo di codifica adottato e dal risultato che si vuole ottenere.
Alcuni metodi di codifica trattano il flusso multimediale in modo
uniforme, vale a dire che il contenuto informativo è pressoché costante nel
tempo (sorgenti CBR), mentre esistono metodi che condensano le
informazioni in alcuni punti piuttosto che in altri (sorgenti VBR), come
per esempio MPEG.
Nel secondo caso la perdita di alcuni spezzoni, piuttosto che di altri, può
risultare più dannosa.
Nel valutare la soglia di accettabilità delle perdite può anche essere
importante la valutazione soggettiva del destinatario e dei dati trasmessi.
Consideriamo per esempio una videoconferenza: l’importanza delle
immagini è sicuramente secondaria rispetto a quelle della voce; vale a dire
che se l’audio continua ad essere comprensibile, è accettabile che il flusso
delle immagini possa interrompersi, ma non vale il viceversa.
La scelta del metodo è quindi dipendente dal risultato ricercato, e di
conseguenza dal medium che s’intende privilegiare per la comunicazione
del contenuto informativo.
Il corretto ordinamento dei dati ricevuti, secondo la sequenza di
spedizione, è solitamente fondamentale per ricostruire correttamente il
flusso originale, è per questo motivo che il riordino dei dati, qualora non
sia intrinsecamente assicurato dall’architettura di rete, viene generalmente
gestito dai protocolli di trasporto; gli stessi si occupano anche della
ritrasmissione in caso di anomalie, così come del controllo dell’affidabilità
della connessione, in modo che non risultino a carico dell’applicazione.
71
4 – Sorgente streaming
Nel caso di flussi multimediali, però, anche questo requisito non è più
indispensabile: si possono semplicemente scartare gli spezzoni fuori
ordine oppure riordinarli, con la sola preoccupazione di non ritardare il
normale fluire della ricezione/riproduzione.
4.3 Generatore di traffico streaming
MPEG è oggi lo standard più diffuso per la codifica del segnale video:
esso è utilizzato per raggiungere un’elevata compressione, cosa che non è
realizzabile se le immagini che compongono la sequenza video vengono
codificate ognuna in modo indipendente dalle altre.
MPEG realizza una codifica in cui vengono mantenute alcune immagini
codificate in modo indipendente dalle altre, quindi poco compresse; le
restanti immagini vengono ricavate da queste attraverso una predizione del
moto, oppure mediante interpolazione tra più immagini.
Esistono ad oggi diverse versioni di questo standard e delle nuove sono in
fase di studio. Tra quelle già in uso, merita di essere citata la MPEG-4 con
cui si realizza un unico ambiente in cui trattare diversi tipi di applicazioni
e di supportare un nuovo tipo di interattività, basato sui contenuti e i
significati dell’informazione audio-video.
Per ulteriori approfondimenti sull’argomento si rimanda a [20].
Per introdurre una sorgente di traffico MPEG (video) nel simulatore è
stato necessario, innanzi tutto, elaborare un modello probabilistico che
emulasse la generazione di pacchetti secondo i canoni di quest’ultimo
standard. A tal proposito è stato preso in esame un modello con processo
casuale di tipo markoviano.
Questo è un modello a tempo discreto della larghezza di banda richiesta da
un flusso dati con codifica di tipo MPEG.
L’emissione di un frame per unità di tempo è considerata come il
funzionamento base del mittente (sender), e il modello descrive la
sequenza della lunghezza delle trame. Così facendo, la più importante
informazione da conoscere è se il trasmettitore sta inviando un’immagine
72
4 – Sorgente streaming
codificata in maniera indipendente dalle altre oppure una serie di
differenze tra due successive.
Si considera che la sorgente sia in uno degli stati possibili e lo stato futuro,
cioè quello in cui la dimensione del pacchetto è pari a quella del pacchetto
che dovrà essere inviato successivamente, viene determinato in base a
quello corrente.
Un modello di sorgente di traffico multilivello può simulare il flusso
continuo MPEG. Secondo tale modello la sorgente può trovarsi in uno tra
due possibili stati: emissione di una immagine completamente nuova
oppure di una serie di differenze con quella precedente.
In entrambi i casi la banda occupata è nota.
I cambiamenti di stato della sorgente sono descritti da un modello
markoviano, e il tempo di permanenza in ciascuno stato è un processo
casuale con distribuzione arbitraria.
Quanto detto fin qui non è stato, per ovvi motivi di semplicità,
implementato esattamente nel simulatore; in realtà è stato fatto qualcosa di
molto simile ma con la possibilità di configurare la sorgente affinché
possa modellare non solo traffico secondo lo standard MPEG, ma
eventualmente anche secondo altri tipi di codifica.
4.3.1 Implementazione della sorgente di traffico
Ciò che è stato realizzato non è altro che una sorgente a quattro stati, di cui
uno consiste in uno stato di segnalazione, mentre nei tre rimanenti
vengono trasmesse informazioni d’utente utilizzando per ognuno un
diverso bit rate.
Per generare un flusso continuo di dati (definizione esatta di stream) si è
deciso di far creare alla sorgente un pacchetto ad ogni frame.
La continuità del flusso dati si ottiene, pertanto, in maniera del tutto
automatica, considerando che la risoluzione temporale del simulatore è
dell’ordine del frame (10 ms).
La variabilità del bit rate si ottiene assegnando a ciascuno stato il valore
della lunghezza, in byte, dei pacchetti generati.
73
4 – Sorgente streaming
I valori scelti per condurre le prove di validazione sono tali da far scaturire
gli stessi valori di bit rate definiti dallo standard (384 kbit/s, 144 kbit/s, 64
kbit/s).
Le varie dimensioni delle unità dati sono, altresì, controllabili da parte
dell’utente del simulatore che dovrà specificarli in un file apposito
(Source.dat), descrivendo le caratteristiche di ciascuno stato.
La modalità con cui si configura la sorgente VBR, cioè mediante il file di
cui sopra, non esclude la possibilità di introdurre eventualmente dei nuovi
stati per esempio in seguito alla standardizzazione di nuovi valori di bit
rate.
4.3.2 Stati della sorgente streaming
Lo stato della sorgente è definito dalla classe MarkovianState (definita nel
file MarkovianState.h). In essa sono definiti tutti i parametri che
caratterizzano il funzionamento della sorgente; fra questi vi sono, un
identificativo numerico per lo stato stesso, la dimensione in byte del
pacchetto da trasmettere, il tempo medio di permanenza in tale stato da
parte della sorgente stessa (figura 4.1).
Nulla vieta di inserire dei nuovi parametri che consentano, ad esempio, di
scegliere la modalità di invio dei riscontri oppure il numero di pacchetti da
inviare ad ogni frame (al momento è 1) per tenere conto della codifica
utilizzata.
La sorgente a più stati è rappresentata, nel software, dalle classi Discrete
State Markovian Source e Descrete State Markovian Data Source (che
eredita dalla prima) entrambe definite nel file Traffic_Source.h.
Di queste ultime classi fanno parte le funzioni di gestione (Handle_ON() e
Handle_OFF()), le funzioni di invio dei pacchetti (Send_packet() e
Send_sign_packet()), ed infine le funzioni per il calcolo del tempo di
interarrivo dei pacchetti e dell’istante di cambiamento dello stato da parte
della
sorgente
(rispettivamente
Get_time_pack()
e
Get_time_to_change_state()).
74
MR-State
75
Figura 4.1: diagramma degli stati della sorgente
streaming
implementata
nel
simulatore.
mean time to stay [ms]
packet size [byte]
Bit rate [kbit/s]
Thl = xx ms
mean time to stay [ms]
Bit rate [kbit/s]
mean time to stay [ms]
Tlh = xx ms
LR-State
CLOSE
status = OFF
packet size [byte]
CLOSE
packet size [byte]
Bit rate [kbit/s]
SIGN-State
packet size [byte]
Bit rate [kbit/s]
HR-State
INVITE
status = ON
Four states streaming source
4 – Sorgente streaming
4 – Sorgente streaming
All’interno del codice sono stati implementati diversi tipi di generatori di
traffico cui, ovviamente, ad ognuno corrisponde un tipo diverso di servizio
offerto dalla rete.
Nel file Simul_service.dat è possibile definire, per ogni cella, la
percentuale di utenti che, all’inizio della simulazione, daranno luogo ad un
certo tipo di flusso di dati.
4.3.3 Generazione e invio di pacchetti
Ogni volta che viene richiamata la funzione Send_packet(), essa genera un
pacchetto di dimensioni opportune e lo inserisce nello
UDP_buff_master_tx; da qui verrà successivamente estratto e,
richiamando la primitiva del caso, dal livello TCP/UDP percorrerà verso il
basso la pila fino ad essere inviato sul canale radiomobile.
Esiste una funzione del tutto analoga alla precedente che è la
Send_sign_packet(), la quale genera pacchetti contenenti informazioni di
segnalazione e, pertanto, prende come parametro un valore cui
corrisponde un certo tipo di messaggio (INVITE, OK, RR, CLOSE).
La corrispondenza tra messaggi e rispettivi valori è stata definita,
mediante delle costanti, nel file Definition.h e nulla vieta di definirne dei
nuovi.
La funzione per il calcolo del tempo di interarrivo dei pacchetti, pur
essendo stata implementata, non viene al momento utilizzata; potrebbe
venire utilizzata in seguito per simulare particolari tipi di codifiche o più
semplicemente per introdurre dei ritardi.
4.3.4 Inizio della sessione di trasmissione
Nell’istante in cui la sorgente di traffico viene creata (cioè le viene
assegnata una locazione di memoria), il suo indirizzo viene memorizzato
da un puntatore definito come istanza della classe Traffic_source (file
Traffic_source.h).
76
4 – Sorgente streaming
All’interno di quest’ultima sono state definite un certo numero di variabili
di stato (variabili booleane) che caratterizzano la stato di funzionamento
della sorgente di traffico.
UE
UTRAN
INV
ITE
OK
Figura
4.2:
descrizione dei messaggi di
segnalazione
inviati
per
l’apertura di una sessione di
streaming.
All’inizio della sessione viene richiamata la funzione Activate() che ha il
compito di attivare la sorgente, ordinando, altresì, l’invio di un pacchetto
di segnalazione con il significato di richiesta di partecipazione alla
sessione in corso e, per mantenere la stessa semantica del protocollo SIP, è
stato chiamato INVITE (figura 4.2).
Per semplicità si è fatta l’ipotesi che i pacchetti di segnalazione abbiano
dimensione fissa; se ad esempio si pone pari a 40 byte la velocità con cui
la sorgente genera i pacchetti quando si trova nello stato di segnalazione
(SIGN) sarà:
77
4 – Sorgente streaming
40byte ⋅ 8 ⋅ 10 −3 kbit
= 32 kbit s
−2
10 s
Dal lato ricezione, quando si riceve un pacchetto di segnalazione di tipo
INVITE, supponendo che la risposta all’invito sia affermativa, si inserisce
nella lista degli eventi (per simularne il ritardo di trasferimento), l’evento
di invio al mittente di un acknowledgement (OK): ciò è possibile in
seguito alla creazione di un evento (Send_ack_ev) appositamente pensato
per tale scopo (figura 4.2).
Quando la pila che ha avanzato la richiesta di partecipazione, (cioè che ha
inviato il messaggio INVITE), riceve un pacchetto di tipo riscontro (OK)
inserisce in calendario un nuovo evento che porterà la sorgente dallo stato
di segnalazione a uno di trasmissione (Change_src_state_ev).
Inoltre viene inserito in calendario l’evento che indica il termine della
sessione in corso, ovvero di disattivazione della sorgente
(Switch_source_ev).
Il tempo di occorrenza di questi due ultimi eventi non sono altro che
variabili casuali che l’utente del simulatore può scegliere di impostare,
specificando nel file delle sorgenti i limiti dell’intervallo di valori che
possono assumere rispettivamente, la permanenza della sorgente nello
stato corrente e la durata di una sessione, nonché il tipo di distribuzione
per ciascuna delle due variabili.
Contemporaneamente vengono messi in calendario anche gli eventi per il
cambiamento di stato della sorgente (dallo stato di segnalazione a quello
di trasmissione dei dati) e per l’invio del primo pacchetto di informazione
(cioè di tipo DATA), in quanto ormai la connessione è stata creata
completamente.
Se la probabilità di perdita dei pacchetti è non nulla, come accade quando
il canale radiomobile non è ideale, il pacchetto INVITE potrebbe non
giungere mai a destinazione e di conseguenza la sessione non prenderà
mai inizio. Per evitare ciò è stato introdotto un timer (WaitSignPck) che
viene attivato al momento dell’invio del messaggio precedente e allo
78
4 – Sorgente streaming
scadere, se non è ancora giunto il messaggio di risposta, si ripete la
procedura. La durata del tempo di attesa non è fissa e l’utente può
specificarne il valore nel file di configurazione delle sorgenti.
In realtà, se il livello RLC lavora in modalità acknowledged, il pacchetto
giungerà sicuramente a destinazione, ma con grande ritardo: per far fronte
a questi casi è stato introdotto un meccanismo che consente di rilevare la
presenza di pacchetti duplicati.
4.3.5 Trasferimento dei dati
Una volta schedulato l’evento di cambiamento di stato della sorgente,
viene chiamata la funzione Change_state().
L’evento contiene, nella propria definizione, anche un valore numerico
che si riferisce allo stato successivo in cui la sorgente dovrà portarsi.
La funzione Get_time_to_change_state() estrae il valore di una variabile
casuale: tale valore verrà poi utilizzato come tempo di occorrenza del
successivo cambiamento di stato della sorgente. La legge di distribuzione
di quest’ultima variabile non è definita a priori, ma è l’utente del
simulatore a sceglierla (file Source.dat) specificando anche i limiti
dell’intervallo dei valori che essa può assumere nonché il valore medio.
Nella fase di attuale sviluppo del sistema si può scegliere fra tre tipi di
distribuzioni: esponenziale, geometrica, uniforme.
Se si decide di utilizzare una codifica tipo MPEG, lo stato di trasmissione
successivo a quello di segnalazione non potrà che essere quello con il bit
rate più elevato: si trasmetterà un’immagine intera e poi un certo numero
di differenze fra questa e le successive.
Per quest’ultimo stato si è deciso di utilizzare pacchetti di dimensione
fissa; se ad esempio si pone pari a 480 byte la velocità con cui la sorgente
genera i pacchetti quando si trova nello stato HR sarà:
480 ⋅ 8 ⋅ 10 −3 kbit
= 384 kbit s
10 −2 s
79
4 – Sorgente streaming
Sempre all’interno della funzione Change_state() viene inserito nella lista
degli eventi il prossimo evento di cambiamento di stato, specificando, tra
l’altro, quale dovrà essere quello successivo.
Anche per lo stato in cui si trasmettono le differenze tra due immagini
successive (LR) si è deciso di utilizzare unità dati di lunghezza fissa; se ad
esempio tale valore si pone pari a 80 byte, la velocità di generazione della
sorgente sarà:
80 ⋅ 8 ⋅ 10 −3 kbit
= 64 kbit s
10 −2 s
In condizioni normali la sorgente ha un funzionamento che oscilla tra
questi ultimi due stati; esiste tuttavia un terzo stato (MR), con una velocità
di generazione dei pacchetti da porre ad un valore intermedio rispetto a
quello degli stati precedenti, in cui è possibile inviare sempre immagini
complete ma con un diverso tipo di codifica e quindi anche una qualità del
servizio offerto inferiore rispetto al caso normale: ciò può essere utile nel
caso in cui le condizioni del canale o comunque il carico della rete non
consentano la fornitura del servizio con la massima qualità possibile.
La decisione di cambiare codifica, e quindi di ridurre la qualità del
servizio offerto viene presa dal trasmettitore sulla base di opportune
indicazioni provenienti dal lato ricevente. In ricezione, infatti, viene
misurata la probabilità di perdita dei pacchetti; quando questa raggiunge
un valore massimo si ordina al trasmettitore di cambiare codifica.
Tutto ciò non può avere effetto immediato dal momento che il messaggio
di controllo deve giungere prima all’applicazione (che non si trova nella
UTRAN ma nella Core Network) e poi tornare indietro.
Inviando pacchetti di dimensione 180 byte, la velocità di generazione dei
pacchetti sarà:
180 ⋅ 8 ⋅ 10 −3 kbit
= 144 kbit s
10 −2 s
80
4 – Sorgente streaming
Occorre tuttavia osservare che la decisione di cambiare la codifica della
sorgente comporta l’introduzione di opportune modifiche ad alcuni
parametri di sistema per la trasmissione, e fra questi vi è il codice
ortogonale utilizzato sul canale radio: di ciò si occupa, in modo del tutto
automatico, il livello RRC (che si trova nel piano di controllo).
In seguito, tutte le procedure fin qui descritte verranno gestite
automaticamente in quanto sia la funzione Change_state() che la funzione
Send_packet(), una volta chiamate, metteranno automaticamente in
calendario un nuovo evento ciascuna del medesimo tipo (figura 4.3).
Tutti i messaggi di controllo della sessione, (cioè di tipo OK, RR) che
vanno dal ricevitore al trasmettitore, per semplicità, non passano
attraverso il canale radio, bensì raggiungono la pila duale corrispondente
mediante opportuni puntatori e la chiamata alla primitiva di indicazione
del blocco UDP; il ritardo con cui tali messaggi vengono ricevuti è fisso
(ack_time) e può essere specificato dall’utente.
UE
UTRAN
IN V IT E
OK
DA TA
DA TA
DA TA
DA TA
RR
DA TA
Figura 4.3: esempio di trasferimento di dati
(dall’utente alla rete) e di riscontri
(dalla rate all’utente).
81
4 – Sorgente streaming
Per fare ciò, la sorgente non si porta nello stato di segnalazione in quanto
sarebbe una complicazione inutile (con in più l’aggiunta di istruzioni che
rallenterebbero l’esecuzione del programma); in altre parole la sorgente
non cambia stato, ma solo in questi casi.
4.3.6 Chiusura della sessione di trasmissione
Una volta che l’istante di simulazione giunge al termine prestabilito per la
fine della sessione di trasmissione, la sorgente passa nello stato di
segnalazione e provvede a inviare i messaggi necessari per la chiusura
della connessione (CLOSE, figura 4.4).
UE
UTRAN
DATA
DATA
DATA
DATA
RR
DATA
DATA
CLOSE
OK
Figura 4.4: esempio di invio di messaggi di
segnalazione per la chiusura della
sessione in corso.
La ricezione di tali informazioni implica la disabilitazione della sorgente.
Come per il pacchetto INVITE, anche il messaggio CLOSE potrebbe
andare perduto: qualora ciò accadesse la sessione non potrebbe più
terminare. Per risolvere questo inconveniente, al momento di invio del
82
4 – Sorgente streaming
pacchetto CLOSE, viene nuovamente attivato il timer WaitSignPck: se allo
scadere non è ancora stato ricevuto il riscontro per il pacchetto CLOSE, la
sessione in corso termina automaticamente.
Comunque vadano le cose, al termine di ogni sessione, se c’è tempo a
sufficienza prima della fine della simulazione, si mette in calendario
l’evento di inizio di una nuova sessione (Rep_session_ev); qualora ciò non
fosse possibile, se tutti gli utenti hanno concluso le proprie sessioni, si
procede con l’ultimo aggiornamento delle statistiche nonché la
presentazione dei risultati ottenuti.
83