Transformation Avancée

Le module Transformation Avancée réécrit les Paires Attribut-Valeur (AVPs) à l'intérieur des messages Diameter qui correspondent à des critères définis par l'opérateur. Utilisez-le pour corriger, traduire ou normaliser le contenu des messages au fur et à mesure qu'ils passent par OmniDRA. Vous n'avez pas besoin de modifier les éléments de réseau d'envoi ou de réception.

Vue d'ensemble

La Transformation Avancée évalue une liste de règles pour chaque message Diameter. Une règle combine un ensemble de filtres (les critères de correspondance) avec une transformation (le changement à appliquer). Lorsqu'une règle correspond, le DRA applique sa transformation au message et arrête le traitement des règles.

La Transformation Avancée fournit trois actions de transformation. :edit change la valeur d'un AVP existant. :remove supprime un ou plusieurs AVPs par code. :overwrite réécrit un ou plusieurs AVPs par nom, y compris les AVPs groupés. Voir Actions de Transformation.

La Transformation Avancée partage son modèle de traitement des règles avec le moteur de routage. Voir Routage Avancé pour savoir comment le DRA prend des décisions de routage.

Comment les Règles Sont Traitée

Le DRA évalue les règles dans l'ordre, de haut en bas, telles qu'elles apparaissent dans la configuration. La première règle correspondante l'emporte. Dès qu'un filtre de règle correspond, le DRA applique sa transformation et ne considère plus d'autres règles. Si aucune règle ne correspond, le message passe transparente sans modification.

Au sein d'une seule règle, le paramètre match contrôle comment les filtres individuels se combinent :

:all - logique ET. Chaque filtre doit passer pour que la règle corresponde.
:any - logique OU. Au moins un filtre doit passer pour que la règle corresponde.
:none - logique NOR. Aucun filtre ne peut passer pour que la règle corresponde (correspondance inverse).

Les règles de transformation opèrent sur le contenu du message. Elles ne sélectionnent pas une destination. Une règle peut réécrire un AVP, par exemple un domaine ou une identité. Le moteur de routage utilise ensuite cet AVP pour transférer le message.

Évaluation du Mode de Correspondance

Les trois modes de correspondance évaluent la même liste de filtres différemment :

Filtres

Les filtres sont les conditions qui décident si une règle s'applique à un message. La Transformation Avancée fournit six types de filtres.

Filtre	Format	Description
`:packet_type`	`{:packet_type, :request}`	Correspond à la direction du message. Accepte uniquement `:request` ou `:answer` ; une liste de valeurs n'est pas acceptée. Voir Filtrage par Type de Paquet.
`:application_id`	`{:application_id, <id>}`	Correspond à l'Application-Id Diameter du message (par exemple `16777251` pour S6a/S6d). Voir Identifiants d'Application.
`:command_code`	`{:command_code, <code>}`	Correspond au Code de Commande Diameter du message (par exemple `318` pour AIR). Voir Codes de Commande.
`:avp`	`{:avp, {<code>, <value>}}`	Correspond à un AVP par son code numérique et sa valeur attendue. Voir Filtrage AVP.
`:to_peer`	`{:to_peer, "hss01.example.com"}`	Correspond au pair de destination résolu d'une demande. Il correspond uniquement aux paquets de demande et ne correspond jamais aux réponses. Accepte une liste de noms d'hôtes (OU). Voir Filtrage par Pair.
`:from_peer`	`{:from_peer, "hss01.example.com"}`	Correspond au pair qui a répondu à un message. Il correspond uniquement aux paquets de réponse et ne correspond jamais aux demandes. Accepte une liste de noms d'hôtes (OU). Voir Filtrage par Pair.

Filtrage par Type de Paquet

Le filtre :packet_type restreint une règle à une direction de trafic. Il accepte exactement l'une des deux valeurs :

:request - correspond uniquement aux messages Diameter de demande.
:answer - correspond uniquement aux messages Diameter de réponse.

Contrairement à :application_id, :command_code et :avp, le filtre :packet_type n'accepte pas une liste de valeurs.

Filtrage AVP

Le filtre :avp a la structure {avp_id, avp_value}. L'avp_id est le code AVP numérique. L'avp_value est la valeur à comparer, exprimée sous forme de chaîne.

Utilisez le filtre :avp pour des AVPs simples tels que User-Name et Origin-Host. Les AVPs groupés ne sont pas pris en charge et ne correspondent pas. Les valeurs binaires complexes ne correspondent pas.

Le filtre correspond aux valeurs de plusieurs manières :

Chaîne exacte - {:avp, {1, "999999000000001"}} correspond uniquement à cette valeur exacte.
Liste de valeurs - {:avp, {1, ["50557...", "505057..."]}} correspond si l'AVP est égal à n'importe quelle valeur de la liste. C'est une logique OU au sein de la liste.
Expression régulière - {:avp, {1, [~r"9999999.*"]}} correspond aux valeurs contre un motif regex.

