ITMI20131081A1 - Radio access network control of media session - Google Patents

Description

Rete ad accesso radio - Controllo di sessioni mediali

Descrizione

Campo tecnico

La presente invenzione è relativa ad un metodo e ad un componente di rete per controllare sessioni mediali (“media session” NdT) che si stabiliscono tra un utente e una rete IP tramite un core network.

Tecnica di base

Sistemi di comunicazione wireless sono ampiamente utilizzati per fornire vari tipi di contenuti di comunicazione quali voce, dati, ecc. Questi sistemi possono essere sistemi di accesso multiplo in grado di supportare la comunicazione con più utenti attraverso la condivisione delle risorse disponibili (ad esempio larghezza di banda e potenza trasmessa).

La priorità di rete è un modo per ottenere la gestione della larghezza di banda della rete ed il controllo per dati, video e traffico voce. Questo tipo di gestione è denominato Quality of Service (QoS) ed è controllato tramite i processi di rete basati su regole. Quality of Service comprende requisiti su tutti gli aspetti di una connessione, come il tempo di risposta di servizio, perdite di frame, rapporto segnale-rumore, diafonia, eco, interruzioni, risposta in frequenza, livelli sonori, e così via. Nella rete basata su regole (anche policy) per una rete basata sul protocollo Internet (Internet Protocol, IP), viene denominata policy un insieme formale di affermazioni che definiscono le modalità di controllo e di elaborazione delle comunicazioni e l’allocazione delle risorse tra gli apparati connessi (o clienti), ossia gli utilizzatori della rete IP. In una rete basata su policy, l’amministratore utilizza regole al fine di definire un particolare livello di priorità ed elaborazione di comunicazione per ciascuno dei tipi di servizi in base a parametri definiti.

In generale, le policy possono essere caratterizzate dalla specificazione e dall’imposizione da parte di vari soggetti della rete. Le regole possono essere configurate staticamente o dinamicamente aggiornate; specificate dagli utenti finali, operatori di rete o fornitori di servizi; e possono essere considerate come linee guida o regole ben definite a seconda delle particolari esigenze di applicazione della policy.

Una volta che un utente è connesso alla rete, le reti mobili cellulari convenzionali comprendono un Controllore di policy e costi (Plocy Control and Charging o PCC), funzionalità che identifica i pacchetti che vengono inviati o ricevuti ed esegue azioni in base ad un set di regole definite nella policy (ad esempio consegnare il pacchetto, scartare il pacchetto, assegnare il costo). Il PCC è costituito dalla Funzione di Controllo di Esecuzione delle Regole (PCEF) e la Politica di Controllo delle unzioni delle Risorse (PCRF). Il PCC dev’essere dinamico, perché ha bisogno di reagire alle diverse applicazioni che un utente sta utilizzando. Per esempio, una costituzione ottimale di una chiamata Voice over IP (VoIP) richiederà l'esistenza dell'IMS della rete mobile (IP Multimedia Subsystem) per istruire il PCC in modo da consentire la consegna di pacchetti appartenenti alla chiamata VoIP. Questo è limitante perché un gestore di telefonia mobile potrebbe non aver accesso a un server di applicazioni specifiche (ad esempio IMS) pur volendo applicare le regole dei criteri per il rispettivo servizio (ad esempio le chiamate VoIP). Inoltre, altre applicazioni che potrebbero beneficiare di policy non necessitano della funzionalità IMS e non scambiano informazioni con la funzionalità PCC nella rete mobile. Un esempio è il video (ad esempio IPTV, Youtube) dove il server video è tipicamente incapace di interagire con il PCC. Questo impedisce ad un operatore di dare priorità e banda radio dedicata a uno di questi servizi.

Sommario dell’invenzione

Sono qui descritti metodi e sistemi per la gestione e/o applicazione di una o più politiche per la gestione del traffico di protocollo internet (IP), tra più accessi di una rete. L’ accesso utilizza una tecnologia di accesso radio (Radio Access Technology, RAT). Inoltre è presente una politica per la gestione della larghezza di banda tra gli accessi multipli. La politica di tutti i molteplici accessi può fare affidamento su politiche intelligenti e complete che sono guidate da numerosi criteri come, ad esempio, la politica dell'operatore, i parametri associati all'abbonamento dell'utente, i requisiti dell'applicazione, le condizioni della rete, l’ubicazione, la potenza disponibile, ecc.

Il metodo può inoltre comprendere la gestione del traffico IP associato ad almeno un trasmettitore e /o ricevitore wireless (wireless transmit and/or receive unit, WTRU) tra la pluralità di accessi rispondente alle norme adatte.

In particolare, il metodo e l’apparato dell’invenzione sono atti a controllare e gestire il flusso di traffico IP senza la necessità di un’architettura complessa come IMS.

In un primo aspetto dell’invenzione, questa riguarda un metodo per controllare sessioni di comunicazioni mediali tra un utente identificato da un identificativo utente ed un dispositivo ricevente attraverso un core network e una rete IP esterna a detto core network, detti accessi a detto core network tramite una rete di accesso radio e detta rete compreso un gateway a detta rete IP esterna, comprendenti le fasi di:

� Controllo, quando detto utente si connette a detto core network, un database per recuperare le regole dei criteri applicabili a detto utente secondo l’identificativo utente e che si riferiscono a una o più sessioni mediali;

� Identificazione dell’istituzione di un canale di default (default bearer) per detto utente su detto core network;

� Analisi dei pacchetti di traffico provenienti da o diretti a detto utente, tra detta rete di accesso e detto core network;

� Verifica dell’istituzione di una sessione di comunicazione mediale richiesta tra l’utente e il dispositivo ricevente;

� Determinazione, per ogni pacchetto appartenente alla sessione di comunicazione mediale stabilita, del tipo di sessione mediale richiesta e stabilita, e gli indirizzi IP dei detti utenti e detta attrezzatura ricevente, tra cui la sessione mediale è stabilita.

� Forzare tale core network e/o rete di accesso radio e/o detto gateway a creare, se tali norme lo consentono, un canale dedicato (dedicated bearer) tra detto utente e detto gateway di detta rete IP esterna con Quality of Service per i pacchetti appartenenti alla già stabilita sessione mediale, detto Quality of Service a seconda della specifica sessione mediale, detto canale dedicato sia stabilito tra gli indirizzi IP e le porte correlate della sessione mediale già stabilita, detto canale dedicato viene creato sulla base delle informazioni ricavabili da detti pacchetti appartenenti a detta sessione mediale stabilita e a detto database.

I tipi di sessione “media” a cui si fa riferimento sono ad esempio: voce, video, messaggio e comunicazioni di allerta, comunicazione tra persone (voce e/o video), tra macchina e persona (ad esempio lo streaming video), comunicazioni tra macchina e macchina (reti di sensori, allarmi, allarmi video). Sono incluse anche combinazioni di queste come ad esempio le sessioni multimediali.

Il metodo dell’invenzione si riferisce ad un sistema di comunicazione che consente agli utenti wireless di comunicare, nel senso sopra specificato, tra di loro e /o a accedere al contenuto di una rete IP, in particolare guadagnando l’accesso a servizi basati su IP esterni secondo una determinata politica. Tali servizi sono per esempio chiamati VoIP, servizi di streaming video, chiamate Skype o videochiamate, accessi server di Youtube, ecc. Il sistema di comunicazione, per esempio, può utilizzare uno o più metodi di accesso al canale, come il Code Division Multiple Access (CDMA), Time Divisioni Multilpe Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA) e altre tecnologie note nella tecnica, come sarà meglio dettagliato in seguito.

Il significato di rete IP “esterna” si riferisce ad una rete esterna al core network. Preferibilmente tale rete IP è l’Internet, una rete aziendale privata o la rete IP di un operatore. Inoltre, la rete IP esterna può essere la stessa IMS. Non è necessario che la rete IP esterna appartenga ad un operatore diverso: core network e rete IP, esterna al core network, possono appartenere al medesimo operatore di una rete di comunicazione wireless.

La rete IP esterna è collegata al core network tramite un gateway appartenente al core network. Il pacchetti vengono instradati dal core network alla rete IP esterna attraverso il gateway. Poi i pacchetti, tramite il gateway, vengono instradati indietro nel core network dalla rete esterna.

L’utente si collega al sistema di comunicazione tramite una rete di accesso radio (RAN).

La RAN è collegata ad un core network che a sua volta consente il collegamento a reti aggiuntive rispetto alla rete IP esterna, come la rete telefonica pubblica commutata (PSTN), internet e altre reti IP.

L’utente potrebbe desiderare di stabilire una sessione mediale con un’apparecchiatura che riceve tramite la rete IP esterna. L’apparecchiatura di ricezione può essere sia un altro utente, oppure un server che comunica attraverso la rete IP, in cui è presente una specifica applicazione.

Un utente può essere qualsiasi tipo di dispositivo configurato per operare e/o comunicare in un ambiente wireless. A titolo di esempio, l’utente può essere configurato per trasmettere e /o ricevere segnali wireless, e può includere un’apparecchiatura utente, una stazione mobile, un’unità in abbonamento fissa o mobile, un cercapersone, un telefono cellulare, un palmare (PDA), uno smartphone, un iPhone, un computer portatile, un netbook, un personal computer, un sensore wireless, elettronica di consumo e altri trasmettitori/ricevitori noti alla tecnica. L’utente può essere collegato ad una persona o anche ad una macchina.

L’utente è identificato da un identificativo utente, che è ad esempio un codice IMSI internazionale presente in una Subscriber Identity Module (SIM), un Universal Subsciber Identity Module (USIM), Removable Identity Module User (R-UIM), un CDMA Subscriber Identity Module (CSIM), una SIM virtuale e/o di un dato numero di serie terminale come un International Mobile Equipment Identifier (IMEI) dell’utente. Qualsiasi altro identificatore utente può essere utilizzato, purché identifichi in modo univoco l’utente.

Preferibilmente, RAN comprende una o più stazioni radio base configurate per trasmettere e /o ricevere segnali wireless all’interno di una particolare regione geografica, che può essere identificata come una cella.

Secondo lo standard, l’utente richiede una connessione alla rete tramite il RAN e un canale di default è stabilito. Il modo in cui viene stabilito un tale canale di default è secondo la tecnica nota.

La connessione richiesta dall’utente al core network può essere stabilita o anche negata, secondo le procedure standard, a seconda del tipo di core network e RAN e la politica standard applicabile, il traffico della rete, ecc.

Un canale è un percorso end to end tra l’utente e il core network e/o il gateway verso la rete IP esterna. Ogni canale di default può essere associato ad un insieme di parametri di QoS che descrivono le proprietà del canale di trasporto, compresi bit rate, ritardo del pacchetto, perdita di pacchetti, tasso di errore per bit, e la politica di scheduling nella stazione radio base.

In una rete LTE, un canale di default può per esempio essere stabilito tra l’utente e un gateway PDN per l’acceso alla rete IP esterna, come Internet. Un canale di default è, per esempio, creato ogni volta che un utente si collega al gateway PDN.

Inoltre, la rete, ai sensi della tecnica nota, assegna all’utente un indirizzo IP dinamico o statico.

Secondo il metodo dell’invenzione, la costituzione del canale di default è controllata e l’indirizzo IP dell’utente viene identificato. Questa identificazione è fatta intercettando e analizzando i pacchetti da/ verso l’utente e il core network.

Dopo che è stato stabilito il canale, l’utente potrebbe richiedere una connessione mediale ad un apposito ricevente. Il collegamento mediale tra l’utente e l’apparecchiatura di ricezione può essere stabilita (o anche negata) secondo le procedure standard a seconda del tipo di core network e RAN e la politica standard applicabile, il traffico nella rete, ecc.

Il collegamento mediale utilizza il canale predefinito già stabilito tra l’utente e il gateway alla rete IP esterna, cioè, i pacchetti relativi al flusso della sessione mediale all’interno del canale predefinito.

Secondo il metodo, preferibilmente prima o non appena viene stabilita la sessione di comunicazione mediale, un database è controllato. La voce del database è l’identificativo dell’utente che identifica l’utente a/ da cui la sessione di comunicazione mediale è diretta. Per ogni identificatore utente, un insieme di regole viene memorizzato all’interno del database. Ad ogni utente pertanto è collegata una pluralità di indirizzi IP, per esempio la pluralità di indirizzi IP indica i server relativi ai servizi a cui l’utente può accedere utilizzando le regole dell’invenzione.

E’ possibile secondo il metodo dell’invenzione leggere l’intero database a intervalli regolari o quando la connessione da parte dell’utente al core network viene richiesta.

L’insieme di regole associate a ciascun utente è preferibilmente modificabile, ad esempio da un operatore che fornisce servizi connessi alla rete e alla quale l’utente è abbonato.

Secondo il metodo dell’invenzione, tutto il traffico tra il RAN e il core network, viene controllato, sia il traffico dati che di segnalazione. In particolare sorgono diverse possibilità: tutti i pacchetti di traffico provenienti da o diretti verso l’utente tra la detta rete di accesso e il detto core network sono analizzati sia prima che entrino nel core network che nel core network stesso.

Inoltre, preferibilmente, anche i pacchetti dal gateway verso la rete IP esterna e verso la rete IP stessa vengono analizzati.

Questo controllo dei pacchetti può essere eseguito da un nodo nel core network stesso, o da un’entità collegata al core network ed esterna a quest’ultimo, che verrà meglio descritto in seguito. In alternativa, la verifica può essere effettuata da un soggetto (nodo) che si trova nella porta di accesso (gateway) alla rete IP esterna o nella RAN.

Dall’analisi dei pacchetti che viaggiano nel core network e/ o tra RAN e core network e/ o tra il gateway alla rete IP esterne e la rete IP e appartenenti alla sessione mediale, il metodo dell’invenzione determina il tipo di sessione mediale richiesta e stabilita, e i due indirizzi IP e porte relative, tra cui la sessione mediale è stabilita.

E’ da intendersi che gli indirizzi IP dell’utente e dell’apparecchiatura ricevente possono cambiare dinamicamente. Per esempio, quando viene richiesta una chiamata VoIP per chiamare un utente finale, la richiesta è diretta verso un determinato server SIP, che ha un dato indirizzo IP e poi viene instradato verso l’utente finale, che ha un indirizzo IP diverso. Così il metodo dell’invenzione registra l’indirizzo IP del dispositivo con cui è attiva la comunicazione.

Tornando al database, le regole del database vengono controllare. Nel caso le regole lo consentano, il metodo dell’invenzione, comunica con il core network e/ o con la rete di accesso radio e /o con il gateway alla rete IP esterna, e forza tale core network e /o rete di accesso radio e/ o gateway a creare un tipo di trasporto dedicato con Quality of Service per i pacchetti appartenenti alla sessione mediale già stabilita. La qualità del servizio dipende dalla sessione mediale specifica, e il canale dedicato è stabilito tra gli indirizzi IP e le porte correlate della sessione mediale già stabilita, detto canale dedicato viene creato sulla base delle informazioni ricavabili dai detti pacchetti appartenenti alla detta sessione mediale stabilita e a detto database.

Come detto, un canale è un percorso end to end tra l’utente e la porta di accesso alla rete IP esterna. Ogni canale è associato a un insieme di parametri di QoS che descrivono le proprietà del canale di trasporto, compresi bit rate, ritardo del pacchetto, perdita di pacchetti, tasso di errore bit, e la politica di scheduling nella stazione di radio base.

In LTE un canale dedicato è ad esempio definito nello standard. Nel UMTS, l’attivazione del canale dedicato può essere considerata come un’attivazione secondaria del contesto PDP (secondary PDP context activation) in 2G e 3G.

