Politique 3GPP et contrôle de la facturation pour le provisionnement et la comptabilité des réseaux filaires

Avantages de la politique 3GPP et de l’architecture de contrôle de charge

• Fournit un cadre unifié pour le provisionnement et la comptabilité des abonnés sur réseau fixe.

Environnement d’accès filaire

Pour les abonnés mobiles, l’équipement utilisateur demande des services ; pour les abonnés aux services filaires à large bande, le PCRF demande des services. Dans l’environnement filaire, le PCRF agit à titre de demandeur de service, et le PCEF agit à titre de destinataire et d’exécuteur du service.

L’adaptation du modèle PCC dans un environnement filaire offre les avantages suivants :

• Commodité

• Technologie avancée

• Déjà mis en œuvre par la branche sans fil de l’opérateur qui fournit souvent une activité beaucoup plus importante que la branche filaire

Le PCRF contrôle le PCEF en appliquant des règles de facturation. Les règles de facturation sont réutilisées en tant que règles de service (de politique) pour appliquer les politiques. Les règles de facturation peuvent également avoir un groupe d’évaluation associé ou une clé de facturation. Par conséquent, la configuration du PCEF doit définir des règles de facturation et une correspondance entre les services de contrôle de crédit (cc-services) et les groupes de notation.

Dans de nombreux cas, les services de comptabilité OCS et OFCS (Offline Charging System) 3GPP exigent que le numéro d’annuaire international des abonnés de la station mobile (MSISDN) soit utilisé pour l’identification des abonnés. Le MSISDN est transmis comme ID d’abonnement. Bien que chaque équipement d’utilisateur mobile soit associé à un MSISDN, cette information n’est pas disponible pour les abonnés filaires. Pour permettre au PCRF de transmettre dynamiquement les paramètres d’ID d’abonnement et de prendre en charge diverses configurations d’authentification, d’autorisation et de provisionnement, les paires attributs-valeur (AVP) de Juniper du tableau 2 ont été allouées à partir de l’espace ID fournisseur de Juniper (2636) attribut spécifique au fournisseur (VSA).

Le système client (routeur) envoie l’AVP de l’indicateur d’abonnement Juniper-Dyn pour indiquer la prise en charge de l’attribution dynamique de l’ID d’abonnement. L’attribut Juniper-Dyn-Subscription-Id-Indicator a deux valeurs :

• DYN_SUBSCRIPtION_NOT_SUPPORTED (0)

• DYN_SUBSCRIPTION_SUPPORTED (1)

Le serveur envoie ensuite l’AVP Juniper-Dyn-Subscription-Id au client qui a indiqué l’assistance. Il s’agit d’un AVP groupé qui contient les valeurs à envoyer en tant que Subscription-Id-Type et Subscription-Id-Data.

Dans de nombreux cas, les abonnés filaires ne prennent en charge qu’une seule famille IP, ce qui est une information obligatoire à la fois pour le service AAA et le PCRF. Pour indiquer cette information, l’AVP de l’indicateur de famille de réseaux Juniper a été alloué à partir de l’espace ID fournisseur de Juniper (2636) VSA du tableau 3.

Le système client (routeur) envoie l’AVP Juniper-Network-Family-Indicator pour indiquer quelles familles de réseaux sont associées à la demande de service et prises en charge par l’abonné. Lorsque vous configurez l’AVP de l’indicateur de famille de réseaux Juniper pour indiquer la famille de réseaux associée, le système envoie les informations au PCRF. L’attribut Juniper-Network-Family-Indicator a quatre valeurs :

• NON SPÉCIFIÉ (0)

• IPV4_FAMILY (1)

• IPV6_FAMILY (2)

• IPV4_IPV6_FAMILY (3)

Les clients des services filaires contrôlent souvent les services aux utilisateurs uniquement par le biais du PCRF et utilisent l’OCS comme un mécanisme pratique de surveillance de l’utilisation en temps réel plutôt que comme une unité d’application. Pour réduire le nombre de configurations OCS erronées possibles, incluez l’instruction force-continue au niveau de la [edit access ocs partition partition-name] hiérarchie pour forcer le PCEF haut débit (BPCEF) à limiter l’impact des réponses négatives de l’OCS et des expirations de quota, et pour empêcher l’envoi de notifications OCS aux groupes de classification concernés. Chaque fois que le PCEF reçoit une réponse négative à un groupe signalé, il cesse de signaler ce groupe à l’OCS.