Utilisez la syntaxe ~r"pattern" pour la correspondance par expression régulière :

Motif	Correspond
`~r"999001.*"`	Valeurs `User-Name`/IMSI commençant par `999001`
`~r"^310[0-9]{3}.*"`	Valeurs avec des préfixes MCC/MNC spécifiques
`~r".*test$"`	Valeurs se terminant par `test`

Filtrage par Pair

Les filtres :to_peer et :from_peer correspondent à un nom d'hôte de pair, et non au contenu du message. Ils sont spécifiques à la direction et complémentaires :

:to_peer correspond au pair de destination résolu auquel le DRA est sur le point de transférer une demande. Il correspond uniquement aux paquets de demande. Il ne correspond jamais à une réponse.
:from_peer correspond au pair qui a répondu à un message. Il correspond uniquement aux paquets de réponse. Il ne correspond jamais à une demande.

Les deux filtres acceptent un seul nom d'hôte ou une liste de noms d'hôtes. Avec une liste, le filtre correspond si le pair est égal à n'importe quel nom d'hôte de la liste. C'est une logique OU.

Filtre	Exemple	Correspond
`:to_peer`	`{:to_peer, "hss01.example.com"}`	Demandes routées vers le pair `hss01.example.com`
`:to_peer`	`{:to_peer, ["hss01.example.com", "hss02.example.com"]}`	Demandes routées vers l'un ou l'autre des pairs listés
`:from_peer`	`{:from_peer, "hss01.example.com"}`	Réponses reçues du pair `hss01.example.com`

Actions de Transformation

La carte transform décrit la transformation. Sa clé action sélectionne une des trois transformations. La direction du message détermine quelles actions sont autorisées :

Action	Ce qu'elle fait	Demandes	Réponses
`:edit`	Réécrit la valeur d'un AVP existant.	Oui	Non
`:remove`	Supprime l'AVP(s) nommé(s) du message.	Oui	Oui
`:overwrite`	Réécrit l'AVP(s) par nom, y compris les AVPs groupés, en utilisant un dictionnaire de décodage.	Oui	Oui

L'Action `:edit`

transform: %{
  action: :edit,
  avps: [{:avp, {1, "999999000000002"}}]
}

:edit se comporte comme suit :

Il modifie la valeur de l'AVP nommé dans le message Diameter à la valeur fournie.
Il n'affecte que les AVPs qui existent déjà dans le message. Si l'AVP ciblé n'est pas présent, le DRA ne fait aucun changement et passe le message tel qu'il a été reçu.
Chaque entrée dans avps est {:avp, {<code>, <new_value>}}. Cela définit cet AVP à la nouvelle valeur.
:edit s'applique uniquement aux demandes. Pour réécrire des AVPs sur les réponses, ou pour atteindre des AVPs groupés, utilisez :overwrite.

L'Action `:remove`

transform: %{
  action: :remove,
  avps: [{:avp, {264, :any}}]
}

:remove se comporte comme suit :

Il supprime l'AVP(s) nommé(s) dans avps du message.
Il correspond uniquement par code AVP. Il ignore la valeur dans chaque entrée avps pour la suppression. Utilisez :any comme valeur pour le rendre explicite.
Il s'applique à la fois aux demandes et aux réponses.

L'Action `:overwrite`

transform: %{
  action: :overwrite,
  dictionary: :diameter_gen_3gpp_s6a,
  avps: [{:avp, {1, "999999000000002"}}]
}

:overwrite se comporte comme suit :

Il réécrit l'AVP(s) nommé(s) par nom. Il utilise le dictionnaire fourni pour décoder et réencoder le message.
Il décode le message complet, donc :overwrite peut atteindre les AVPs groupés / enregistrement que :edit ne peut pas.
Il requiert une clé dictionary. Cette clé nomme le dictionnaire Diameter qui décrit le message (par exemple :diameter_gen_3gpp_s6a).
Il s'applique à la fois aux demandes et aux réponses.

Paramètres de la Carte de Transformation

Paramètre	Type	Obligatoire	Par défaut	Description
`action`	Atome	Oui	-	La transformation à appliquer : `:edit` (réécrire une valeur AVP existante - demandes uniquement), `:remove` (supprimer l'AVP(s) par code - demandes et réponses), ou `:overwrite` (réécrire l'AVP(s) par nom, y compris les AVPs groupés - demandes et réponses).
`avps`	Liste	Oui	-	Liste des cibles AVP. Pour `:edit`/`:overwrite`, chaque entrée est `{:avp, {<code>, <new_value>}}` et définit cet AVP à `<new_value>`. Pour `:remove`, le DRA utilise uniquement `<code>` et ignore la valeur (utilisez `:any`).
`dictionary`	Atome	Seulement pour `:overwrite`	`:not_used`	Le dictionnaire Diameter qui décode et réencode le message afin que le DRA puisse écraser les AVPs nommés (groupés), par exemple `:diameter_gen_3gpp_s6a`. Les actions `:edit` et `:remove` ignorent cette clé.

