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

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

• Fournit un cadre unifié pour le provisionnement et la comptabilité des abonnés des réseaux filaires.

Environnement d’accès filaire

Pour les abonnés mobiles, l’équipement utilisateur demande des services ; pour les abonnés des services filaires à large bande, la FCRP demande des services. Dans l’environnement filaire, le PCRF fonctionne en tant que demandeur de service, et le PCEF fonctionne en tant que récepteur et exécuteur de service.

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

• Commodité

• Technologie de pointe

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

Le PCRF contrôle le PCEF en poussant des règles de charge. Les règles de facturation sont réutilisées en tant que règles de service (stratégie) pour appliquer les stratégies. Les règles de charge peuvent également être associées à un groupe d’évaluation, ou à une clé de recharge. Par conséquent, la configuration du PCEF doit définir des règles de facturation et un mappage 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 OFC (Offline Charging System) 3GPP nécessitent l’utilisation du numéro d’annuaire international des abonnés de la station mobile (MSISDN) pour l’identification de l’abonné. Le MSISDN est transmis en tant qu’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 attribut-valeur (AVP) Juniper du tableau 2 ont été allouées à partir de l’attribut spécifique au fournisseur (VSA) de l’espace ID fournisseur Juniper (2636).

Le système client (routeur) envoie l’AVP Juniper-Dyn-Subscription-Id-Indicator 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é la prise en charge. 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 requise à la fois pour le service AAA et PCRF. Pour indiquer ces informations, l’AVP Juniper Network-Family-Indicator a été alloué à partir de l’espace Juniper Vendor-ID (2636) VSA du Tableau 3.