Al fine di indirizzare i pacchetti nel canale dedicato, per esempio secondo l’invenzione un filtro è stabilito secondo un formato che utilizza i modelli di flusso del traffico (Traffic Flow Template, TFT). Il TFT contiene informazioni di filtraggio pacchetti per identificare e mappare i pacchetti per canali specifici, i filtri possono ad esempio contenere cinque parametri, comunemente indicati come un 5-tupla. I filtri dell’invenzione contengono qualsiasi combinazione di parametri a livello IP e di trasporto come ad esempio ma non limitati a:

� L’indirizzo IP di origine;

� L’indirizzo IP di destinazione;

� Il numero di porta di origine;

� Il numero di porta di destinazione;

� L’identificatore di protocollo (cioè, TCP o UPD).

In alternativa o in aggiunta, altri parametri che possono essere inclusi sono: - Indirizzo IPv4 remoto;

- Indirizzo IPv4 locale;

- Indirizzo IPv6 remoto;

- Lunghezza Indirizzo IPv6/ prefisso remoto;

- Lunghezza indirizzo IPv6/ prefisso located;

- Protocollo di identificazione / header successivo;

- Singola porta locale;

- Intervallo di porte locali;

- Singola porta remota;

- Intervallo di porte remote;

- Indice tipo di parametro di sicurezza;

- Tipo di servizio/ classe di traffico;

- Tipo di flusso;

Nel metodo dell’invenzione, i filtri vengono quindi creati senza un intervento del IMS, ma semplicemente analizzando il contenuto dei pacchetti scambiati tra RAN e core network e applicando il criterio nel database. Prima i pacchetti relativo al collegamento dell’utente e alla creazione del canale predefinito sono analizzati, poi i pacchetti relativi alla connessione mediale stabilita vengono esaminati al fine di ottenere tutte le informazioni necessarie per impostare i filtri necessari per forzare il core network e/ o il gateway e /o il RAN per creare il canale dedicato per tale sessione mediale.

Secondo una realizzazione preferita, prima della creazione di un canale dedicato con Quality of Service per i pacchetti appartenenti alla sessione mediale già stabilita, il metodo comprende la fase di forzatura di tale core network e/ o rete di accesso radio e /o gateway per creare, se tali norme lo consentono, un canale dedicato con Quality of Service per i pacchetti appartenenti alla segnalazione per la creazione della sessione mediale.

In questo modo anche il traffico di segnalazione e non solo il traffico dati utilizza un canale dedicato: in altre parole i pacchetti di comunicazione per l’instaurazione della sessione mediale possono transitare anche in un canale dedicato. Questo canale può essere creato immediatamente, ad esempio non appena un utente si collega al core network, o dopo che sono stati inviati i primi pacchetti di segnalazione che richiedono una sessione mediale.

Preferibilmente, la forzatura del core network e /o rete di accesso radio e /o gateway per creare un canale dedicato comprende:

- Verifica in detto database se detto utente è autorizzato a stabilire una sessione di comunicazione mediale del tipo richiesto, e

- In caso affermativo, la creazione di detto canale dedicato.

Secondo il metodo dell’ invenzione, tutti i pacchetti che scorrono tra la RAN e il core network e/ o dal gateway alla rete IP esterna sono esaminati e il tipo di sessione di comunicazione mediale è determinato. Tale sessione mediale per esempio può essere un video in streaming di Youtube, una comunicazione Skype, una comunicazione VoIP, streaming di canali TV, ecc. secondo l’invenzione, preferibilmente nel database, associato a ciascun utente, come identificativo dell’identificatore utente, è presente un elenco di possibili tipi di sessioni di comunicazione e nel caso la sessione mediale stabilita appartenga alla lista di possibili tipi, allora secondo il metodo, il core network o la RAN o il gateway è costretto a creare un canale dedicato per la sessione mediale.

Ciò avviene automaticamente, il che significa che il canale dedicato è creato sulla base delle informazioni recuperate dai pacchetti e le informazioni presenti nel database, senza alcun’altra comunicazione esterna.

In alternativa o in aggiunta, secondo una forma di realizzazione preferita, la forzatura del core network e/ o rete di accesso radio e/o del gateway per creare un canale dedicato comprende:

- Determinazione della posizione geografica di detto utente;

- Verifica in detta banca dati se detto utente è autorizzato a stabilire una sessione mediale in detto luogo geografico, e

- In caso affermativo, la creazione di detto canale dedicato.

Preferibilmente, nel database, associato ad ogni utente, è presente un elenco di possibili luoghi da cui è consentito all’utente ottenere una sessione di comunicazione mediale e nel caso in cui la posizione attuale dell’utente appartenga alla lista delle possibili ubicazioni geografiche, poi in base al metodo, il core network e/ o la RAN e/ o il gateway è costretto a creare un canale dedicato per la sessione mediale.

Anche in questo caso il canale dedicato è creato automaticamente.

In alternativa o in aggiunta, secondo una forma di realizzazione preferita, detta forzatura del core network e/ o rete di accesso radio e/o detto gateway per creare un canale dedicato comprende:

- Verifica in detta banca dati se a detto utente è consentito stabilire una sessione di comunicazione mediale con detto dispositivo ricevente; e

- In caso affermativo, la creazione di detto canale dedicato.

In altre parole, è presente, nella banca dati un elenco di indirizzi IP autorizzati, ogni indirizzo IP corrispondente al dispositivo ricevente. Se l’apparecchiatura di ricezione, che può essere sia il punto finale della comunicazione mediale desiderata o un server che reindirizza la comunicazione al reale punto finale, appartiene alla lista autorizzata, viene creato il canale dedicato.

In alternativa o in aggiunta, secondo una forma di realizzazione preferita, la forzatura del core network e/ o rete di accesso radio e/ o gateway per creare un canale dedicato comprende:

- Determinazione del flusso mediale richiesto da detto utente;

- Verifica in detta banca dati se detto utente è autorizzato ad accedere a detto flusso mediale, e

- In caso affermativo, la creazione di detto canale dedicato.

Tale flusso mediale, ad esempio, può essere un canale video di Youtube sulla musica classica. Secondo l’invenzione, preferibilmente nel database, associato a ciascun utente, è presente un elenco di possibili flussi mediale e nel caso il flusso mediale richiesto appartenga alla lista dei tipi possibili di flussi, allora secondo il metodo, il core network e/ o la RAN e/ o il gateway è costretto a creare un canale dedicato per la sessione mediale.

Preferibilmente detta sessione mediale è una sessione VoIP o una sessione di streaming.

Preferibilmente detta apparecchiatura di ricezione è un application server o un server SIP o un altro utente.

Secondo una realizzazione preferita, nel caso non ci sia corrispondenza tra la sessione mediale e le regole di politica, ad esempio, nel caso la sessione mediale richiesta non sia appartenente ai mezzi di sessione consentiti per tale utente o il server richiesto non sia tra l’elenco di server consentiti, ecc., il metodo dell’invenzione comprende la fase di chiusura/ o bloccaggio di detta sessione mediale (che è già stata stabilita) tra detto utente e detto ricevitore.

In questo modo, non vi è alcuna comunicazione tra l’utente e il dispositivo ricevente.

Preferibilmente, la Quality of Service per il canale dedicato include uno o più dei seguenti parametri: bit rate garantito, bit rate massimo, Quality of Service Class Identifier, attribuzione e priorità di conservazione, Differentiated Services Code Point.

Nell’invenzione, la QoS dipende dal tipo di sessione mediale che viene richiesta dall’utente. Pertanto una sessione vocale avrà una QoS differente da una sessione video. La QoS può essere associata ad un canale dedicato in modi diversi, ad esempio determinando uno o più dei parametri sopra elencati. Come detto, questi parametri sono diversi a seconda del tipo di sessione che viene trasportata nel canale dedicato.

Preferibilmente, il metodo comprende inoltre:

- Contare il numero di sessioni di comunicazione mediali svolte da detto utente in un arco di tempo;

- Stabilire detto canale dedicato solo se detto numero di sessioni eseguite entro detto periodo di tempo è inferiore a una determinata soglia.

In altre parole, per ogni utente è presente e memorizzato un contatore nel database, o in un altro luogo adatto. Nel caso in cui vi sia un limite superiore delle possibili sessioni mediali che possono essere stabilite da un utente, il metodo dell’invenzione comprende l’evitare di stabilire ulteriori canali dedicati se il numero di sessioni mediali ha superato tale limite superiore.

Vantaggiosamente, il metodo dell’invenzione comprende:

- Controllo in detta banca dati del massimo bitrate in uplink e/ o la velocità massima in downlink che detto utente è autorizzato ad utilizzare;

- Stabilire detto canale dedicato solo se detta sessione di comunicazione mediale richiede un uplink e/ o velocità in downlink pari o al di sotto di detto valore massimo del bitrate uplink e/ o detto massimo tasso di downlink.

Secondo l’invenzione, il canale dedicato è creato solo se uplink o downlik soddisfa i requisiti supplementari eventualmente presenti nel database, come detto, tale controllo viene seguito prima - dall’analisi del pacchetto -comprendendo il tipo di sessione mediale stabilita e poi controllando il downlink o uplink bitrate del medesimo.

Secondo l’invenzione, preferibilmente il metodo comprende:

- Determinazione del carico di traffico di detto core network r/ o rete di accesso radio;

- Stabilire detto canale dedicato solo se detto carico di traffico è sotto una certa soglia.

Il carico di traffico è inoltre ottenuto analizzando il flusso di pacchetti nel core network e/o rete di accesso.

Preferibilmente il metodo comprende:

- Verifica in detta banca dati del valore di accesso prioritario di detto utente;

- Confronto di detto valore di priorità di accesso con un valore di accesso di emergenza memorizzato;

- Nel caso in cui il valore di priorità di accesso di detto utente sia uguale o maggiore del valore di accesso di emergenza memorizzato, abbattere il canale dedicato e/ o bloccare l’accesso di rete di un altro utente (o utenti) avente detto valore di priorità di accesso inferiore a detto valore di emergenza;

- Creazione di un canale dedicato per detto utente avente detto valore di priorità di accesso superiore a detto valore più basso di priorità di accesso.

- In questo modo, l'utente che ha il valore di priorità più bassa viene "espulso" dalla rete se un utente avente una priorità superiore dovesse stabilire una sessione mediale.

- Preferibilmente, il valore accesso prioritario di detto utente ha una corrispondente allocazione di Quality of Service e valore di Priorità di ritenzione.

- In base ad un secondo aspetto, l'invenzione riguarda un apparato configurato per implementare una funzione di controllo di policy in una rete di telecomunicazioni per il controllo di sessione di comunicazione mediale; detta rete di telecomunicazioni comprende un core network avente un gateway per una rete IP esterna, una rete di accesso radio, e la rete IP esterna a detta rete principale. L'apparecchio comprende:

- Un database contenete le regole e i criteri applicabili per gli utenti di detta rete di telecomunicazione in base ad identificativi utente e che si riferiscono a una o più sessioni mediali;

- Un primo rilevatore idoneo a identificare la creazione di un canale predefinito per un utente su detto core network;

- Un secondo rilevatore idoneo a identificare la creazione di una sessione di comunicazione mediale richiesta tra l'utente e il dispositivo ricevente;

- Un analizzatore atto ad analizzare tutti i pacchetti di traffico provenienti da o a detto utente tra detta rete di accesso e detto core network e / o da gateway per una rete IP esterna e di determinare per ciascun pacchetto appartenente alla sessione di comunicazione mediale stabilita, il tipo della sessione di supporto richiesto e stabilito, e gli indirizzi IP e le porte di detto utente e detto dispositivo ricevente, tra cui la sessione di mediale è stabilita;

- Una policy Enforcer adatta per forzare tale core network e / o rete di accesso radio e / o detto gateway per creare, se tali norme lo consentono, un canale dedicato tra detto utente e detto gateway con Quality of Service per i pacchetti appartenenti alla già stabilita sessione mediale, detta Quality of Service dipende dalla specifica sessione mediale, detto canale dedicato stabilito tra gli indirizzi IP e le porte correlate della sessione mediale già stabilita, detto canale dedicato viene creato sulla base delle informazioni ricavabili dai detti pacchetti appartenenti a detta sessione mediale stabilita e detto database.

Analizzatore, enforcer e rilevatore possono essere elementi separati, o lo stesso elemento, hardware o software.

Preferibilmente, i detti primo e secondo rilevatore, detto analizzatore e detta policy enforcer fanno parte dello stesso nodo.

In altre parole, le varie funzioni sono svolte da un unico dispositivo.

In una implementazione vantaggiosa, detti primo e secondo rilevatore, detto analizzatore e detta policy enforcer sono parte di detto core network.

Essere parte del core network significa che possono essere anche parte di un nodo già esistente del core network, come ad esempio la porta di accesso alla rete IP esterna, oppure possono essere nodo aggiuntivo del core network.

Alternativamente, in una diversa forma di realizzazione preferita, detti primo e secondo rilevatore, detto analizzatore e detta policy enforcer sono parte di detta rete di accesso radio.

In questo modo il criterio è applicabile tramite la stazione base e tutte le funzioni sono svolte da esso.

Breve descrizione dei disegni

L'invenzione sarà meglio compresa con riferimento ai disegni allegati, in cui:

- Fig. 1 è una rappresentazione schematica di un sistema di comunicazione in cui è implementato il metodo dell'invenzione;

- Fig. 2 è una rappresentazione schematica di un sistema di comunicazione diverso in cui è implementato il metodo dell'invenzione;

- Fig. 3 è una rappresentazione schematica più dettagliata di una rete di comunicazione in cui è implementato il metodo dell'invenzione;

- FIG. 3A è una rappresentazione schematica più dettagliata di una diversa forma di realizzazione di una rete di comunicazione in cui è implementato il metodo dell'invenzione;

- Fig. 4 è una rappresentazione schematica più dettagliata di una ulteriore variante realizzativa di una rete di comunicazione in cui è implementato il metodo dell'invenzione;

- Fig.5 è una rappresentazione schematica di un pacchetto IP contenente un messaggio di segnalazione VoIP(SIP);

- Fig.6 è una voce del database dell’invenzione;

- Fig.7 è un diagramma di flusso di una fase del metodo dell'invenzione;

- Fig. 8 è un diagramma di flusso di una diversa fase del metodo dell'invenzione;

- Fig. 9 è un diagramma di flusso di una diversa fase del metodo dell'invenzione;

- Fig. 10 è un diagramma di una forma di realizzazione dell'applicazione di una fase del metodo dell'invenzione;

- Fig. 11 è un diagramma di una forma di realizzazione dell'applicazione di una diversa fase del metodo dell'invenzione;

- Fig.12 è uno schema di una realizzazione dell’ applicazione di una ulteriore fase del metodo dell'invenzione;

- Fig.13 è un diagramma di una forma di realizzazione dell'applicazione di un ancora ulteriore fase del metodo dell'invenzione, e

- Fig.14 è un diagramma di una forma di realizzazione dell'applicazione di un ulteriore passo del metodo dell'invenzione.

Descrizione dettagliata delle forme di realizzazione preferite

Fig. 1 o 2 sono rappresentazioni schematiche di possibili sistemi di comunicazione 100 in cui una o più realizzazioni descritte della presente invenzione possono essere implementate. In generale, il sistema di comunicazione 100 definisce un'architettura che supporta i sistemi di accesso multiplo su cui più utenti wireless possono accedere e / o di scambio (ad esempio, di inviare e / o ricevere) contenuti, come voce, dati, video, messaggistica, trasmissione, ecc.

