Applicazioni streaming nell UMTS

Transcript

1 Multichannel Applications Centre Applicazioni streaming nell UMTS Rossello Placido - 3G Applications Designer, Multichannel Applications Centre Quinary SpA 1

2 Copyright 2001 Quinary SpA Tutti i diritti sono riservati. Questo documento non può essere copiato o riprodotto in alcuna forma, ivi inclusi supporti magnetici o altri media elettronici, e le informazioni in esso contenute non possono essere utilizzate, distribuite o rese pubbliche, né interamente né in parte, senza il preventivo consenso scritto di Quinary SpA. 2

3 Indice. Applicazioni streaming nell UMTS Indice 1. Introduzione Il metodo streaming Streaming Media nell UMTS Protocolli per lo Streaming Media su UMTS Real-time Transport Protocol (RTP) Real-time Transport Control Protocol (RTCP) Real-time Streaming Protocol (RTSP) Session Description Protocol (SDP) Codec Appendice A Appendice B

4 1. Introduzione L UMTS (Universal Mobil Telecommunications System) ha come scopo principale quello di far convergere in un unico sistema i principali trend dell attuale mercato delle comunicazioni e cioè di fornire agli utenti la possibilità di un accesso efficiente ad un ampia gamma di informazioni ed applicazioni, garantendo la crescente necessità di mobilità. In altri termini, il ruolo dell UMTS dovrà essere quello di far incontrare due differenti soluzioni, attualmente scarsamente correlate: Internet e le mobile network. L UMTS offrirà la possibilità di comunicare in movimento in ogni ambiente, attraverso una grande varietà di applicazioni e l universalità dei terminali. Con questa nuova tecnologia, tutte le applicazioni oggi possibili solo sulla rete fissa saranno fruibili anche attraverso le reti mobili, tenendo però conto delle inevitabili limitazioni dovute alle capacità dei link radio nonchè dei problemi tipici dei terminali mobili, quali le ridotte capacità di visualizzazione e la limitata autonomia delle batterie. Considerando che- almeno per la Release 99 - le infrastrutture dell UMTS saranno affiancate e coesisteranno sia con le reti wireless attuali (GSM) che con quelle di seconda generazione (HCSD, GPRS), è prevedibile che inizialmente le principali applicazioni della terza generazione di reti wireless saranno caratterizzate da parametri di QoS che i precedenti sistemi non garantivano in maniera efficiente. Successivamente, grazie ai vantaggi che la disponibilità di nuove bande radio offrirà agli operatori e alla definitiva affermazione di nuove tecnologie, quali ad esempio la Voice over IP, è prevedibile un graduale smistamento di tutti i servizi e applicazioni su sistemi UMTS. In quest ottica la 3GPP (Third Generation Partnership Project) ha definito le seguenti quattro principali classi di QoS per il trasporto dei dati su UMTS : Conversational/real time class Streaming class Interactive class Background class I principali parametri ed i tipi di servizi rientranti in queste classi di QoS sono riportati in Figura 1. Type Service Data Rate Delay Delay Variation Reliability Conversational/ real time Conversational voice 4-25 kbit/s <150 ms <1 ms <3% FER Videophone kbit/s <150 ms <1% FER Telemetry (control) <28.8 kbit/s <250 ms 0% FER Games <1 kbit/s <250 ms <3% FER Interactive Voice messaging 4-13 kbit/s <1 sec <1 ms <3% FER Web browsing 4 sec/pag e-commerce 4 sec <0% FER Streaming Streaming audio kbit/s <10 sec <1 ms <1% FER Video kbit/s <10 sec <1% FER Telemetry (monitoring) <28.8 kbit/s <10 sec 0% FER Figura 1. Quality of Service (QoS) Source: ITU et al. 4

5 Guidati dall esperienza di Internet, dove la richiesta di accesso ad informazioni digitali multimediali (testo, video e audio) è in continua crescita, in questo documento si è dedicata particolare attenzione alle applicazioni di streaming media, che sicuramente rappresentano un forte potenziale commerciale, soprattutto nelle prime fasi operative dell UMTS. In particolare, lo studio è finalizzato alla creazione di un simulatore software per un accurata analisi prestazionale dei servizi di video streaming, attraverso l interfaccia UTRAN (UMTS Terrestrial Radio Access Network). Le specifiche non descrivono l intera gamma dei servizi offerti: moltissimi aspetti, quali, ad esempio, l ottimizzazione delle caratteristiche del canale fisico in base al tipo di traffico ed al suo volume e la scelta delle modalità operative, sono lasciati all implementazione dei costruttori e, in ultima analisi, alle scelte di configurazione degli operatori. La 3GPP definisce un vasto insieme di possibili caratteristiche da assegnare al canale fisico, ciascuna delle quali configurabile secondo le proprie necessità. Tra queste vi sono: lo spreading factor, pari al rapporto tra il chip rate all interfaccia radio (fissato dalla banda disponibile) e il bit rate d utente prima della moltiplicazione per il codice di canalizzazione; la codifica di canale -che utilizza codici FEC (Forward Error Correction) di tipo convoluzionale o turbo- per la quale differenti rate di codice sono configurabili sui canali fisici a partire da codici con rate base (1/2, 1/3) e da questi derivando codici con rate superiori (ad esempio 2/3) mediante operazioni di punctring (eliminazione di bit di ridondanza). Altre scelte lasciate agli implementatori sono: le politiche di admission control, le modalità di gestione delle risorse radio (scheduling a livello MAC) e soprattutto la scelta dei canali per la trasmissione dei dati e per il controllo di particolari tipi di servizi. L utilizzo di un appropriato strumento software che valuti le prestazioni dei servizi dati a pacchetto sull interfaccia radio UMTS permette di ottenere dei criteri guida per la definizione di tali servizi: con esso è possibile analizzare l incidenza dei vari parametri sulla capacità del sistema ed ottimizzare la qualità della trasmissione. Potranno trarre vantaggio da questo tipo di analisi prestazionale tutte le parti attive al progetto UMTS: i costruttori, per quel che riguarda le implementazioni dei software degli apparati; gli operatori, per poter definire in maniera chiara le strategie di gestione; gli sviluppatori delle nuove applicazioni, che inevitabilmente si baseranno sui servizi di trasmissione analizzati. 2. Il metodo streaming Con il termine streaming si fa riferimento ad un insieme di tecnologie che consentono il trasferimento di dati in rete in modo tale che la riproduzione dei file può iniziare prima ancora che gli stessi siano trasmessi e ricevuti nella loro interezza. Tra le soluzioni attualmente disponibili, il metodo streaming rappresenta la soluzione sicuramente più adatta per la diffusione in rete di contenuti multimediali: la riproduzione può iniziare immediatamente dopo l instaurazione della connessione, mentre la ricezione della parte restante dell informazione avviene simultaneamente, in background. Questa tecnologia ha fornito un grosso impulso alla diffusione in rete di contenuti multimediali, poiché risolve in maniera brillante i problemi tipici delle precedenti metodologie di trasferimento, basate essenzialmente sul principio del download and play. Secondo questa principio, largamente adottato nel web-browsing, per consentire al browser la visualizzazione dei contenuti multimediali di una pagina web bisogna attendere la ricezione completa del file che li contiene, il che comporta la sua completa memorizzazione nell area cache dell hard disk (Figura 2). FILE Buffer Pacchetti video file Esecuzione dopo il download VIDEO SERVER VIDEO Figura 2. Modello download and play 5