Environnement Junos OS

Il existe trois catégories de profils dynamiques dans l’environnement Junos OS :

• profils dynamiques du client

• profils-dynamiques-de-service-cos

• profils dynamiques de service de pare-feu

Les profils dynamiques du client et les profils dynamiques des services cos définissent la bande passante et d’autres caractéristiques des services fournis à un abonné ; Les profils de service de pare-feu effectuent le filtrage et le comptage des utilisations. Pour toutes les catégories des profils dynamiques, le nom du profil dynamique du service est utilisé comme valeur d’un AVP Charging-Rule-Name.

Lorsque service-dynamic-profile n’a pas de variables, ou lorsque les valeurs par défaut fournies dans la définition service-dynamic-profile sont demandées, aucun élément supplémentaire n’est requis. Pour fournir des valeurs personnalisées pour un profil dynamique de service, utilisez l’AVP Charging-Rule-Definition avec des VSA supplémentaires.

Le PCRF utilise les VSA de substitution de Juniper existants (ID de fournisseur 2636 et Type 2024) pour fournir des attributs sous forme de paires nom-valeur. Le PCRF peut également inclure des paramètres comme notation de position pour une partie du nom de la règle. L’AVP Informations de redirection (ID de fournisseur 10415 et Type 1085) fournit une valeur pour le paramètre URL de redirection.

Pour chaque nom de paramètre de profil dynamique de service demandé par les clients, un nouveau VSA de paramètre Juniper est défini. Le Tableau 4 décrit l’ensemble initial de VSA fixes de paramètres Juniper.

Si les paramètres ou l’identificateur de service et le groupe de classification doivent être indiqués par le PCRF, la définition de la règle de tarification AVP est utilisée ; sinon, le nom de la règle de facturation AVP est utilisé.

Dans les cas où il existe une combinaison Service-Identifier et Rating-Group, ou lorsque seul Service-Identifier ou uniquement Rating-Group est spécifié, la combinaison doit être unique parmi les règles installées pour un abonné. Vous configurez service-context-id sur le routeur.

Connexion abonné

Le routeur envoie une requête CCR Diameter contenant un ensemble fixe d’informations requises à un gestionnaire de stratégies (PCRF) et reçoit une réponse CCA contenant des stratégies et d’autres informations. Le provisionnement Gx est activé pour les abonnés lorsque vous incluez l’instruction provisioning-order pcrf au niveau de la [edit access profile profile-name] hiérarchie. Lorsqu'une application demande à AAA d'activer la session du abonné, le routeur envoie un message CCR-GX-I (où I représente INITIAL_REQUEST) au PCRF pour demander un ensemble fixe d'informations de provisionnement pour la session abonné, et reçoit un message de réponse CCA-GX-I contenant des politiques et d'autres informations, y compris le code de résultat AVP (code AVP 268).

Lorsque vous configurez l’instruction provisioning-order dans le profil d’accès, le module PCEF haut débit (BPCEF) envoie une demande de provisionnement au PCRF lors de l’activation du client. Les exemples suivants illustrent un échange de paquets CCR-GX-I et CCA-GX-I :

Exemple de paquet CCR-GX-I

Exemple de paquet CCA-GX-I

Le PCRF renvoie un message CCA-GX-I qui comprend le code de résultat AVP (code AVP 268) qui correspond aux catégories de résultats répertoriées dans le tableau 5.

Comme le montre le tableau 6, le traitement des réponses CCA-GX-I dépend de trois facteurs :

• Si le délai d’expiration de la décision locale a expiré

• Le cadre de la décision locale

• La catégorie de résultat

Le Tableau 6 contient également les actions d’expiration du délai d’expiration des décisions locales PCRF.

Une connexion d’abonné déclenche la séquence d’événements suivante :

1. Une application cliente, telle que DHCP, PPP ou sessions d’abonné statiques, demande AAA d’authentifier l’abonné.

