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 :
- Le PCEF envoie un CCR-I à OCS.
- 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.
- 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.
- Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.
- 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.
- 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.
- 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 :
- Le PCEF envoie un CCR-I à OCS.
- 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.
- 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.
- Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.
- 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.
- 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.
- 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 :
- Le PCEF envoie un CCR-U au OCS.
- 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.
- 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.
- Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.
- 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é.
- 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.
- L'ensemble du quota consommé est signalé au OCS avec le CCR-U réussi.
- 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 :
- Le PCEF envoie un CCR-U au OCS.
- 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.
- 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.
- Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.
- 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é.
- 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.
- Le PCEF envoie un CCR-T à OCS afin de signaler l'intégralité du quota consommé.
- 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 :
- Le PCEF envoie un CCR-U au OCS.
- 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.
- 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.
- Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session.
- 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é.
- 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.
- Le PCEF lance une nouvelle session avec le CCR-I et reçoit le CCA-I.
- 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 :
- Le PCEF envoie le CCR-U pour RG1 à OCS.
- 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.
- 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.
- Si le volume et/ou l'heure intermédiaires sont configurés, le quota intermédiaire est attribué à la session
- À 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.
- 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.
- 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.
- L'ensemble du quota consommé est signalé au OCS avec le CCR-U réussi.
- 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 :
- Le PCEF envoie un CCR-T à OCS.
- 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.
- 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 :
- Le PCEF envoie un CCR à OCS et le OCS répond par un code d'erreur.
- Le code d'erreur est configuré de manière statique dans le mécanisme SU.
- 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