6 Questo è ovviamente un grosso limite applicativo, sia perché l informazione visiva e sonora tende ad essere molto esosa in termini di occupazione di memoria, sia perché i tempi di attesa legati al download sono tipicamente molto lunghi. Il dover creare una copia dei contenuti scaricati crea inoltre problemi di copyryght. Con il metodo streaming, invece, i file vengono suddivisi in pacchetti di misura appropriata alla banda disponibile tra client e server. Quando il client ha ricevuto un certo numero di pacchetti, il software d utente può, contemporaneamente, visualizzare un pacchetto, decomprimerne un altro e riceverne un terzo. La visualizzazione dei contenuti del file può quindi avvenire in tempo reale, man mano che i dati stessi vengono ricevuti (Figura 3). FILE Buffer Pacchetti Video Esecuzione Real-Time VIDEO SERVER VIDEO PLAYER (CLIENT) Figura 3. Modello streaming La contemporaneità delle operazioni a carico dell applicazione client richiede l utilizzo di software capaci di fornire il multithreading, cioè quella funzionalità secondo la quale un programma può essere separato in sezioni indipendenti, threads, ciascuna delle quali, pur essendo caratterizzata da un flusso sequenziale di controllo proprio, può essere eseguita contemporaneamente ed indipendentemente dalle altre. Porzioni del codice vengono attivate al verificarsi di particolari eventi, senza abbattere per questo il resto del programma. La funzionalità di multitasking, invece, consente l elaborazione contemporanea di più processi, effettuando una condivisione delle risorse di calcolo, e cioè assegnando a ciascuno di essi tutte le risorse per un dato intervallo di tempo. Tipicamente il multithreading è una caratteristica offerta dai linguaggi orientati ad oggetti, quali ad esempio java. Per questo motivo, per la realizzazione di applicazioni di streaming su dispositivi wireless, si prevede un massiccio utilizzo della tecnologia KVM (K Virtual Machine) proposta da Sun. La KVM è una java virtual machine compatta e portatile, pensata per dispositivi con ridotte capacità computazionali, come ad esempio telefoni cellulari, pagers, personal organizer e mobile internet devices. Essa consente di avere le principali funzionalità della programmazione java, pur disponendo di pochissima memoria. In particolare, il core della KVM richiede una memoria statica compresa in un range tra 40 e 80 Kbytes. In termini di capacità trasmissive, per ottenere una riproduzione di qualità accettabile è necessario disporre di una banda passante sufficientemente ampia e relativamente costante. Se il traffico in rete risulta congestionato si determinano delle momentanee interruzioni nella riproduzione, che vengono però limitate da un congruo spazio di buffer. Più precisamente, la presenza di buffer di ricezione è necessaria per risolvere il problema del jitter. Anche in assenza di congestione, infatti, le reti fisse, poiché adottano politiche di trasmissione a commutazione di pacchetto di tipo datagram, instradano ciascun pacchetto in maniera indipendente, con conseguenti variazioni significative nel tempo di transito. In altri termini, le reti attuali sono tipicamente sincrone, cioè nella migliore delle ipotesi garantiscono la consegna dei pacchetti con un ritardo variabile entro un dato intervallo. Le applicazioni real time necessitano, invece, di un servizio di trasmissione isocrono, vale a dire caratterizzato da ritardi di consegna costanti. La variazione del ritardo di consegna viene chiamata jitter e questo causa delle inaccettabili discontinuità nella riproduzione dei contenuti multimediali. La presenza di buffer di ricezione (playout), congiuntamente all utilizzo di protocolli come l RTP - che include per ciascun pacchetto informazioni temporali (time stamp) e numero di sequenza - consente la corretta ricostruzione dei flussi e l eliminazione del jitter (Figura 4). Il flusso sincrono di arrivo viene facilmente convertito dall applicazione client in un flusso isocrono direttamente visualizzabile. Tuttavia se i terminali riceventi hanno limitate capacità di bufferizzazione si possono verificare overflow dei buffer, con conseguente perdita di alcuni pacchetti ed impoverimento della qualità di visualizzazione. 6

7 Jitter < 0 Jitter = 0 Flusso sincrono di pacchetti (ritardo variabile entro un dato intervallo) Playout Buffer Flusso isocrono di pacchetti (ritardo costante) Figura 4. Modello per l eliminazione del jitter 3. Streaming Media nell UMTS La Figura 5 mostra il modello logico proposto dalla 3GPP per l UMTS. Sono stati individuati tre principali domini, ciascuno dei quali interagirà con quelli adiacenti allo scopo di fornire all utente finale una serie di prestazioni innovative rispetto allo scenario attuale. Le applicazioni, implementabili nel dominio dei terminali e delle applicazioni, potranno sfruttare contemporaneamente differenti servizi forniti dal dominio sottostante, riuscendo così a fornire prodotti multimediali su terminali mobili. E quindi evidente il ruolo di primaria importanza che lo streaming su UMTS giocherà nella realizzazione di queste nuove applicazioni, nonchè nelle applicazioni già presenti su internet, quali video/audio-on-demand, teleconference (video e audio), broadcasting (web-tv e web-radio), information-push, multiparty games, alle quali la mobilità fornirà un notevole valore aggiunto, realizzando una maggiore connettività, intesa come possibilità di essere sempre on-line. Con l ausilio dei nuovi sistemi di localizzazione previsti per l UMTS, inoltre, i confini del real-time streaming si allargheranno notevolmente. Basti pensare a possibili applicazioni quali: telesorveglianza in movimento (ad esempio: portavalori), telemonitoring su autoambulanze, travel e road traffic assistance, ecc. La 3GPP -nelle Tecnical Specification e della Release 4- fornisce una panoramica generale delle architetture, dei protocolli e dei codec previsti per la 3G PSS (3 rd Generation Packetswitched Streaming Service). USER MAN MACHINE INTERFACE Terminal Application Domain Basic UMTS Terminal Features and Services Domain APPLICATIONS SERVICES sms audio video data Basic UMTS Control and Transport NETWORK CAPABILITIES SERVICE CAPABILITIES BEARER CAPABILITIES Figura 5. Differenziazione tra servizi e applicazioni nei terminali mobili Source 3GPP 7