Configuration

Configurez la Transformation Avancée sous module_advanced_transform dans config/runtime.exs. Le module est désactivé par défaut. Il ne fait rien jusqu'à ce que vous définissiez enabled sur true.

module_advanced_transform: %{
  enabled: true,
  rules: [
    %{
      rule_name: "transform_user_name",
      match: :all,
      filters: [
        {:application_id, 16_777_251},
        {:command_code, 318},
        {:avp, {1, "999999000000001"}}
      ],
      transform: %{
        action: :edit,
        avps: [{:avp, {1, "999999000000002"}}]
      }
    }
  ]
}

Paramètres du Module

Paramètre	Type	Obligatoire	Par défaut	Description
`enabled`	Booléen	Non	`false`	Active le module. Lorsque `false`, le DRA n'évalue aucune règle et tous les messages passent sans changement.
`rules`	Liste	Oui (lorsqu'il est activé)	-	Liste ordonnée des règles de transformation. Le DRA les évalue de haut en bas. La première règle correspondante l'emporte. Voir Paramètres de Règle.

Paramètres de Règle

Chaque entrée dans rules est une carte avec les clés suivantes.

Paramètre	Type	Obligatoire	Par défaut	Description
`rule_name`	Chaîne	Oui	-	Identifiant unique et descriptif pour la règle. Il soutient la clarté opérationnelle et la surveillance.
`match`	Atome	Oui	-	Comment les filtres se combinent : `:all` (ET), `:any` (OU), ou `:none` (NOR). Voir Comment les Règles Sont Traitée.
`filters`	Liste	Oui	-	Liste des conditions de filtre qu'un message doit satisfaire selon le mode `match`. Voir Filtres.
`transform`	Carte	Oui	-	Le changement à appliquer lorsque la règle correspond. Voir Paramètres de la Carte de Transformation.

Exemples

Exemple 1 : Réécrire un User-Name sur les Demandes S6a AIR

module_advanced_transform: %{
  enabled: true,
  rules: [
    %{
      rule_name: "transform_user_name",
      match: :all,
      filters: [
        {:application_id, 16_777_251},
        {:command_code, 318},
        {:avp, {1, "999999000000001"}}
      ],
      transform: %{
        action: :edit,
        avps: [{:avp, {1, "999999000000002"}}]
      }
    }
  ]
}

Comment cela fonctionne : Avec match: :all, chaque filtre doit passer. La règle ne correspond qu'aux messages S6a (16777251) de Demande d'Information d'Authentification (318) dont le User-Name (AVP 1) est égal à 999999000000001. Lors d'une correspondance, l'action :edit réécrit User-Name à 999999000000002. Si un message ne contient pas d'AVP User-Name, le DRA ne fait aucun changement.

Cas d'utilisation : Corriger ou normaliser une identité d'abonné spécifique alors qu'elle transite par le DRA. Par exemple, mapper un IMSI hérité à sa valeur actuelle lors d'une migration.

Exemple 2 : Réécriture de Domaine Basée sur la Plage IMSI

module_advanced_transform: %{
  enabled: true,
  rules: [
    %{
      rule_name: "rewrite_destination_realm_roaming_partner",
      match: :all,
      filters: [
        {:avp, {296, "epc.mnc057.mcc505.3gppnetwork.org"}},
        {:avp, {1, [~r"50557.*"]}}
      ],
      transform: %{
        action: :edit,
        avps: [{:avp, {283, "epc.mnc030.mcc310.3gppnetwork.org"}}]
      }
    }
  ]
}

Comment cela fonctionne : La règle correspond lorsque le Origin-Realm (AVP 296) est égal au domaine du partenaire en itinérance et que le User-Name/IMSI (AVP 1) commence par 50557. Elle réécrit ensuite le Destination-Realm (AVP 283). Le moteur de routage transfère ensuite le message vers le bon réseau partenaire. La première règle correspondante l'emporte, donc placez les plages IMSI plus spécifiques au-dessus des plus larges.

Cas d'utilisation : Diriger le trafic des abonnés en itinérance ou MVNO vers le bon réseau central hébergé. Le DRA sélectionne le réseau par la plage IMSI et le domaine d'origine.

Exemple 3 : Supprimer un AVP des Réponses d'un Pair Spécifique

module_advanced_transform: %{
  enabled: true,
  rules: [
    %{
      rule_name: "strip_origin_host_from_partner_answers",
      match: :all,
      filters: [
        {:packet_type, :answer},
        {:from_peer, "hss01.partner.example.com"},
        {:command_code, 318}
      ],
      transform: %{
        action: :remove,
        avps: [{:avp, {264, :any}}]
      }
    }
  ]
}

Comment cela fonctionne : Le filtre :packet_type limite la règle aux réponses. Le filtre :from_peer la limite aux réponses de hss01.partner.example.com. Le filtre :command_code la limite aux AIA (318). Lorsque les trois correspondent, l'action :remove supprime l'Origin-Host (AVP 264) quelle que soit sa valeur. La suppression correspond uniquement par code AVP.

Cas d'utilisation : Supprimer un AVP des réponses d'un réseau partenaire. Utilisez cela lorsque le partenaire remplit l'AVP de manière incorrecte ou lorsque l'AVP ne doit pas être transmis en aval.

Exemple 4 : Écraser un AVP Groupé sur les Demandes S6a

module_advanced_transform: %{
  enabled: true,
  rules: [
    %{
      rule_name: "overwrite_user_name_s6a",
      match: :all,
      filters: [
        {:packet_type, :request},
        {:application_id, 16_777_251},
        {:command_code, 318}
      ],
      transform: %{
        action: :overwrite,
        dictionary: :diameter_gen_3gpp_s6a,
        avps: [{:avp, {1, "999999000000002"}}]
      }
    }
  ]
}

Comment cela fonctionne : La règle correspond aux demandes S6a (16777251) AIR (318). L'action :overwrite décode le message avec le dictionnaire :diameter_gen_3gpp_s6a, réécrit les AVP(s) nommés, et réencode le message. Elle décode le message complet, donc :overwrite peut atteindre les AVPs imbriqués à l'intérieur de structures groupées/enregistrement que :edit ne peut pas toucher.

Cas d'utilisation : Corriger un AVP qui se trouve à l'intérieur d'un AVP groupé, par exemple un champ au sein d'un abonnement ou d'un groupe spécifique au fournisseur. Un simple :edit ne correspondrait pas à un tel AVP.

Tables de Référence

Identifiants d'Application

ID	Interface	Description	Référence
16777251	S6a/S6d	Authentification et abonnement MME/SGSN ↔ HSS	3GPP TS 29.272

Codes de Commande

Code	Commande	Interface	Référence
318	Demande/Réponse d'Information d'Authentification (AIR/AIA)	S6a/S6d	3GPP TS 29.272 §7.2.5
316	Demande/Réponse de Mise à Jour de Localisation (ULR/ULA)	S6a/S6d	3GPP TS 29.272 §7.2.3

Codes AVP Communs

Code	AVP	Description	Référence
1	User-Name	Identité de l'abonné (IMSI sur S6a).	3GPP TS 29.272 / RFC 6733 §8.14
264	Origin-Host	Identité Diameter de l'initiateur du message.	RFC 6733 §6.3
283	Destination-Realm	Le domaine auquel le message est destiné. Le DRA l'utilise pour le routage.	RFC 6733 §6.6
296	Origin-Realm	Domaine de l'initiateur du message.	RFC 6733 §6.4

Meilleures Pratiques

Spécificité - Ordre des règles de la plus spécifique à la plus générale. La première règle correspondante l'emporte.
Performance - Placez les règles les plus souvent correspondantes en premier. Cela réduit la surcharge d'évaluation.
Test - Validez les motifs d'expressions régulières avant le déploiement.
Nommage - Utilisez des valeurs descriptives pour rule_name pour la clarté opérationnelle et la surveillance.
Surveillance - Suivez les taux de correspondance des règles. Cela confirme que les règles se comportent comme prévu.

Documentation Connexe

Routage Avancé - Sélection de destination utilisant le même modèle de traitement des règles.

Vue d'ensemble​

Comment les Règles Sont Traitée​

Évaluation du Mode de Correspondance​

Filtres​

Filtrage par Type de Paquet​

Filtrage AVP​

Filtrage par Pair​

Actions de Transformation​

L'Action :edit​

L'Action :remove​

L'Action :overwrite​

Paramètres de la Carte de Transformation​

Configuration​

Paramètres du Module​

Paramètres de Règle​

Exemples​

Exemple 1 : Réécrire un User-Name sur les Demandes S6a AIR​

Exemple 2 : Réécriture de Domaine Basée sur la Plage IMSI​

Exemple 3 : Supprimer un AVP des Réponses d'un Pair Spécifique​

Exemple 4 : Écraser un AVP Groupé sur les Demandes S6a​

Tables de Référence​

Identifiants d'Application​

Codes de Commande​

Codes AVP Communs​

Meilleures Pratiques​

Documentation Connexe​