2. L’authentification commence si le profil d’accès de l’abonné spécifie l’authentification RADIUS. La connexion se poursuit une fois l’authentification réussie. La connexion échoue lorsque l’instruction authentication-order du profil ne spécifie pas d’authentification RADIUS ou pas d’authentification. La connexion échoue également en cas d’échec de l’authentification.

3. Les services par défaut sont activés pour l’abonné. Tous les services que le serveur d’authentification inclut dans l’octroi d’authentification sont activés. En outre, un service par défaut peut avoir été configuré pour l’application cliente.

4. Si le profil d’accès de l’abonné spécifie le provisionnement Gx, le routeur initie l’échange de messages Gx en envoyant un message CCR-GX-I au PCRF. Le routeur attend que le PCRF réponde avec un message CCA-GX-I dans un délai d’expiration non configurable.

   Lorsque le PCRF répond dans le délai d’expiration et inclut l’AVP Charge-Rule-Install dans le message CCA-GX-I, la connexion de l’abonné est retardée pendant que le routeur désactive tous les services par défaut et tente d’activer les services spécifiés.

   • Si tous les services spécifiés sont activés, la connexion se termine.

   • Si l’un des services ne peut pas être activé, le routeur envoie au PCRF un message CCR-GX-U (où U représente UPDATE_REQUEST) avec l’état des services (un rapport de règle). Le PCRF répond à ce message par un CCA-GX-U qui peut contenir un nouvel ensemble de services à activer.

   • Le routeur ignore les services par défaut, même si le message CCA-GX-I n’inclut aucun service. Dans ce cas, aucun service n’est activé.

   Si le PCRF ne renvoie pas de CCA-GX-I dans le délai imparti, la connexion de l’abonné se termine.

   • Le routeur recherche d’abord les services renvoyés par le serveur d’authentification et active ceux qu’il trouve. Si aucun service de ce type n’est trouvé, le routeur active tous les services par défaut configurés localement. La connexion de l’abonné se termine lorsque l’activation du service par défaut est réussie, mais échoue lorsqu’un service par défaut ne parvient pas à s’activer. Étant donné qu’il n’est pas nécessaire que les services par défaut soient présents, la connexion se termine également lorsqu’aucun service par défaut n’est trouvé.

   • Si la connexion est terminée (avec ou sans service par défaut), le routeur renvoie périodiquement le message CCR-GX-I au PCRF. Si le PCRF renvoie par la suite un CCA-GX-I, le routeur désactive le service par défaut, le cas échéant, puis active tous les services inclus dans le CCA-GX-I. Si le message n’inclut aucun service, aucun service n’est activé, pas même un service par défaut.

   • Si l’un des services contenus dans le CCA-GX-I ne peut pas être activé, le routeur envoie au PCRF un message CCR-GX-U avec l’état des services (un rapport de règle). Le PCRF répond à ce message par un CCA-GX-U qui peut contenir un nouvel ensemble de services à activer.

Récupération d’erreur de connexion d’abonné

À partir de la version 20.1R1 de Junos, vous pouvez configurer le routeur pour qu’il récupère certaines erreurs de serveur PCRF en réinitialisant la session de l’abonné afin de resynchroniser les états du routeur et du serveur PCRF. Certains serveurs PCRF peuvent ne pas gérer correctement une situation où les messages CCA-GX-I qu’ils ont envoyés au routeur sont perdus. Lorsque le routeur tente à nouveau d’envoyer le CCR-GX-I au PCRF, le serveur n’est pas synchronisé avec le routeur car il a déjà envoyé une réponse et ne sait pas que le routeur n’a pas reçu le message. Cette incompatibilité d’état peut entraîner l’une des erreurs suivantes :

• Le serveur PCRF répond à la nouvelle tentative avec un CCA-GX-I qui contient le code de résultat de diamètre AVP (code 268) avec une valeur de 5012 (DIAMÈTRE IMPOSSIBLE DE SE CONFORMER). Ceci est considéré comme une défaillance permanente (Tableau 5).

• Le serveur PCRF envoie un RAR. Le serveur s’attend à ce que la session soit active, car il a envoyé le CCA-GX-I au routeur et ne sait pas que le message n’a pas été reçu. Le serveur peut envoyer l’un des messages RAR suivants :

  • RAR-GX-D pour déconnecter la session car il considère qu’elle est incorrecte

  • RAR-GX-A pour lire les informations sur la mauvaise session

  • RAR-GX-U pour mettre à jour la session, car il considère qu’elle fonctionne normalement.

