Legare il pricing alla Qualità del Servizio

Con l'arrivo del Gprs si pone il problema - che si ripresenterà probabilmente amplificato con l'Umts - di differenziare il livello di servizio offerto al fine di assicurare un'appropriata QoS ad ogni utente.
Tale differenziazione - volta ad incoraggiare gli utenti a scegliere quanto più adeguato alle specifiche esigenze - può essere raggiunta anche (e soprattutto) attraverso il pricing.
Gli utenti di una rete mobile possono essere tariffati, come noto, in diversi modi: tempo, utilizzo delle risorse, tipologia di servizio ("evento"), località/numero di origine e di destinazione della chiamata, e così via.
Più spesso, il princing deriva da una combinazione di tali modalità.
In più, il pricing può essere definito in modo "dinamico", quando le tariffe possono variare al verificarsi di determinate condizioni sulla rete, o "statico", se tale caratteristica non è prevista.
La definizione del pricing è da sempre una decisione strategica e di marketing più che una questione di tecnologia, anche se con l'aumento del livello di complessità dei servizi, delle applicazioni e dei rapporti tra i diversi attori della catena del valore, l'aspetto tecnologico diviene meno secondario.

Utilità
E' possibile sviluppare una teoria che definisca le funzioni di utilità, che descrivano in che modo gli utenti sono sensibili a modifiche nella QoS.
In altre parole, l'utilità indica la propensione alla spesa degli utenti in cambio della garanzia di un certo livello di QoS.
Idealmente, tale utilità potrebbe essere espressa come funzione degli attuali parametri di QoS, quali ad esempio il ritardo o la perdita di pacchetti.
Nelle reti mobili reali però tali grandezze sono virtualmente impossibili da prevedere, in quanto legate strettamente a fattori estemporanei. Per questo, l'idea è quella di valutare l'utilità come funzione delle risorse rese disponibili dalla rete ad un utente.
Naturalmente, le diverse applicazioni mostrano una sensibilità diversa ai parametri di QoS: la voce e il video real-time, ad esempio, sono estremamente sensibili ai ritardi di trasmissione, mentre le applicazioni dati risentono in modo molto maggiore della perdita di pacchetti.
Si può quindi pensare, ad esempio, a funzioni di utilità legate alle specifiche applicazioni: per l'e-mail, utilità come funzione decrescente del ritardo medio e della percentuale di messaggi non consegnati in un certo tempo; per la voce come funzione del ritardo unidirezionale e della percentuale dei pacchetti voce il cui ritardo supera un valore definito.

Un'altra possibilità è quella di definire l'utilità come funzione delle risorse dedicate.

Ad esempio, le applicazioni real time, come la voce ed il video, che utilizzano uno schema di bit rate costante richiedono una quantità di banda fissata per mantenere un'adeguata QoS. Per tali applicazioni, che possono essere definite "anelastiche" rispetto alla banda richiesta, un modello della funzione di utiltà a scalino appare adeguato (a destra).

Infine, esistono diverse modalità attraverso le quali le applicazioni real time di cui si parlava in precedenza possono essere rese "tolleranti" a variazioni nella banda a disposizione, principalmente mediante schemi di codifica adattivi, ma cionondimeno una banda minima è comunque richiesta. Per tali applicazioni, definbili "parzialmente elastiche", la funzione di utilità può essere come quella di destra.

In questa trattazione, il punto debole principale è ovviamente l'assunto di conoscere a priori la funzione di utilità dei propri utenti: ai fini del pricing, infatti, assumere una data funzione di utilità rischia di semplificare oltre misura la complessità delle scelte dell'utente e le motivazioni che vi sono dietro.

In conclusione, è possibile ipotizzare un futuro dove i livelli di QoS sono definiti in modo arbitrariamente dettagliato e i prezzi delle connessioni e dei servizi sono definiti in base ad essi, eventualmente anche in tempo reale in funzione o meno del raggiungimento della qualità contrattata tra il fornitore e l'utente.
Il punto chiave di tutto è comunque la chiarezza nei confronti dell'utente stesso: i parametri usati (banda utilizzata, byte trasmessi, ecc.) devono essere resi chiari all'utilizzatore finale e sarà compito di chi offre il servizio astrarre le metriche utilizzate per la valutazione della QoS e delle performance e renderle comprensibili all'utente medio, in modo che questi possa valutare per che cosa gli si chiede di pagare e possa fare la scelta più adeguata alle sue necessità.