8 Lo scenario architetturale previsto è rappresentato in Figura 6. Streaming Client Content Server utran UMTS Core Network IP Network utran Streaming Client User and terminal profiles Portals Figura 6: Architettura generale per la 3G PSS Source: 3GPP TS V1.00 lo Streaming Client è l entità che richiede il servizio di streaming (tipicamente un contenuto audio e/o video). Esso risiede nell UE (User Equipment), che comprende il terminale fisico usato dall utente della PLMN (Public Land Mobile Network) ed il modulo di identità USIM (UMTS Subscriver Identity Module). Il contenuto richiesto è tipicamente memorizzato o direttamente catturato dal Content Server, che può essere situato in qualsiasi punto della rete Internet. la UMTS Core Network è costituita da tutte quelle entità fisiche che forniscono funzioni di rete e servizi di telecomunicazione, compresi aspetti quali la gestione della localizzazione e dell identificazione degli utenti, le capacità di commutazione ed instradamento, la gestione generale della mobilità. la UTRAN (UMTS Terrestrial Radio Access Network) è invece composta da tutte quelle entità che gestiscono l accesso delle comunicazioni d utente alle risorse della Core Network ed include tutte le infrastrutture necessarie per l accesso radio cellulare. i blocchi tratteggiati sono elementi utilizzabili per fornire servizi supplementari finalizzati al miglioramento della globalità del servizio. In particolare, i Portals, sono dei server che consentono un conveniente accesso ai contenuti disponibili, ad esempio possono offrire content browse e meccanismi per facilitare la ricerca. I Terminal Profile Server possono essere usati per memorizzare capacità e preferenze dei terminali. Questo tipo di informazione può risultare molto utile per il controllo della presentazione di un media ad un utente mobile. I componenti funzionali previsti per la 3GPP PSS sono schematizzati in Figura 7. Il servizio streaming su UMTS necessita, oltre che di terminali mobili dotati di display grafici e di dispositivi di output per il suono, dei seguenti meccanismi di controllo: Presentation Control: meccanismo necessario per specificare l interfaccia di layout dell utente, per definire l insieme di media su cui si baserà l applicazione multimediale e per sincronizzare gli stessi. Capability Exchange: meccanismo attraverso il quale poter adattare il media stream alle caratteristiche computazionali del terminale che lo richiede. Probabilmente tale metodo sarà 8

9 implementato dai costruttori in modo tale da essere automatico, quindi trasparente per l utente finale. Session set-up and control: funzionalità necessarie rispettivamente per caratterizzare e controllare una sessione di streaming tra client e server. Ad esempio sono inclusi in tali funzionalità i comandi di controllo remoto: play, pause, fast forward, rewind e stop. Session Establishement: cioè i metodi per richiedere lo streaming media, da un browser o da un qualunque altro sito abilitato alla funzione di streaming server, ed instaurare una sessione. Source: 3GPP TS V1.00 Figura 7. Componenti funzionali della 3GPP packet switched mobile streaming. 4. Protocolli per lo Streaming Media su UMTS I protocolli raccomandati dalla 3GPP per la realizzazione dei componenti di controllo descritti sono quelli che, fra gli attualmente disponibili, meglio si prestano al trasporto e al controllo di traffico realtime e multicast richiesti dalla tecnologia streaming. In particolare, sono previsti i seguenti protocolli: 1. Real-time Transport Protocol (RTP), per il trasporto dei pacchetti contenenti i dati; 2. Real-Time Control Protocol (RTCP), per il trasporto dei pacchetti di controllo a livello di trasporto; 3. Real-Time Streaming Protocol (RTSP), per il trasporto delle informazioni di controllo a livello di applicazione; 9

10 4. Session Description Protocol (SDP), come formato per la presentation description sia per il server che per il client. E previsto inoltre sia l uso del Transport Control Protocol (TCP) che del User Datagram Protocol (UDP), entrambi appoggiati sull Internet Protocol (IP). I protocolli RTP, RTCP, RTSP e SDP non forniscono tutte le funzionalità tipiche dei protocolli di trasporto, quindi vengono associati al TCP o all UDP per utilizzare le loro funzionalità di multiplexing e checksum. In pratica, i pacchetti RTP e RTCP vengono incapsulati in pacchetti UDP, mentre i pacchetti SDP e RTSP vengono incapsulati in pacchetti TCP. Questa distinzione è resa necessaria dal fatto che certamente l UDP è più adatto alle caratteristiche di trasporto dei dati e del controllo a livello di trasporto delle applicazioni real-time e multicast. Mentre il TCP, progettato per il trasporto di traffico senza particolari necessità nel ritardo di consegna, si presta bene al trasporto dei pacchetti di controllo di applicazione, che contengono i comandi remoti e le presentation description. In termini di affidabilità il TCP è sicuramente superiore rispetto all UDP, in quanto presenta una serie di sofisticati meccanismi per la correzione degli errori e la prevenzione delle perdite. Se però si tiene conto che la maggior parte degli algoritmi di playback tollera meglio la mancanza di alcuni dati, rispetto ai lunghi ritardi tipici della ritrasmissione, causa di inaccettabili discontinuità nella riproduzione di un media, l UDP risulta certamente preferibile per le applicazioni real-time. Inoltre, lo slow-start, conseguente dal meccanismo che il TCP utilizza per il controllo della congestione, potrebbe interferire con il notevole rate necessario per l esecuzione di un audio/video. Per quanto riguarda il multicast, infine, il TCP, impiegando più risorse del sistema operativo rispetto all UDP, è meno adatto di quest ultimo per tutte quelle applicazioni in cui il server deve manipolare simultaneamente più client. Nei paragrafi successivi viene riportata una panoramica generale delle caratteristiche principali dei protocolli RTP, RTCP, RTSP, e SDP. 4.1 Real-time Transport Protocol (RTP) L RTP è un protocollo che fornisce, attraverso servizi unicast o multicast, funzioni di trasporto end-toend per applicazioni real-time. Le trasmissioni sono controllate dal protocollo integrato RTCP, che consente, attraverso un feedback periodico, un valido monitoring circa la qualità del servizio di trasporto. Il protocollo RTP non esegue indirizzamento o resource reservation, quindi non fornisce nessun meccanismo per assicurare i parametri di QoS delle applicazioni di cui trasporta le informazioni. Per tale scopo esso viene spesso supportato da altri protocolli come il RSVP (Resource ReSerVation Protocol). Spesso il protocollo RTP è integrato con il processamento delle applicazioni piuttosto che essere implementato in un livello separato. Esso è deliberatamente non completo e consente espansioni e modifiche per particolari applicazioni. Per questo motivo ogni versione utilizzata deve essere corredata da un documento di specifica del profilo, che definisce il set di tipi di payload e codec utilizzati ed il mapping dei loro formati (ad esempio la codifica dei vari media). Il profilo definisce anche le estensioni e le modifiche apportate per supportare particolari classi di applicazioni. Differenti applicazioni per Internet sono già state implementate e sono disponibili in letteratura. Queste applicazioni includono trasmissioni di audio e video e sono corredate da appositi tool per la diagnostica ed il monitoring. E opportuno sottolineare che ogni qual volta si procede nella definizione di una nuova implementazione bisogna tenere conto delle limitazioni in termini di banda del sistema a cui l implementazione stessa è destinata. Questo è di fondamentale importanza per limitare l impatto della high-bandwidth che tipicamente caratterizza le applicazioni multimediali. Per settare una sessione RTP, l applicazione definisce un particolare indirizzo di trasporto costituito da un indirizzo di rete (ad esempio un indirizzo IP) ed una coppia di porte UDP (una porta rappresenta un astrazione che i protocolli di trasporto utilizzano per distinguere differenti destinazioni all interno di un stesso host computer), rispettivamente per RTP e RTCP. In una sessione multimediale ogni media è trasportato in una sessione separata, il cui indirizzo di trasporto sarà costituito dal medesimo indirizzo di rete ma da differenti coppie di porte su cui convogliare i flussi di 10

