Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Configuration

Diagramme du réseau

Expiration Tx

Délai de réponse

Basculement de session de diamètre

Mécanisme FH

Configuration du mécanisme FH

Comportement par défaut du mécanisme FH

Flux d'appels détaillé du mécanisme FH

Mécanisme SU

Configuration du mécanisme SU

Flux d'appels du mécanisme SU

Exemples de configuration FH et SU

Vérification

Dépannage

Informations connexes

Introduction

Ce document décrit comment configurer les mécanismes de gestion des pannes (FH) et de serveur inaccessible (SU) sur l'interface Gy afin de résoudre les problèmes rencontrés sur le système de facturation en ligne (OCS) ou en ce qui concerne la connectivité entre la fonction PCEF (Policy and Charging Enforcement Function) et OCS. Les informations décrites dans ce document s'appliquent aux fonctionnalités Home Agent (HA), Gateway General Packet Radio Service (GPRS) Support Node (GGSN) et Packet Data Network Gateway (PGW) qui s'exécutent sur le routeur à services agrégés de la gamme Cisco 5000 (ASR5K).

Conditions préalables

Conditions requises

Cisco recommande que votre système réponde à ces exigences afin d'utiliser les mécanismes FH et SU :

- Le service de tarification améliorée (ECS) est disponible

- Le PCEF existe au sein de la HA, GGSN ou PGW

- Il existe une connectivité de diamètre correct via la base de données

- L'application Diamètre Credit Control Application (DCCA) est disponible

Components Used

Les informations de ce document sont basées sur toutes les versions de l'ASR5K.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Le PCEF est connecté à OCS via l'interface Gy, qui utilise Diameter comme protocole de base et DCCA. Il s'agit du flux de messages entre le PCEF et le OCS :

- Demande de contrôle de crédit (CCR) âÂ  â  Ce message est envoyé du PCEF au BSC. Il existe trois types de messages CCR : Initial, Update et Terminate.

- Réponse au contrôle du crédit (DPA) -  -  Ce message est envoyé du BCP au PCEF en réponse au CCR. Il existe également trois types de messages CCA : Initial, Update et Terminate.

- Demande de réautorisation (RAR) -  -  Ce message est envoyé par le Bureau des services de communication au PCEF lorsqu'une nouvelle autorisation de session est requise.

- Réponse de réautorisation (RAA) -  -  Ceci est la réponse au RAR du PCEF au OCS.

La connectivité de diamètre est établie entre le PCEF et le OCS afin d'activer le flux de messages. Il est possible que l'OCS envoie des messages négatifs, que la connexion de transport échoue entre le PCEF et l'OCS ou que le message expire, ce qui peut provoquer une défaillance dans l'établissement de la session de l'abonné. Cela peut empêcher l'abonné d'utiliser les services.

Ces deux mécanismes peuvent être utilisés pour résoudre ce problème :

- Le mécanisme FH

- Le mécanisme des États-Unis

Configuration

Cette section décrit les configurations requises pour prendre en charge les mécanismes FH et SU.

Diagramme du réseau

Les informations de ce document utilisent cette topologie :

Expiration Tx

Il s'agit d'un compteur de niveau application pour le DCCA qui est configurable dans les paramètres de contrôle de crédit de diamètre. La valeur peut être comprise entre 1 et 300 secondes.

Voici un exemple :

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

Délai de réponse

Il s'agit d'un délai d'expiration de la base de données et il est configurable dans les paramètres Diamètre du point de terminaison. La valeur peut être comprise entre 1 et 300 secondes.

Note: La valeur configurée pour ce compteur doit être supérieure à celle utilisée pour le compteur Tx-Expiry.

Voici un exemple :

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

Basculement de session de diamètre

Cette fonctionnalité est utilisée afin d'activer ou de désactiver le basculement de session de contrôle de crédit de diamètre, qui permet au système d'utiliser un serveur secondaire lorsque le serveur principal devient inaccessible. Ceci est configurable dans les paramètres de contrôle de crédit de diamètre.

