Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Configurazione

Esempio di rete

Tx-Scadenza

Timeout risposta

Failover di sessione con diametro

Meccanismo FH

Configurazione meccanismo FH

Comportamento predefinito del meccanismo FH

Flusso chiamate dettagliate meccanismo FH

Meccanismo SU

Configurazione meccanismo SU

Flussi chiamate meccanismo SU

Configurazioni di esempio per FH e SU

Verifica

Risoluzione dei problemi

Informazioni correlate

Introduzione

In questo documento viene descritto come configurare i meccanismi FH (Failure-Handling) e SU (Server-Unreachable) sull'interfaccia Gy per risolvere i problemi rilevati nel sistema di caricamento online (OCS) o per quanto riguarda la connettività tra la funzione PCEF (Policy and Charging Enforcement Function) e OCS. Le informazioni descritte in questo documento si applicano alle funzionalità Home Agent (HA), GPRS (Gateway General Packet Radio Service) Support Node (GSN) e PGW (Packet Data Network Gateway) che vengono eseguite su Cisco serie 5000 Aggregated Services Router (ASR5K).

Prerequisiti

Requisiti

Cisco consiglia al sistema di soddisfare questi requisiti per utilizzare i meccanismi FH e SU:

- È disponibile il servizio di ricarica avanzata (ECS, Enhanced Charging Service)

- La funzione PCEF esiste all'interno di HA, GSN o PGW

- La connettività del diametro è adeguata tramite il diabase

- È disponibile l'applicazione DCCA (Diameter Credit Control Application)

Componenti usati

Le informazioni fornite in questo documento si basano su tutte le versioni di ASR5K.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Il PCEF è collegato a OCS tramite l'interfaccia Gy, che utilizza Diameter come protocollo di base e DCCA. Questo è il flusso di messaggi tra PCEF e OCS:

- Credit Control Request (CCR) âÂ Questo messaggio viene inviato dal PCEF a OCS. Esistono tre tipi di messaggi CCR: Iniziale, Aggiorna e Termina.

- Credit Control Answer (CCA) âÂÂ Questo messaggio viene inviato da OCS al PCEF in risposta al CCR. Esistono inoltre tre tipi di messaggi CCA: Iniziale, Aggiorna e Termina.

- Richiesta di riautorizzazione (RAR) âÂ Questo messaggio viene inviato da OCS al PCEF quando è necessaria una riautorizzazione della sessione.

- Risposta di riautorizzazione (RAA) âÂQuesta è la risposta al RAR dal PCEF all'OCS.

Viene stabilita una connettività del diametro tra il PCEF e l'OCS per abilitare il flusso dei messaggi. È possibile che OCS invii messaggi negativi, che la connessione di trasporto tra PCEF e OCS abbia esito negativo oppure che il messaggio sia in timeout e ciò possa causare un errore nell'impostazione della sessione del sottoscrittore. In questo modo l'abbonato potrebbe non poter utilizzare i servizi.

Per risolvere il problema è possibile utilizzare i due meccanismi seguenti:

- Il meccanismo FH

- Il meccanismo degli Stati Uniti

Configurazione

In questa sezione vengono descritte le configurazioni necessarie per supportare i meccanismi FH e SU.

Esempio di rete

Per le informazioni di questo documento viene utilizzata la topologia seguente:

Tx-Scadenza

Timer a livello di applicazione per DCCA configurabile nelle impostazioni di controllo del credito del diametro. Il valore può essere compreso tra 1 e 300 secondi.

Di seguito è riportato un esempio:

[local]host_name(config-dcca)# diameter pending-timeout

Timeout risposta

Si tratta di un timeout del diabase ed è possibile configurarlo nelle impostazioni dell'endpoint del diametro. Il valore può essere compreso tra 1 e 300 secondi.

Nota: Il valore configurato per questo timer deve essere maggiore di quello utilizzato per il timer Tx-Expiry.

Di seguito è riportato un esempio:

[context_name]host_name(config-ctx-diameter)# response-timeout

Failover di sessione con diametro