11 pacchetti RTP e RTCP. In un applicazione di videoconferenza, ad esempio, audio e video sono codificati in maniera differente e trasportati tramite due diverse sessioni RTP. Questa differenziazione fornisce maggiore flessibilità al protocollo RTP, consentendo implementazioni sia per il processamento singolo che per il processamento multiplo. La sincronizzazione dei vari stream di cui una sessione multimediale è composta, è a carico dell applicazione e viene effettuata sulla base delle informazioni temporali riportate sia sui pacchetti RTP che su quelli RTCP. Il pacchetto RTP è composto da un header che contiene tutte le informazioni necessarie per la corretta manipolazione del pacchetto stesso, seguito da un payload che invece contiene i dati che devono essere trasferiti. L header di ciascun pacchetto RTP (Figura 8) contiene una serie di informazioni di fondamentale importanza per la sincronizzazione e la visualizzazione di contenuti multimediali, nonchè per la determinazione di eventuali pacchetti fuori ordine. In appendice A è riportata una descrizione dettagliata del significato dei vari campi dell header dei pacchetti RTP. Figura 8: formato dell Header dei pacchetti RTP 4.2 Real-time Transport Control Protocol (RTCP) Il protocollo RTCP lavora congiuntamente al protocollo RTP e fornisce una serie di importanti servizi di controllo a livello di trasporto, per applicazioni real-time multicast e/o unicast. La funzione principale del protocollo RTCP è quella di fornire un feedback circa la qualità della distribuzione dei dati. Il protocollo RTCP è basato sulla trasmissione periodica di pacchetti di controllo da parte di tutti i partecipanti ad una sessione, ed usa i medesimi meccanismi di distribuzione dei pacchetti dati. In pratica, ogni ricevente di uno stream RTP fornisce periodicamente alla sorgente, attraverso appositi pacchetti RTCP, una serie di riscontri circa la qualità di ricezione. Ciascun pacchetto di report contiene delle statistiche che permettono di determinare importanti informazioni come il tasso di perdita, la distribuzione dei ritardi di consegna, ecc. Tali informazioni costituiscono le basi per un controllo della congestione. In particolare, dall analisi dei report delle stazioni riceventi, nei casi in cui vi sono gli estremi dell insorgere di congestione, le sorgenti possono modificare il rate di trasmissione ed eventualmente il tipo di codifica, evitando che la congestione diventi persistente. Inoltre, poiché è previsto che i pacchetti di controllo RTCP possano essere monitorati anche da terze parti, quali ad esempio i network manager, l uso dell RTCP rappresenta uno strumento ausiliare per la valutazione delle performance di rete per la distribuzione multicast. Un altra funzione molto importante del protocollo RTCP consiste nell identificazione delle sorgenti RTP. Ogni pacchetto RTCP contiene infatti un identificatore a livello di trasporto, detto Canonical Name (CNAME). Tale identificatore è di fondamentale importanza per tenere traccia di tutti i partecipanti ad una sessione RTP. I ricevitori usano il CNAME per associare gli stream multipli di dati provenienti da un dato partecipante in un set di relative sessioni RTP, potendo così sincronizzare i vari media. Ancora, poiché il protocollo RTP è stato progettato allo scopo di supportare anche applicazioni multicast, esso garantisce la possibilità di scalare automaticamente l ammontare dei dati trasmessi in relazione al numero di partecipanti ad una data sessione. Più precisamente, per ogni sessione il traffico emesso è soggetto ad un limite aggregato chiamato session bandwidth, che deve essere suddiviso tra tutti i partecipanti alla sessione. Il traffico dati di applicazioni multicast è relativamente autolimitante (nel senso che tipicamente è raro che in una conferenza più di due interlocutori parlino contemporaneamente): su un dato link può quindi 11