Voici un exemple :

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

Mécanisme FH

Le mécanisme FH ne fonctionne que si le basculement de session de diamètre est présent. Le FH permet au système de choisir de poursuivre la session et de la convertir en mode hors connexion, ou de mettre fin à la session en cas d'erreur de connexion ou de niveau message.

Note: Le FH est activé et configuré par défaut.

Configuration du mécanisme FH

Le mécanisme FH peut être configuré dans les paramètres de contrôle de crédit de diamètre. Voici la syntaxe utilisée dans la configuration 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 première section spécifie le type de demande : Initial (CCR-I), Update (CCR-U) et Terminate (CCR-T).

La deuxième section spécifie l'action qui doit être effectuée lorsque le mécanisme FH est activé. Ces trois actions sont possibles avec le mécanisme FH :

- Continue ââ  â  Ceci permet à la session de continuer et de la convertir en mode hors connexion. Cette fonction utilise deux options liées à l'expiration du délai d'attente :

- Go-offline-after-tx-expiration âÂ  â  Ceci commence la charge hors connexion après l'expiration de Tx se produit.

- Retry-after-tx-expiration âÂ  â  Ceci renouvelle le serveur secondaire après l'expiration de Tx.

- Réessayer et terminer âÂ  â  Cette opération met fin à la session après que le système a recommencé le serveur secondaire, si le serveur secondaire n'est pas disponible non plus. Cela utilise également l'option Retry-after-tx-expiration, qui tente à nouveau le serveur secondaire après l'expiration de Tx.

- Terminate âÂ  â  Ceci met fin à la session sans aucune tentative de contact avec le serveur secondaire.

Comportement par défaut du mécanisme FH

Cette section décrit le comportement par défaut de FH lorsqu'aucune configuration n'est présente. Par défaut, le mécanisme FH est activé lors d'un délai de réponse (RT), sauf lorsque l'action Terminate est configurée.

Si une paire de valeurs d'attribut Credit-Control-Failure-Handling (AVP) est reçue du serveur, les paramètres reçus sont appliqués.

Voici quelques exemples :

- Demande initiale > Terminer

- Update-Request > Retry-and-Terminate

- Terminate-Request > Retry-and-Terminate

Flux d'appels détaillé du mécanisme FH

Cette section décrit le flux d'appels détaillé du mécanisme FH avec toutes les options possibles.

Demande initiale

Paramètre CCFH

Commande CLI

Comportement à Tx

Comportement à RT

Le secondaire est actif

Secondaire désactivé

Continuer

requête initiale

continuer

S/O

Continuer

Secondaire

prend le relais après

RT

Hors ligne après une autre RT.

Aucune autre demande de quota n'est effectuée

pour tout groupe de notation de la session

après une défaillance DCCA (même si

la connectivité à DCCA est restaurée)

requête initiale

continuer la mise hors connexion après-

tx-expiration

Hors ligne

S/O

Hors ligne à Tx

Hors ligne à Tx

requête initiale

continuer la tentative après-

tx-expiration

Continuer

S/O

Secondaire

prend le relais après

Tx

Hors connexion après une autre transaction

Réessayer et terminer

requête initiale

réessayer et terminer

S/O

Réessayer

Secondaire

prend le relais après

RT

Terminer après une autre RT

requête initiale

réessayer et terminer

retry-after-tx-expiration

Réessayer

S/O

Secondaire

prend le relais après

Tx

Terminer après une autre transaction

Terminer

requête initiale

terminer

Terminer

S/O

Terminer après Tx

Terminer après Tx

Update-Request

Paramètre CCFH

Commande CLI

Comportement à Tx

Comportement à RT

Le secondaire est actif

Secondaire désactivé

Continuer

update-request

continuer

S/O

Continuer

Secondaire

prend le relais après

