RETI MOBILI E MULTIMEDIALI

1. Università degli Studi di Roma “La Sapienza” Dipartimento INFOCOM RETI MOBILI E MULTIMEDIALI Aldo Roveri Lezioni dell’ a.a. 2009-2010 1

2. VII. Reti per la multimedialità Aldo Roveri, “RETI MOBILI E MULTIMEDIALI” Univ. di Roma “La Sapienza” - a.a. 2009-2010

3. CONTENUTI • VII.1 IP Multimedia Subsystem • VII.2 Correttivi sull’operatività di Internet • VII.3 Modalità di scheduling e di policing • VII.4 Servizi integrati e servizi differenziati • VII.5 Il ReservationProtocol

4. Reti per la multimedialità • VII.1 IP Multimedia Subsystem

5. IP Multimedia Subsystem • Una modalità per realizzare servizi multimediali in ambiente NGN con utenti fissi o mobili è l’impiego del IP Multimedia Subsystem (IMS). • Un IMS è un insieme di entità funzionali e di inter-facce della rete dorsale utilizzate da un fornitore di servizio di rete per offrire agli utenti servizi basati su SIP.

6. Impiego di SIP (1/2) • Tra i vari protocolli che esistono per il trasporto multimediale è stato scelto SIP, per la sua semplicità, estendibilità e disponibilità, unitamente agli ulteriori protocolli a questo correlati. • Lo scopo è quello di disporre di regole di dialogo (segnalazione) per l’instaurazione e la gestione della sessione.

7. Impiego di SIP (2/2) • Data questa scelta sono necessarie per la sua operatività le seguenti entità funzionali: • Componenti SIP; • Database di Utente; • Piattaforma di Servizio • Entità di Interlavoro

8. Componenti SIP • Le funzionalità chiave per questi componenti sono: • gli User Agents (UA); • i Proxy; • i Registrar. • Le funzionalità UA sono fornite dagli apparati fissi o mobili (IMS Terminals) che agiscono come punti-terminali; • le funzionalità Proxy/Registrar sono fornite dal Call Session Control Function (CSCF).

9. Database di Utente • È una funzionalità fornita in primo luogo dal Home Sub-scriber Server (HSS) che costituisce evoluzione dell’HLR e che contiene informazioni varie sull’utente abilitato al servizio. • L’HSS memorizza varie informazioni tra le quali • dati identificativi di utente; • profilo di servizio sottoscritto dall’utente; • informazioni per la gestione della sicurezza nell’accesso; • dati di localizzazione dell’utente. • L’SLF (Subscription Locator Function) fornisce al nodo richiedente (AS o CSCF) l’HSS di pertinenza di un deter-minato utente. • È necessario quando l’architettura prevede diversi HSS.

10. Piattaforma di Servizio • È una funzionalità chiamata anche Application Server (AS) e contiene la logica di esecuzione dei servizi. • In IMS vi sono più AS che offrono servizi a valore aggiunto; se ne distinguono tre tipi: • SIP Application Server (SIP AS): ospitano ed eseguono servizi IMS; • Open Service Architecture Service Capability Server (OSA-SCS): interfaccia verso l’OSA Framework Application Server per eseguire la logica del servizio; • IP Multimedia Service Switching Function (IM-SSF): è un’Application Server basato sul protocollo CAMEL.

11. Entità di Interlavoro (1/2) • Sono funzionalità necessarie per interoperare con altre reti quali, ad esempio, la rete telefonica. • Queste Entità sono: • Breakout Gateway Control Function (BGCF): sceglie la rete nella quale avviene il Breakout PSTN; • Media Gateway Control Function (MGCF): comunica con S-CSCF e con MGW; questo se-condo colloquio è utilizzato per instaurare una connessione bearer attraverso MGW;

12. Entità di Interlavoro (2/2) • Media Gateway Function (MGW): deve innanzitutto convertire i media da un formato a un altro; inoltre deve terminare i canali bearer dalla rete CS e gli stream mediali dalla rete a pacchetto; • Signalling Gateway Function (SGW): provvede a convertire la segnalazione a livello di trasporto tra il trasferimento basato sull’SS7 e quello basato su IP

13. CSCF • È una funzionalità che assume tre differenti tipi: • il Proxy-CSCF; • il Interrogating-CSCF; • il Serving-CSCF. • Le prime due funzionalità possono essere viste come SIP-Proxy, mentre la terza agisce come SIP-Registrar.