12 essere facilmente mantenuto costante, a prescindere dal numero di partecipanti. Viceversa, il traffico di controllo cresce proporzionalmente al numero di partecipanti e potrebbe quindi facilmente generare problemi di band enforcement. Per limitare questo problema il protocollo RTCP applica delle politiche di controllo sul traffico emesso calcolando con appositi algoritmi gli inter-tempi di trasmissione dei pacchetti di report, in modo da poter scalare il rate di traffico emesso e suddividere la session bandwidth, in base al numero di partecipanti. In linea generale il traffico RTCP è soggetto alle seguenti limitazioni: non può coprire più del 5 % della quota di dati utili. Ogni partecipante può fissare la sua quota corrispondente in base alla conoscenza del numero complessivo dei partecipanti e della quota di dati utili; l inter-tempo d arrivo medio del pacchetto RTCP deve essere almeno di 5 secondi; il 25% del traffico RTCP spetta al Sender. Comunque gli algoritmi per il calcolo del tempo di trasmissione dei pacchetti RTCP tengono conto di particolari situazioni che richiedono una certa urgenza nella ricezione delle informazioni di riscontro, come ad esempio durante le fasi di set-up di nuove sessioni. Per implementare le funzioni descritte, il protocollo RTCP prevede l uso di cinque differenti tipi di pacchetti, ognuno dei quali è comunque preceduto da un header standard comune e molto simile all header dei pacchetti RTP: SR: Sender Report, utilizzati da tutti i partecipanti ad una sessione, che trasmettono e/o ricevono flussi di dati, per il report delle statistiche di trasmissione e ricezione. RR: Receiver Report, aventi la funzione di trasportare le informazioni di riscontro sulla ricezione, trasmesse da tutti i partecipanti alla sessione che si limitano a ricevere flussi di dati. SDES: Source Description, contenenti tutte le informazioni necessarie alla corretta identificazione delle sorgenti RTP, incluso il CNAME. BYE, pacchetti attraverso cui si notifica a tutti i partecipanti l uscita di scena di uno di essi. APP: Application, intesi come pacchetti per usi sperimentali, o per particolari tipi di applicazioni che richiedono funzionalità di controllo non-standard. Tramite essi si trasportano dati dipendenti dalla specifica applicazione. Analogamente al caso del protocollo RTP, più pacchetti RTCP, anche di diverso tipo, possono essere composti ed incapsulati in un pacchetto UDP. Per massimizzare la risoluzione delle statistiche, ogni pacchetto composto, periodicamente trasmesso in accordo alle costrizioni della session bandwidth, deve contenere al suo interno almeno un pacchetto SR o RR. Ciascun pacchetto di report è caratterizzato (Figura 9) da: un header contenente una serie di informazioni generali sulle caratteristiche del pacchetto; un blocco, presente solo nei pacchetti SR, contenente le informazioni su quanto trasmesso dalla sorgente; un certo numero di blocchi di report, ciascuno dei quali relativo ad un particolare flusso ricevuto; un blocco contenente informazioni circa eventuali estensioni apportate al protocollo allo scopo di supportare particolari applicazioni. In appendice B è riportata una descrizione dettagliata del significato dei vari campi dell header dei pacchetti SR RTCP. 12

13 V=2 P PT=SR=200 lenght Fraction lost SSRC of sender NTP timestamp, most significant word NTP timestamp, least significant word RTP timestamp Sender's packet count Sender's octet count SSRC _1 (SSRC of first source) cumulative number of packet lost Extented highest sequence number received interarrival jitter Last SR (LSR) Delay since last SR (DLSR) SSRC_2 (SSRC od second source)... profile-specific extension Figura 9. formato dei pacchetti Sender Report RTCP header sender info report block 1 report block Real-time Streaming Protocol (RTSP) Il RTSP è un protocollo a livello di applicazione, progettato per controllare trasmissioni dati con caratteristiche real-time. La funzionalità principale del protocollo RTSP è quella di fornire il controllo remoto di rete per i server multimediali. In pratica esso definisce una serie di metodi, che devono essere implementati nel software del server e/o del client, aventi la funzione di consentire l allocazione e l uso delle risorse stream dei server. Tra i metodi principali vi sono: option - per il recupero dei parametri della presentazione; setup - indica al server di allocare le risorse e far partire una sessione RTSP; describe - recupera la descrizione di una presentazione o di un media, fornendola al client in un formato per lui comprensibile; play e record - fanno partire la trasmissione dei dati costituenti gli stream allocati con il setup Nel caso del record viene abilitata la registrazione dei dati trasmessi; pause - causa un temporaneo blocco delle trasmissioni, senza però determinare il rilascio delle risorse di rete e del server; redirect - nel caso di diffusione di contenuti distribuiti, connette il client con un altra locazione della rete; teardown - rilascia tutte le risorse impegnate dalla sessione. Una buona parte di questi metodi determina la necessità da parte del server di mantenere lo stato, a differenza dell HTTP che è stateless. In particolare, poiché il controllo RTSP viene tipicamente trasmesso attraverso il protocollo di trasporto connection-oriented TCP, mentre il trasporto dei dati avviene solitamente via UDP, il mantenimento dello stato da parte del server è necessario per poter correlare le richieste allo stream di dati. Il trasferimento dei dati continua infatti anche se il server non riceve esplicite richieste RTSP. Inoltre, durante il ciclo di vita di 13

14 una sessione il singolo stream di un media può essere controllato da richieste RTSP trasmesse sequenzialmente su differenti sessioni TCP e questo rafforza la necessità di una correlazione esplicita tra dati e controllo di applicazione. I vari metodi sono invocati e consegnano i risultati della loro esecuzione attraverso la trasmissione di messaggi che rappresentano l unità base della comunicazione RTSP. Essi consistono in una sequenza strutturata di ottetti secondo la sintassi: { method name} {URL} protocol version } CRLF {MIME header field } CRLF.. {optional body, length} Per tale motivo il protocollo RTSP viene definito text-based e questa sua caratteristica gli conferisce una buona estendibilità poiché risulta estremamente facile aggiungere parametri e funzionalità opzionali. La bassa frequenza di spedizione dei comandi contenuti nei messaggi lo rende inoltre decisamente efficiente in termini di processamento. Attraverso la spedizione dei messaggi, sia i client che i server possono effettuare richieste. In Figura 10 è rappresentata una tipica sessione RTSP. L apertura di una qualsiasi sessione RTSP inizia con un messaggio di OPTION, attraverso il quale il client richiede una lista dei metodi disponibili al server, che li elencherà nel messaggio di risposta. Stabiliti i metodi che possono essere evocati durante la sessione, segue l instaurazione vera e propria. Questa viene effettuata per il tramite di un messaggio di SETUP, che include un Transport-Header contenente tutte le informazioni di inizializzazione del trasporto, cioè tutti i parametri di trasporto accettabili dal client per la trasmissione. Il server può richiedere l autentificazione del client attraverso un messaggio (detto ID message) e controllando il messaggio di ID-RESP con cui il client risponderà. Tramite questi due messaggi il client ed il server possono negoziare il metodo di autentificazione, scegliendo tra i tanti supportati dal protocollo RTSP. Una volta settata la sessione, il client evoca, attraverso un apposito messaggio, il metodo DESCRIBE per ottenere una serie di dettagliate informazioni circa la presentazione che sta richiedendo. Come risposta il client otterrà un Presentation Description File, scritto in un apposito formato (ad esempio SDP) e contenente una descrizione dei media che compongono la presentazione, della loro codifica ed una serie di altri parametri atti ad una non ambigua caratterizzazione del materiale richiesto e dei formati per esso disponibili. In effetti il protocollo RTSP è neutrale rispetto al formato utilizzato per tale descrizione: l unica prescrizione che viene fatta è quella che una Presentation Description deve contenere almeno un RTSP URI. Inoltre, attraverso il metodo ANNOUNCE, la descrizione della presentazione può essere mandata in tempo-reale piuttosto che spedita per il tramite del Presentation Description File. Attraverso il messaggio OPTION, il client può negoziare una serie di opzioni per il trasferimento degli stream. Un ampia serie di informazioni possono essere scambiate tra client e server anche attraverso gli Header Field, che possono avere il significato di richieste, di risposte, o semplicemente il significato generale di contenitori per il trasporto di informazioni utili per il controllo. Vengono ad esempio trasmesse notizie relative ai bit rate tipici, le stime delle bandwidth disponibili al client, le lunghezze degli stream, i tipi di contenuti, le necessità di eventuali proxy, ecc. Dopo questa fase informativa, il client, tramite i messaggi di GET-PARAM e SET-PARAM, decide quali parametri, fra i disponibili, ritiene più adeguati alle sue capacità. A sua volta il server replica con un messaggio di PARAM- REPLY o PARAM-REFUSE, rispettivamente se può accettare o no le richieste. Infine, il server inizia a spedire dati solo dopo che riceve il messaggio di PLAY. Grazie al messaggio PLAY-RANGE esiste anche la possibilità di specificare quale range dello stream deve essere trasferito. Durante il trasferimento dei dati una serie di messaggi possono essere trasmessi per il controllo remoto della presentazione. Tra questi vi sono il PAUSE, il RECORD, che in accordo al presentation description file consente la registrazione di un dato range dello stream, e tutti i messaggi come FAST-FORWARD e REWIND che, nel caso di un media preregistrato, consentono di muoversi avanti e indietro nella registrazione come se questa fosse residente in locale. 14