RT

Hors connexion après une autre RT

update-request

continuer la mise hors connexion après-

tx-expiration

Hors ligne

S/O

Hors ligne à Tx

Hors ligne à Tx

update-request

continuer la tentative après-

tx-expiration

Continuer

S/O

Secondaire

prend le relais après

Tx

Hors connexion après une autre transaction

Réessayer et terminer

update-request

réessayer et terminer

S/O

Réessayer

Secondaire

prend le relais après

RT

Envoie CCR-T après une autre RT

update-request

réessayer et terminer

retry-after-tx-expiration

Réessayer

S/O

Secondaire

prend le relais après

Tx

Envoie CCR-T après une autre transmission

Terminer

update-request

terminer

Terminer

S/O

Envoie CCR-T après Tx

Envoie CCR-T après Tx

Terminate-Request

Paramètre CCFH

Commande CLI

Comportement à Tx

Comportement à RT

Le secondaire est actif

Secondaire désactivé

Continuer

Terminer-request

continuer

S/O

Réessayer

CCR-T est envoyé

au secondaire

après RT

Terminer après une autre RT

Terminer-request

continuer la mise hors connexion après-

tx-expiration

Réessayer

S/O

CCR-T est envoyé

au secondaire

après Tx

Terminer après une autre transaction

Terminer-request

continuer la tentative après-

tx-expiration

Réessayer

S/O

CCR-T est envoyé

au secondaire

après Tx

Terminer après une autre transaction

Réessayer et terminer

Terminer-request

réessayer et terminer

S/O

Réessayer

CCR-T est envoyé

au secondaire

après RT

Terminer après une autre RT

Terminer-request

réessayer et terminer

retry-after-tx-expiration

Réessayer

S/O

CCR-T est envoyé

au secondaire

après Tx

Terminer après une autre transaction

Terminer

Terminer-request

terminer

Terminer

S/O

Terminer après

Tx

Terminer après Tx

Mécanisme SU

Le mécanisme SU est similaire au mécanisme FH, mais il fournit un contrôle plus granulaire des procédures de défaillance. En plus de la poursuite de la session après les échecs de niveau de message et de connexion (transport), ce mécanisme peut être utilisé lorsque les réponses sont lentes à partir du OCS. Il fournit également les options permettant de poursuivre la session pendant une certaine durée/épuisement du quota avant la fin, ou d'utiliser un quota provisoire configurable (volume et temps) et des tentatives de serveur configurables avant qu'une session ne soit convertie en mode hors connexion ou terminée.

Configuration du mécanisme SU

Le mécanisme SU peut être configuré dans les paramètres de contrôle de crédit de diamètre. La syntaxe utilisée dans la configuration SU varie en fonction de la version utilisée.

Pour les versions 12.1 et antérieures, il s'agit de la syntaxe utilisée pour la configuration du mécanisme SU :

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

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

| aftertimer-expiry <timeout_period> ] } }

Pour les versions 12.2 et ultérieures, il s'agit de la syntaxe utilisée pour la configuration du mécanisme 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> ] } }

Note: Dans les versions antérieures à la version 12.2, il était possible de configurer indépendamment les mécanismes FH et SU ; cependant, dans les versions 12.2 et ultérieures, le mécanisme SU a priorité sur le mécanisme FH lorsqu'il est configuré.

Si le serveur renvoie l'AVP CC-FH et que le mécanisme SU est configuré pour un ensemble de déclencheurs de comportement, la configuration SU est appliquée ; sinon, la valeur AVP CC-FH est appliquée. Par défaut, les codes de résultats tels que 3002, 3004 et 3005 sont défaillants de livraison et sont traités comme des RTs.

Ces actions sont possibles avec le mécanisme des États-Unis :

- Comportement-Déclencheur -  -  Indique le type de messages pouvant être des Demandes initiales (CCR-I) ou Demandes de mise à jour (CCR-U). Trois options sont disponibles pour ces déclencheurs :