14. P-CSCF • È il primo punto di contatto per un UE all’interno di IMS; appartiene alla rete visitata o a quella casalinga; il primo caso riguarda l’UE in roaming. • È essenzialmente un server SIP-Proxy. • Ha i seguenti compiti principali: • inoltra la richiesta “SIP Register” ricevuta da un utente a un I-CSCF, individuato attraverso il nome del dominio di casa fornito dall’UE; • inoltra i messaggi SIP ricevuti dall’UE al S-CSCF; • inoltra all’UE i messaggi ricevuti dall’I-CSCF/S-CSCF; • mantiene una associazione di sicurezza con l’UE, come è necessario per una comunicazione sicura nella rete di accesso.

15. I-CSCF • È il primo e singolo punto di contatto con altre reti per tutte le sessioni destinate a un utente in casa o in roaming. • È essenzialmente un server SIP-Proxy. • Ha i seguenti compiti principali: • sceglie l’S-CSCF durante la procedura di registrazione; la scelta è effettuata tenendo conto delle potenzialità di servizio richieste per l’utente e le potenzialità offerte dai vari S-CSCF nella rete; • ottiene dall’HSS l’indirizzo dell’S-CSCF con il quale l’UE è registrato e inoltra la richiesta/risposta SIP all’appropriato S-CSCF.

16. S-CSCF • Fornisce all’UE i servizi di controllo di sessione. • Agisce come un SIP-Registrar. • Svolge le seguenti funzioni principali: • accetta richieste di registrazione dall’UE e fornisce questa informazione all’HSS; • interagisce con le piattaforme AS per supportarne i relativi servizi; • fornisce all’UE di origine vari servizi quali: • l’indirizzo dell’I-CSCF per la rete che serve l’UE di destinazione; • l’inoltro di richieste/risposte SIP per questo I-CSCF; • fornisce all’UE di destinazione vari servizi che consen-tono l’instaurazione di una sessione con l’UE di origine.

17. IMS: traffici di utente e di segnalazione (1/2) • Nella seguente Fig.VII.1 si suppone che l’utente sia in roaming e che il P-CSCF sia nella rete visitata; • nella rete casalinga il primo punto di contatto è l’I-CSCF, la cui localizzazione è ottenuta utilizzando il DNS e il nome del dominio di utente; • l’I-CSCF usa l’infomazione fornita dall’HSS per contattare l’S-CSCF; • l’S-CSCF, in associazione con la piattaforma di servizio fornisce i servizi IMS.

18. IMS: traffici di utente e di segnalazione (2/2) tratta da S. Kasera, N. Narang: 3G Mobile Networks, Mc Graw Hill, 2005 Fig.VII.1

19. IMS: struttura funzionale (1/4) • Nelle tre Figg. VII.2, VII.3 e VII.4 seguenti viene presentata la struttura funzionale di IMS. • Nella Fig. VII.2 si suppone che l’UE sia in roaming e che il P-CSCF appartenga alla rete visitata; • nella Fig. VII.5, si suppongono due accessi distinti con il coinvolgimento di due P-CSCF appartenenti alla rete casalinga; • infine, la Fig. VII.4 considera un’ulteriore rappre-sentazione della struttura funzionale di IMS.

20. IMS: struttura funzionale (2/4) tratta da S. Kasera, N. Narang: 3G Mobile Networks, Mc Graw Hill, 2005 Fig.VII.2

21. IMS: struttura funzionale (3/4) tratta da G. Camarillo, M. A. Garcia-Martin: The 3G IMS,Wiley, 2006 Fig.VII.3

22. IMS: struttura funzionale (4/4) Figura tratta da “IEEE_Communications Magazine”, October 2005 Fig.VII.4

23. Reti per la multimedialità • VII.2 Correttivi sull’operatività di Internet

24. Adeguamento della QoS • Per un superamento dei limiti di Internet a operare come supporto di servizi multimediali, occorre applicare alcuni criteri correttivi per conseguire una adeguata Qualità di Servizio (QoS).

25. Primo criterio • Un primo criterio parte dalla distinzione di classi di traffico e riguarda la possibilità per i router di distinguere i pacchetti in base alla classe di traffico di pertinenza. • Ciò può essere ottenuto con una marcatura dei pacchetti e con la definizione del modo in cui un router opera nei loro confronti tenendo conto della loro marcatura.

26. Secondo criterio (1/2) • Un secondo criterio alla base della fornitura di garanzie di QoS prevede che, in presenza di una molteplicità di flussi informativi legati a differenti o uguali classi di traffico, ciascun flusso, nell’utilizzazione di una risorsa (ad es. della capacità di trasferimento di un collegamento) sia isolato rispetto agli altri in modo che l’uno non subisca gli effetti negativi derivanti dal comportamento non conforme degli altri.