I sistemi ad accesso multiplo possono comprendere rispettivi accessi, ciascuno dei quali può essere, per esempio, una rete di accesso, il punto di accesso e simili. In varie forme di realizzazione, tutti gli accessi multipli possono essere configurati con e / o impiegare le stesse tecnologie di accesso radio. Alcuni o tutti questi accessi possono essere posseduti, gestiti, controllati, utilizzati, ecc. da un singolo operatore di rete mobile e / o vettore o più operatori / vettori.

Il sistema di comunicazione 100 può consentire agli utenti wireless di accedere ai contenuti attraverso la condivisione e / o la distribuzione di risorse di sistema, tra cui, ad esempio, la larghezza di banda wireless. Il sistema di comunicazione 100, per esempio, può impiegare uno o più metodi di accesso al canale, come accesso multiplo a divisione di codice (CDMA), accesso multiplo a divisione di tempo (TDMA), l'accesso multiplo a divisione di frequenza (FDMA), ortogonale FDMA (OFDMA), singola -portante FDMA (SC-FDMA), e altre tecnologie note nella tecnica, come sarà meglio dettagliato di seguito.

Con riferimento ora alla fig. 1, il sistema di comunicazione 100 può comprendere trasmissione / ricezione unità wireless ("WTRUs") o - brevemente -101 utenti, una rete di accesso radio ("RAN") 104, un nucleo di rete 106, una rete telefonica pubblica commutata ("PSTN" ) 108, Internet 110, e altre reti 112. Qualsiasi numero di reti può essere collegato tramite il core network 106.

Ciascuno dei WTRUs 101 può essere qualsiasi tipo di dispositivo configurato per operare e / o comunicare in un ambiente wireless. A titolo di esempio, il WTRUs 101 può essere configurato per trasmettere e / o ricevere segnali wireless, e può comprendere un terminale utente ("UE"), una stazione mobile, una unità di abbonato fissa o mobile, un cercapersone, un telefono cellulare, un assistente personale digitale ("PDA"), uno smartphone, un iPhone, un computer portatile, un netbook, un personal computer, un sensore wireless, elettronica di consumo, e di altri trasmettitori / ricevitori noti nella tecnica.

Preferibilmente, RAN 104 include una o più stazioni di base 114. Come descritto più dettagliatamente di seguito, la RAN 104 può includere stazioni di base e / o elementi di rete diversi dalla stazione base 114 (non mostrato), ad esempio un controllore di stazione base ("BSC"), un controllore di rete radio ("RNC" ), nodi di ripetizione, ecc La stazione di base 114 può essere configurata per trasmettere e / o ricevere segnali wireless all'interno di una particolare regione geografica, che può essere indicata come una cella (non mostrato nei disegni allegati).

La stazione 114 di base può essere un qualsiasi tipo di dispositivo configurato per interfacciarsi con modalità wireless con almeno una delle WTRUs 101 e può agevolare l'accesso a una o più reti di comunicazione, come il core network 106. Le stazioni di base 114 possono essere, per esempio, qualsiasi tipo di stazione radio base ("BTS"), Node-B ("NB"), evoluto NB ("ENB"), casa NB ("HNB"), Casa ENB ("HeNB"), impresa NB ("ENT-NB "), impresa ENB (" ENT-ENB "), un controller di sito, un punto di accesso (" AP "), un router wireless, e simili. Sebbene raffigurato come un unico elemento, ciascuna delle stazioni base 114 può comunque includere qualsiasi numero di stazioni base comunicativamente accoppiate e / o elementi di rete. Il termine "H / E (e) NB" è usato qui di seguito, per semplicità di esposizione, per fare riferimento a un HNB, un HeNB, un ENT-NB, un ENT-ENB, una stazione base di una rete di accesso trusted-3GPP o simili.

Le stazioni base 114 possono comunicare con uno o più dei WTRUs 101 su un'interfaccia aerea 116, che può essere qualsiasi collegamento di comunicazione senza fili adatto. L'interfaccia aerea 116 può essere stabilita utilizzando qualsiasi RAT adatto.

Più specificamente, come notato sopra, il sistema di comunicazione 100 può essere un sistema ad accesso multiplo e può utilizzare uno o più sistemi di accesso al canale, come CDMA, TDMA, FDMA, OFDMA, SC-FDMA, e simili. Per esempio, la stazione base 114 nel RAN 104 e il WTRUs 101 può implementare una tecnologia radio, come Universal Mobile Telecommunications System ("UMTS") Terrestrial Radio Access ("UTRA"), che può stabilire l'interfaccia aerea 116 usando wideband CDMA ("WCDMA"). WCDMA può includere protocolli di comunicazione come ad esempio High-Speed Packet Access ("HSPA") e / o Evolved HSPA ("HSPA "). HSPA può includere High Speed DL Packet Access ("HSDPA") e / o High-Speed Packet Access UL ("HSUPA").

In un'altra forma di realizzazione, la stazione base 114 e il 101 WTRUs può implementare una tecnologia radio, come Evolved UMTS Terrestrial Radio Access ("E-UTRA"), che può stabilire l'interfaccia aerea 116 utilizzando Long Term Evolution ("LTE") e / o LTE-Advanced ("LTE-A").

In altre realizzazioni, le stazioni base 114 e il 101 WTRUs possono implementare tecnologie radio come IEEE 802.16 (ovvero Worldwide Interoperability for Microwave Access ("WiMAX")), CDMA2000, CDMA2000 12X, CDMA2000 EV-DO, Interim Standard 2000 (" IS-2000 "), Interim Standard 95 (" IS-95 "), ad interim standard 856 (" IS-856 "), sistema globale per comunicazioni mobili (" GSM "), Enhanced Data Rates per GSM Evolution (" edge ") , GSM EDGE ("GERAN"), e simili.

La RAN 104 è in comunicazione con il core network 106, che può essere configurato per fornire servizi voce e dati a uno o più dei WTRUs 101.

Il core network 106 può anche servire come gateway per la WTRUs 101 per accedere alla rete PSTN 108, Internet 110, e / o altre reti 112. La PSTN 108 può includere reti telefoniche a commutazione di circuito che forniscono semplice vecchio servizio telefonico. Internet 110 può includere un sistema globale di reti e dispositivi che utilizzano protocolli di comunicazione comuni, come il Transmission Control Protocol ("TCP"), l'User Datagram Protocol ("UDP") e il protocollo Internet ("IP") nella suite TCP/IP del protocollo Internet. La rete 100 può includere ulteriori reti di comunicazione cablate o wireless di proprietà e / o gestite da altri fornitori di servizi.

Quanto sopra sono solo esempi di sistemi di comunicazione 100 a cui la presente invenzione può essere applicata, comunque altri tipi di sistemi di comunicazione sono altrettanto possibili. Con riferimento alla fig. 2, secondo la tecnica nota, un sistema di comunicazione convenzionale 100 comprende inoltre una funzione applicazione (AF) 142 che comunica in modo dinamico le regole e i criteri a una funzione di controllo risorse (PCRF) 141 che a sua volta comunica con una funzione di forzatura delle politiche di controllo (PCEF ) 140. PCEF è generalmente parte del core network mobile 106 che fa rispettare tali norme. La soluzione principale nei sistemi di comunicazione noti 100 dell'applicazione funzione 142 è l'IP Multimedia Subsystem (IMS) utilizzato per supportare servizi di Voice over IP nelle reti mobili. In fig. 2, gli stessi numeri di riferimento indicano gli stessi elementi di fig.1 già descritta.

Con riferimento ora alle Figg. 3 e 4, sono adesso raffigurate due diverse forme di realizzazione del sistema di comunicazione 100'' secondo l'invenzione. Come sopra, gli stessi numeri di riferimento indicano gli stessi elementi di figg.1 e 2.

La Rete 100'' comprende una RAN 104, un core network 106 ed una rete IP 110.112.142 esterna al core network. Gli elementi che hanno lo stesso numero di riferimento come nelle figure 1 e 2 sono analoghi agli elementi aventi lo stesso numero già descritto in dettaglio con riferimento alle figg. 1 e 2 e di comunicazione dei sistemi 100 e 100 ".

Secondo un primo aspetto della presente invenzione, la rete 100'' comprende un Mobile Policy Engine (MPE) 500, implementato come una parte del core network 106 (forma di realizzazione della fig. 4) o come un'entità esterna al core network 106 (forma di realizzazione di fig.3).

Alternativamente, con riferimento alla fig. 3A, il MPE può opzionalmente essere implementato come parte di E-UTRA e della BTS, come la ENB o HeNB. L’ MPE può anche essere implementato come parte di un core network locale all'interno della E-UTRA e / o BTS. Tale attuazione semplifica la distribuzione della rete descritta in questa invenzione utilizzando stazioni base compatte modificate che possono funzionare indipendente utilizzando la funzionalità di rete completa.

L'MPE è adatto per applicare una determinata politica (contenute in un database, come dettagliato di seguito) per gli utenti, come ad esempio WTRUs, che si connette alla rete 100''. La politica riguarda principalmente la creazione di sessione di comunicazione mediale.

Il MPE 500 è collegato alla rete di accesso radio RAN 104 e ad un gateway 204 a una rete esterna di dati IP 108.110.112, che può essere sia Internet 108 o qualsiasi altra rete IP 112 come una rete IP di proprietà. Il gateway potrebbe essere un qualsiasi nodo del core network attrezzato per l'interfacciamento con la rete IP esterna. Per esempio, in un protocollo LTE, il gateway potrebbe essere un PGW (PDN Gateway).

Il Gateway PDN fornisce la connettività dal WTRU a reti di dati a pacchetto esterni per essere il punto di uscita e di ingresso del traffico per il WTRU. Un WTRU può avere connettività simultanea con più di un PGW per accedere a più PDNs. Più specificatamente, quando il WTRU collega alla rete 100'' via RAN 104, viene creato un canale predefinito, secondo lo standard.

In questa comunicazione iniziale tra il WTRU e il core network 106, al fine di eseguire la procedura di collegamento e la creazione di un canale dedicato, numerose informazioni sono state scambiate tra il core network o il RAN e il WTRU.

Una parte o tutte queste informazioni vengono recuperate dal MPE 500, che intercetta e analizza i pacchetti tra il RAN e il core network.

Poi la WTRU richiede una sessione mediale. La sessione mediale può essere stabilita tra il WTRU ed un'altra WTRU o tra l'WTRU e un server, più in generale, tra il WTRU e qualsiasi altro dispositivo fisso o senza fili raggiungibile utilizzando un indirizzo IP, che sarà chiamato ricevitore. I pacchetti appartenenti alla sessione mediale fluiscono nel canale predefinito già creato secondo la norma tra il WTRU e il gateway alla rete IP esterna, in modo che le comunicazioni possano essere ottenute con la rete IP esterna.

Subito dopo l'istituzione della sessione mediale richiesta, MPE 500 analizza anche il contenuto dei pacchetti che scorrono all'interno del canale di default e ad esso relativi. Intercettare e analizzare i pacchetti, consente all’MPE di recuperare informazioni aggiuntive, oltre a quella già ottenute. Queste informazioni vengono utilizzate per impostare un filtro per i pacchetti che scorrono dal / al WTRU che è stato collegato alla rete 100''. In altre parole, il MPE deve essere "intelligente", in modo che possa intercettare e analizzare il pacchetti e rilevare le informazioni necessarie, come di seguito dettagliato. I pacchetti da intercettare sono sia i pacchetti prima della creazione del canale predefinito che i pacchetti che fluiscono nel canale predefinito appartenente alla sessione mediale. I pacchetti vengono intercettati e analizzati al fine di ottenere le informazioni necessarie per il set-up di un filtro appropriato.

MPE può intercettare e analizzare i pacchetti all'interno del core network, o intercettare e analizzare gli stessi di fuori del core network, in particolare tra la RAN e il core network.

In alternativa o in aggiunta alla MPE può anche analizzare i pacchetti dal gateway verso la rete IP esterna.

Per impostare un filtro, l' MPE deve confrontare le informazioni recuperate dai pacchetti con una politica applicabile a tale WTRU che ha richiesto la comunicazione mediale. La politica è contenuta in un database che può essere interrogato, per esempio dal MPE, come di seguito dettagliato.

Il Mobile Policy Engine MPE500 può essere attuato mediante hardware dedicato e / o comprendere funzioni software eseguite da un processore. Inoltre, il MPE può essere parte di nodi già esistenti nel core network 106.

Rete 100'' comprende inoltre un database di politica utente 501. L'UPD 501 comprende i dati che descrivono l'accesso degli utenti e profili di servizio che devono essere applicati. Ciascuna voce del database è identificata da un identificativo utente. Come noto nella tecnica, ogni WTRU 101 o utente viene identificato da un "identificativo utente" 302 tale identificatore può essere per esempio un International Mobile Subscriber Identity (IMSI) e / o un determinato numero di serie terminale come Internationale Mobile Equipment Identifier (IMEI) del WTRU. Qualsiasi altro identificativo utente può essere utilizzato, purché identifichi univocamente il WTRU 101.

Oltre all'identità dell'utente (per esempio, una voce collegata l'identificativo utente), la politica database utente 501 può contenere uno o più dei dati illustrati con riferimento alla fig.6, raccolti in un record 301:

• Identificativo utente 302;

• Livello di priorità 303: un numero corrispondente alla priorità relativa assegnata al WTRU 101 corrispondente all'identificativo utente 302. Come esempio, questo potrebbe essere un numero su una scala da 10 (priorità massima) a 1 (priorità più bassa);

• Elenco dei server VoIP consentiti per canale dedicato 304: uno o più indirizzi di Internet Protocol (IP) o Fully Qualified Domain Name (FQDN) che identificano i server VoIP permessi per canali dedicati. Quando l'utente stabilisce una chiamata VoIP con uno di questi server, allora il MPE 210 agirà per assegnare un tipo di trasporto dedicato di alta qualità per la chiamata;

• Elenco dei server video consentiti per canale dedicato 305: uno o più indirizzi di Internet Protocol (IP) o Fully Qualified Domain Name (FQDN) che identificano i server video permessi per canali dedicati. Quando l'utente stabilisce un video in streaming con uno di questi server, allora il MPE 210 agirà per assegnare un tipo di trasporto dedicato di alta qualità per la connessione;

• Elenco di server consentito per canale dedicato che utilizza una data applicazione 306: come sopra ma in relazione ai server per qualsiasi altro tipo di applicazione, ad esempio, transazioni finanziarie, download di file. Una o più copie di campo 306 possono esistere all'interno di una registrazione della UPD 301, ognuno dei quali identifica una diversa applicazione;

• Non consentire chiamate VoIP in entrata o in uscita 307-308;

• Elenco dei numeri di chiamata VoIP non consentiti 309: L'elenco dei numeri (e / o identificatori utente) che il WTRU deve essere bloccato dal chiamare (es. numeri internazionali);

• Massimo throughput in Uplink (UL) 310: massimo bitrate in uplink che il WTRU può di utilizzare;

• Massimo throughput di Downlink (DL), velocità 311: massimo bitrate in downlink che il WTRU può di utilizzare;

• Elenco dei luoghi non consentiti per l'accesso alla rete 312: un elenco di luoghi nei quali alla WTRU non è consentita la connessione alla rete;

• Elenco dei luoghi non consentiti per le chiamate VoIP 313: un elenco di luoghi nei quali alla WTRU non è consentito effettuare chiamate VoIP;

• Elenco dei luoghi non consentiti per una determinata applicazione 314: un elenco di luoghi nei quali alla WTRU non è consentito stabilire connessioni e / o utilizzare una data applicazione. Una o più copie di campo 314 possono esistere all'interno di una registrazione della UPD 301, ognuna delle quali identifica una diversa applicazione;

• Numero massimo di chiamate VoIP 315: il numero massimo di chiamate voce contemporanee consentite per la WTRU;

• Numero massimo di comunicazioni per una data applicazione 316: il numero massimo di comunicazioni contemporanee per la WTRU in relazione a una data applicazione;

• Elenco di indirizzi IP consentiti e porta 317, gli indirizzi IP e le porte con le quali la WTRU non può comunicare.

La posizione sopra può includere un identificatore di stazione base, 3GPP Service Area Identifier (SAI), identificatore cellule e / o altre informazioni sulla posizione quali le coordinate GPS.

Un UPD 501 include uno o più record 301 come illustrato in figura 6, in particolare preferibilmente un record per ogni identificativo utente 302.

Campi di informazioni UPD 306, 314 e / o 316 possono essere replicati più volte in un singolo record UPD 301 per soddisfare il numero di applicazioni che devono essere profilate per la WTRU.

I campi del UPD 501 riguardanti un WTRU identificato dall’ identificativo utente 302 che si collega alla rete 100'' vengono recuperati facoltativamente dal MPE sia durante il collegamento della WTRU, che durante la creazione del canale predefinito tra la WTRU e il gateway alla rete IP esterna.

Pertanto, data l’identificazione di utilizzatore di un dato WTRU collegato alla rete 100'', il MPE 500 innanzitutto rileva l’identificatore proprio dell'utente analizzando i primi pacchetti scambiati con il core network (questo pacchetto può essere intercettato all’interno o all'esterno del core network). Dall'identificatore utente, il MPE legge il database di 501, per comprendere il tipo di politica che è applicabile a tale WTRU.