Questa funzione viene utilizzata per abilitare o disabilitare il failover della sessione di controllo del credito del diametro, che consente al sistema di utilizzare un server secondario quando il server primario diventa irraggiungibile. Questa opzione può essere configurata nelle impostazioni di controllo del credito del diametro.

Di seguito è riportato un esempio:

local]host_name(config-dcca)# diameter session failover

Meccanismo FH

Il meccanismo FH funziona solo se è presente il failover di sessione del diametro. FH consente al sistema di scegliere se continuare la sessione e convertirla in modalità non in linea oppure terminare la sessione quando si verifica un errore a livello di connessione o di messaggio.

Nota: FH è abilitato e configurato per impostazione predefinita.

Configurazione meccanismo FH

Il meccanismo FH può essere configurato nelle impostazioni di controllo del credito del diametro. Di seguito viene riportata la sintassi utilizzata nella configurazione FH:

failure-handling { initial-request | terminate-request | update-request } { continue

[ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate,

[ retry-after-tx-expiry ] | terminate }

La prima sezione specifica il tipo di richiesta: Iniziale (CCR-I), Aggiornamento (CCR-U) e Termina (CCR-T).

La seconda sezione specifica l'azione da eseguire quando viene attivato il meccanismo FH. Il meccanismo FH permette di realizzare le tre seguenti azioni:

- Continue âÂ In questo modo la sessione continua e la converte in offline. Questa funzione utilizza due opzioni correlate alla scadenza imposta:

- Go-offline-after-tx-expÂ ÂÂ Questa opzione avvia la ricarica offline dopo la scadenza di Tx.

- Retry-after-tx-expÂ ÂÂ In questo modo si ritenta il server secondario dopo la scadenza di Tx.

- Retry-and-terminate âÂ In questo modo la sessione viene terminata dopo che il sistema ha eseguito un nuovo tentativo di accesso al server secondario, se questo non è disponibile. In questo modo viene inoltre utilizzata l'opzione Retry-after-tx-expend, che consente di riprovare il server secondario dopo la scadenza di Tx.

- Terminate âÂÂ In questo modo la sessione viene terminata senza alcun tentativo di contattare il server secondario.

Comportamento predefinito del meccanismo FH

In questa sezione viene descritto il comportamento predefinito di FH quando non è presente alcuna configurazione. Per impostazione predefinita, il meccanismo FH viene attivato durante un timeout di risposta (RT, Response Timeout), tranne quando è configurata l'azione Termina.

Se viene ricevuta una coppia di valori dell'attributo Credit-Control-Failure-Handling (AVP) dal server, vengono applicate le impostazioni ricevute.

Seguono alcuni esempi:

- Initial-Request > Termina

- Update-Request > Retry-and-Terminate

- Termina-Richiesta > Riprova-e-Termina

Flusso chiamate dettagliate meccanismo FH

In questa sezione viene descritto in dettaglio il flusso di chiamata del meccanismo FH con tutte le opzioni possibili.

Richiesta iniziale

Impostazione CCFH

Comando CLI

Comportamento a Tx

Comportamento in RT

Il database secondario è attivo

Secondario non attivo

Continua

richiesta iniziale

continua

N/D

Continua

Secondaria

rileva dopo

RT

Offline dopo un altro RT.

Non vengono eseguite altre richieste di quota

per qualsiasi gruppo di valutazione all'interno della sessione

dopo un errore DCCA (anche se

la connettività a DCCA viene ripristinata)

richiesta iniziale

continua offline dopo

tx-scadenza

Non in linea

N/D

Offline in modalità Tx

Offline in modalità Tx

richiesta iniziale

continua dopo

tx-scadenza

Continua

N/D

Secondaria

rileva dopo

Tx

Offline dopo un'altra transazione

Riprova e termina

richiesta iniziale

retry-and-terminate

N/D

Riprova

Secondaria

rileva dopo

RT

Termina dopo un altro RT

richiesta iniziale

retry-and-terminate

riprova-dopo-scadenza-tx

Riprova

N/D

Secondaria

rileva dopo

Tx

Termina dopo un'altra trasmissione

Termina

richiesta iniziale

terminare

Termina

N/D

Termina dopo Tx

Termina dopo Tx

Update-Request

Impostazione CCFH

Comando CLI

Comportamento a Tx

Comportamento in RT

Il database secondario è attivo

Secondario non attivo

Continua

richiesta-aggiornamento

continua

N/D

Continua

Secondaria

rileva dopo

RT

Offline dopo un altro RT

richiesta-aggiornamento

continua offline dopo

tx-scadenza

Non in linea

N/D

Offline in modalità Tx

Offline in modalità Tx

richiesta-aggiornamento

continua dopo

tx-scadenza

Continua

N/D

Secondaria

rileva dopo

Tx

Offline dopo un'altra transazione

Riprova e termina

richiesta-aggiornamento

retry-and-terminate

N/D

Riprova

Secondaria

rileva dopo

RT

Invia CCR-T dopo un altro RT

richiesta-aggiornamento

retry-and-terminate

riprova-dopo-scadenza-tx

Riprova

N/D

Secondaria

rileva dopo

Tx

Invia CCR-T dopo un'altra trasmissione

Termina

richiesta-aggiornamento

terminare

Termina

N/D

Invia CCR-T dopo Tx

Invia CCR-T dopo Tx

Terminate-Request

Impostazione CCFH

Comando CLI

Comportamento a Tx

Comportamento in RT

Il database secondario è attivo

Secondario non attivo

Continua

terminate-request

continua

N/D

Riprova

CCR-T inviato

secondario

dopo RT

Termina dopo un altro RT

terminate-request

continua offline dopo

tx-scadenza

Riprova

N/D

CCR-T inviato

secondario

dopo Tx

Termina dopo un'altra trasmissione

terminate-request

continua dopo

tx-scadenza

Riprova

N/D

CCR-T inviato

secondario

dopo Tx

Termina dopo un'altra trasmissione

Riprova e termina

terminate-request

retry-and-terminate

N/D

Riprova

CCR-T inviato

secondario

dopo RT

Termina dopo un altro RT

terminate-request

retry-and-terminate

riprova-dopo-scadenza-tx

Riprova

N/D

CCR-T inviato

secondario

dopo Tx

Termina dopo un'altra trasmissione

Termina

terminate-request

terminare

Termina

N/D

Termina dopo

Tx

Termina dopo Tx

Meccanismo SU

Il meccanismo SU è simile al meccanismo FH, ma fornisce un controllo più granulare sulle procedure di errore. Oltre alla continuazione della sessione dopo gli errori a livello di messaggio e connessione (trasporto), questo meccanismo può essere utilizzato quando le risposte sono lente da OCS. Fornisce inoltre le opzioni per continuare la sessione per una certa durata/esaurimento della quota prima della terminazione, oppure utilizzare la quota temporanea configurabile (volume e tempo) e i tentativi del server configurabili prima che una sessione venga convertita in non in linea o terminata.

Configurazione meccanismo SU

Il meccanismo SU può essere configurato nelle impostazioni di controllo del credito del diametro. La sintassi utilizzata nella configurazione su varia in base alla versione utilizzata.

Nelle versioni 12.1 e precedenti, questa è la sintassi utilizzata per la configurazione del meccanismo SU:

servers-unreachable { initial-request { continue | terminate [ after-timer-expiry

<timeout_period> ] } | update-request { continue | terminate [ after-quota-expiry

| aftertimer-expiry <timeout_period> ] } }

Per la versione 12.2 e successive, questa è la sintassi utilizzata per la configurazione del meccanismo SU:

servers-unreachable { behavior-triggers { initial-request | update-request }

result-code { any-error | <result-code> [ to <end-result-code> ] }

| transport-failure [ response-timeout | tx-expiry ] | initial-request

{ continue [ { [ after-interim-time <timeout_period> ] [ after-interim-volume

<quota_value> ] } server-retries <retry_count> ] | terminate [ {

[ after-interim-time <timeout_period> ] [ after-interim-volume <quota_value> ]

} server-retries <retry_count> | after-timer-expiry <timeout_period> ] }

| update-request { continue [ { [ after-interim-time <timeout_period> ]

[ after-interim-volume <quota_value> ] } server-retries <retry_count> ]

| terminate [ { [ after-interim-time <timeout_period> ] [ after-interim-volume

<quota_value> ] } server-retries <retry_count> ] | after-quota-expiry |

after-timer-expiry <timeout_period> ] } }