- Code de résultat âÂ  â  Ceci permet de configurer des codes de résultat spécifiques, une plage de codes de résultat (3000-5999), ou toute erreur avec le type de message.

- Transport-Failure -  â  Cette spécification déclenche le comportement en cas de défaillance du transport, qui est rétrocompatible avec la version 12.0. Deux options sont disponibles pour ce paramètre :

- Response-Timeout âÂ  Â  Cette option déclenche le comportement sur RT et doit toujours être utilisée avec les échecs de transport.

- Tx-Expiry âÂ  â  Cette option déclenche le comportement à l'expiration de Tx et doit toujours être utilisée avec une défaillance de transport.

- Actions —  â  Indique l'action qui est exécutée lorsqu'un déclencheur SU pour CCR-I ou CCR-U se produit. Cette action varie en fonction du type de message et de la version du logiciel.

- Continuer âÂ  â  Cela permet de convertir la session en mode hors connexion et de continuer. Aucune autre option n'est disponible pour l'utilisation de cette action dans les versions antérieures à la version 12.2. Dans les versions 12.2 et ultérieures, les options de quota intermédiaire, de tentatives de serveur et d'expiration après délai de temporisation sont disponibles pour la configuration avec cette action.

- Terminate âÂ  â  Ceci entraîne la fin de la session lorsque le serveur devient inaccessible. Cette action autorise les options de quota intermédiaire, de tentatives de serveur et d'expiration après minuteur.

Ces options peuvent être utilisées avec l'action Continuer ou Terminer :

- Post-intermédiaire-time âÂ  â  Cette option permet la continuation ou la fin de l'appel après la période de temporisation intermédiaire. Ceci est similaire à un quota de temps avant l'exécution de l'action. La valeur est formatée en secondes et peut être comprise entre 1 et 4 294 967 295.

- After-intermédiaire-volume âÂ  â  Cette option attribue le quota intermédiaire et permet la poursuite ou la fin de la session avant l'épuisement du volume configuré. La valeur est formatée en octets et peut être comprise entre 1 et 4 294 967 295.

- Server-retries -  ââ' Cette option permet au PCEF de réessayer le OCS avant la poursuite ou la fin de la session. Le nombre de tentatives peut être configuré et la valeur est comprise entre 0 et 65 535. Si la valeur est égale à zéro, la nouvelle tentative ne se produit pas et l'action est immédiatement appliquée.

Note: Les options post-provisoire et post-intermédiaire-volume sont toujours utilisées avec l'option server-retries, ou les trois peuvent être utilisées simultanément et appliquées à la fois pour poursuivre et terminer les actions. Les options post-provisoire et post-intermédiaire-volume attribuent également du temps ainsi que des quotas de volume, et le quota épuisé déclenche d'abord une nouvelle tentative du serveur.

- After-timer-expiration âÂ  Â  Cette option spécifie la durée (en secondes) pendant laquelle les sessions restent dans l'état hors connexion avant la fin. Les valeurs peuvent être comprises entre 1 et 4 294 967 295. Cette option ne s'applique qu'aux actions terminées.

- Après l'expiration du quota âÂ  â  Cette option met fin à la session à l'épuisement du quota déjà assigné.

Voici quelques informations importantes à retenir :

- Les options post-provisoire, post-intermédiaire-volume et server-retries peuvent être utilisées individuellement ou en combinaison, et elles sont applicables aux actions de poursuite et de fin.

- L'option post-quota-expiration ne s'applique qu'au déclencheur de comportement Update-Requests.

- L'option post-expiration du compteur ne s'applique qu'à l'action de fin.

- Les options post-provisoire, post-provisoire-volume et server-retries ne s'appliquent qu'aux versions 12.2 et ultérieures.

- Si le basculement de session de diamètre est pris en charge (et configuré), le serveur secondaire est toujours contacté avant le déclenchement du mécanisme SU.