Vous pouvez utiliser la configuration PCRF local-decision pour réinitialiser la session d’abonné en réponse à l’une ou l’autre de ces erreurs ou aux deux.

• Incluez l’option reinit-on-failure pour l’erreur de défaillance permanente.

• Inclure reinit-on-rar l’option pour l’erreur RAR.

L’opération de réinitialisation se compose des étapes suivantes dans les deux cas :

1. Le routeur envoie une demande de fin de session, CCR-GX-T, au PCRF pour mettre fin à la session. Ceci est fait dans le but d’obtenir le même état pour le routeur et le serveur PCRF pour cette session.

2. Le routeur attend un délai de réinitialisation pour recevoir un CCA-GX-T. Vous pouvez utiliser cette reinit-timeout option pour spécifier une période différente de la période par défaut.

3. Si le routeur reçoit un CCA-GX-T dans le délai d’expiration ou si un CCA-GX-T n’arrive pas avant l’expiration du délai, le routeur envoie un CCR-GX-I au PCRF avec un nouvel ID de session étendu. L’ID de session étendue est transmis dans l’ID de session Diameter AVP (code AVP 263).

   Le routeur forme l’ID de session étendue en ajoutant un horodatage de session qui consiste en l’heure UTC lorsque le routeur crée le CCR-GX-I. Par exemple, considérez l’AVP d’ID de session Diameter suivant. L’ID de session est 23 et use-session-stamp n’est pas configuré :

   Lorsque use-session-stamp configuré, l’horodatage de la session est ajouté à la valeur AVP :

Le Tableau 7 fournit des détails sur la façon dont le routeur réagit à ces erreurs en fonction de l’état PCRF local actuel.

Mise à jour des abonnés

Chaque fois qu’un événement déclencheur se produit sur le routeur, une demande de mise à jour est envoyée au PCRF. Les exemples suivants montrent un échange de paquets CCR-GX-U (où U représente UPDATE_REQUEST) et CCA-GX-U :

Exemple de paquet CCR-GX-U

Exemple de paquet CCA-GX-U

Le PCRF renvoie un message CCA-GX-U qui comprend le code de résultat AVP (code AVP 268) qui correspond aux catégories de résultats répertoriées dans le tableau 8.

Déconnexion des abonnés

Lorsque l’application cliente envoie un avis de déconnexion abonné à AAA, Gx envoie un message CCR-GX-T (où T représente TERMINATION_REQUEST) pour informer le PCRF que la session de abonné provisionnée est terminée.

Chaque fois qu’un événement déclencheur se produit sur le routeur, une demande d’arrêt est envoyée au PCRF. Les exemples suivants illustrent un échange de paquets CCR-GX-T et CCA-GX-T :

Exemple de paquet CCR-GX-T

Exemple de paquet CCA-GX-T

Le PCRF renvoie un message CCA-GX-T qui comprend le code de résultat AVP (code AVP 268) qui correspond aux catégories de résultats répertoriées dans le tableau 9.

Si la valeur du code de résultat est Succès, Gx avertit AAA et AAA informe l’application que la déconnexion est terminée. Si Gx ne reçoit pas de message CCA-GX-T, ou si le code de résultat AVP a une autre valeur ou est manquant, la demande d’arrêt est retentée jusqu’à ce que le message CCA-GX-T soit renvoyé avec succès. Le routeur avise le PCRF des déconnexions d’abonnés en envoyant une autre demande de RCC pour qu’une réponse à l’ACC en accuse réception. Le PCRF peut également utiliser les requêtes RAR pour forcer la déconnexion des abonnés ou pour modifier les services appliqués.

Si la valeur Result-Code est Failure, la requête est retentée.

Déconnexion des abonnés

Pour effectuer des déconnexions d’abonnés, le PCRF envoie un RAR-GX-D (où D représente DISCONNECT) et le BPCEF répond par un message RAA-GX-D.

Les exemples suivants illustrent un échange de paquets RAR-GX-D et RAA-GX-D :

Exemple de paquet RAR-GX-D

Exemple de paquet RAA-GX-D