Nota: Nelle versioni precedenti alla versione 12.2, era possibile configurare i meccanismi FH e SU in modo indipendente; tuttavia, nelle versioni 12.2 e successive, il meccanismo SU ha la precedenza sul meccanismo FH quando viene configurato.

Se il server restituisce l'AVP CC-FH e il meccanismo SU è configurato per una serie di trigger di comportamento, viene applicata la configurazione SU; in caso contrario, viene applicato il valore CC-FH AVP. Per impostazione predefinita, i codici di risultato come 3002, 3004 e 3005 rientrano in un errore di recapito e vengono trattati come RT.

Queste azioni sono possibili grazie al meccanismo USA:

- Behavior-Trigger ÂÂ Specifica il tipo di messaggi che possono essere Richieste iniziali (CCR-I) o Richieste di aggiornamento (CCR-U). Per questi trigger sono disponibili tre opzioni:

- Codice risultato âÂÂÂ Consente la configurazione di codici risultato specifici, di intervalli di codici risultato (3000-5999) o di qualsiasi errore insieme al tipo di messaggio.

- Transport-Failure âÂÂ Questa specifica attiva il comportamento in caso di errore di trasporto, compatibile con la versione 12.0 precedente. Sono disponibili due opzioni per questa impostazione:

- Response-Timeout âÂ Questa opzione attiva il comportamento su RT e deve essere sempre utilizzata in caso di errori di trasporto.