15 Figura 10. Schematizzazione di una generica sessione RTSP In appendice C é riportato l esempio di una singola sessione di stream playback. Naturalmente, in questo documento non è possibile descrivere tutti i possibili messaggi e le funzionalità da essi attivabili. Per maggiori informazioni sul protocollo RTSP si rimanda al documento RFC 2326 della IETF. In linea generale si possono però riassumere le caratteristiche del protocollo RTSP affermando che esso fornisce, sia ai providers che agli utenti, i seguenti benefici: Pieno controllo bidirezionale sugli stream dati. Infatti, anche il controllo di stream multipli avviene su un unico asse temporale utilizzando il controllo aggregato. Questo significa che, ad esempio, audio e video, pur essendo trasportati indipendentemente l uno dall altro, possono essere controllati da parte del client attraverso l uso di un unico set di comandi remoti. La sincronizzazione dei vari stream è a carico delle applicazioni, sulla base delle informazioni trasmesse attraverso i messaggi RTSP. La completa controllabilità delle trasmissioni è realizzabile anche per applicazioni multi-server, in cui ciascun media costituente una presentazione risiede in un server differente. In tali casi il client automaticamente stabilisce una serie di sessioni di controllo con ciascuno dei server concorrenti. Alta affidabilità del trasporto attraverso le infrastrutture di rete. A tale proposito, oltre alla caratteristica di indipendenza dal trasporto (intesa nel senso che si ha possibilità di utilizzare il TCP, l UDP o un altro protocollo per il trasporto dei messaggi di controllo), sono previsti una serie di meccanismi attraverso i quali segnalare la non corretta ricezione di alcuni pacchetti e chiederne la ritrasmissione. Il server può inoltre segnalare al client la presenza di alcuni errori di trasmissione e, se lo ritiene necessario, interrompere la comunicazione a scopo cautelare. Infine, sono previste modalità operazionali di tipo sia unicast che multicast: per tali scopi ogni stream controllabile deve essere identificato da un appropriato URL di residenza, oltre che da un indirizzo di trasporto che identifichi la destinazione. Basso overhead per il trasferimento dei dati. La caratteristica di text-based prima descritta riduce al massimo gli overhead protocollari, snellendo il numero di campi a dimensione fissa che devono essere trasmessi. Sicurezza. 15

16 La presenza di procedure di identificazione che precedono l apertura di ogni sessione RTSP rende il protocollo sufficientemente sicuro nei confronti delle violazioni. Tale sicurezza viene amplificata dalla possibilita di crittografare i dati, offerta dal protocollo RTP a cui tipicamente il protocollo RTSP viene associato. Inoltre, tutti i meccanismi di protezione tipici dell HTTP sono utilizzabili anche dal RTSP. Per questa e per altre caratteristiche in comune al protocollo HTTP, il protocollo RTSP viene detto HTTP friendly e questo comporta una grande flessibilità nel riuso di molte delle infrastrutture già esistenti. Protezione dei diritti di proprietà intellettuali. Durante la fase di trasmissione delle presentation description, è possibile inviare una serie di informazioni riguardanti i diritti di diffusione dei particolari media. I metodi per la registrazione possono essere implementati e/o abilitati solo per la distribuzione di quei contenuti che non hanno limitazioni di copyrigth. Per i contenuti protetti da copyrigth, che potranno essere scaricati a pagamento, tutte le funzionalità di registrazione possono invece essere interdette. Piena negoziabilità delle applicazioni. Questa viene ottenuta sia attraverso la possibilità di negoziazione circa la capacità del client e del server, sia attraverso la possibilità di negoziare la modalità di trasporto. Più precisamente, attraverso la negoziazione delle capacità vengono resi noti quali metodi sono implementati e possono essere evocati, quindi si possono istanziare le risorse più appropriate alle capacità dell interfaccia utente e del server. Ad esempio, nel caso in cui il server non è nella possibilità di effettuare il posizionamento ad un punto preciso di un dato media (seeking), allora il client deve essere in grado di disabilitare tutti gli indicatori di posizione. Invece, attraverso la negoziazione della modalità di trasporto, si può scegliere quella che più si adatta alle caratteristiche del flusso che si deve controllare, oltre che adattare le trasmissioni a particolari esigenze legate alla presenza di proxy e firewall. Ad esempio, un firewall potrebbe essere capace di interpretare e far passare solo pacchetti UDP ed in tale caso l uso del TCP non sarebbe possibile. 4.4 Session Description Protocol (SDP) Il Session Description Protocol (SDP) rappresenta un valido strumento per la descrizione di sessioni multimediali con caratteristiche real-time. Il suo scopo fondamentale è quello di specificare all utente quali tipi di tool sono necessari per poter accedere ad una data presentazione multimediale. In particolare, l uso del SDP è limitato alla specifica delle modalità di accesso e del tipo di codifica dei media che si vogliono scaricare da un dato server. I contenuti informativi descritti per mezzo del formato SDP sono recuperabili direttamente, per mezzo del download tramite HTTP di un file che li contiene, o come replica di una richiesta di tipo DESCRIBE, se si usa il RTSP. Il SDP non è stato progettato per negoziare il tipo di codifica o le modalità di accesso, ma si limita all adempimento di funzioni informative, rappresentando essenzialmente un formato standard per la descrizione di sessioni multimediali. Ad esempio, il RTSP può utilizzare il SDP per la descrizione delle sessioni, ma effettua tutte le negoziazioni necessarie attraverso meccanismi propri. Il SDP è anche un valido strumento di supporto per le conferenze multimediali su Mbone, cioè su quella parte di Internet che supporta l IP Multicast, consentendo delle efficienti comunicazioni moltia-molti. In tale tipo di applicazioni il SDP si limita a fornire le Session Announcement e le Session Invitation, fornendo ai potenziali partecipanti le indicazioni circa gli indirizzi e i tool necessari per poter accedere ad una conferenza. In tale caso i file SDP di invito o di annuncio sono recapitati via o via WWW a tutti coloro che si vogliono informare circa l avvenimento della conferenza. Le SDP session description sono interamente testuali e consistono in una serie di linee dalla forma: <type>=<value> dove, il <type> è sempre una singola lettera che identifica il tipo di informazione che si sta fornendo con la specifica linea ed il <value> rappresenta una stringa testuale il cui formato dipende dal tipo. Una session description è strutturata su due livelli fondamentali, Session-level description e Media-level description, riportanti rispettivamente informazioni specifiche sulla sessione e sui media di cui quest ultima è composta. 16