Le PCRF renvoie un message RAA-GX-T qui inclut le code de résultat AVP (code AVP 268) qui correspond aux catégories de résultats répertoriées dans le Tableau 10.

Récupération des pannes de connectivité

Gx ne s’appuie pas sur l’état de la connexion entre les appareils pour détecter les pannes de routeur ou de PCRF, car certains événements n’affectent pas l’état de la connexion et d’autres ne sont pas détectés lorsqu’il y a un relais Diameter ou un proxy entre les appareils.

Pour atténuer les défauts de connectivité avec le PCRF, le routeur utilise les procédures de récupération d’erreur suivantes :

• Si le PCRF n’est pas disponible et si vous avez installé et configuré un service par défaut, la connexion de l’abonné procède en conséquence.

• Les demandes de provisionnement non reconnues sont rejouées indéfiniment ou jusqu’à ce que l’abonné se déconnecte.

• Les demandes de déconnexion attendent la fin de l’interrogatoire OCS final, puis toute demande de déconnexion non reconnue est rejouée pendant 24 heures.

• Le routeur utilise la redondance de transport Diameter standard pour communiquer avec les PCRF redondants.

Un aspect important de la tolérance de panne Gx est que les demandes de connexion et de résiliation des abonnés sont retentées (rejouées) 24 heures jusqu’à ce qu’une réponse satisfaisante soit reçue du PCRF. Vous pouvez lancer la clear network-access pcrf subscribers commande pour effacer tous les abonnés PCRF.

Premier interrogatoire à l’OCS

Au cours de la première interrogation, le routeur envoie une requête Diameter CCR contenant un ensemble fixe d’informations requises au serveur de charge OCS. Le serveur de charge OCS répond ensuite avec le temps de validité, les groupes d’évaluation et les quotas d’utilisation.

Pour configurer une liste de services de facturation afin de communiquer des informations avec l’OCS via le protocole Gy, configurez l’instruction charging-service-list ocs au niveau de la [edit access profile profile-name] hiérarchie. Les exemples suivants illustrent un échange de paquets CCR-GY-I et CCA-GY-I :

Exemple de paquet CCR-GY-I

Exemple de paquet CCA-GY-I

Interrogatoire intermédiaire à l’OCS

Une fois que le routeur a envoyé un ensemble fixe d’informations requises au serveur de facturation OCS, le serveur de facturation OCS répond avec le temps de validité, les groupes d’évaluation et les quotas d’utilisation. L’expiration des délais de validité et des quotas déclenche des événements d’interrogation intermédiaires.

Chaque fois qu’un événement déclencheur se produit sur le routeur, une demande de mise à jour est envoyée à l’OCS. Les exemples suivants montrent un échange de paquets CCR-GY-U (où U représente UPDATE_REQUEST) et CCA-GY-U :

Exemple de paquet CCR-GY-U

Exemple de paquet CCA-GY-U

Interrogatoire final à l’OCS

Lorsque l’application cliente envoie un avis de déconnexion abonné à AAA, Gy envoie un message CCR-GY-T (où T représente TERMINATION_REQUEST) pour informer l’OCS que le abonné provisionné est résilié.

Chaque fois qu’un événement déclencheur se produit sur le routeur, une demande d’arrêt est envoyée à l’OCS. Les exemples suivants illustrent un échange de paquets CCR-GY-T et CCA-GY-T :

Exemple de paquet CCR-GY-T

Exemple de paquet CCA-GY-T

Récupération des pannes de connectivité

Gy ne s’appuie pas sur l’état de la connexion entre les appareils pour détecter les pannes de routeur ou d’OCS, car certains événements n’affectent pas l’état de la connexion et d’autres ne sont pas détectés lorsqu’il y a un relais Diameter ou un proxy entre les appareils.

Pour atténuer les défauts de connectivité avec l’OCS, le routeur utilise les procédures de récupération d’erreur suivantes :

• Si OCS n’est pas disponible, vous pouvez le configurer pour autoriser le trafic des abonnés en définissant l’instruction force-continue au niveau de la [edit access ocs partition partition-name] hiérarchie.

  Remarque :

  Il force-continue s’agit d’une instruction de configuration obligatoire.

• Les premiers interrogatoires et les interrogatoires intermédiaires non acquittés sont relancés indéfiniment ou jusqu’à ce que l’abonné se déconnecte.