- Tx-Expiry âÂ Questa opzione attiva il comportamento alla scadenza di Tx e deve essere sempre utilizzata in caso di errore di trasporto.

- Azioni âÂÂ Specifica l'azione che viene eseguita quando si verifica un trigger SU per CCR-I o CCR-U. Questa azione varia in base al tipo di messaggio e alla versione del software.

- Continue ÂÂ In questo modo è possibile convertire la sessione in offline e continuare. Non sono disponibili altre opzioni per l'utilizzo di questa azione nelle versioni precedenti alla 12.2. Nelle versioni 12.2 e successive, le opzioni relative alla quota provvisoria, ai tentativi del server e alla scadenza del timer sono disponibili per la configurazione con questa azione.

- TerminateÂÂ In questo modo la sessione viene terminata quando il server diventa irraggiungibile. Questa azione consente di impostare le opzioni relative alla quota provvisoria, ai tentativi del server e alla scadenza del timer.

Le opzioni seguenti possono essere utilizzate con l'azione Continua o Termina:

- After-interim-time ÂÂ Questa opzione consente di continuare o terminare la chiamata dopo il periodo di timeout provvisorio. È simile a una quota di tempo prima dell'esecuzione dell'azione. Il valore viene formattato in secondi e può essere compreso tra 1 e 4.294.967.295.

- After-interim-volume ÂÂ Questa opzione assegna la quota provvisoria e consente la continuazione o la chiusura della sessione prima dell'esaurimento del volume configurato. Il valore è formattato in byte e può essere compreso tra 1 e 4.294.967.295.

- Server-retries ÂÂ Questa opzione consente al PCEF di riprovare a eseguire OCS prima della continuazione o della chiusura della sessione. È possibile configurare il numero di tentativi e il valore è compreso tra 0 e 65.535. Se il valore è zero, il tentativo non verrà eseguito e l'azione verrà applicata immediatamente.

Nota: Le opzioni after-interim-time e after-interim-volume vengono sempre utilizzate con l'opzione server-retries oppure possono essere utilizzate contemporaneamente e applicate a entrambe le azioni continue e terminate. Le opzioni after-interim-time e after-interim-volume assegnano anche il tempo e la quota del volume e la quota esaurita innesca un nuovo tentativo del server.