27. Secondo criterio (2/2) • Per applicare questo criterio si possono seguire due vie: • porre in atto un sistema di sorveglianza (policing) che assicuri il rispetto di quanto stabilito e, nel caso in cui questo rispetto non avvenga, intervenga in modo da penalizzare l’applicazione non conforme; • prevedere uno scadenzamento (scheduling) dei pacchetti in modo da assegnare a ogni flusso una porzione fissa della risorsa.

28. Terzo criterio • Un terzo criterio, direttamente collegato al conseguimento di elevata efficienza nell’utilizzazione delle risorse (ad es. di buffer e di larghezza di banda), consiste nel consentire tale utilizzazione nel modo più efficiente possibile anche in presenza di isolamento dei flussi. • Ad esempio, se a un flusso è stata attribuirà metà della larghezza di banda di un collegamento, occorre consentire in un certo momento a questo flusso di utilizzare l’intera larghezza di banda che fosse disponibile in quel momento.

29. Quarto criterio (1/2) • Per realizzare quanto previsto nei tre criteri precedenti occorre che ogni comunicazione indichi preventivamente quali sono i requisiti di servizio che le sono necessari al trasferimento del flusso ad essa pertinente; in base alla indicazione di questi requisiti, alla comunicazione potrà essere consentito o negato il suo accesso ai servizi di rete.

30. Quarto criterio • Secondo il quarto criterio è necessario un processo di ammissione della comunicazione durante il quale vengono confrontati i requisiti di servizio (QoS richiesta) con le risorse disponibili in quel dato momento: se la richiesta può essere soddisfatta la comunicazione potrà accedere alla rete, altrimenti il suo ingresso sarà negato.

31. Reti per la multimedialità • VII.3 Modalità di scheduling e di policing

32. Scheduling di un collegamento (1/2) • E’ la procedura con cui i pacchetti, appartenenti a diversi flussi e a differenti classi di traffico, sono selezionati nei buffer dei router prima di essere inoltrati sul collegamento. • Il modello di una procedura di scheduling è quello di un sistema a coda, in cui il servente è in corrispondenza modellistica con il collegamento, mentre l’ambiente di attesa (fila d’attesa) ha la struttura e la modalità di gestione connessa al tipo di procedura.

33. Scheduling di un collegamento (2/2) • In questa schematizzazione i pacchetti entrano nel sistema a coda e, dopo una eventuale sosta nella fila d’attesa e con un prelievo dipendente dalla modalità di gestione, vengono inoltrati verso il servente.

34. Modalità con priorità • Una prima modalità di selezione consiste nell’uso delle priorità ; i pacchetti, in relazione alla classe di traffico di pertinenza, sono prelevati dalla fila d’attesa e inoltrati verso il collegamento con un ordine che dipende dalla priorità attribuita ad ogni classe: cioè i pacchetti appartenenti a una classe di maggiore priorità sono scelti con un ordine prioritario rispetto a quelli di una classe con minore priorità; inoltre la scelta tra i pacchetti di una classe è effettuata secondo la strategia FIFO (First In – First Out).

35. Modalità round-robin • In una seconda modalità di selezione, i pacchetti appartenenti a differenti classi di traffico sono scelti con avvicendamento circolare . • La forma più semplice di questa modalità prevede l’alternanza dell’inoltro : prima viene scelto un pacchetto di classe 1, poi uno di classe successiva; se una classe non vede la presenza di pacchetti, si passa alla classe ancora successiva. • La semplice alternanza dell’inoltro non costituisce però una modalità di selezione basata su un ordine delle classi di traffico.

36. Modalità Weighted Fair Queuing (1/3) • Una selezione può essere introdotta con una alternanza basata su un accodamento equo poderato (Weighted Fair Queuing – WFQ). • In questa modalità a ogni classe di traffico è attribuito un peso: con riferimento alla classe i-esima, sia wi il valore del peso a questa attribuita.

37. Modalità Weighted Fair Queuing (2/3) • Il prelievo di un pacchetto dalla fila d’attesa e il conseguente inoltro verso il collegamento sono alternati in modo che al servizio di una classe segua quello della classe successiva, ma con una variante: con riferimento ai pacchetti della classe i-esima, a questi è garantita una frazione di servizio uguale a wi / Σwj , ove a denominatore si indica la somma dei pesi di tutte le classi che hanno pacchetti da inoltrare.

38. Modalità Weighted Fair Queuing (3/3) • Conseguentemente anche nel caso peggiore (quando tutte le classi hanno pacchetti accodati), la classe i-esima ha la garanzia di ricevere una certa frazione della capacità C del collegamento; tale frazione è almeno uguale a C wi / Σwj .