• Les derniers interrogatoires non reconnus sont rediffusés jusqu’à 24 heures.

• Le routeur utilise la redondance de transport Diameter standard pour communiquer avec les OCS redondants.

• Vous pouvez configurer des événements de redondance de transport pour déclencher des défaillances dans le trafic de l’application.

Un aspect important de la tolérance de panne Gy est que les demandes de connexion et de résiliation des abonnés sont retentées (rejouées) 24 heures jusqu’à ce qu’une réponse satisfaisante soit reçue de l’OCS. Vous pouvez lancer la clear network-access ocs statistics commande pour effacer toutes les statistiques OCS.

Abandonner les demandes de session

L’OCS peut émettre une demande d’abandon de session (ASR) lorsque le routeur MX Series destinataire collecte les données finales et publie l’interrogatoire final. Une fois que le routeur MX Series reçoit la réponse, il arrête de mettre à jour l’OCS pour la session concernée.

OCS SFTP-Sauvegarde

Le stfp-backup est le premier mécanisme de sauvegarde implémenté. Les opérations sont contrôlées par les paramètres suivants :

• accumulation-timeout – Les fichiers sont écrits après le temps d’accumulation des fichiers de la première soumission CCR-GY-T.

• accumulation-count – Les fichiers sont écrits après que le nombre de demandes a été satisfait pour le file-account-count.

• accumulation-size – Les fichiers sont écrits après que leur taille ait atteint la limite de taille d’accumulation.

• retry-interval : chaque opération d’écriture ayant échoué est retentée après cet intervalle jusqu’à ce que le délai de sauvegarde soit accumulé.

• response-timeout : délai d’expiration de la réponse de commande sftp individuelle.

Avantages de Gy File Backup

• Fournit un autre moyen de gérer l’instabilité du réseau interne.

Interactions de connexion

Cette séquence d’événements de connexion est déclenchée par la détection d’un flux de données de service sur le PCEF. Il s’agit généralement d’un paquet PADI DHCP DISCOVER ou PPPoE envoyé par l’abonné (le CPE) :

1. Le PCEF envoie un CCR-GX-I au PCRF avec des informations identifiant l’abonné.

2. Le PCRF répond avec un CCA-GX-I au PCEF avec des instructions sur les règles à appliquer pour l’abonné.

3. Le PCEF installe les services/règles demandés pour l’abonné.

4. Si l’OCS est utilisé, le PCEF envoie le premier interrogatoire à l’OCS à l’aide d’un message CCR-GY-I, et l’OCS envoie les rapports applicables au PCRF à l’aide d’un message CCA-GY-I.

   S’il est configuré, le PCEF envoie une notification au moyen d’un message CCR-GX-U au PCRF après le traitement des services/règles demandés.

   • La règle est signalée au PCRF comme inactive lorsque les deux conditions suivantes sont vraies :

     • L’instanciation du profil dynamique de service échoue.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) est défini pour la règle de facturation.

     Lorsque la règle est signalée comme inactive, elle n’affecte pas la connexion de l’abonné ou les autres règles.

   • La règle est signalée au PCRF comme active lorsque toutes les conditions suivantes sont remplies :

     • L’instanciation du profil dynamique de service réussit.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) est défini pour la règle de facturation.

     • Le déclencheur d’événement SUCCESSFUL_RESOURCE_ALLOCATION est défini dans la demande.

   • Le rapport n’est pas envoyé lorsqu’il n’y a pas de règles à signaler.

5. Le PCRF répond par un message CCA-GX-U.

6. Le PCEF active les services pour l’abonné.

Interactions de mise à jour

Cette séquence d’événements de mise à jour est déclenchée par un message RAR-GX-U reçu par le PCEF du PCRF.

1. Si la demande de mise à jour contient une installation ou une modification de règles avec des groupes d’évaluation, le PCEF rejette la demande ; sinon, il accuse réception de la demande en envoyant un message RAA-GX-U au PCRF.

2. Le PCEF lance le processus de suppression et d’installation du service.