- Dopo la scadenza del timerÂÂ Questa opzione specifica la durata (in secondi) per la quale le sessioni rimangono nello stato offline prima che si verifichi la terminazione. I valori possono essere compresi tra 1 e 4.294.967.295. Questa opzione è applicabile solo per le azioni di terminazione.

- Dopo la scadenza della quota âÂÂ Questa opzione termina la sessione al momento dell'esaurimento della quota già assegnata.

Ecco alcune importanti informazioni da ricordare:

- Le opzioni after-interim-time, after-interim-volume e server-retries possono essere utilizzate singolarmente o in combinazione e sono applicabili sia alle azioni continue che alle azioni terminate.

- L'opzione after-quota-expndr è applicabile solo al trigger di comportamento Update-Requests.

- L'opzione after-timer-exceeded (dopo la scadenza del timer) è applicabile solo all'azione di terminazione.

- Le opzioni after-interim-time, after-interim-volume e server-retries sono applicabili solo alla versione 12.2 e successive.

- Se il failover di sessione del diametro è supportato (e configurato), il server secondario viene sempre contattato prima dell'attivazione del meccanismo SU.

- Il server contattato per ultimo prima dell'attivazione del meccanismo su viene sempre contattato quando il tempo o il volume intermedio è esaurito e l'opzione tentativi del server è configurata con un valore maggiore di zero. Ad esempio, se si prova prima OCS1 e si prova OCS2 dopo un errore in OCS1, la comunicazione con OCS2 attiva il meccanismo SU. Durante il nuovo tentativo del server, viene contattato prima OCS2 e quindi OCS1 se viene ricevuta una risposta negativa da OCS2.

Flussi chiamate meccanismo SU

Il meccanismo SU può essere attivato da un guasto del CCR-I o del CCR-U, e la causa può essere un codice di errore, un guasto di trasporto, una scadenza Tx o RT. L'azione può consistere nell'allocazione di una quota provvisoria (tempo e/o volume), nel numero di tentativi del server, nel valore del timer (determina l'attivazione della modalità non in linea per l'ora specificata e solo per l'interruzione) o nella scadenza della quota (solo per CCR-U e l'interruzione) prima che la sessione venga disconnessa o termini.

La quota provvisoria viene fornita per sessione e non per gruppo di valutazione (RG) negli scenari MSCC (Multiple Services Credit Control).

Esiste la possibilità che il server primario generi un errore di trasporto e che il server secondario generi un timeout di scadenza Tx o di risposta. In questo scenario, l'errore più recente viene considerato come la causa del fallimento.

Se il meccanismo SU non è configurato per l'attivazione di un guasto, viene attivato il meccanismo FH.

Nota: Nelle sezioni seguenti vengono forniti alcuni esempi di flusso di chiamata correlati al meccanismo SU. Questi flussi di chiamate vengono forniti in base al presupposto che sia supportato il failover della sessione di diametro e che il server secondario sia configurato con un valore di scadenza Tx inferiore al valore RT. Inoltre, si presume che il meccanismo SU sia configurato per errori di trasporto, scadenza Tx e RT.

Richiesta iniziale senza disconnessione della sessione

Flusso di messaggi per questo scenario:

1. Il PCEF invia un CCR-I all’OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, viene attivato il meccanismo SU. Questo si verifica immediatamente in caso di errori di trasporto o dopo la scadenza Tx per un timeout.

4. Se il volume e/o l'ora provvisori sono configurati, la quota provvisoria viene assegnata alla sessione.

5. Dopo l'esaurimento della quota provvisoria (tempo o volume) e se il valore dei tentativi del server è maggiore di zero, il CCR-I viene inviato nuovamente al server che ha attivato il meccanismo SU. Se si verifica un altro errore, il CCR-I viene inviato a un altro server.

6. Se viene nuovamente rilevato un errore di trasporto o un timeout Tx, i passaggi da 2 a 5 vengono ripetuti finché il valore dei tentativi del server non viene esaurito o non viene fornita una risposta corretta da OCS.

7. Se il problema persiste, la sessione viene continuata (convertita in modalità offline) o terminata in base alla configurazione.