17 Una più dettagliata descrizione delle sintassi e delle interpretazioni delle informazioni trasportate nelle session description SDP è riportata nel documento della IETF RFC La 3GPP, nel documento 3GPP TR V1.0.0, raccomanda l uso del SDP come formato per la descrizione delle sessioni e definisce quali informazioni sono richieste e quali sono opzionali (Figura 11). Type Description Requirements 3GGP Recommendations Session Description v Protocol Version R R o Owner/creator and session R R identifier s Session name R R i Session information O O u URI of description O O e address O O p Phone number O O c Connection Information O O b Bandwidth Information O R z Time Zone Adjustments O O k Encryption Key O O a Session Attributes O O Time Description t Time the session is active R R r Repeat times O O Media Description m Media name and transport address R R I Media title O O c Connection Information O O b Bandwidth Information O R k Encryption Key O O a Attribute Lines O O R = Required, O = Optional Source: 3GPP TS V1.00 Figura 11. Item del SDP previsti per le session description nell UMTS 5. Codec Con il termine Codec si intende la coppia codificatore/decodificatore con cui, in generale, possono essere trattate le informazioni digitali. Nel caso dello streaming media le codifiche sono prevalentemente relative alla necessità di comprimere quanto più possibile i dati che devono essere trasmessi, allo scopo di minimizzare la banda necessaria. Se la compressione è conveniente per qualsiasi tipologia di dati, diventa estremamente necessaria per la trasmissione di video, che altrimenti richiederebbe delle bande talmente ampie che neanche le più moderne tecnologie telecomunicazioniste sono in grado di fornire. In effetti la sola compressione non è sufficiente a consentire la trasmissione real time di filmati. Per raggiungere tale obiettivo si fa ricorso all uso congiunto dello Scaling, che consiste essenzialmente nello scalare le dimensioni della finestra in cui visualizzare il filmato. Così facendo si riducono notevolmente i tre parametri che principalmente concorrono nella determinazione del data rate necessario per la trasmissione del filmato e cioè il frame resolution, il frame rate ed il color depth. La compressione invece agisce sulla ridondanza che tipicamente caratterizza i video digitali. In linea di massima la compressione può avvenire riducendo la ridondanza all interno di uno stesso fotogramma, 17

18 in tal caso si parla di compressione intraframe, o riducendo la ridondanza tra fotogrammi adiacenti, come nel caso della compressione interframe. I moderni codec per la compressione, congiuntamente allo scaling, consentono una riduzione del data rate di un filmato tale da garantirne la trasmissione attraverso gli attuali modem. Al di là dei dettagli tecnici adottati dalle varie metodologie di compressione attualmente disponibili sul mercato, in questo documento si vuole concentrare l attenzione sugli standard di compressione raccomandati dalla 3GPP per lo streaming su UMTS, cercando di mettere in evidenza le caratteristiche principali che hanno determinato o che determineranno le scelte. In particolare, nel documento 3GPP TS , come video codec vengono raccomandati gli standard ITU-T-H.263 e MPEG-4, anche se è lasciata aperta la possibilità di utilizzare altri video codec opzionali. In generale, la scelta è strettamente vincolata all esigenza di adoperare codec decisamente robusti nei confronti del trattamento degli errori. Infatti, essendo il link radio tipicamente soggetto ad un alta incidenza di disturbi che causano errori sui dati trasferiti, i decoder che verranno utilizzati nell UMTS dovranno includere delle tecniche efficienti per nascondere gli errori dovuti alla trasmissione. Queste tecniche devono fornire la possibilità di sostituire le parti errate di un video frame con immagini interpolate da locazioni spazialmente differenti, all interno dello stesso frame o dai fotogrammi precedenti. In ogni caso i decodificatori devono essere in grado di tollerare qualsiasi bit-stream senza manifestare comportamenti catastrofici, come ad esempio il reset dei terminali. La scelta dei codec H.263 e MPEG-4 scaturisce dal fatto che queste due tecniche, fra l altro molto simili, oltre a garantire un efficiente rapporto di compressione, inglobano una serie di metodi di error resilence che le rendono particolarmente adatte all uso nell ambiente mobile. Per nascondere gli errori di trasmissione, il codec MPEG-4 utilizza i seguenti tool, appositamente progettati per garantire robustezza alle operazioni di decompressione: Resync Marker incrementa la possibilità del decodificatore di resincronizzare il bit-stream, garantendo la continuazione delle operazioni di decodifica anche quando, a causa di errori di trasmissione, si sia persa la sincronizzazione fra i dati. Tale funzionalità viene ottenuta inserendo, in fase di codifica, dei Resynk marker, che forniscono al decodificatore dei punti di riferimento supplementari rispetto allo Start Code generalmente utilizzato per le operazioni di sincronizzazione. Header Extension Code (HEC) abilita la decodifica indipendente di ciascun pacchetto video. Data Partitioning attraverso cui si possono distribuire le informazioni all interno di ciascun pacchetto per migliorare il grado di localizzazione degli errori e quindi la loro cancellazione. Sia i codici H.263 che MPEG-4 possono essere direttamente mappati su pacchetti RTP con una semplice modifica degli header di quest ultimi. Le specifiche per questo tipo di operazioni sono state publicate dalla IETF, rispettivamente nei documenti IETF RFC 2429 e IETF RFC La possibilità di mappare direttamente i bit-stream H.236 e MPEG-4 nel payload RTP consente di bypassare l utilizzo dei metodi di sincronizzazione e di stream management tipici dei codec, fornendo una grossa interoperabilità. Inoltre, entrambi i codec prevedono la possibilità del decoder di rispondere ad una serie di comandi detti TemporalSpatialTradeOff commands o VideoFastUpdate commands, che il decodificatore può inviare, facendo uso del protocollo H.245, per fornire un feedback molto utile per migliorare le performance nei confronti degli errori. Stando alla più recente letteratura che si occupa di streaming media, sembrerebbe che il codec MPEG- 4 sia favorito rispetto al H.263, sia perché tramite esso si può codificare anche l audio, sia perché presenta delle innovazioni tecnologiche molto interessanti, come la possibilità di trasmettere oggetti descritti da forme (shapes), testo e movimento, invece che i soliti frame rettangolari costituite da pixel. Questo abilita l interazione tra i vari media, rendendo il codec MPEG-4 sicuramente più adeguato agli scenari multimediali a cui tramite l UMTS si va incontro. 18