- Le serveur qui a été contacté avant le déclenchement du mécanisme de l'unité de mesure est toujours contacté lorsque l'heure ou le volume intermédiaire est épuisé et que l'option de nouvelles tentatives du serveur est configurée avec une valeur supérieure à zéro. Par exemple, si OCS1 est essayé en premier et OCS2 est essayé après une erreur sur OCS1, alors la communication avec OCS2 déclenche le mécanisme SU. Pendant la tentative de nouvelle tentative du serveur, OCS2 est contacté en premier, puis OCS1 si une réponse négative est reçue d'OCS2.

Flux d'appels du mécanisme SU

Le mécanisme SU peut être déclenché par une défaillance du CCR-I ou du CCR-U, et la cause peut être un code d'erreur, une défaillance de transport, une expiration de Tx ou une RT. L'action peut être une allocation de quota intermédiaire (temps et/ou volume), le nombre de tentatives du serveur, la valeur du compteur (cause la déconnexion de la session pendant une durée spécifiée et uniquement pour la fin), ou l'expiration du quota (uniquement pour le CCR-U et la fin) avant que la session ne soit hors connexion ou se termine.

Le quota provisoire est fourni par session et non par groupe de cotation (RG) dans les scénarios MSCC (Multiple Services Credit Control).

Il est possible que le serveur principal déclenche une défaillance de transport et que le serveur secondaire déclenche l'expiration de délai de réponse ou l'expiration de délai de réponse. Dans ce scénario, la dernière erreur est considérée comme le déclencheur de l'échec.

Si le mécanisme SU n'est configuré pour aucun déclencheur de défaillance, le mécanisme FH est déclenché.

Note: Les sections suivantes fournissent des exemples de flux d'appels liés au mécanisme SU. Ces flux d'appels sont fournis sous l'hypothèse que le basculement de session de diamètre est pris en charge et que le serveur secondaire est configuré avec une valeur d'expiration Tx inférieure à la valeur RT. En outre, on suppose que le mécanisme SU est configuré pour les défaillances de transport, Tx-expiration et RT.

Demande initiale sans déconnexion de session

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR-I à OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, le mécanisme SU est déclenché. Cela se produit immédiatement pour les défaillances de transport ou après l'expiration de la taxe pour un délai d'attente.

4. Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.

5. Après épuisement du quota intermédiaire (temps ou volume) et si la valeur des tentatives du serveur est supérieure à zéro, le CCR-I est de nouveau envoyé au serveur qui a déclenché le mécanisme SU. En cas de défaillance supplémentaire, le CCR-I est envoyé à un autre serveur.

6. Si l'échec du transport ou le délai d'attente Tx est de nouveau détecté, les étapes 2 à 5 sont répétées jusqu'à ce que la valeur des nouvelles tentatives du serveur soit épuisée ou qu'une réponse réussie ne vienne pas de OCS.

7. Si le problème existe toujours, la session se poursuit (convertie en mode hors connexion) ou se termine conformément à la configuration.

Note: Le quota provisoire qui est consommé pendant la session passe en mode SU en raison de CCR-I n'est pas indiqué dans le prochain CCR-I. Tous les contingents provisoires utilisés sont déclarés dans le CCR-U, qui suit le CCA-I réussi.

Demande initiale avec déconnexion de session

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR-I à OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, le mécanisme SU est déclenché. Cela se produit immédiatement pour les défaillances de transport ou après l'expiration de la taxe pour un délai d'attente.

4. Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.

5. Après épuisement du quota intermédiaire (temps ou volume) et si la valeur des tentatives du serveur est supérieure à zéro, le CCR-I est de nouveau envoyé au serveur qui a déclenché le mécanisme SU. En cas de défaillance supplémentaire, le CCR-I est envoyé à un autre serveur.