39. Policing (1/5) • E’ una procedura basilare per il conseguimento di una adeguata QoS in una infrastruttura (come Internet) operante a pacchetto; è preposta a controllare il ritmo con cui i pacchetti sono immessi nella rete. • Oggetti del controllo possono essere in alternativa o in unione:

40. Policing (2/5) • il ritmo medio, e cioè il numero medio di pacchetti che possono essere immessi in rete in un dato intervallo di tempo a lungo termine; • il ritmo di picco, e cioè il numero massimo di pacchetti che possono essere inviati in un breve intervallo di tempo; • la durata di una raffica, e cioè la durata massima di una emissione di pacchetti consecutivi.

41. Policing (3/5) • Per monitorare il rispetto dei limiti imposto ad un flusso di pacchetti si può ricorrere ad un meccanismo di policing chiamatotokenbucket. • Un tokenbucket è un modello costituito da un recipiente in grado di contenere fino a B gettoni (token). • I gettoni sono generati a ritmo di G gettoni/s e quindi, se possibile, immessi nel recipiente. • Se il recipiente contiene un numero di gettoni inferiore a B allora un nuovo gettone può essere aggiunto agli altri, altrimenti viene scartato.

42. Policing (4/5) • L’impiego del tokenbucket come mezzo per una procedura di policy può essere così chiarito. • Supponiamo che, per essere immesso nella rete, il pacchetto debba prelevare un gettone dal recipiente. • Se il recipiente è vuoto, si pongono due alternative: il pacchetto aspetta un nuovo gettone oppure viene scartato; escludendo per semplicità questa seconda alternativa, la massima durata di una raffica è di B pacchetti.

43. Policing (5/5) • Inoltre, il massimo numero di pacchetti che possono essere emessi in un intervallo temporale di durata T è uguale a G T + B; quindi il ritmo G serve a limitare il ritmo medio a lungo termine con cui i pacchetti possono essere immessi nella rete. • Mettendo in serie due tokenbucket è anche possibile controllare il ritmo di picco

44. Ritardo massimo in una coda (1/3) • Consideriamo il collegamento in uscita da un router che instrada N flussi tra cui l’i-esimo è sorvegliato da un tokenbucket con parametri Bi ,Gi (i =1,2, ...., N); assumiamo che ciascun flusso sia scadenzato con un meccanismo WFQ. • Vogliamo determinare il ritardo massimo subito da un pacchetto mentre è in attesa del servizio WFQ e dopo aver superato il controllo del tokenbucket.

45. Ritardo massimo in una coda (2/3) • Supponiamo che il recipiente del flusso 1 sia inizialmente pieno e che arrivi una raffica di B1 pacchetti; questi rimuovono tutti i gettoni del recipiente e poi si uniscono nell’area di attesa della WFQ riservata al flusso 1. • D’altra parte i B1 pacchetti della raffica sono serviti a un ritmo almeno uguale a Cw1/Σwj; conseguentemente l’ultimo pacchetto della raffica accumulerà un ritardo complessivo massimo che è dato da DMAX = B1/( Cw1/Σwj ).

46. Ritardo massimo in una coda (3/3) • Quindi in presenza di B1 pacchetti serviti a un ritmo almeno uguale a Cw1/Σwjpacchetti/s, il tempo necessario per emettere l’ultimo bit dell’ultimo pacchetto non può superare il valore espresso da DMAX .

47. Reti per la multimedialità • VII.4 Servizi integrati e servizi differenziati

48. Inteserv e Diffserv • Visti i principi e i meccanismi utilizzati per fornire QoS in Internet, vengono qui presentate due architetture che incorporano questi accorgimenti. • Si allude alle architetture Intserv (IntegratedServices) e Diffserv (DifferentiatedServices), che, pur non avendo avuto una larga diffusione, rappresentano gli attuali standard IETF per formire garanzie di QoS.

49. Intserv (1/3) • E’ un modello progettato per lo strato IP e basato su flussi : questi sono, per ogni sessione, una sorta di circuito virtuale dall’origine alla destinazione. • Le caratteristiche basilari dell’architettura Intserv sono le seguenti:

50. Intserv (2/3) • i router devono conoscere la quantità di risorse (buffer e larghezze di banda) riservata alle sessioni in corso di svolgimento; • la sessione che richiede garanzie di QoS deve preliminarmente prenotare le risorse necessarie per assicurarsi che i requisiti di cui necessita possono essere soddisfatti dai router collocati sul percorso tra sorgente e destinazione.