Nota: La quota provvisoria che viene consumata durante la sessione in modalità SU a causa di CCR-I non viene segnalata nella successiva CCR-I. Tutti i contingenti provvisori utilizzati sono registrati nella CCR-U, che segue il successo della CCA-I.

Richiesta iniziale con disconnessione sessione

Flusso di messaggi per questo scenario:

1. Il PCEF invia un CCR-I all’OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, viene attivato il meccanismo SU. Questo si verifica immediatamente in caso di errori di trasporto o dopo la scadenza Tx per un timeout.

4. Se il volume e/o l'ora provvisori sono configurati, la quota provvisoria viene assegnata alla sessione.

5. Dopo l'esaurimento della quota provvisoria (tempo o volume) e se il valore dei tentativi del server è maggiore di zero, il CCR-I viene inviato nuovamente al server che ha attivato il meccanismo SU. Se si verifica un altro errore, il CCR-I viene inviato a un altro server.

6. Se viene nuovamente rilevato un errore di trasporto o un timeout Tx, i passaggi da 2 a 5 vengono ripetuti finché il valore dei tentativi del server non viene esaurito o non viene fornita una risposta corretta da OCS. A questo punto, la sessione viene disconnessa senza il consumo dell'intera quota provvisoria.

7. Dopo la chiusura della sessione, il PCEF invia nuovamente il CCR-I per avviare una nuova sessione. Se l'operazione ha esito positivo, il PCEF invia il messaggio CCR-T, che riporta l'intera quota temporanea utilizzata.

Update-Request senza disconnessione della sessione

Flusso di messaggi per questo scenario:

1. Il PCEF invia un CCR-U all'OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, viene attivato il meccanismo SU. Questo si verifica immediatamente in caso di errori di trasporto o dopo la scadenza Tx per un timeout.

4. Se il volume e/o l'ora provvisori sono configurati, la quota provvisoria viene assegnata alla sessione.

5. Dopo l'esaurimento della quota provvisoria (tempo o volume) e se il valore dei tentativi del server è maggiore di zero, il CCR-U viene inviato nuovamente al server che ha attivato il meccanismo SU. Se si verifica un altro errore, viene inviato un CCR-U a un altro server contenente l'intera quota non segnalata utilizzata.

6. Se viene nuovamente rilevato un errore di trasporto o un timeout Tx, i passaggi da 2 a 5 vengono ripetuti finché il valore dei tentativi del server non viene esaurito o non viene fornita una risposta corretta da OCS.

7. L'intera quota consumata viene comunicata all'OCS con l'esito positivo della CCR-U.

8. Se il problema persiste, la sessione viene continuata (convertita in modalità offline) o terminata in base alla configurazione dopo l'esaurimento del valore massimo dei tentativi.

Update-Request con disconnessione sessione

Flusso di messaggi per questo scenario:

1. Il PCEF invia un CCR-U all'OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, viene attivato il meccanismo SU. Questo si verifica immediatamente in caso di errori di trasporto o dopo la scadenza Tx per un timeout.

4. Se il volume e/o l'ora provvisori sono configurati, la quota provvisoria viene assegnata alla sessione.

5. Dopo l'esaurimento della quota provvisoria (tempo o volume) e se il valore dei tentativi del server è maggiore di zero, il CCR-U viene inviato nuovamente al server che ha attivato il meccanismo SU. Se si verifica un altro errore, viene inviato un CCR-U a un altro server contenente l'intera quota non segnalata utilizzata.

6. Se viene nuovamente rilevato un errore di trasporto o un timeout Tx, i passaggi da 2 a 5 vengono ripetuti finché il valore dei tentativi del server non viene esaurito o non viene fornita una risposta corretta da OCS. A questo punto, la sessione viene disconnessa prima di consumare l'intera quota temporanea.

7. Il PCEF invia una CCR-T all'OCS per comunicare l'intera quota consumata.

8. Se OCS risponde con un codice risultato 2002, i rapporti aggiuntivi non sono necessari.

Update-Request con sessione sconosciuta

Flusso di messaggi per questo scenario:

1. Il PCEF invia un CCR-U all'OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, viene attivato il meccanismo SU. Questo si verifica immediatamente in caso di errori di trasporto o dopo la scadenza Tx per un timeout.

4. Se il volume e/o l'ora provvisori sono configurati, la quota provvisoria viene assegnata alla sessione.

5. Dopo l'esaurimento della quota provvisoria (tempo o volume) e se il valore dei tentativi del server è maggiore di zero, il CCR-U viene inviato nuovamente al server che ha attivato il meccanismo SU. Se si verifica un altro errore, viene inviato un CCR-U a un altro server contenente l'intera quota non segnalata utilizzata.

6. OCS risponde con un codice risultato 5002 (ID sessione sconosciuto) per CCR-U, che è possibile nello scenario in cui OCS è stato riavviato e ha perso le informazioni ID sessione.

7. Il PCEF avvia una nuova sessione con il CCR-I e riceve il CCA-I.

8. Il PCEF riporta l'intera quota provvisoria utilizzata tramite CCR-U nei messaggi successivi.

Update-Request con più RG (scenario MSCC)

Flusso di messaggi per questo scenario:

1. Il PCEF invia il CCR-U per RG1 all'OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, viene attivato il meccanismo SU. Questo si verifica immediatamente in caso di errori di trasporto o dopo la scadenza Tx per un timeout.

4. Se il volume e/o l'ora provvisori sono configurati, la quota provvisoria viene assegnata alla sessione

5. A questo punto RG2 esaurisce anche l'intera quota assegnata ma non avvia CCR-U perché la sessione è già in modalità SU e inizia a consumare la quota provvisoria.

6. Dopo l'esaurimento della quota provvisoria (tempo o volume) e se il valore dei tentativi del server è maggiore di zero, il CCR-U viene inviato nuovamente al server che ha attivato il meccanismo SU. Se si verifica un altro errore, viene inviato un CCR-U a un altro server contenente l'intera quota non segnalata utilizzata per entrambi gli RG.

7. Se viene nuovamente rilevato un errore di trasporto o un timeout Tx, i passaggi da 2 a 6 vengono ripetuti finché il valore dei tentativi del server non viene esaurito o non viene fornita una risposta corretta da OCS.

8. L'intera quota consumata viene comunicata all'OCS con l'esito positivo della CCR-U.

9. Se il problema persiste, la sessione viene continuata (convertita in modalità offline) o terminata in base alla configurazione dopo l'esaurimento del valore massimo dei tentativi.

Terminate-Request

Flusso di messaggi per questo scenario:

1. Il PCEF invia un CCR-T all'OCS.

2. Rilevato timeout o errore di trasporto. Se viene rilevato un errore di trasporto, il PCEF riprova immediatamente con il server secondario; in caso contrario, viene attivata la scadenza Tx.

3. Se anche il server secondario presenta un errore di trasporto o un timeout, la sessione viene rimossa.

Gestione dei codici di errore CCR

Flusso di messaggi per questo scenario:

1. La funzione PCEF invia una CCR a OCS, che risponde con un codice di errore.

2. Il codice di errore è configurato in modo statico nel meccanismo SU.

3. Il PCEF fornisce la quota provvisoria senza un nuovo tentativo al server secondario.

Configurazioni di esempio per FH e SU

Questa sezione fornisce un esempio di configurazione per i meccanismi FH e SU. Quando sono configurati sia il meccanismo FH che il meccanismo SU, l'SU ha la precedenza sull'FH per lo stesso trigger di comportamento.

Di seguito è riportato un esempio:

credit-control group test

diameter origin endpoint test

diameter peer-select peer test

quota volume-threshold percent 10

diameter pending-timeout 80 deciseconds msg-type any

diameter session failover

trigger type rat lac

apn-name-to-be-included virtual

quota request-trigger exclude-packet-causing-trigger

failure-handling initial-request continue retry-after-tx-expiry

servers-unreachable initial-request terminate after-interim-volume 200

after-interim-time 3600 server-retries 0

servers-unreachable behavior-triggers initial-request transport-failure