Ulteriormente, la rete 100'' comprende un'unità di controllo Policy PCU 502 che comprende un'interfaccia, inclusa ma non limitata a una interfaccia grafica utente 503 e / o Application Programming Interface 504, che permettono a un gestore di rete di:

• creare e / o modificare e / o cancellare le politiche nel UPD;

• creare e / o modificare e / o eliminare i gruppi di utenti;

• creare e / o modificare e / o eliminare le definizioni di aree geografiche;

• creare e / o modificare e / o eliminare gli indirizzi IP e / o sottoreti (corrispondente ad esempio a sottoreti private aziendali, sotto rete privata del Dipartimento di Ingegneria, i siti di file sharing, ecc);

• selezionare un algoritmo di Access Priority Mode per il controllo accessi che utilizza livelli di priorità di accesso;

• assegnare all'utente una quantità massima di traffico utilizzabile al mese (espressa in megabyte, gigabyte o altri);

• ecc

Il MPE 500 è collegato alla PCU 502 e in aggiunta può leggere tutte le voci del UPD 501.

La PCU (o il MPE, come già detto) può così leggere i campi della UPD 501 riguardanti una WTRU identificata dall'identificativo utente 302 che si collega alla rete 100''. Questo recupero è effettuato sia durante la procedura di collegamento della WTRU, che durante la creazione del canale di default tra la WTRU e il gateway alla rete IP esterna.

L'MPE, UPD e / o PCU può essere attuato nell'ambito dei nodi di Mobile Core Network convenzionali (LTE Evolved Packet Core, UMTS Packet Core ecc). L'UPD può anche essere implementato come parte di un Home Location Register convenzionale e / o Home Subscriber System (HSS). Ad esempio, nell'esempio di fig. 4, un utente convenzionale WTRU 101 si connette a un convenzionale Radio Network Access 104. Il Radio Network Access 104 comprende l’elemento stazione radio base della rete. Questo include l'UMTS Radio Access Network (UTRAN) o l'LTE evolved UMTS Radio Network Access (E-UTRAN), e altri. Il Radio Network Access 104 è collegato ad un Mobile Core Network 106. Il Mobile Core Network 106 è suddiviso in una funzione Mobile Core Traffic 204 che gestisce la sua attività e funzione Mobile Core Signalling 205 che gestisce l'elaborazione dei messaggi di segnalazione di instradamento del traffico. Come esempio, in reti LTE, l’MME corrisponde alla funzione Mobile Core Signalling 205 e il P-GW e S-GW corrispondere alla funzione Mobile Core Traffic 204.

L’MPE 500 è collegato alla funzione Mobile Core Signalling 205, alla funzione Mobile Core Traffic 204, al Radio Access Network 104, all'unità di controllo policy (PCU) 502 e ad Internet, IMS, altre applicazioni e reti 108, 110, 112, 142.

MPE e PCU possono essere situati all'interno del core network (forma di realizzazione della fig.4) o all'esterno dello stesso (forma di realizzazione di fig.3 e 3A).

L'MPE 500 è configurato per elaborare la segnalazione e il traffico tra la rete di accesso radio 104 e il mobile core network 106. Il MPE 500 è configurato per elaborare segnalazione e traffico tra il mobile core network 106 e la rete IP esterna, come Internet, altre applicazioni e reti.

La PCU 502 è configurata per elaborare segnali radio. Pertanto, il MPE 500 legge e analizza tutti i pacchetti relativi alla segnalazione e il flusso di traffico, mentre la PCU legge e analizza tutti i pacchetti di segnalazione radio. La PCU 502 legge i criteri utente in UPD 501 e le eventuali modifiche ad essi. Comunica i policy records 301 contenenti i corrispondenti identificatori utente 302 al MPE 500.

MPE e PCU possono essere implementate nello stesso nodo, cioè, MPE e PCU possono essere la stessa unità. Tuttavia, nel caso in cui in diverse parti del core network 106 debbano essere stabilite differenti filtri, allora preferibilmente sono situate parecchi MPE e un singolo PCU viene utilizzato come un "coordinatore" di tutti gli MPE, decidendo quali filtri devono essere attuati e in quali nodi, in funzione dei segnali nel processo di lettura.

Come mostrato in fig.3A, MPE 500 e PCU 502 possono anche essere parte della stazione di base 114. Anche in questo caso, MPE e PCU possono coincidere in una singola unità.

L'analisi dei pacchetti da parte MPE 500 e / o dalla PCU 502 deve essere in profondità al fine di applicare il criterio contenuto nella UPD 501. Con riferimento alla fig. 5, questo può essere spiegato con un esempio. Per applicare il criterio, per ciascuna sessione mediale che viene stabilita dal WTRU, il MPE deve conoscere almeno uno o più dei seguenti dati:

- L'indirizzo IP associato al WTRU;

- La posizione del WTRU;

- L'indirizzo IP e la porta TCP / UDP del server / WTRU supplementare con il quale alla WTRU è permesso di comunicare (ad esempio, per stabilire una sessione mediale o per inviare il traffico mediale) ad esempio 304 Elenco dei server VoIP ammessi per canale dedicato, 305, 306;

- Il tipo di sessione mediale stabilita;

- L'indirizzo IP e la porta TCP / UDP del server / WTRU aggiuntivo con cui alla WTRU non è permesso di comunicare (include le opzioni "Tutti non consentiti a meno che non siano stati consentiti sopra", "Nessuno non consentito") 317.

In alternativa, la posizione del WTRU è determinata dalla PCU: nel caso in cui la PCU legga la segnalazione e le voci del database UPD, il MPE non ha bisogno di avere la conoscenza della posizione di WTRU perché i filtri sono implementati dal PCU. Per esempio, assumendo che la PCU abbia acquisito la conoscenza della posizione di WTRU, PCU informa il MPE quando deve bloccare tutte le comunicazioni da / per l'WTRU perché il WTRU è in una posizione in cui le comunicazioni sono disattivate in base alla politica, e, al contrario, si informa il MPU quando deve consentire di nuovo tali comunicazioni, in quanto il WTRU è uscito tale posizione. In questo scenario, il MPE non ha bisogno di conoscere la posizione del WTRU.

