Applicazione di controllo del credito di diametro - Diameter Credit-Control Application
L'applicazione per il controllo del credito di diametro è un protocollo di rete per l' applicazione di diametro utilizzato per implementare il controllo del credito in tempo reale per una varietà di servizi per l'utente finale.
È uno standard IETF definito per la prima volta in RFC 4006 e aggiornato in RFC 8506.
Scopo
Lo scopo dell'applicazione di controllo del credito di diametro è fornire un framework per l'addebito in tempo reale, inteso principalmente per la comunicazione tra gateway/punti di controllo e i sistemi di conto/saldo di back-end (tipicamente un sistema di addebito online ).
L'applicazione specifica i metodi per:
- Gestione delle quote (Prenota, Riautorizza, Abbandona)
- Addebito/Credito semplice
- Controlli di equilibrio
- Richieste di prezzo
L'applicazione di controllo del credito di diametro non specifica quale tipo di unità vengono acquistate/utilizzate e quali articoli vengono addebitati. Questo è lasciato al contesto del servizio che deve essere specificato separatamente, così come parte della semantica.
Esempi di unità usate/acquistate:
- Tempo
- Carica/scarica byte
- SMS (messaggi di testo)
Esempi di articoli addebitati:
- Soldi
- Punti
- Unità (ad es. se il saldo è mantenuto nelle stesse unità di ciò che viene utilizzato)
Il controllo del credito del diametro specifica anche come gestire il problema abbastanza complesso di più tipi di unità utilizzate/addebitate a fronte di un singolo saldo utente. Ad esempio, un utente può pagare sia per il tempo online che per i byte di download, ma ha un solo saldo del conto.
Ricarica basata sulla sessione
Un processo di controllo del credito basato sulla sessione utilizza diverse interrogazioni che possono includere la prima, l'intermedia e l'ultima interrogazione. Durante l'interrogazione il denaro viene riservato dal conto utente. L'addebito basato sulla sessione viene in genere utilizzato per scenari in cui le unità addebitate vengono consumate continuamente, ad esempio l'addebito per l'upload/download di byte.
Ricarica basata sugli eventi
Un processo di controllo del credito basato su eventi utilizza gli eventi come meccanismo di addebito. La ricarica basata sugli eventi viene in genere utilizzata quando le unità non vengono consumate continuamente, ad esempio un utente che invia un MMS.
Codici di comando
Per supportare il controllo del credito tramite Diametro, sono disponibili due messaggi di diametro, il CCR (Richiesta di controllo del credito) e il CCA (Risposta del controllo del credito). Il codice comando per CCR/CCA è 272, come definito in RFC 4006
Per la gestione delle quote il client invia CCR al server richiedendo unità e segnalando il consumo. Il server concede unità e addebita all'utente. Per il semplice addebito/accredito il cliente invia una CCR chiedendo al server di accreditare/addebitare l'account dell'utente. Per le richieste di prezzo, il cliente chiede al server qual è il prezzo per un'unità e il server risponde con il prezzo.
Flussi di messaggi
I flussi di messaggi sono generalmente guidati dal punto di controllo che richiede le unità e dal server che le concede. Il messaggio può anche essere generato da altre applicazioni di diametro, come NASREQ (RFC4005) per sessioni limitate nel tempo/utilizzo.
Il diagramma seguente mostra un flusso di messaggi semplificato per una sessione che utilizza le concessioni di quota.
Il client inizia richiedendo 10 unità dal server. Il server verifica che l'utente/abbonato disponga di un saldo sufficiente. In questo esempio il server concede al client tutte le unità richieste. se l'abbonato avesse un saldo insufficiente avrebbe potuto concedere meno quote o rifiutarlo completamente.
Quando o prima che la sessione dell'abbonato abbia utilizzato le unità concesse, il client invia un aggiornamento al server indicando quante unità sono state utilizzate e quante ne vorrebbe concedere questa volta. Il client può richiedere le unità prima che la concessione precedente sia completamente utilizzata, al fine di evitare di sospendere la sessione dell'abbonato mentre si parla con il server. In questo esempio il client invia la richiesta quando sono state utilizzate 7 unità delle 10 precedentemente concesse; e chiedi altre 10 unità, che il server concede. Il server può utilizzare il conteggio delle unità utilizzate per addebitare il saldo dell'abbonato (le unità di concessione non indicano che verranno utilizzate. L'AVP delle unità utilizzate contiene l'utilizzo effettivo). È anche possibile che il server dica al client per quanto tempo la concessione è valida, nel qual caso si prevede che il client invii un aggiornamento alla scadenza del timer della concessione.
Ci possono essere molti messaggi di aggiornamento durante una sessione.
Infine, l'abbonato ha terminato la sessione e il client invia un messaggio di terminazione al server contenente le ultime unità usate. Il server può utilizzare il messaggio di terminazione per cancellare eventuali prenotazioni correlate effettuate nel sistema di gestione del saldo back-end. Se l'abbonato non ha terminato la sessione da solo ma ha invece esaurito il suo saldo, il server avrebbe risposto prima con un rifiuto a un messaggio di aggiornamento, possibilmente dicendo al client/punto di controllo di reindirizzare il traffico (questo normalmente ha senso solo per il traffico HTTP / WAP ).
Matrice AVP
AVP per nuovi codici di comando
I nuovi codici di comando, CCA e CCR, potrebbero richiedere alcuni AVP come indicato di seguito. Gli AVP in grassetto sono nuovi per DCCA.
| Codice di comando | ||
|---|---|---|
| nome attributo | CCR | CCA |
| Acct-Multi-Session-Id | 0-1 | 0-1 |
| Auth-Application-Id | 1 | 1 |
| CC-Correlazione-Id | 0-1 | 0 |
| CC-Session-Failover | 0 | 0-1 |
| CC-Richiesta-Numero | 1 | 1 |
| Tipo di richiesta CC | 1 | 1 |
| CC-Sotto-Sessione-Id | 0-1 | 0-1 |
| Verifica-Saldo-Risultato | 0 | 0-1 |
| Informazioni sui costi | 0 | 0-1 |
| Credit-Control-Failure-Handling | 0 | 0-1 |
| Destinazione-host | 0-1 | 0 |
| Destinazione-Regno | 1 | 0 |
| Gestione-fallimento-addebito diretto | 0 | 0-1 |
| Evento-Timestamp | 0-1 | 0-1 |
| Fallito-AVP | 0 | 0+ |
| Indicazione dell'unità finale | 0 | 0-1 |
| Granted-Service-Unit | 0 | 0-1 |
| Controllo-credito-servizi multipli | 0+ | 0+ |
| Indicatore multiservizi | 0-1 | 0 |
| Origine-Host | 1 | 1 |
| Origine-Reame | 1 | 1 |
| Origine-Stato-Id | 0-1 | 0-1 |
| Proxy-Info | 0+ | 0+ |
| Host di reindirizzamento | 0 | 0+ |
| Reindirizzamento-utilizzo dell'host | 0 | 0-1 |
| Reindirizza-Max-Cache-Time | 0 | 0-1 |
| Azione richiesta | 0-1 | 0 |
| Unità-servizio-richiesto | 0-1 | 0 |
| Percorso-Record | 0+ | 0+ |
| Codice-Risultato | 0 | 1 |
| Service-Context-Id | 1 | 0 |
| Identificatore di servizio | 0-1 | 0 |
| Service-Parameter-Info | 0+ | 0 |
| ID sessione | 1 | 1 |
| Id abbonamento | 0+ | 0 |
| Causa di risoluzione | 0-1 | 0 |
| Info-attrezzatura-utente | 0-1 | 0 |
| Usato-Service Unit | 0+ | 0 |
| Nome utente | 0-1 | 0-1 |
| Validità-Tempo | 0 | 0-1 |
Nuovi AVP per i codici di comando del protocollo di base
| Codice di comando | ||
|---|---|---|
| nome attributo | RAR | RAA |
| CC-Sotto-Sessione-Id | 0-1 | 0-1 |
| Identificatore pool GSU | 0-1 | 0-1 |
| Identificatore di servizio | 0-1 | 0-1 |
| Rating-Gruppo | 0-1 | 0-1 |
La tabella utilizza i seguenti simboli:
- 0 L' AVP NON DEVE essere presente nel messaggio
- 0+ Zero o più istanze dell'AVP POSSONO essere presenti nel messaggio
- 0-1 Zero o un'istanza di AVP PU essere presente nel messaggio. È considerato un errore se c'è più di un'istanza dell'AVP
- 1 Un'istanza dell'AVP DEVE essere presente nel messaggio
- 1+ Almeno un'istanza dell'AVP DEVE essere presente nel messaggio
Norme correlate
- RFC 4005 - Applicazione server di accesso alla rete del diametro.
- RFC 4006 - Applicazione di controllo del credito di diametro (obsoleto)
- RFC 8506 - Applicazione per il controllo del credito di diametro.
- 3GPP 32.299 - Gestione delle telecomunicazioni 3GPP - Gestione della ricarica - Applicazioni di ricarica del diametro.