6. Si l'échec du transport ou le délai d'attente Tx est de nouveau détecté, les étapes 2 à 5 sont répétées jusqu'à ce que la valeur des nouvelles tentatives du serveur soit épuisée ou qu'une réponse réussie ne vienne pas de OCS. À ce stade, la session est déconnectée sans consommation de l'intégralité du quota provisoire.

7. Après la fin de la session, le PCEF envoie à nouveau le CCR-I afin de commencer une nouvelle session. Si cela réussit, le PCEF envoie le CCR-T, qui signale l'ensemble du quota temporaire utilisé.

Update-Request sans déconnexion de session

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR-U au OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, le mécanisme SU est déclenché. Cela se produit immédiatement pour les défaillances de transport ou après l'expiration de la taxe pour un délai d'attente.

4. Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.

5. Après épuisement du quota intermédiaire (temps ou volume) et si la valeur des tentatives du serveur est supérieure à zéro, le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme SU. En cas d'autre défaillance, un CCR-U est envoyé à un autre serveur qui contient l'intégralité du quota non déclaré consommé.

6. Si l'échec du transport ou le délai d'attente Tx est de nouveau détecté, les étapes 2 à 5 sont répétées jusqu'à ce que la valeur des nouvelles tentatives du serveur soit épuisée ou qu'une réponse réussie ne vienne pas de OCS.

7. L'ensemble du quota consommé est signalé au OCS avec le CCR-U réussi.

8. Si le problème existe toujours, la session se poursuit (convertie en mode hors connexion) ou se termine conformément à la configuration après épuisement de la valeur de nouvelle tentative maximale.

Demande de mise à jour avec déconnexion de session

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR-U au OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, le mécanisme SU est déclenché. Cela se produit immédiatement pour les défaillances de transport ou après l'expiration de la taxe pour un délai d'attente.

4. Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.

5. Après épuisement du quota intermédiaire (temps ou volume) et si la valeur des tentatives du serveur est supérieure à zéro, le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme SU. En cas d'autre défaillance, un CCR-U est envoyé à un autre serveur qui contient l'intégralité du quota non déclaré consommé.

6. Si l'échec du transport ou le délai d'attente Tx est de nouveau détecté, les étapes 2 à 5 sont répétées jusqu'à ce que la valeur des nouvelles tentatives du serveur soit épuisée ou qu'une réponse réussie ne vienne pas de OCS. À ce stade, la session est déconnectée avant de consommer l'intégralité du quota temporaire.

7. Le PCEF envoie un CCR-T à OCS afin de signaler l'intégralité du quota consommé.

8. Si le BSC répond par un code de résultat 2002, les rapports supplémentaires ne sont pas nécessaires.

Update-Request avec session inconnue

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR-U au OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, le mécanisme SU est déclenché. Cela se produit immédiatement pour les défaillances de transport ou après l'expiration de la taxe pour un délai d'attente.

4. Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.

5. Après épuisement du quota intermédiaire (temps ou volume) et si la valeur des tentatives du serveur est supérieure à zéro, le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme SU. En cas d'autre défaillance, un CCR-U est envoyé à un autre serveur qui contient l'intégralité du quota non déclaré consommé.

6. L'OCS répond avec un code de résultat 5002 (ID de session inconnu) pour le CCR-U, ce qui est possible dans le scénario où l'OCS a redémarré et perdu les informations d'ID de session.

7. Le PCEF lance une nouvelle session avec le CCR-I et reçoit le CCA-I.

8. Le PCEF signale l'intégralité du quota provisoire consommé via CCR-U dans les messages suivants.

Update-Request avec plusieurs RG (scénario MSCC)

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie le CCR-U pour RG1 à OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, le mécanisme SU est déclenché. Cela se produit immédiatement pour les défaillances de transport ou après l'expiration de la taxe pour un délai d'attente.

4. Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session

5. À ce stade, RG2 épuise également l'intégralité du quota assigné mais n'initie pas le CCR-U car la session est déjà en mode SU et commence à consommer le quota provisoire.