19 Appendice A. Applicazioni streaming nell UMTS 6. Appendice A Con riferimento alla Figura 8, in appendice vengono descritti i campi che compongono l header dei pacchetti RTP ed i loro significati. I primi dodici ottetti sono presenti in ogni pacchetto RTP, mentre i rimanenti dipendono dal particolare profilo utilizzato. Il significato dei campi rappresentati in Figura 8 è il seguente: Version (v): 2 bit Questo campo identifica la versione dell RTP. Il presente documento fa riferimento alla versione 2, la cui specifica è riportata nel documento rfc 1889 della IETF. Padding (p): 1 bit Se tale bit è settato ad 1, il pacchetto contiene uno o più ottetti di padding ( riempimento). Tali ottetti potrebbero essere necessari per alcuni tipi di algoritmi di crittografia utilizzati per la protezione dell informazione trasmessa. L ultimo ottetto del padding contiene un conteggio del numero di ottetti di padding utilizzati e che quindi devono essere ignorati. Extention (x): 1 bit Se il bit di estensione è settato, l header standard del pacchetto è seguito da un header addizionale, che specifica le modifiche apportate al protocollo per servire particolari tipi di applicazioni. Tale possibilità risulta essere molto importante soprattutto per le prospettive dell UMTS, per le quali si prevede la definizione di uno svariato numero di nuove applicazioni con caratteristiche decisamente insolite rispetto a quanto il mercato delle telecomunicazioni ha fino ad oggi proposto. CSRC Count (CC): 4 bit Tale campo specifica il numero di Contributing Source (CSRC) presenti nel pacchetto. Ogni CSRC rappresenta la sorgente di uno stream di pacchetti RTP. Ad esempio, in una audio conferenza più partecipanti possono parlare contemporaneamente. Ognuno di essi rappresenta una sorgente e lo stream combinato della loro contemporanea emissione viene effettuato a carico di un sistema intermediario, detto RTP mixer, il quale riceve i pacchetti RTP di ciascuna sorgente e genera un nuovo pacchetto rappresentante una combinazione degli ingressi. Poiché i differenti flussi in ingresso potrebbero non essere sincronizzati, il mixer si occupa anche di effettuare una nuova temporizzazione per il flusso di uscita. Inoltre, attraverso l uso dei mixer è possibile differenziare il formato, quindi la qualità delle trasmissioni, per i vari partecipanti ad una sessione RTP. Ad esempio, nei casi in cui alcuni partecipanti alla sessione sono localizzati in un area ad alta velocità ed altri partecipanti in un area a bassa velocità, piuttosto che forzare tutte le trasmissioni alle caratteristiche di bassa velocità d accesso, si può porre in prossimità delle aree più svantaggiate un mixer che riceve gli stream con le caratteristiche temporali tipiche dell accesso veloce e li riconverte, generando nuovi stream con differenti temporizzazioni, in flussi più adeguati ai link a bassa velocità. Marker (M): 1 bit Tale bit assume differenti significati a seconda del profilo utilizzato. In generale il suo uso è destinato a caratterizzare un pacchetto rispetto a tutti gli altri del flusso di appartenenza. Payload Type (PT): 7 bit Questo campo identifica il formato del payload del pacchetto e determina la sua interpretazione per le applicazioni. Il payload indica, ad esempio, il tipo di media di cui i dati fanno parte e la codifica (compressione) utilizzata. I possibili formati consentiti sono definiti nel profilo dell applicazione. Tipicamente, in un dato istante, si suppone che una sorgente RTP emetta pacchetti caratterizzati dal medesimo formato, anche se, allo scopo di poter adattare le trasmissioni alle condizioni della rete, durante la trasmissione sono consentite variazioni di tale formato. In altri termini, il protocollo RTP prevede la possibilità di effettuare codifica adattativa, che consiste nel modificare il tipo di compressione utilizzato in risposta al feedback fornito dai ricevitori attraverso i pacchetti di controllo RTCP. Sequence number : 16 bit 19

20 Appendice A. Applicazioni streaming nell UMTS E costituito da un contatore che viene incrementato dalla sorgente dello stream per ogni pacchetto inviato. Attraverso tale campo, l applicazione può determinare eventuali pacchetti persi e ricomporre la corretta sequenza, anche quando i pacchetti arrivano fuori ordine. Inoltre, grazie all indicazione fornita dal sequence number, l applicazione può decodificare il singolo pacchetto ricevuto anche se questo non è arrivato in sequenza, senza dover aspettare l arrivo dei precedenti. Timestamp: 32 bit Il timestamp riflette l istante di campionamento del primo ottetto del pacchetto RTP. L istante di campionamento viene derivato da un orologio che incrementa monotonicamente e linearmente, con una risoluzione adeguata, in modo tale da permettere la sincronizzazione ed il calcolo del jitter. Synchronisation source (SSRC) identifiers: 32 bit Identifica la sorgente dello stream di cui il pacchetto RTP trasporta i dati. Tipicamente una SSRC può essere un microfono, una telecamera o un RTP mixer. Tale identificatore è indipendente dall indirizzo di trasporto. Infatti, nel caso di una sessione a partecipazione multipla, ciascun partecipante viene identificato, a livello di trasporto, da un indirizzo (Transport address) costituito dalla combinazione di un indirizzo di rete e da una o più porte, a seconda del numero di media di cui è composta l applicazione, ma solamente chi emette flussi di dati possiederà un identificatore di SSRC. Contributing source (CSRC) identifiers: 32 bit Una lista contenente gli identificatori delle sorgenti che contribuiscono al payload del pacchetto. Il numero di contribuenti è riportato nel campo CC precedentemente descritto. Infine, è opportuno sottolineare che i pacchetti dati RTP non contengono nessuna indicazione sulla loro lunghezza. La massima dimensione di un pacchetto RTP è quindi definita dal protocollo di trasporto (tipicamente l UDP) che supporta le trasmissioni attraverso la rete. Inoltre, allo scopo di ridurre l overhead ciascun pacchetto UDP può trasportare diversi pacchetti RTP. 20