tx-expiry

servers-unreachable update-request continue after-interim-volume 200

after-interim-time 3600 server-retries 50

servers-unreachable behavior-triggers update-request transport-failure

tx-expiry

Verifica

Per verificare che la configurazione funzioni correttamente, immettere il comando show active-charge service<service name>:

# show active-charging service name test

Service name: test

TCP Flow Idle Timeout : 300 (secs)

UDP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ALG Media Idle Timeout : 120 (secs)

TCP Flow-Mapping Idle Timeout : 300 (secs)

UDP Flow-Mapping Idle Timeout : Not Configured

Deep Packet Inspection: Enabled

Passive Mode : Disabled

CDR Flow Control : Enabled

CDR Flow Control Unsent Queue Size: 75

Unsent Queue high watermark: 56

Unsent Queue low watermark: 18

Content Filtering: Disabled

Dynamic Content Filtering: Disabled

URL-Blacklisting: Disabled

URL-Blacklisting Match-method: Exact

Content Filtering Match-method: Generic

Interpretation of Charging-rule-base-name: active-charging-group-of-ruledefs

Selection of Charging-rule-base AVP : Last

Credit Control:

Group         : test

Mode                   : diameter

APN-name-to-be-included: gn

Trigger-Type           : N/A

Failure-Handling:

Initial-Request  : continue retry-after-tx-expiry

Update-Request   : retry-and-terminate

Terminate-Request: retry-and-terminate

Server Unreachable Failure-Handling:

Initial-Request  : terminate

Update-Request   : continue

Risoluzione dei problemi

Immettere il comando show active-charge credit-control statistics per visualizzare le statistiche relative ai meccanismi SU e FH. Di seguito è riportato un esempio di output:

#show active-charging credit-control statistics

...

OCS Unreachable Stats:

Tx-Expiry:               2291985       Response-TimeOut:        615

Connection-Failure:      2             Action-Continue:         0

Action-Terminated:       0             Server Retries:          2023700

Assumed-Positive Sessions:

Current:                 2             Cumulative:              2196851

Di seguito sono riportate alcune note importanti sull'output di questo esempio:

- Tx-Expiry âÂ Indica una condizione SU a causa di una scadenza Tx.

- Response-Timeout âÂ Indica una condizione SU dovuta a una RT.

- Connection-Failure âÂÂ Indica una condizione SU a causa di un errore di trasporto.

- Azione-ContinuaÂ Questo campo indica il numero di sessioni non in linea.

- Azione-TerminaÂÂ Questo campo indica il numero di sessioni terminate.

- Tentativi server âÂÂ Questo campo indica il numero di tentativi di OCS.

- Sessioni presunte positive:

- Current âÂÂ Questo campo indica il numero di sessioni attualmente nella condizione SU.

- Cumulativo âÂÂ Questo campo indica il numero totale di sessioni passate allo stato SU.

Immettere il comando show active-charge session full all per visualizzare le informazioni correlate allo stato su della sessione. Di seguito è riportato un esempio di output:

#show active-charging sessions full all

..

..

Current Server Unreachable State:                           CCR-I

Interim Volume in Bytes (used / allotted):                 84/ 200

Interim Time in Seconds (used / allotted):                 80/ 3600

Server Retries (attempted / configured):                    1/ 50

Di seguito sono riportate alcune note importanti sull'output di questo esempio:

- Current Server Unreachable State âÂ Specifica se lo stato corrente su è dovuto a CCR-I o CCR-U.

- Volume provvisorio in byte (utilizzato/assegnato) âÂÂ Mostra il volume provvisorio in byte utilizzati rispetto ai byte allocati.

- Tempo intermedio in secondi (utilizzato/assegnato) âÂÂ Mostra il volume intermedio in secondi utilizzati rispetto ai secondi allocati.

- Tentativi server (tentati/configurati) âÂÂ Numero di tentativi server rispetto al numero configurato.

Informazioni correlate

- Guida di riferimento all'interfaccia della riga di comando, StarOS release 16

- Documentazione e supporto tecnicoÂ Cisco Systems