6. Après épuisement du quota intermédiaire (temps ou volume) et si la valeur des tentatives du serveur est supérieure à zéro, le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme SU. En cas d'échec supplémentaire, un CCR-U est envoyé à un autre serveur qui contient l'intégralité du quota non déclaré consommé pour les deux groupes de routage.

7. Si l'échec du transport ou le délai d'attente Tx est de nouveau détecté, les étapes 2 à 6 sont répétées jusqu'à ce que la valeur des nouvelles tentatives du serveur soit épuisée ou qu'une réponse réussie ne vienne pas de OCS.

8. L'ensemble du quota consommé est signalé au OCS avec le CCR-U réussi.

9. Si le problème existe toujours, la session se poursuit (convertie en mode hors connexion) ou se termine conformément à la configuration après épuisement de la valeur de nouvelle tentative maximale.

Terminate-Request

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR-T à OCS.

2. Un dépassement de délai ou une défaillance de transport est détecté. Si une défaillance de transport est détectée, le PCEF recommence immédiatement avec le serveur secondaire ; sinon, l'expiration de taxe est déclenchée.

3. Si le serveur secondaire présente également une défaillance ou un délai d'attente de transport, la session est supprimée.

Gestion du code d'erreur CCR

Voici le flux de messages pour ce scénario :

1. Le PCEF envoie un CCR à OCS et le OCS répond par un code d'erreur.

2. Le code d'erreur est configuré de manière statique dans le mécanisme SU.

3. Le PCEF fournit le quota intermédiaire sans nouvelle tentative sur le serveur secondaire.

Exemples de configuration FH et SU

Cette section fournit un exemple de configuration pour les mécanismes FH et SU. Lorsque les deux mécanismes FH et SU sont configurés, le SU prime sur le FH pour le même déclencheur de comportement.

Voici un exemple :

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

Vérification

Afin de vérifier que votre configuration fonctionne correctement, entrez la commande show active-load service <nom de service> :

# 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

Dépannage

Entrez la commande show active-load credit-control statistics afin d'afficher les statistiques liées aux mécanismes SU et FH. Voici un exemple de sortie :

#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

Voici quelques remarques importantes sur cette sortie d'exemple :

- Tx-Expiry â â  Ceci indique une condition SU due à une expiration Tx.

- Response-Timeout -  â  Ceci indique une condition SU due à une RT.

- Connexion-Échec -  -  Indique une condition SU due à une défaillance de transport.

- Action-Continue -  -  Ce champ indique le nombre de sessions qui se sont déconnectées.

- Action-Terminate âÂ  â  Ce champ indique le nombre de sessions qui ont été terminées.

- Server Retries -  -  Ce champ indique le nombre de tentatives de l'OCS.

- Sessions présumées positives :

- Current âÂ  â  Ce champ indique le nombre de sessions qui sont actuellement dans la condition SU.

- Cumulative ââ â  Ce champ indique le nombre total de sessions qui sont passées à l'état SU.

Entrez la commande show active-load sessions full all afin d'afficher les informations liées à l'état SU de la session. Voici un exemple de sortie :

#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

Voici quelques remarques importantes sur cette sortie d'exemple :

- Current Server Unreachable State -  -  Indique si l'état actuel du SU est dû au CCR-I ou au CCR-U.

- Volume intermédiaire en octets (utilisé/alloué) âÂ  â  Affiche le volume intermédiaire en octets utilisés par rapport aux octets alloués.

- Temps intermédiaire en secondes (utilisé/alloué) â  â  Affiche le volume intermédiaire en secondes utilisé par rapport aux secondes allouées.

- Tentatives de serveur (tentées/configurées) -  -  Nombre de tentatives de serveur par rapport à celui configuré.

Informations connexes

- Référence de l'interface de ligne de commande, StarOS version 16

- Support technique et documentation -  -  Cisco Systems