3. Le PCEF attend la fin du processus de retrait et d’installation du service et, le cas échéant, commence le processus de collecte de données final pour la déclaration au BSC. Lorsque les statistiques finales sont collectées, le PCEF envoie une demande CCR-GY-U pour en informer l’OCS. Cela fait partie du processus de suppression d’un service existant dans chacun des cas suivants :

   • Lorsque le service supprimé a un groupe d’évaluation.

   • Lorsqu’une nouvelle règle avec un groupe d’évaluation a été ajoutée.

   • Lorsque des règles avec un groupe d’évaluation ont été à la fois supprimées et ajoutées.

4. Le PCEF envoie les rapports pertinents au PCRF au moyen d’un message CCR-GX-U.

   • La règle est signalée au PCRF comme inactive lorsque les deux conditions suivantes sont vraies :

     • L’instanciation du profil dynamique de service échoue.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) est défini pour la règle de facturation.

     Lorsque la règle est signalée comme inactive, cela n’affecte pas la mise à jour ou les autres règles.

   • La règle est signalée au PCRF comme active lorsque toutes les conditions suivantes sont remplies :

     • L’instanciation du profil dynamique de service réussit.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) est défini pour la règle de facturation.

     • Le déclencheur d’événement SUCCESSFUL_RESOURCE_ALLOCATION est défini dans la demande.

   • Le rapport n’est pas envoyé lorsqu’il n’y a pas de règles à signaler.

Interactions entre l’expiration des quotas et la durée de validité

Pour les expirations de quota et les interactions de temps de validité, le routeur envoie une interrogation intermédiaire à l’OCS à l’aide d’un message CCR-GY-U et traite la réponse OCS.

Connexion et surveillance des interactions

Lors de l’établissement d’une connexion avec le serveur PCRF, OCS ou Diameter Relay/Proxy, le démon Diameter effectue une transaction de demande d’échange de capacités (CER)/réponse d’échange de capacités (CEA) standard. Vous utilisez l’infrastructure Junos OS Diameter existante pour configurer une topologie appropriée avec les fonctionnalités de redondance nécessaires. De plus, vous pouvez utiliser la même connexion Diameter pour les communications PCRF et OCS, ainsi que pour d’autres applications.

Les exemples suivants illustrent deux scénarios de connexion de communication différents :

Exemple de CER avec une connexion dédiée utilisée pour communiquer avec le PCRF

Exemple de CER avec une connexion dédiée utilisée pour communiquer avec PCRF et OCS

Vous surveillez et gérez les connexions à l’aide de messages DWR/DWA et DPR/DPA standard.

Interactions de déconnexion

Cette séquence d’événements de déconnexion est déclenchée par l’une des raisons suivantes :

• Une demande de déconnexion d’un abonné, telle qu’un paquet DHCP RELEASE ou PPPoE PADT.

• Le PCEF reçoit un RAR du PCRF avec une demande de résiliation d’une session d’abonné.

La séquence suivante se produit lorsque la déconnexion est déclenchée :

1. L’infrastructure système informe l’OCS que la déconnexion de l’abonné a commencé.

2. S’il y a lieu, l’OCS entame le processus final de collecte des données.

   • Si le service supprimé a un groupe d’évaluation, les données finales de ce service doivent être déclarées. L’OCS commence la collecte finale des données si nécessaire.

3. Le PCRF et le PCEF attendent tous deux la fin du processus d’interrogatoire final.

4. Le PCEF envoie une demande de résiliation (message CCR-GX-T) au PCRF, puis attend la réponse (message CCA-GX-T) du PCRF.

5. Le PCEF termine le processus de déconnexion de l’abonné.

Messages communs en amont

Les messages en amont pour la réponse de contrôle du crédit pour l’ouverture, la mise à jour et la résiliation (CCR-GX-I, CCR-GX-U et CCR-GX-T) et le RAA-GX peuvent inclure les règles, paramètres et données suivants :

• AVP d’horodatage des événements
• Notifications d’installation des règles de facturation
• Commandes de déclenchement d’événements

Messages courants en aval

Les messages en aval pour la réponse de contrôle du crédit pour l’initiation et la mise à jour (CCA-GX-I et CCA-GX-U) et RAR-GX peuvent inclure les règles prédéfinies suivantes avec des paramètres et des données :

• Commandes d’installation de la règle de facturation
• Commandes de suppression des règles de facturation
• Commandes de déclenchement d’événements