Se per esempio il WTRU 101 richiede una sessione SIP utilizzando un server SIP o proxy, il pacchetto che viene inviato dal WTRU 101 e dalla RAN sta scorrendo all'interno del core network è tale come in fig.5. Fig.12 mostra il flusso di un tale pacchetto all'interno del core network. Il pacchetto IP che contiene il messaggio SIP è un pacchetto IP che è caratterizzato da una tupla di 5, incluso l'indirizzo IP sorgente, indirizzo IP di destinazione, porta sorgente, porta di destinazione, numero di protocollo. Se il MPE 500 rileva solo queste informazioni contenute nel pacchetto IP, il MPE 500 comprende che i messaggi SIP sono utilizzati per stabilire una comunicazione tra due punti finali, ma l'MPE 500 non può determinare quali due punti finali intendano stabilire una comunicazione e quale applicazione sia trasportata dal pacchetto IP. Ciò significa che le informazioni di cui sopra sono solo sufficienti a determinare che una WRTU sta tentando di stabilire una comunicazione tramite SIP. Non è sufficiente per determinare che tipo di voce / video, o altra applicazione stia venendo stabilita o i punti finali che saranno coinvolti in tale comunicazione, una volta stabilita (che non sempre coincide con l'originaria destinazione e provenienza indirizzi IP contenuti nel pacchetto IP).

Il messaggio SIP è un messaggio di "applicazione" trasportato dal pacchetto IP.

Può contenere informazioni, tra cui:

• Codice di successo o di errore,

• Identità del chiamante (o il numero),

• Identità chiamata (o numero),

• Tipo di chiamata (voce, video) o messaggio,

• lndirizzo IP e porte che il chiamante e il chiamato utilizzeranno per inviare gli effettivi dati mediali (voce, video, messaggi, ecc)

Solo se il MPE 500 legge anche queste informazioni contenute nel messaggio SIP, in aggiunta alle informazioni trasportato dal pacchetto IP, esso può determinare quale tipo di applicazione o sessione mediale è stabilita e i punti finali che saranno coinvolti nella comunicazione non appena sarà stabilita. L'MPE implementa uno o più filtri, come meglio dettagliato di seguito, che vengono ricevuti dal PCU (o generati automaticamente). Pertanto la quantità e il tipo di informazioni che MPE deve recuperare dai pacchetti per attuare i filtri effettivamente dipende dai filtri stessi. Tuttavia, in generale l'informazione minima è relativa ai punti finali coinvolti nella sessione mediale e al tipo di sessione mediale.

La PCU 502 fornisce le informazioni contenute nel UPD 501 al MPE 500, sia a seguito di una richiesta da parte del MPE 500 o automaticamente. Per esempio, la PCU 502 può inviare dati di policy al MPE 500 per un dato utente ogni volta che rileva che la WTRU è connesso alla rete. Il MPE 500 può inoltre richiedere tutti i dati di policy dalla PCU 502 al tempo di avvio e / o ad intervalli regolari, per esempio quando il MPU è l'unico nodo senza la PCU. La PCU 502 può informare il MPE 500 di eventuali variazioni dei dati memorizzati nel UPD 501.

In base a tali politiche, il MPE 500 stabilisce un filtro per il traffico e la segnalazione, per rilevare eventi legati agli identificatori di utente 302 che corrispondono alle politiche che richiedono un'azione da intraprendere, preferibilmente sulla base delle istruzioni ricevute dal PCU.

In altre parole, dato l'identificativo utente letto dai pacchetti del WTRU per il quale è stato istituito un canale di default e in cui i pacchetti relativi ad una sessione di supporto sono in viaggio, i MPE intercetta gli ulteriori pacchetti appartenenti alla sessione mediale e confronta le informazioni recuperate con la politica associata al WTRU ottenuto dalla UPD 501. In questo modo il MPE può creare un filtro appropriato.

Tali eventi possono includere ad esempio:

• Un utente mobile che si collega alla rete (nessuna area di posizione);

• Un utente mobile che si collega alla rete (da una zona di posizione specifica comprendente uno o più di un identificatore di stazione base cellulare, 3GPP Service Area Identifier, coordinate GPS etc);

• Un utente mobile componente o ricevente una chiamata vocale circuito a / da un determinato numero;

• Un utente mobile componente o ricevente una chiamata VoIP da / verso un determinato numero o identificativo utente;

• Un utente mobile in una determinata località componente o ricevente una chiamata vocale a circuito;

• Un utente mobile in una determinata località componente o ricevente una chiamata VoIP;

• Un utente mobile che completi con successo una chiamata VoIP con un determinato server VoIP, l'indirizzo IP dell'utente chiamante, indirizzo IP dell'utente chiamato, trasporto di ricezione e trasmissione (ad esempio User Datagram Protocol), i numeri di porta, ecc;

• Un utente mobile che si connette a un determinato server per una data applicazione (ad esempio video streaming da server di Youtube 1 in Egitto).

Quando il MPE 500 rileva che un evento per un determinato identificatore utente 302 si è verificato, che corrisponde alle informazioni in UPD 501, allora il MPE 500 intraprenderà le azioni previste dalla politica per tale specifico identificativo utente 302, come ad esempio:

• Nessuna azione che significa che il MPE 500 non interferisce con le comunicazioni da / per l'WTRU 101;

• Rifiuta una richiesta di una WTRU 101 per connettersi alla rete 106 sulla base del livello di priorità 303 e il risultato di un algoritmo di priorità (cfr. esempi di algoritmi nelle figure 8 e 9);

• Rifiuta una richiesta di una WTRU 101 per connettersi alla rete da un determinato luogo, perché la posizione non consentito (vedi scheda articolo 312 in figura 6);

• Rifiuta una WTRU 101 componente o ricevente una chiamata VoIP da / verso un determinato numero o identificativo utente;

• Rifiuta una WTRU 101 componente o ricevente una chiamata vocale circuito da un determinato luogo;

• Rifiutare una WTRU componente o ricevente una chiamata VoIP da un determinato luogo;

• Comunica con il Mobile Core Network 106 e / o Radio Network Access 104 per creare o abbattere un canale dedicato con qualità garantita del servizio (QoS) per una chiamata VoIP;

• Comunica con il Mobile Core Network 106 e / o Radio Network Access 104 per creare o abbattere un canale dedicato con qualità garantita del servizio (QoS) per l'applicazione data (ad esempio video streaming o altro).

Tutte queste azioni sono specificate dal UPD 501 per l’identificativo utente 302 associato alla specifica WTRU 101.

Così PCU 502 e MPE 500 sono progettati in modo da controllare e analizzare tutti i pacchetti di entrambi i flussi di segnale o di dati all'interno del core network 106. Dall'analisi dei pacchetti, è ottenuto l'identificativo utente 302 del WTRU 101 che è collegato alla rete 100''. L'UPD 501 viene interrogato al fine di ottenere tutte le regole di politica 301 che sono associate a tale identificatore 302 o, in alternativa tutte le voci della UPD 501 sono disponibili perché erano state scaricate in precedenza. L'MPE 500 crea così un filtro che applica queste politiche.

Nel caso in cui la politica lo consenta, per un dato WTRU per il quale è stata stabilita una connessione tra il supporto WTRU e l'apparecchiatura ricevente che può essere sia un altro WTRU o un server, l'MPE costringe il core network o il gateway o il RAN, o una loro combinazione a creare un canale dedicato, invece del canale predefinito standard, per la comunicazione mediale già stabilita.

In altre parole, il MPE, a seconda di ciò che la politica dice di un dato WTRU, costringe la rete a far fluire i pacchetti in un canale avente una migliore QoS invece di quella predefinita già assegnato al WTRU.

Un canale dedicato è un canale che trasporta un flusso di dati specifico, identificato dal TFT (Traffic Template Flow), con un dato QoS. Un canale è considerato un contesto di informazioni di trasmissione o un percorso di caratteristiche definite, ad esempio capacità, ritardo, priorità e / o tasso di errore bit. È possibile stabilire un numero di canali tra un gateway di una rete di comunicazione mobile e un WTRU, ad esempio, un telefono cellulare o un altro tipo di terminale mobile. Un canale può effettuare un traffico dati in direzione downlink (DL) dalla rete all'apparecchiatura dell'utente, e può trasportare traffico di dati in direzione uplink (UL) dall’attrezzatura utente alla rete. Nel gateway e nell’UE, il traffico dati, che comprende una pluralità di pacchetti di dati IP (IP: "Internet Protocol", che può essere l'IP versione 4, indicato anche come IPv4 o IP Versione 6, indicato anche come IPv6) può essere filtrato, ad esempio, utilizzando i filtri dei pacchetti IP 5-tuple, indirizzando in tal modo i pacchetti di dati IP a un canale desiderato.

Facendo riferimento alla figura 7, è fornito un diagramma di flusso descrivente il funzionamento del MPE 500 per assegnare un canale dedicato con Quality of Service (QoS) garantita per una chiamata VoIP richiesta da una WTRU. Lo stesso diagramma di flusso di fig. 7 può essere applicato a qualsiasi altra sessione di supporto, non solo sessioni VoIP. Il WTRU è già stata collegata con successo al core network, un canale di default è stato creato e una chiamata VoIP, cioè, una sessione di comunicazione mediale, è stata istituito con il canale di default. Nel 402, i MPE 500 filtra i messaggi per rilevare una chiamata VoIP stabilita con successo che:

• si è basata su una segnalazione VoIP (SIP) con un server VoIP presente nella "Lista di server VoIP consentiti per canali dedicati" 304 e;

• non ha violato le politiche di "chiamate in entrata non permesse” 307 o "Chiamate in uscita non permesse" 308 e;

• non ha comportato la chiamata dell'utente a un numero o un identificativo utente che fa parte dell' "Elenco dei numeri di chiamate VoIP non consentiti" 309.

In altre parole, tutte le esigenze della politica applicabile al WTRU 101 che ha avviato la sessione di comunicazione mediale, WTRU identificato dal suo identificativo 302, e scritto in UPD 501, devono essere soddisfatte.

Una chiamata VoIP stabilita con successo è quella in cui la procedura SIP è stata completata con successo, la chiamata è stata accettata e il traffico voce sta per iniziare. Quando viene rilevato un tale stabilimento di chiamata VoIP, il MPE 500 salva i parametri della chiamata inclusi nei messaggi SIP come l’indirizzo IP del chiamante, l'indirizzo IP chiamato, fonte chiamante e porta di destinazione, sorgente chiamata e porta di destinazione. Il MPE 500 inoltre incrementa un contatore utilizzato per tenere traccia del numero di chiamate VoIP contemporanee. L’elaborazione procede poi sul passo 403.

Nel 403 il MPE 500 controlla l’elemento di informazione UPD 501 "Numero massimo di chiamate VoIP" 315 e il contatore di cui sopra per determinare se la chiamata stabilita che è stata rilevata supera il numero massimo di chiamate voce contemporanee permesso. Se il numero massimo viene superato poi dal 402 il processo continua nel passo 405 descritto di seguito. Se il numero massimo non viene superato, allora l'elaborazione continua con il passo 404.

Nel passo 404, il MPE 500 comunica con il Radio Access Network 104 e / o il core network 106 per stabilire un canale dedicato per la chiamata VoIP utilizzando i parametri salvati come i TFT (Traffic Template Flow) parametri dedicati al canale previsti dal 3GPP standard. L’MPE 500 continua a monitorare i messaggi di segnalazione delle chiamate VoIP stabilite. Quando è previsto che la chiamata sia terminata, il MPE 500 comunica con il Radio Access Network 104 e / o al Mobile Core Network 106 di abbattere il canale sopra dedicato. L'MPE 500 decrementa anche il contatore utilizzato per tenere traccia del numero di chiamate VoIP contemporanee.

Lo stesso diagramma di flusso si applica allo stesso modo per qualsiasi applicazione diversa dal VoIP utilizzando per esempio gli elementi informativi del profilo utente nel database 501 "Elenco dei server video permessi per canali dedicati" 305 e "Lista di server consentiti per canali dedicato utilizzando l'applicazione X" 306. In questo caso, l’MPE 500 filtra pacchetti per rilevare la costituzione ottimale di una connessione al server di applicazione dato. Salva i parametri della connessione, come la fonte o l'indirizzo IP del client e l'indirizzo IP della porta, destinazione o del server e la porta, e li utilizza come TFT del canale dedicato per stabilire un canale dedicato. Utilizzando gli stessi principi di cui sopra, saranno stabiliti canali dedicati solo per un numero di comunicazioni contemporanee fino al numero di elemento di informazione UPD "Numero massimo di comunicazioni che utilizzano l'applicazione X" 316.

Più in dettaglio, viene eseguito un controllo in 503 per determinare se la priorità di accesso è abilitata. Se la priorità di accesso è abilitata, viene eseguito un controllo a 504 e 507 per determinare se la modalità di priorità di accesso è uguale a "Emergenza" o "Prelazione". Se la modalità di priorità di accesso = emergenza, l'elaborazione avviene in 505 per determinare se l'utente che si collega ha un accesso prioritario Livello 303 (che può essere letto dal UPD 501), che è inferiore alla soglia di emergenza. Se è inferiore alla soglia di emergenza, allora all'utente collegato viene negato l'accesso a 506, altrimenti è consentito l'accesso a 512. L’MPE 500 può negare l'accesso a 506 bloccando i relativi messaggi di segnalazione relativi all'utente richiedente una connessione, in modo che essi non vengano elaborati dal Mobile Core Network 106, e rispondendo con segnalazione contenenti la causa di rifiuto appropriata, nel caso in cui la priorità livello della WTRU sia inferiore alla soglia di emergenza. Scegliendo la causa appropriata di rifiuto, il MPE 500 è in grado di fare in modo che il terminale mobile dell'utente non tenti nuovamente una connessione per un lungo periodo. L'MPE 500 può consentire l'accesso a 512, lasciando il relativo messaggio di segnalazione attraverso il Mobile Core Network 106 per la normale elaborazione. L’MPE 500 può anche ottenere gli stessi risultati per la comunicazione con il Mobile Core Network 106 istruendolo a negare l'accesso all’ utente che si connetta al posto di bloccare i messaggi.

Invece, se la modalità di priorità di accesso è uguale a "Prelazione" nel 507, un altro controllo è realizzato in 508 per determinare se il numero totale di utenti attualmente connessi alla rete ha raggiunto la soglia di priorità. Se la soglia di priorità non è stata raggiunta allora nel 512 è consentito l'accesso alla rete all'utente che si connette. L’MPE 500 può consentire l'accesso a 512, lasciando il relativo messaggio di segnalazione attraverso il Mobile Core Network 106 per la normale elaborazione.

Invece, se è determinato nel 508 che il numero totale di utenti attualmente connessi alla rete ha raggiunto la soglia di priorità, in 509 l'elenco di utenti attualmente connessi viene analizzato per determinare l'utente o gli utenti che hanno il più basso livello di priorità di accesso 303 (lettura dal UPD 501). Utilizzando queste informazioni nel 511 viene effettuata una verifica per determinare se il livello di priorità di accesso 303 dell'utente connesso è maggiore del livello di priorità di accesso più basso tra gli utenti già connessi che erano stati determinati in 509. In quest'ultimo caso, cioè se la priorità di accesso è maggiore, l'elaborazione procede a 513 dove la connessione dell'utente (o di uno degli utenti) avente il più basso livello di priorità di accesso è terminata per fare spazio per l'utente in fase di collegamento. Successivamente 512 viene eseguito come sopra. Invece se nel 511 la priorità di accesso Livello 303 dell'Utente in fase di collegamento non è superiore al più basso livello di priorità di accesso tra gli utenti già connessi allora l’elaborazione procede a 506 come sopra descritto, dove all'utente in fase di collegamento è negata la connessione. Se l'utente ha l'accesso negato, il processo riparte dai 401 iniziali.

Facendo riferimento alla Figura 8, è fornito un diagramma di flusso per descrivere il funzionamento della PCU 502 e / o MPE 500 per l'implementazione di un esempio di algoritmo di priorità che utilizza le informazioni di livello di priorità 303 nel UPD 501 per garantire l'accesso alla rete agli utenti ad alta priorità in ambienti mission-critical.

L'algoritmo inizia al 701. Se un WTRU richiede una nuova connessione (denominata "Connessione Utente") come determinato in 702, viene eseguito un controllo in 703 per determinare se la priorità di accesso è abilitata. Se la priorità di accesso è abilitata, viene eseguito un controllo a 704 e 707 per determinare se la modalità priorità di accesso è uguale a "Emergenza" o "Prelazione". Nel primo caso, la lavorazione avviene in 705 per determinare se l'utente in fase di collegamento ha un accesso con Livello di priorità 303 (che può essere letto dal UPD 501) che è inferiore alla soglia di emergenza. Se è inferiore alla soglia di emergenza, allora all’utente in fase di collegamento viene negato l'accesso a 706, altrimenti è consentito l'accesso a 712. La PCU 502 e / o 500 MPE possono negare l'accesso a 706 bloccando i messaggi di segnalazione relativi all'utente richiedente una connessione, in modo che essi non verranno elaborati dal Mobile Core Network 106, e rispondendo con segnalazione contenente l'appropriata causa di rifiuto. Scegliendo la causa di rifiuto appropriata la PCU 502 e / o MPE 500 è in grado di impedire al terminale mobile dell'utente di tentare nuovamente una connessione per un lungo periodo. La PCU 502 e / o 500 MPE possono permettere l'accesso a 712, lasciando il relativo messaggio di segnalazione attraverso il Mobile Core Network 106 per la normale elaborazione. La PCU 502 e / o 500 MPE possono ottenere gli stessi risultati per la comunicazione con il Mobile Core Network 106 istruzione istruendola a negare l'accesso all’ utente che si connette al posto di bloccare i messaggi.

Invece, se la modalità di priorità di accesso è uguale a "prevenzione" in 707, un altro controllo è realizzato in 708 per determinare se il numero totale di utenti attualmente connessi alla rete ha raggiunto la soglia di priorità. Se la soglia di priorità non è stata raggiunta poi nel 712, all'utente che si connette, è consentito l'accesso alla rete. La PCU 502 e / o 500 MPE possono permettere l'accesso a 712, lasciando il relativo messaggio di segnalazione attraverso il Mobile Core Network 106 per la normale elaborazione.

Invece, se è determinato nel 708 che il numero totale di utenti attualmente connessi alla rete ha raggiunto la soglia di priorità, in 709 l'elenco di utenti attualmente connessi viene analizzato per determinare l'utente o gli utenti che hanno il più basso livello di priorità di accesso 303 (lettura dal UPD 501). Utilizzando queste informazioni in 711 viene effettuata una verifica per determinare se il livello di priorità di accesso 303 dell'utente connesso è maggiore del livello di priorità di accesso più basso tra gli utenti già connessi che era stato determinato in 709. In quest'ultimo caso, l'elaborazione procede a 713 dove la connessione dell'utente (o di uno degli utenti) avente il più basso livello di priorità di accesso è terminata per fare spazio per l'utente in fase di collegamento. Successivamente 712 viene eseguita come sopra. Invece se nel 711 la priorità di accesso Livello 303 dell'Utente in fase di collegamento non è superiore al più basso livello di priorità di accesso tra gli utenti già connessi, l’elaborazione procede, quindi, a 706 per negare l'accesso all'utente in fase di collegamento come descritto sopra.

Facendo riferimento alla Figura 9, è fornito un diagramma di flusso che descrive il funzionamento del MPE 500 e / o 502 PCU per attuare un esempio di un algoritmo di priorità che utilizza le informazioni di livello di priorità 303 nel UPD 501 per garantire l'accesso alla rete utenti ad alta priorità in ambienti missioncritical.

L'algoritmo inizia in 601. In 602 se la modalità priorità di accesso è uguale a "Emergenza" allora nel 603 la lista degli utenti collegati alla rete viene controllata per determinare se uno qualsiasi di questi utenti abbia un accesso prioritario livello 303 (che può essere letto dal UPD 501), che è inferiore alla soglia di emergenza. Se sono trovati tali utenti, questi sono poi scollegati dalla rete in 604. L'MPE 500 e / o 502 PCU può disconnettere gli utenti, generando i relativi messaggi di segnalazione che causano la fine della connessione del terminale mobile dell'utente. Questi messaggi di segnalazione possono essere inviati dal MPE 500 e / o PCU 502 direttamente al Radio Access Network 104 o il MPE 500 e / o PCU 502 può comunicare con il Mobile Core Network 106, al fine di istruirlo per terminare la connessione e inviare i messaggi di segnalazione necessari.

Nelle figure 10-14, sono dettagliate due forme preferite di due diverse sessioni di comunicazioni mediali secondo il metodo dell'invenzione. La procedura iniziale, come la ricerca e una procedura di collegamento RRC tra l'apparecchiatura dell'utente WTRU e la stazione base non è spiegato e realizzato secondo lo standard della rete coinvolta.

I vari elementi della rete 100'' con riferimento alle Figg.10-14 sono quelli già descritti con riferimento alle figg.3 e 4.

Anche se i nomi dei nodi delle fig. 10-14 sono relativi a una rete LTE (EUTRAN), questi nomi non sono limitativi e il flusso di traffico può essere lo stesso in un'altra rete utilizzando diversi protocolli. Reti preferite sono UMTS, LTE e LTE-Advanced.

Con iniziale riferimento alla fig. 10, la prima fase è una procedura di collegamento del WTRU con la rete, procedimento che comprende anche un procedimento di autenticazione basato sul identificativo utente, in questo caso l'IMSI del WTRU (passo 1s). In una versione, l'IMSI potrebbe anche non essere disponibile in questa fase e può essere richiesto dal MME dopo l'attacco WRTU. Come già accennato, questa procedura iniziale non è rilevante per l'invenzione e dipende dalla rete e sul protocollo.

Come esempio di una fase di collegamento 1s, nel EUTRAN, il WTRU invia una RRC_CONNECTION_REQUEST alla stazione base (BTS indicata con 10 in fig.). Se la stazione base BTS accetta la richiesta, invia un RRC_CONNECTION_ACCEPT a WTRU. Alla ricezione di questo messaggio di accettazione, viene stabilita la connessione RRC. Per completare la procedura, il WTRU invia messaggio RRC_CONNECTION_COMPLETE insieme a un messaggio NAS. Per EUTRAN, il messaggio NAS è un PDN Connectivity Request, che è un messaggio in cui il WTRU informa la rete che ha bisogno di un canale per trasmettere dati. Alla ricezione di un messaggio RRC_CONNECTION_COMPLETE insieme con il messaggio NAS, la stazione base estrae il messaggio NAS, e lo inserisce in un messaggio S1AP (Initial WTRU Message) e lo passa al MME. Questo passo 1s è indicato con "Attach request" 1s in fig. 10. Inoltre, le informazioni relative alla IMSI del WTRU sono anche inviate attraverso questo messaggio al MME.

L'aspetto importante per l'invenzione è che nella procedura di collegamento 1s, o dopo la stessa, l'identificativo dell'utente (IMSI) del WTRU viene inviato al core network (ad esempio per l'MME).

La PCU, secondo l'invenzione, può intercettare e analizzare tutti i messaggi all'interno del core network, cioè tutti i messaggi che vengono inviati e ricevuti dal / al RAN (in questo caso le BTS) e dal / al gateway (in fig.10 indicato come PGW / SGW) alla rete IP esterno. Preferibilmente, la PCU è responsabile del controllo e l'analisi di tutti i messaggi relativi alla segnalazione (in cui la segnalazione si intende in senso stretto, cioè di segnalazione radio). Pertanto, si possono analizzare i messaggi inviati dalla stazione base BTS alla MME durante la fase di collegamento 1s e rilevare quindi la IMSI e, facoltativamente, ma preferibilmente, anche la posizione del WTRU. Di conseguenza, viene fatta una richiesta al Database delle policy utente UPD se l'IMSI del WTRU che richiede il collegamento appartiene agli IMSI elencati nel database UPD, passo 3s. In caso affermativo, il download può avvenire dal UPD al MPE (via PCU o direttamente) di tutte le informazioni contenute nell’ UPD relative al WTRU avente il dato IMSI. In alternativa l'UPD non ha bisogno di essere interrogato o scaricato poichè tutte le voci della UPD 501 sono disponibili nella PCU e / o MPE in quanto erano state precedentemente scaricate.

In questo momento, a seconda delle pochissime informazioni disponibili, ci può essere opzionalmente già un'azione della PCU dell'invenzione. Per esempio, nel caso non sia consentito l'IMSI del WTRU secondo le informazioni recuperate dal UPD per connettersi alla rete dall'area specifica in cui si trova, il MPE costringe il MME e / o la BTS a non accettare la connessione, ad esempio per bloccare lo stesso. In alternativa o in aggiunta, il collegamento viene anche abbattuto nel caso ci sia un traffico troppo elevato (ad esempio al di sopra di una certa soglia) all'interno della rete e la IMSI del WTRU non abbia una priorità sufficientemente elevata per chiudere il collegamento di altri WTRUs.

Questi passaggi opzionali non sono mostrati in fig.10.

Nel caso al WTRU sia permesso di comunicare con la rete, il flusso dei messaggi continua.

Una procedura di sicurezza e di autenticazione ha luogo in 5s.

Nella fase seguente, secondo lo standard, viene creato un canale di default per il WTRU (passaggi 7s-12s). I dettagli di questa fase non sono rilevanti per l'invenzione, l'unica parte rilevante è che da questa procedura di stabilimento del canale predefinito, la PCU è in grado di recuperare l'indirizzo IP del WTRU.

A seguito della richiesta di collegamento iniziale, un messaggio di richiesta di sessione (passo 6s) viene inviato dal MME al gateway SGW / PGW alla rete IP esterna e una risposta è ottenuta dalla stessa (fase 7s).

Ad esempio, MME legge il messaggio NAS inviato durante la fase di collegamento 1s e capisce che WTRU ha bisogno di un canale di default e un indirizzo IP. MME crea un messaggio GTP Create Session Request - 6s - e la inoltra al SGW. A questo punto MME assegna un ID EPS al canale. Questo canale è il canale di default.

A titolo di esempio, considerando GTPv2 interfaccia S11 based, l'MME invia la GTP Create Session Request al S-GW che include FTEID (fully qualified tunnel end point identifier) per lo user plane, EBI, richiesta QoS, l'indirizzo IP di WRTU (settato a 0 se si utilizza l'assegnazione dinamica dell'indirizzo IP).

Una volta che l'MME riceve la create session response dalla S / P-GW, l'MME riceve l'indirizzo IP da inviare al WTRU, FTEID per l'entità user plane S1-U di S-GW, passo 7s.

A questo punto, la PCU conosce l'indirizzo IP del WRTU dato che esso rileva e analizza tutti i messaggi all'interno del core network.

Così il messaggio di configurazione per creare il canale di default viene inviato dal MME al WTRU, passo 8s. Dopo la risposta, 9s, il WTRU può trasmettere dati, essendo il collegamento completo, 10s.

In un esempio più dettagliato di questi passaggi 8 e 9, MME riceve la risposta di sessione della fase 7s. Prende il SGW TEID, EBI e valori QoS e li inserisce nel contesto del messaggio Activate Bearer Context Request NAS e lo invia alla stazione base nel S1AP ERAB setup request message. A questo punto il canale EPS viene stabilito e un Canale Radio deve essere stabilito in modo che il WTRU possa iniziare la trasmissione dei dati.

ERAB (EUTRAN radio access bearer) Setup Request fa lo stesso. La stazione base riceve il messaggio S1AP, estrae il messaggio NAS, lo colloca in un RRC_CONFIGURATION_REQUEST e lo invia a WTRU. Anche la stazione base BTS legge i valori QoS e SGW FTEID per la trasmissione di dati in uplink (passo 8s).

WTRU risponde con un messaggio RRC_CONFIGURATION_COMPLETE. Inoltre, avvia l'elaborazione del messaggio NAS. Una volta che lo strato NAS approva l'istituzione del canale di default, lo stesso è informato con la stazione base in un RCC UL Info UL Transfer Message. Il messaggio NAS Activate Default Bearer Context Request Context Request Accept Message viene allegato al messaggio RRC. A questo punto il WTRU conosce l'ID del canale, un indirizzo IP e corrispondenti valori di QoS.

La stazione base BTS informa che WTRU ha accettato il canale di default da MME in S1-AP UL NAS transport message e il messaggio NAS è collegato ad esso. Anche la stazione base indica la sua FTEID per la comunicazione da user plane a MME (passo 9s).

MME indica preferibilmente le informazioni dell’user plane della stazione base al SGW gateway. Questo viene fatto in un GTP message modifier bearer request 11s. SGW "impara" le informazioni dello user plane della stazione base da esso. Dopo questo scambio di dati user plane 12s, i dati affluiranno sul canale di default appena stabilito.

Il canale di default assegnato preferibilmente rimane finché WTRU è collegato. Il canale di default è un servizio di best effort. Ogni canale di default viene fornito con un indirizzo IP. WTRU può avere ulteriori canali di default e, quindi, la fase sopra descritta può essere ripetuta più volte per ogni canale. Ogni canale di default ha un proprio indirizzo IP e la PCU "impara" ogni indirizzo IP separato come visto sopra. Preferibilmente, QCI 5 a 9 (Non-GBR) può essere assegnato al canale predefinito.

Il QCI è uno scalare che denota un insieme di caratteristiche di trasporto (canale con / senza tasso garantito di bit, priorità, budget di ritardo del pacchetto, tasso di perdita di pacchetto) e utilizzato per dedurre specifici parametri dei nodi che controllano il trattamento dei pacchetti di inoltro (ad esempio, gestione, pesi soglie di ammissione, soglie di gestione delle code, configurazione del protocollo a livello del collegamento, ecc.)

Ciascun flusso di pacchetti viene mappato su un singolo valore QCI a seconda del livello di servizio richiesto dall'applicazione. L'utilizzo del QCI evita la trasmissione di un set completo di parametri QoS, correlato con le interfacce di rete e riduce la complessità di negoziazioni di QoS.

Preferibilmente, il canale stabilito è un portatore EPS, tra la stazione base e il gateway SGW / PGW alla rete IP esterna.

Al termine della creazione del canale predefinito, la PCU ha appreso, da un'analisi dei messaggi scambiati all'interno del core network, la IMSI e IP del WTRU. Inoltre, preferibilmente sa anche la posizione del WTRU (che può cambiare nel tempo, quindi l'applicazione delle regole applicabili al WTRU, che possono dipendere dalla sede della medesima, possono anche cambiare con il tempo).

È da intendersi che sebbene quanto sopra è stato descritto con riferimento ad una rete EUTRAN, può essere applicato a qualsiasi rete. L'aspetto importante è che nella rete in questione ci deve essere una procedura in cui il WTRU può collegarsi alla rete e quindi un canale può essere stabilito. Secondo l'invenzione, la rete include un Mobile Policy Engine e / o Policy Control Unit che può fare una analisi di tutti i pacchetti all'interno del core network in modo che un filtro possa essere imposto, non appena è stabilito il canale.

Secondo l'invenzione, a seguito della positiva procedura di collegamento e stabilimento del canale predefinito, un filtro di pacchetti è configurato come da passo 2s descritto nel seguito.

Avviene lo scaricamento dal MPE di tutte le politiche per quella specifica WTRU che ha ottenuto un canale di default dal UPD 501. Pertanto al passo 2s il MPE imposta un filtro per quella WTRU specifica avendo l'identificativo utente specifico o IMSI. Per ogni pacchetto che è diretto da / per l'WTRU avente l'identificativo utente specifico per il quale il filtro è stato istituito con l'MPE, il MPE controlla se vi è una corrispondenza tra il filtro scaricato e il pacchetto analizzato. Questo controllo viene effettuato solo se esistono politiche di filtro per l'utente specifico.

I filtri di cui sopra sono descritti con riferimento alla figura 3. Pertanto, ad esempio, ogni pacchetto deve essere controllato per quanto riguarda l'indirizzo IP di destinazione, ad esempio se l'indirizzo IP appartiene a un server consentito o meno; deve essere controllato per quanto riguarda il tipo di sessione di comunicazione mediale che viene richiesta (ad esempio audio, video, ecc); deve essere controllato per quanto riguarda la quantità di traffico già presente nella la rete, il tipo di campo di protocollo (ad esempio se il pacchetto appartiene ad un protocollo di trasporto consentito), deve essere verificato rispetto alla porta di destinazione del protocollo di trasporto utilizzato (ad esempio, se la porta utilizzata è consentita), deve essere verificato rispetto ai campi protocollo dell’applicazione o messaggi come registrazione SIP (ad esempio, se l'utente è autorizzato a registrarsi ad un certo server), SIP invite (ad esempio se l'utente è autorizzato ad avviare la comunicazione verso un determinato utente SIP), ecc

Secondo una fase opzionale dell'invenzione, con riferimento ora alla fig. 11, viene creato un canale dedicato per la segnalazione SIP. Il Mobile Policy Engine MPE invia un comando (passo 13s) al gateway SGW / PGW per richiedere alla stessa di creare un tipo di trasporto dedicato. Essendo un canale dedicato per la segnalazione SIP, il filtro realizzato secondo l'invenzione indirizza tutto il traffico di dati SIP nel canale specifico creato proveniente dal WTRU, sulla base di:

Indirizzo IP di origine, IP di destinazione e la porta di destinazione UDP (di solito 5060).

Come detto il MPE dell'invenzione è in grado di analizzare tutti i pacchetti all'interno del core network e quindi è anche in grado di filtrare lo stesso.

Preferibilmente, il canale dedicato utilizza i modelli dei flussi di traffico (TFT) per dare un trattamento speciale a servizi specifici.

Il gateway SGW / PGW a causa del comando di passo 13s ricevuti dal MPE istruisce l'MME - passo 14s - per creare il richiesto canale dedicato. Il canale dedicato è realizzato come un canale dedicato "standard" secondo il protocollo usato. Ad esempio, il SGW può inviare come passo 13s GTP Create Bearer Request con LBI, nuovi valori di QoS, PTI e SGW FTEID per lo user plane di MME.

Al momento del ricevimento del Create portatore, MME crea un NAS Message Activate Dedicated Bearer Context Request, lo mette in un S1AP ERAB setup request e lo invia alla stazione base. La stazione base legge il messaggio NAS, memorizza i valori di FTEID SGW user plane e QoS. Quindi inoltra il messaggio NAS nella WTRU nella richiesta di riconfigurazione RRC. Queste due fasi sono riassunte nella fase 15s di fig.11.

Questo canale per la segnalazione SIP, o per qualsiasi altro tipo di segnalazione che può essere utilizzato per dare la priorità al momento della richiesta di una sessione mediale, ad esempio HTTP streaming video, stabilimento di VoIP sessioni, di gioco, comunicazione macchina a macchina, ecc, può essere creato subito dopo la costituzione del canale di default per un dato WTRU (cioè non appena viene creato il canale di default, il MPE costringe il SGW / PGW e MME a creare un canale dedicato per il traffico di segnalazione, indipendentemente dal fatto che il WTRU abbia inviato ogni pacchetto di segnalazione per richiedere una sessione mediale.

Alternativamente, il MPE può attendere per istruire il MME a creare il canale dedicato per il traffico di segnalazione per il primo pacchetto di tale segnalazione. Ad esempio, può aspettare che rilevi i primi pacchetti di segnalazione SIP che richiedono un collegamento SIP.

Un canale dedicato può essere GBR o non-GBR (mentre un canale di default può essere solo non-GBR).

Indipendentemente dall’istituzione di un canale dedicato per la segnalazione, il metodo dell'invenzione comprende una fase di una creazione di un canale dedicato per il flusso di traffico mediale, se sono soddisfatte le condizioni imposte dal filtro. Il seguente è un esempio in dettaglio del metodo già descritto con riferimento alla fig.7.

Facendo ora riferimento alla fig.12, nel seguito, la creazione di una sessione di comunicazione mediale è descritta tra l'WTRU ed un "utilizzatore finale". L'utente finale può essere un server, o un WTRU aggiuntivo collegato alla rete. La seguente è descritta con riferimento ad una sessione di comunicazione che utilizza VoIP (SIP) Session Initiation Protocol per iniziare, modificare e terminare la sessione, comunque qualsiasi altra sessione di comunicazione mediale e corrispondenti protocolli di segnalazione possono essere utilizzati.

Sessioni di supporto possono essere avviate da diversi protocolli quali SIP, ma anche HTTP, RTSP per lo streaming video, o anche protocolli di livello inferiore, come L3 tunnel initialization, ecc.

Al fine di iniziare la comunicazione, come esempio, un invito SIP viene inviato dal WTRU. Il WTRU qui indicato è il WTRU che in fig. 10 è collegato alla rete e per il quale il filtro è stato stabilito dalla MPE appena il canale di default è stato creato dal MME.

L'INVITE è un metodo SIP che specifica l'azione che il richiedente (Calling Party) vuole che il ricevitore (Called Party) prenda. La richiesta INVITE contiene una serie di campi di intestazione. Campi di intestazione sono chiamati attributi e forniscono ulteriori informazioni su un messaggio. Quelli presenti in un INVITE includono un identificatore univoco per la chiamata, l'indirizzo di destinazione, indirizzo Calling Party, indirizzo Called Party e informazioni sul tipo di sessione che il richiedente vuole stabilire con il ricevitore.

I pacchetti appartenenti al messaggio SIP INVITE, passo 19s, possono fluire o nel canale dedicato per segnalazione SIP se tale canale è stato stabilito a seconda della fase facoltativa del metodo dell'invenzione sopra descritta con riferimento alla fig. 11, oppure possono fluire nel canale predefinito stabilito secondo le fasi 1s-12s.

Il messaggio SIP è diretto al "utente finale" (cioè Called Party) con cui il WTRU vuole stabilire una comunicazione, ad esempio un altro WRTU, o ad un server SIP (o SIP Proxy), che può essere solo una destinazione intermedia del SIP invite (per es SIP proxy o server SIP). Per esempio, nel caso di chiamate VoIP, il server SIP reindirizza il messaggio di invito ad un altro WTRU che può accettare (o rifiutare) il SIP invite.

Pertanto, spesso il messaggio di SIP INVITE non contiene l'indirizzo IP finale del "utente finale", che normalmente non è nemmeno noto al WTRU. Il SIP INVITE quindi contiene preferibilmente ad esempio l'indirizzo IP di un proxy SIP e INVITE Request viene inviata al proxy. Il corpo della INVITE Request trasporta un messaggio SDP (Session Description Protocol) che fornisce i parametri (codec, indirizzo IP, porta), la persona chiamata dovrà inviare il flusso RTP al chiamante. Il proxy SIP, in questo diagramma di flusso di fig. 12 identificato con il "server SIP", risponde con "100 Trying" e poi inoltra la INVITE Request all'utente finale di destinazione (cioè la WTRU da contattare o addirittura un server aggiuntivo). Il proxy server aggiunge un’ intestazione Via: al messaggio. Per conoscere l'indirizzo IP dell'utente finale, il proxy SIP ha preferibilmente accesso ad un database di posizione e conosce quindi gli indirizzi IP di tutti gli utenti registrati (la più semplice attuazione di questo è tale che il server di registrazione e il proxy siano la stessa applicazione).

L '"utilizzatore finale" può accettare la chiamata (o non tenerne conto) e invia la risposta "200 OK", vedere fase 20s. Il corpo della risposta contiene un messaggio SDP in modo che il WTRU sappia dove inviare il flusso RTP. Il server proxy inoltra la risposta al WTRU.

Il WTRU conferma la ricezione del "200 OK" con il messaggio di ACK (non mostrato). Il server proxy inoltra l'ACK per l'utente finale. A questo punto, la chiamata è stata stabilita ed entrambe le parti iniziano a inviare i loro flussi RTP, che è la sessione mediale del presente esempio. Questo metodo può essere ugualmente applicato ad altri tipi di flussi mediali che non utilizzano RTP.

Pertanto è stata stabilita una sessione mediale tra il WTRU e l'utente finale.

L'MPE è in grado di rilevare e analizzare tutti i pacchetti all'interno del core network. Abbiamo anche visto che per la WTRU specifica inviante un SIP invite è stato stabilito un filtro dal MPE. Così il MPE può rilevare, dall'analisi del flusso di pacchetti, che una sessione di comunicazione mediale è stata stabilita tra il WTRU e l'utente finale. Inoltre, grazie all'analisi dei pacchetti, il MPE può rilevare anche l'indirizzo IP dell'utente finale, che può cambiare costantemente, come nel presente esempio. In questo esempio, l'indirizzo IP del server SIP non è lo stesso come l'indirizzo IP del "utilizzatore finale", che è per esempio un'altra WTRU a cui la chiamata VoIP era diretta. Il MPE deve essere in grado di tenere traccia dinamicamente dell'indirizzo IP del WTRU e dell'utilizzatore finale della comunicazione mediale.

Il SIP OK menzionato può quindi essere inviato dal server SIP se questo è l'utente finale o dall'utilizzatore finale, come il WTRU aggiuntivo.

I pacchetti da / verso il WTRU per cui è stato stabilito il filtro sono quindi controllati nel modo seguente:

Quando il MPE ha ricevuto un pacchetto deve recuperare l'indirizzo IP dell'utente finale a cui è diretto e poi controllare se l'indirizzo IP dell'utente finale e / o Called Party (ad es identificativo dell'utente o numero telefonico) è elencato tra gli indirizzi IP e numeri consentiti o identificatori (cfr. elementi 304, 306, 309 della UPD in fig.6).

In caso affermativo, si controlla il tipo di sessione mediale che è stato stabilito. Per esempio, la politica potrebbe consentire un canale dedicato per la voce, ma non per i video o viceversa.

Per il traffico VoIP, il filtro è costituito da un indirizzo IP sorgente, indirizzo IP di destinazione, porta di origine UDP e l'indirizzo di destinazione UDP, in altre parole, tutti i pacchetti identificati da un tale IP sorgente e destinazione, come una sorgente e destinazione UDP vengono spostati nel canale dedicato, che è stato creato dalla MME costretto dal MPE. Così i pacchetti voce possono fluire nel canale dedicato avente una QoS migliore del canale predefinito.

Se i pacchetti soddisfano tutti i requisiti scritti nella politica scaricata dalla PCU nel MPE dal UPD (o in alternativa già scaricata da MPE dal UPD), un canale dedicato viene creato e i pacchetti relativi alla sessione di comunicazione mediale possono fluirvi (per esempio voce, nel caso di una connessione VoIP).

Sorgono due possibilità secondo l'invenzione.

In un primo scenario in cui il canale dedicato per la segnalazione SIP è stato stabilito in base alle fasi 13s-18s, il MPE comanda il gateway SGW / PGW di modificare il canale dedicato esistente, passo 21s. Preferibilmente, la modifica è tale che la GBR è aumentata rispetto alla GBR richiesta per il canale dedicato utilizzato solo per la segnalazione di trasferimento.

La variazione GBR del canale dedicato, tramite il MME, è realizzata secondo lo standard, in particolare nella fase 22s il gateway SGW / PGW, seguendo il comando dato dal MPE (passo 21s), invia una richiesta al MME per modificare il canale dedicato (step 22s), indicando la nuova QCI e GBR. MME richiede alla stazione base e al WTRU di modificare il canale EPS dedicato (23s) e il MME poi riceve un messaggio di accettazione della modifica (passo 24s). La risposta viene quindi inoltrata al gateway (passo 25 anni) e una conferma della modifica viene inviata dal gateway al MPE (passo 26s).

È da intendersi che la richiesta del canale dedicato è inizializzata dalla MPE all'interno del core network, e non dall'esterno dello stesso. Dopo i passi 22s-25s per la costituzione del canale dedicato già esistente, il gateway invia un riconoscimento (passo 26s) per l'MPE per riconoscere il successo del cambiamento nel GBR del canale dedicato.

Alternativamente, sempre con riferimento agli stessi numeri 21s-26s, qualora non sia stabilito alcun canale dedicato per la segnalazione SIP, e i pacchetti SIP invite fluiscano nel canale predefinito, nel passo 21s MPE, avendo compreso dall’analisi dei pacchetti che il WTRU per cui il filtro è attivo e un canale predefinito è stabilito ha stabilito inoltre con successo un collegamento mediale, invia un comando al gateway per creare un nuovo tipo di trasporto dedicato. I passi 22s-25s in cui viene creato il canale dedicato sono analogici per misure 14s-17s in cui è stato creato il canale dedicato per la segnalazione SIP (il QoS potrebbe essere diverso).

Tutti i pacchetti relativi alla sessione di comunicazione mediale (in questo caso la voce della chiamata VoIP) stanno dunque fluendo all'interno del canale dedicato così creato (o modificato) e il MPE fornisce i filtri necessari.

Come mostrato in fig. 13, quando uno dei WTRU riaggancia, si invia la richiesta BYE e il SIP proxy inoltra il messaggio per l'altra parte. L'altra parte risponde alla richiesta BYE con "OK 200" (di nuovo, il server proxy inoltra la risposta dall'altra parte). Entrambe le parti interrompono l'invio di dati RTP e la chiamata è finita. Questo è il passo 27s raffigurato.

Lo stesso può avvenire se una delle due parti è inattiva. Tale inattività potrebbe essere determinata dal messaggio 27s (BYE) o utilizzando un metodo di "rilevamento di inattività". In quest'ultimo caso il MPE può stabilire che l'inattività è verificata quando, in un dato periodo di tempo, esso rileva che nessun pacchetto mediale è stato scambiato dal WRTU. Secondo una fase facoltativa dell'invenzione, il GBR o comunque la QoS del canale dedicato può cambiare a seconda del flusso di traffico in rete. Per esempio, come descritto con riferimento alle fasi 22s-25s in cui è stato aumentato il GBR del canale dedicato, il GBR può anche essere diminuita. Con riferimento ora alle fasi 29s-32s, a seguito di un comando 28s dal MPE al gateway per diminuire il GBR del canale dedicato, l'MME, il WTRU e la stazione base diminuiscono il GBR del canale dedicato (in modo analogo a come descritto con riferimento ai passi 22s-25s). Alternativamente, invece di diminuire o comunque modificare la QoS del canale dedicato, lo stesso può essere abbattuto, sempre a seguito di un comando del MPE.

Al termine delle fasi decrescenti o di abbattimento 29s-32s, un acknowledge viene inviato al MPE (passo 33s).

La descrizione della creazione di un canale dedicato con riferimento a una procedura SIP è applicabile a qualsiasi altra comunicazione mediale che la WTRU desidera instaurare sia con un'altra WTRU o con un server (come il server proxy descritto sopra).

L'MPE costringe il core network, in particolare forza il gateway e / o l'MME a stabilire il tipo di trasporto dedicato, non appena viene stabilita la comunicazione mediale. La QoS del canale dedicato dipende dal database, cioè dalla WTRU e il suo IMSI, dalla sua posizione del WTRU; dal traffico nella rete e dal tipo di comunicazione mediale richiesto.

Come si è visto, la QoS può anche cambiare nel corso della stessa seduta, se le condizioni della rete cambiano.

Con riferimento ora alla fig. 14, assumendo che passi 1s-12s siano già stati eseguiti, cioè il WTRU sia collegato alla rete e un canale di default è stato già stabilito, il WTRU desidera avere una sessione di comunicazione mediale che include la visualizzazione video di un dato nome "video.flv ".

Opzionalmente, un canale dedicato per una segnalazione HTTP può essere determinato, come descritto per la segnalazione SIP in fig. 11. (ad esempio per tutti HTTP GET, 200Ok e 301 messaggi che coinvolgono un indirizzo IP del server video specificato)

Il WTRU invia quindi un richiesta HTTP GET ad un video server 40s per ottenere il video desiderato.

Generalmente, un messaggio di richiesta HTTP dal WTRU a un server comprende, entro la prima riga del messaggio, il metodo da applicare alla risorsa, in questo caso una procedura GET, l'identificatore della risorsa e la versione del protocollo in uso. Inoltre, è richiesta la forma URI assoluto quando la domanda si riferisce a un proxy. Al proxy è chiesto di inoltrare la richiesta e la manutenzione di essa da una cache valida, e restituire la risposta. Si noti che la delega può inoltrare la richiesta a un altro proxy o direttamente al server.

Il MPE istituisce un filtro con l'indirizzo IP del server video, che è la meta della prima richiesta HTTP GET.

In questo esempio, la risposta dal server video è un "301 Moved Permanently" 41s, il che significa che il video richiesto non è disponibile perché è stato definitivamente trasferito. In risposta 301, il server video include anche l'indirizzo IP del nuovo server che contiene il video, denominato server1.

Il MPE cambia quindi i filtri per tener conto del nuovo indirizzo IP della "destinazione finale" della sessione mediale che sta per essere stabilita.

Una nuova richiesta HTTP GET 42s viene così inviata dal WTRU al nuovo server 1 e in questo caso si ottiene una risposta 200 OK, cioè la WTRU scarica correttamente video 43s.

Anche in questo caso, alla creazione del collegamento mediale, i pacchetti sono controllati dal MPE e per i pacchetti della connessione mediale possono essere creati canali dedicati se i pacchetti soddisfano tutte le condizioni della politica.

Così, il MPE 500 da un'analisi dei pacchetti che scorrono nei core network e diretti da / per WTRU per il quale la politica è stata scaricata, rileva tutti i parametri da controllare con le regole di policy. Un tale controllo comprende verificare o aver verificato in detta banca dati se detto utente è autorizzato ad accedere a detto flusso mediale. Nel caso in cui i parametri corrispondono alle regole di policy, il canale dedicato per tale sessione di comunicazione è stabilito, cioè tutti i pacchetti della sessione mediale affluiscono al canale dedicato così creato.

Per il video http riportato nell'esempio il filtro deve essere l'URL del video (composto dall'indirizzo IP video e l'URI, che è il percorso del contenuto). Nel caso in cui un messaggio di reindirizzamento server venga ricevuto, il filtro viene aggiornato per includere il nuovo URL del video (composto da l'indirizzo IP del server a cui il contenuto è stato reindirizzato e l'URI). Il filtro che mappa il contenuto prioritario al canale dedicato sarebbe composto da porta TCP sorgente (http in questo caso), porta di destinazione TCP, indirizzo di destinazione (indirizzo UE) e l'indirizzo di origine (vedi sopra).

Avendo stabilito la connessione mediale dopo l'OK 200, come in fig. 12, il MPE comanda al gateway di creare un canale dedicato per la sessione mediale, in questo caso per visualizzare il video richiesto. Come spiegato sopra, un canale dedicato potrebbe essere già presente per la segnalazione HTTP, in questo caso la QoS di un tale canale dedicato già esistente viene modificata (migliorata) o un nuovo canale dedicato viene creato.

Così, il MPE comanda al gateway di modificare o creare un tipo di trasporto dedicato (passo 44s). I passi per realizzare il canale 45s-498s sono gli stessi di quelli descritti con riferimento alla fig.12.

Quando viene creato il canale dedicato, viene inviata una conferma al MPE (passo 49s).

Claims (23)

1. Rivendicazioni 1. Un metodo per il controllo di sessione di comunicazione mediale tra un utente (WTRU, 101) identificato da un identificativo utente (302) ed un dispositivo ricevente (101, server SIP, server video) attraverso un core network (106) e una rete IP (110.112) esterna a detto core network, detto utente accedente a detto core network tramite una rete di accesso radio (RAN, 104) e detta rete comprendente un gateway (PGW, 204) a detta rete IP esterna, il metodo comprendendo le fasi di: a. Controllo, quando detto utente (WTRU, 101) si connette a detto core network (106), di un database (UPD 501) per recuperare regole di policy applicabili a detto utente secondo l'identificativo utente (301) e che si riferiscono ad uno o più sessioni mediali; b. Identificazione dello stabilirsi di un canale di default (default bearer) per detto utente (WTRU, 101) su detto core network (106); c. Analisi di tutti i pacchetti di traffico provenienti da o diretti verso detto utente tra detta rete di accesso (RAN 104) e detto core network e / o un gateway (PGW, 204) di detta rete IP esterna (110.112); d. Controllo circa l'istituzione di una sessione della richiesta comunicazione mediale tra l'utente e il dispositivo ricevente; e. Determinazione, per ogni pacchetto appartenente alla sessione di comunicazione mediale stabilita, del tipo di sessione mediale richiesta e stabilita, degli indirizzi IP e delle porte di detto utente e detto dispositivo ricevente, tra cui la sessione mediale è stabilita; f. forzare tale core network (106) e / o rete di accesso radio (RAN 104) e / o detti gateway (PGW, 204) a creare, se tali regole lo consentono, un canale dedicato tra detto utente e detto gateway (PGW, 204) con Quality of Service per i pacchetti appartenenti alla sessione mediale già stabilita, detto qualità del servizio dipendente dalla sessione mediale specifica, detto canale dedicato essendo stabilito tra gli indirizzi IP e le porte correlate della sessione mediale già stabilita, detto canale dedicato essendo creato sulla base delle informazioni ricavabili da detti pacchetti appartenenti a detta sessione mediale stabilita e detto database (UDP 501). 2. Metodo secondo la rivendicazione 1, in cui, prima della creazione di un canale dedicato con Qualità di servizio per i pacchetti appartenenti alla sessione mediale già stabilita, è compreso il la fase atta a forzare tale core network (106) e / o rete di accesso radio (RAN 104) e / o gateway (PGW, 204) a creare, se tali norme lo consentono, un canale dedicato con Quality of Service per i pacchetti appartenenti ai messaggi di segnalazione della sessione mediale stabilita. 3. Metodo secondo la rivendicazione 1 o 2, in cui la fase atta a forzare il core network (106) e / o rete di accesso radio (RAN 104) e / o detto gateway (PGW, 204) a creare un canale dedicato comprende: a. Verifica in detto database (UPD, 501) se a detto utente (WTRU 101) è consentito stabilire una sessione di comunicazione mediale del tipo richiesto, e b. In caso affermativo, la creazione di detto canale dedicato. 4. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui la fase atta a forzare il core network (106) e / o rete di accesso radio (RAN 104) e / o gateway (PGW, 204) a creare un canale dedicato comprende: a. Determinazione della posizione geografica di detto utente; b. Verifica in detto database (UPD, 501) se a detto utente è consentito stabilire una sessione di comunicazione mediale, in detta posizione geografica, e c. In caso affermativo, la creazione di detto canale dedicato. 5. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui la fase atta a forzare il core network (106) e / o rete di accesso radio (RAN 104) e / o gateway (PGW, 204) a creare un canale dedicato comprende: a. Verifica in detto database (UPD, 501) se a detto utente è consentito stabilire una sessione di comunicazione mediale con detto dispositivo ricevente; ed b. In caso affermativo, la creazione di detto canale dedicato. 6. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui la fase di forzatura del core network (106) e / o rete di accesso radio (RAN 104) e / o gateway (PGW, 204) a creare un canale dedicato comprende: a. Determinazione del flusso mediale richiesto da detto utente; b. Verifica in detto database (UPD 501) se detto utente è autorizzato ad accedere a detto flusso mediale e c. In caso affermativo, la creazione di detto canale dedicato. 7. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detta sessione mediale è una sessione VoIP o una sessione di streaming. 8. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detto dispositivo ricevente è un application server o un server SIP o un altro utente. 9. Il metodo secondo le rivendicazioni da 3 a 6, in cui, in un caso negativo, esso comprende l’abbattimento e / o bloccaggio di detta sessione mediale tra detto utente e detto dispositivo ricevente. 10. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detta fase di analisi dei pacchetti di traffico include rilevare in detto pacchetto di traffico in una o più dei seguenti parametri: - L'indirizzo IP associato all'utente; - La posizione dell'utente; - L'indirizzo IP e la porta TCP / UDP di un server e / o utenti supplementari con i quali l'utente è autorizzato a comunicare; - Il tipo di sessione mediale stabilita; - L'indirizzo IP e la porta TCP / UDP del server e / o di altro utente con cui l'utente non è autorizzato a comunicare. 11. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui la qualità del servizio per il canale dedicato include uno o più dei seguenti parametri: Bit Rate Garantito, Bit Rate Massimo, Quality of Service Class Identifier (QCI), attribuzione e conservazione di priorità, Differentiated Services Code Point (DSCP). 12. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, comprendente: a. Conta del numero di sessioni di comunicazione mediale stabilite da detto utente in un arco di tempo; b. Istituzione di detto canale dedicato solo se detto numero di sessioni mediali eseguite entro detto intervallo di tempo è inferiore ad una determinata soglia. 13. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, comprendente: a. Il controllo in detto di database (UPD, 501), della massima velocità in uplink e / o la massima velocità di downlink che detto utente è autorizzato ad utilizzare; b. Istituzione di detto canale dedicato solo se detta sessione di comunicazione mediale richiede una velocità di uplink e / o velocità di downlink inferiore a detta velocità massima di uplink e / o detta velocità massima di downlink. 14. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, comprendente: a. Determinazione del carico di traffico su detto core network; b. Istituzione di detto canale dedicato solo se detto carico di traffico è sotto una certa soglia. 15. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, comprendente: a. Verifica in detto database (UPD, 501) del valore di priorità di accesso di detto utente; b. Confronto di detto valore di priorità di accesso con un valore di accesso di emergenza memorizzato; c. Abbattimento del canale dedicato e / o blocco dell'accesso alla rete di altri utenti aventi detto valore di priorità di accesso inferiore a detto valore di emergenza; d. Stabilimento di un canale dedicato per detto utente avente detto valore di accesso prioritario uguale o superiore a detto valore di accesso di emergenza. 16. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, comprendente: a. Verifica in detto dabase (UPD, 501) del valore di priorità di accesso di detto utente; b. Confronto di detto valore di priorità di accesso con il valore di accesso prioritario di tutti gli altri utenti, determinando il valore di priorità di accesso più basso; c. Nel caso il valore di accesso prioritario di detto utente sia maggiore del valore di priorità di accesso più basso, abbattere il canale dedicato o bloccare l'accesso di rete di un altro utente avente detto valore di priorità di accesso più basso; d. Stabilire un canale dedicato per detto utente avente detto valore di priorità di accesso superiore a detto valore di priorità di accesso più basso. 17. Il metodo secondo una qualsiasi delle rivendicazioni precedenti in cui il valore di priorità di accesso di detto utente ha una corrispondente allocazione della Quality of Service e valore di Retention Priority. 18. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detta fase di analisi dei pacchetti, comprende l’analisi del pacchetto tra detto gateway (PGW, 204) e detta rete IP esterna. 19. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detto core network (106) è un core network LTE o un core network UMTS. 20. Un apparato configurato per implementare una funzione di controllo policy in una rete di telecomunicazioni (100'') per controllare una sessione di comunicazione mediale; detta rete di telecomunicazioni (100'') comprendente un core network (106) avente un gateway (PGW, 204) verso una rete IP esterna (110.112), una rete di accesso radio (RAN 104), e la rete IP esterna al detto core network, l'apparecchiatura comprendendo: a. Un database (UPD, 501) comprendente regole di policy applicabili agli utilizzatori di detta rete di telecomunicazioni secondo un identificativo utente (302) e che si riferiscono ad una o più sessioni mediali; b. Un primo rilevatore (MPE, PCU) atto a identificare la creazione di un canale predefinito per un utente su detto core network (106); c. Un secondo rivelatore (MPE, PCU) atto a identificare la creazione di una sessione di comunicazione mediale richiesta tra l'utente e il dispositivo ricevente; d. Un analizzatore (MPE, PCU) atto ad analizzare tutti i pacchetti di traffico provenienti da o diretti verso detto utente tra detta rete di accesso (RAN 104) e detto core network e / o un gateway (PGW, 204) verso una rete IP esterna (110.112) e di determinare per ogni pacchetto appartenente alla sessione mediale stabilita, il tipo di sessione mediale richiesta e stabilita, e gli indirizzi IP e le porte di detto utente e detto dispositivo ricevente, tra cui la sessione mediale è stabilita; e. Un policy enforcer (MPE, PCU) atto a forzare tale core network (106) e / o rete di accesso radio (RAN 104) e / o detto gateway (PGW, 204) a creare, se tali policy lo consentono, un canale dedicato tra detto utente e detto gateway con Quality of Service per i pacchetti appartenenti alla sessione mediale già stabilita, detta Quality of Service dipendendo dalla sessione mediale specifica, detto canale dedicato stabilito tra gli indirizzi IP e le porte correlate della sessione mediale già stabilita, detto canale dedicato essendo creato sulla base delle informazioni ricavabili da detti pacchetti appartenenti a detta sessione mediale stabilita e detto database (UPD, 501). 21. Apparecchiatura secondo la rivendicazione 20, in cui detto primo e secondo rilevatore, detto analizzatore e detto policy enforcer fanno parte dello stesso nodo. 22. Apparecchiatura secondo la rivendicazione 20 o 21, in cui detto primo e secondo rilevatore, detto analizzatore e detto policy enforcer sono parte di detto core network. 23. L'apparecchio secondo una qualsiasi delle rivendicazioni 20 - 22, in cui detto primo e secondo rilevatore, detto analizzatore e detto policy enforcer sono parte di detta rete di accesso radio. 1. A method for controlling media communication session between a user (WTRU, 101) identified by a user identifier (302) and a receiving equipment (101, SIP server, Video server) via a core network (106) and a IP network (110,112) external to said core network, said user accessing said core network via a radio access network (RAN, 104) and said network including a gateway (PGW, 204) to said external IP network, the method including the steps of: a. Checking, when said user (WTRU, 101) connects to said core network (106), a database (UPD 501) to retrieve policy rules applicable to said user according to the user identifier (301) and which relate to one or more media sessions; b. Identifying the establishment of a default bearer for said user (WTRU, 101) on said core network (106); c. Analyzing all traffic packets originating from or directed to said user between said access network (RAN 104) and said core network and/or a gateway (PGW, 204) to said external IP network (110,112); d. Checking the establishment of a requested media communication session between the user and the receiving equipment; e. Determining, for each packet belonging to the established media communication session, the type of media session requested and established, and the IP addresses and ports of said user and said receiving equipment, between which the media session is established; f. forcing such core network (106) and/or radio access network (RAN 104) and/or said gateway (PGW, 204) to create, if such policy rules allow, a dedicated bearer between said user and said gateway (PGW, 204) with Quality of Service for the packets belonging to the already established media session, said Quality of Service depending on the specific media session, said dedicated bearer being established between the IP addresses and related ports of the already established media session, said dedicated bearer being created on the basis of the information retrievable from said packets belonging to said established media session and said database (UDP 501).
2. 2. The method according to claim 1, wherein, before the creation of a dedicated bearer with Quality of Service for the packets belonging to the already established media session, it includes the step of forcing such core network (106) and/or radio access network (RAN 104) and/or gateway (PGW, 204) to create, if such policy rules allow, a dedicated bearer with Quality of Service for the packets belonging to the media session establishment signaling messages.
3. 3. The method according to claim 1 or 2, wherein the step of forcing the core network (106) and/or radio access network (RAN 104) and/or said gateway (PGW, 204) to create a dedicated bearer includes: a. Verifying in said database (UPD, 501) whether said user (WTRU 101) is allowed to establish media communication session of the type requested; and b. In the affirmative case, creating said dedicated bearer.
4. 4. The method according to any of the preceding claims, wherein the step of forcing the core network (106) and/or radio access network (RAN 104) and/or gateway (PGW, 204) to create a dedicated bearer includes: a. Determining the geographical location of said user; b. Verifying in said database (UPD, 501) whether said user is allowed to establish media communication session in said geographical location; and c. In the affirmative case, creating said dedicated bearer.
5. 5. The method according to any of the preceding claims, wherein the step of forcing the core network (106) and/or radio access network (RAN 104) and/or gateway (PGW, 204) to create a dedicated bearer includes: a. Verifying in said database (UPD, 501) whether said user is allowed to establish media communication session with said receiving equipment; and b. In the affirmative case, creating said dedicated bearer.
6. 6. The method according to any preceding claims, wherein the step of forcing the core network (106) and/or radio access network (RAN 104) and/or gateway (PGW, 204) to create a dedicated bearer includes: a. Determining the media stream requested by said user; b. Verifying in said database (UPD 501) whether said user is allowed to access said media stream; and c. In the affirmative case, creating said dedicated bearer.
7. 7. The method according to any of the preceding claims, wherein said media session is a VoIP session or a streaming session.
8. 8. The method according to any of the preceding claims, wherein said receiving equipment is an application server or a SIP server or another user.
9. 9. The method according to claims from 3 to 6, wherein, in a negative case, it includes tearing down and/or blocking said media session between said user and said receiving equipment.
10. 10.The method according to any of the preceding claims, wherein said step of analyzing traffic packets includes detecting in said traffic packet one or more of: - IP address associated to the user; - the location of the user; - the IP address and TCP/UDP port of a server and/or additional user to which the user is allowed to communicate with; - the type of media session established; - the IP address and TCP/UDP port of the server and/or additional user to which the user is not allowed to communicate with.
11. 11.The method according to any of the preceding claims, wherein the Quality of Service for the dedicated bearer includes one or more of the following parameters: Guaranteed Bit Rate, Maximum Bit Rate, Quality of Service Class Identifier, Allocation and Retention Priority, Differentiated Services Code Point.
12. 12.The method according to any of the preceding claims, including: a. Counting the number of media communication session performed by said user within a time frame; b. Establishing said dedicated bearer only if said number of media session performed within said time frame is below a given threshold.
13. 13.The method according to any of the preceding claims, including: a. Checking in said database (UPD, 501) the maximum uplink bitrate and/or the maximum downlink rate that said user is allowed to use; b. Establishing said dedicated bearer only if said media communication session requires a uplink and/or downlink rate below said maximum uplink bitrate and/or said maximum downlink rate.
14. 14.The method according to any of the preceding claims, including: a. Determining the traffic load of said core network; b. Establishing said dedicated bearer only if said traffic load is below a given threshold.
15. 15.The method according to any of the preceding claims, including: a. Verifying in said database (UPD, 501) the priority access value of said user; b. Comparing said priority access value with a stored emergency access value; c. Tearing down the dedicated bearer and/or blocking network access of other user(s) having said priority access value lower than said emergency value; d. Establishing a dedicated bearer for said user having said priority access value equal to or greater than said emergency access value.
16. 16.The method according to any of the preceding claims, including: a. Verifying in said database (UPD, 501) the priority access value of said user; b. Comparing said priority access value with the priority access value of all other user(s), determining the lowest priority access value; c. In case the priority access value of said user is greater than the lowest priority access value, tearing down the dedicated bearer or blocking network access of another user having said lowest priority access value; d. Establishing a dedicated bearer for said user having said priority access value greater than said lowest priority access value.
17. 17.The method according to any of the preceding claims wherein the priority access value of said user has a corresponding Quality of Service Allocation and Retention Priority value.
18. 18.The method according to any of the preceding claims, wherein said step of analyzing the packets, includes to analyze the packet between said gateway (PGW,204) and said external IP network.
19. 19.The method according to any of the preceding claims, wherein said core network (106) is a LTE core network or a UMTS core network.
20. 20.An apparatus configured to implement a policy control function in a telecommunication network (100’’) for controlling media communication session; said telecommunication network (100’’) including a core network (106) having a gateway (PGW,204) to an external IP network (110,112), a radio access network (RAN 104), and the IP network external to said core network, the apparatus comprising: a. A database (UPD, 501) including policy rules applicable to users of said telecommunication network according to a user identifier (302) and which relate to one or more media sessions; b. A first detector (MPE,PCU) apt to identify the establishment of a default bearer for a user on said core network (106); c. A second detector (MPE,PCU) apt to identify the establishment of a requested media communication session between the user and the receiving equipment; d. An analyzer (MPE,PCU) apt to analyze all traffic packets originating from or directed to said user between said access network (RAN 104) and said core network and/or a gateway (PGW, 204) to an external IP network (110,112) and to determine for each packet belonging to the established media communication session, the type of media session requested and established, and the IP addresses and ports of said user and said receiving equipment, between which the media session is established; e. A policy enforcer (MPE,PCU) apt to force such core network (106) and/or radio access network (RAN 104) and/or said gateway (PGW, 204) to create, if such policy rules allow, a dedicated bearer between said user and said gateway with Quality of Service for the packets belonging to the already established media session, said Quality of Service depending on the specific media session, said dedicated bearer being established between the IP addresses and related ports of the already established media session, said dedicated bearer being created on the basis of the information retrievable from said packets belonging to said established media session and said database (UPD, 501).
21. 21.The apparatus according to claim 20, wherein said first and second detector, said analyser and said policy enforcer are part of the same node.
22. 22.The apparatus according to claim 20 or 21, wherein said first and second detector, said analyzer and said policy enforcer are part of said core network.
23. 23.The apparatus according to any of claims 20 - 22, wherein said first and second detector, said analyzer and said policy enforcer are part of said radio access network.