Le système client (routeur) envoie l’AVP Juniper-Network-Family-Indicator pour indiquer les familles de réseaux associées à la demande de service et prises en charge par l’abonné. Lorsque vous configurez l’AVP Juniper-Network-Family-Indicator 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 réseaux filaires contrôlent souvent les services aux utilisateurs uniquement par l’intermédiaire du PCRF et utilisent l’OCS comme mécanisme pratique de surveillance de l’utilisation en temps réel plutôt que comme unité d’application de la loi. 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 à large bande (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 pour les groupes de notation concernés. Chaque fois que le PCEF reçoit une réponse négative à l’un des groupes signalés, 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-client

• profils dynamiques-de-service cos

• profils_dynamiques-de-service-de-pare-feu

Les profils dynamiques client et les profils dynamiques cos-service 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 de l’utilisation. Pour toutes les catégories de profils dynamiques, le nom du profil dynamique du service est utilisé comme valeur d’un AVP de nom de règle de chargement.

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 Juniper existants (Vendor-ID 2636 et Type 2024) pour fournir des attributs sous forme de paires nom-valeur. Le PCRF peut également inclure des paramètres en tant que notation positionnelle pour une partie du nom de la règle. L’AVP Redirect-Information (ID 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 des VSA fixes avec paramètres Juniper.

S’il est nécessaire d’indiquer des paramètres ou l’identificateur de service et le groupe d’évaluation par le PCRF, l’AVP de définition de règle de charge est utilisé ; sinon, c’est l’AVP Charging-Rule-Name qui est utilisé.

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

Connexion de l’abonné

Le routeur envoie une requête Diameter CCR 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 de l'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 de l'abonné, et reçoit un message de réponse CCA-GX-I contenant des stratégies 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 de la réponse CCA-GX-I dépend de trois facteurs :

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

• La mise en place de la décision locale

• La catégorie de résultats

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 les sessions d’abonnés statiques, demande à AAA d’authentifier l’abonné.

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

3. Les services par défaut sont activés pour l’abonné. Tous les services inclus par le serveur d’authentification dans l’octroi d’authentification sont activés. En outre, un service par défaut a peut-être é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 Charging-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 est terminée.

   • 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 tous 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é est terminée.

   • 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 de l’abonné

À partir de la version 20.1R1 de Junos, vous pouvez configurer le routeur pour qu’il se remette de certaines erreurs de serveur PCRF en réinitialisant la session de l’abonné pour 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 ou l’autre 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 INCAPABLE DE SE CONFORMER). Il s’agit d’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 ignore 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 que la session est mauvaise

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

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

Vous pouvez utiliser la configuration PCRF local-decision pour réinitialiser la session de l’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.

Dans les deux cas, l’opération de réinitialisation se compose des étapes suivantes :

1. Le routeur envoie une demande d’interruption de session, CCR-GX-T, au PCRF pour mettre fin à la session. Ceci est fait pour tenter de faire en sorte que le routeur et le serveur PCRF aient le même état pour cette session.

2. Le routeur attend un délai d’expiration 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 d’expiration, le routeur envoie un CCR-GX-I au PCRF avec un nouvel ID de session étendu. L’ID de session étendu est transmis dans l’ID de session Diameter AVP (code AVP 263).

   Le routeur forme l’ID de session étendue en ajoutant un tampon de session qui correspond à l’heure UTC à laquelle le routeur crée le CCR-GX-I. Prenons l’exemple de l’AVP Session ID Diameter suivant. L’ID de session est 23 et use-session-stamp n’est pas configuré :

   Avec use-session-stamp configuré, l’horodatage de 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 actuel du PCRF local.

Mise à jour de l’abonné

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 illustrent 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 de l’abonné

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

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 Result-Code est Success, Gx notifie 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, alors la demande d’arrêt est réessayée jusqu’à ce que le message CCA-GX-T soit renvoyé avec succès. Le routeur informe le PCRF des déconnexions d’abonnés en envoyant une autre demande de CCR pour qu’elle obtienne un accusé de réception par une réponse CCA. Le PCRF peut également utiliser des requêtes RAR pour forcer la déconnexion de l’abonné ou pour modifier les services appliqués.

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

Déconnexion de l’abonné

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 connexion entre les périphériques pour détecter les pannes de routeur ou de PCRF, car certains événements n’affectent pas l’état de connexion et d’autres ne sont pas détectés lorsqu’il existe un relais ou un proxy Diameter entre les périphériques.

Pour atténuer les défaillances 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 que vous avez installé et configuré un service par défaut, la connexion de l’abonné se poursuit en conséquence.

• Les demandes d’approvisionnement sans accusé de réception sont relues indéfiniment ou jusqu’à ce que l’abonné se déconnecte.

• Les demandes de déconnexion attendent la fin de l’interrogation OCS finale, puis toutes les demandes de déconnexion sans accusé de réception sont relues 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 de Gx est que les demandes de connexion et de résiliation de l’abonné sont réessayées (relues) 24 heures jusqu’à ce qu’une réponse satisfaisante soit reçue du PCRF. Vous pouvez exécuter la clear network-access pcrf subscribers commande pour effacer tous les abonnés PCRF.

Premier interrogatoire à l’OCS

Lors du premier interrogatoire, le routeur envoie une requête Diameter CCR contenant un ensemble fixe d’informations requises au serveur de charge OCS. Le serveur de recharge OCS répond ensuite avec l’heure de validité, les groupes d’évaluation et les quotas d’utilisation.

Pour configurer une liste de services de recharge 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 charge OCS, le serveur de charge OCS répond avec l’heure de validité, les groupes d’évaluation et les quotas d’utilisation. Les délais de validité et les expirations de quota déclenchent des interrogations 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 illustrent 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 de l’abonné à AAA, Gy envoie un message CCR-GY-T (où T représente TERMINATION_REQUEST) pour informer l’OCS que l’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 connexion entre les périphériques 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 existe un relais ou un proxy Diameter entre les périphériques.

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

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

  Note:

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

• Les premiers interrogatoires et les interrogatoires intermédiaires non accusés de réception sont répétés indéfiniment ou jusqu’à ce que l’abonné se déconnecte.

• Les interrogatoires finaux non reconnus se répètent jusqu’à 24 heures.

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

• Vous pouvez configurer des événements de redondance de transport pour qu’ils déclenchent des échecs dans le trafic applicatif.

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

Abandon des demandes de session

L’OCS peut émettre un ASR (Abort-Session-Request) lorsque le routeur MX Series récepteur collecte les données finales et publie l’interrogation finale. Une fois que le routeur MX Series a reçu la réponse, il arrête la mise à jour de l’OCS pour la session concernée.

Sauvegarde SFTP OCS

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 l’heure 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 nombre de comptes de fichiers.

• accumulation-size : les fichiers sont écrits une fois que leur taille a atteint la limite de taille d’accumulation.

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

• response-timeout – Le délai d’expiration de la réponse à la 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 typiquement d’un paquet DHCP DISCOVER ou PPPoE PADI envoyé par l’abonné (le CPE) :

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

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

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

4. Si l’OCS est utilisé, le PCEF envoie la première interrogation à l’OCS à l’aide d’un message CCR-GY-I, et l’OCS envoie les rapports pertinents 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 remplies :

     • L’instanciation du profil dynamique du 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 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 requête.

   • 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é.

Mettre à jour les interactions

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

1. Si la demande de mise à jour contient une installation ou une modification de règles avec des groupes de notation, 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 que le processus de suppression et d’installation du service soit terminé et, s’il y a lieu, démarre le processus final de collecte de données pour la déclaration à l’OCS. Lorsque les statistiques finales sont recueillies, le PCEF envoie une demande CCR-GY-U pour en aviser 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 les 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 remplies :

     • L’instanciation du profil dynamique du 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 requête.

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

Expiration du quota et interactions validité-heure

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

Interactions de connexion et de surveillance

Lors de l’établissement d’une connexion avec le serveur PCRF, OCS ou Diameter Relay/Proxy, le démon Diameter effectue une transaction standard de demande d’échange de capacités (CER)/de réponse d’échange de capacités (CEA). Vous utilisez l’infrastructure Diameter existante de Junos OS 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 montrent deux scénarios de connexion de communication différents :

Exemple d’utilisation d’une connexion dédiée pour communiquer avec le PCRF

Exemple de REC 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’un des éléments suivants :

• 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 de données.

   • Si le service supprimé a un groupe d’évaluation, les données finales pour ce service doivent être déclarées. L’OCS entreprend la collecte finale des données au besoin.

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 ascendants courants

Les messages en amont pour Credit Control Response for Initiation, Update, and Termination (CCR-GX-I, CCR-GX-U et CCR-GX-T) et RAA-GX peuvent inclure les règles, paramètres et données suivants :

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

Messages courants en aval

Les messages en aval pour la réponse d’initiation et de mise à jour du contrôle des crédits (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 charge
• Commandes de suppression des règles de charge
• Commandes de déclenchement d’événement