Transformation Avancée

Le module Transformation Avancée réécrit les Paires Attribut-Valeur (AVP) à l'intérieur des messages Diameter qui correspondent à des critères définis par l'opérateur. Il vous permet de corriger, traduire ou normaliser le contenu des messages au fur et à mesure qu'ils passent par OmniDRA sans changer 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, sa transformation est appliquée au message et le traitement des règles s'arrête.

Trois actions de transformation sont disponibles : :edit change la valeur d'un AVP existant, :remove supprime les AVP par code, et :overwrite réécrit les AVP par nom (y compris les AVP groupés). Voir Actions de Transformation.

La Transformation Avancée est étroitement liée à, et partage son modèle de traitement des règles avec, le moteur de routage. Voir Routage Avancé pour savoir comment les décisions de routage sont prises.

Comment les Règles Sont Traitée

Les règles sont évaluées dans l'ordre, de haut en bas, telles qu'elles apparaissent dans la configuration. La première règle correspondante gagne : dès qu'un filtre de règle correspond, sa transformation est appliquée et aucune autre règle n'est considérée. 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).

Par rapport au routage, les règles de transformation opèrent sur le contenu du message et ne sélectionnent pas elles-mêmes une destination. Une règle peut réécrire un AVP (par exemple un domaine ou une identité) que le moteur de routage utilise ensuite 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. Six types de filtres sont disponibles.

Filtre	Format	Description
`:packet_type`	`{:packet_type, :request}`	Correspond à la direction du message. N'accepte que `: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. Ne correspond qu'aux paquets de demande — il 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. Ne correspond qu'aux paquets de réponse — il 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 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 est structuré comme {avp_id, avp_value}, où avp_id est le code numérique de l'AVP et avp_value est la valeur à comparer, exprimée sous forme de chaîne.

Le filtre :avp est destiné aux AVP simples tels que User-Name et Origin-Host. Les AVP groupés ne sont pas supportés et ne correspondront pas, et les valeurs binaires complexes ne correspondront pas.

Les valeurs peuvent être correspondantes de plusieurs manières :

Chaîne exacte — {:avp, {1, "999999000000001"}} ne correspond qu'à cette valeur exacte.
Liste de valeurs — {:avp, {1, ["50557...", "505057..."]}} correspond si l'AVP est égal à n'importe quelle valeur de la liste (logique OU dans 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 plutôt qu'au contenu du message. Ils sont spécifiques à la direction et complémentaires :

:to_peer correspond au pair de destination résolu auquel une demande est sur le point d'être transférée. Il ne correspond jamais qu'aux paquets de demande ; contre une réponse, il ne correspond jamais.
:from_peer correspond au pair qui a répondu à un message. Il ne correspond jamais qu'aux paquets de réponse ; contre une demande, il ne correspond jamais.

Les deux filtres acceptent soit un seul nom d'hôte, soit une liste de noms d'hôtes, auquel cas le filtre correspond si le pair est égal à n'importe quel nom d'hôte de la liste (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 pair listé
`:from_peer`	`{:from_peer, "hss01.example.com"}`	Réponses reçues du pair `hss01.example.com`

Actions de Transformation

La transformation est décrite par la carte transform. Sa clé action sélectionne une des trois transformations. Quelles actions sont permises dépend de la direction du message :

Action	Ce qu'elle fait	Demandes	Réponses
`:edit`	Réécrit la valeur d'un AVP existant.	Oui	Non
`:remove`	Supprime les AVP nommés du message.	Oui	Oui
`:overwrite`	Réécrit les AVP par nom, y compris les AVP 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 AVP qui existent déjà dans le message. Si l'AVP ciblé n'est pas présent, aucun changement n'est effectué et le message est transmis tel quel.
Chaque entrée dans avps est {:avp, {<code>, <new_value>}} et définit cet AVP à la nouvelle valeur.
:edit s'applique uniquement aux demandes. Pour réécrire les AVP sur les réponses, ou pour atteindre les AVP groupés, utilisez :overwrite.

L'action `:remove`

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

:remove se comporte comme suit :

Il supprime les AVP nommés dans avps du message.
La correspondance se fait uniquement par code AVP — la valeur dans chaque entrée avps est ignorée pour la suppression. Utilisez :any comme valeur pour le rendre explicite.
Elle 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 :

Elle réécrit les AVP nommés par nom, en utilisant le dictionnaire fourni pour décoder et réencoder le message.
Étant donné que le message est entièrement décodé, :overwrite peut atteindre les AVP groupés / enregistrements que :edit ne peut pas.
Elle nécessite une clé dictionary nommant le dictionnaire Diameter qui décrit le message (par exemple :diameter_gen_3gpp_s6a).
Elle s'applique à la fois aux demandes et aux réponses.

Paramètres de la Carte de Transformation

Paramètre	Type	Requis	Par défaut	Description
`action`	Atome	Oui	-	La transformation à appliquer : `:edit` (réécrire une valeur d'AVP existante — demandes uniquement), `:remove` (supprimer les AVP par code — demandes et réponses), ou `:overwrite` (réécrire les AVP par nom, y compris les AVP 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`, seul `<code>` est utilisé et la valeur est ignorée (utilisez `:any`).
`dictionary`	Atome	Seulement pour `:overwrite`	`:not_used`	Le dictionnaire Diameter utilisé pour décoder/réencoder le message afin que les AVP nommés (groupés) puissent être écrasés, par exemple `:diameter_gen_3gpp_s6a`. Ignoré par `:edit` et `:remove`.

Configuration

La Transformation Avancée est configurée sous module_advanced_transform dans config/runtime.exs. Le module est désactivé par défaut et ne fait rien jusqu'à ce que enabled soit défini 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	Requis	Par défaut	Description
`enabled`	Booléen	Non	`false`	Active le module. Lorsque `false`, aucune règle n'est évaluée et tous les messages passent inchangés.
`rules`	Liste	Oui (lorsqu'activé)	-	Liste ordonnée des règles de transformation. Évaluées de haut en bas ; la première règle correspondante gagne. 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	Requis	Par défaut	Description
`rule_name`	Chaîne	Oui	-	Identifiant unique et descriptif pour la règle. Utilisé pour 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 qui doivent être satisfaites selon le mode `match`. Voir Filtres.
`transform`	Carte	Oui	-	Le changement à appliquer lorsque la règle correspond. Voir Paramètres de 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 ça 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. Lorsqu'elle correspond, l'action :edit réécrit User-Name à 999999000000002. Si un message ne contient pas d'AVP User-Name, aucun changement n'est effectué.

Cas d'utilisation : Corriger ou normaliser une identité d'abonné spécifique au fur et à mesure 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 ça 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) afin que le moteur de routage transfère le message vers le bon réseau partenaire. Étant donné que la première règle correspondante gagne, placez les plages IMSI plus spécifiques au-dessus des plus générales.

Cas d'utilisation : Diriger le trafic d'abonnés en itinérance ou MVNO vers le bon réseau central hébergé en fonction de leur plage IMSI et de leur 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 ça fonctionne : Le filtre :packet_type limite la règle aux réponses, :from_peer la limite aux réponses reçues de hss01.partner.example.com, et :command_code la limite à AIA (318). Lorsque les trois correspondent, l'action :remove supprime le Origin-Host (AVP 264) quelle que soit sa valeur — la suppression correspond uniquement au code AVP.

Cas d'utilisation : Supprimer un AVP que un réseau partenaire remplit incorrectement, ou qui ne devrait pas être transféré en aval, de ses réponses.

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 ça 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 nommés, et le réencode. Étant donné que le message complet est décodé, :overwrite peut atteindre les AVP imbriqués dans des structures groupées/enregistrements 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 groupe de données d'abonnement ou spécifique au fournisseur — où un simple :edit ne correspondrait pas.

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'expéditeur du message.	RFC 6733 §6.3
283	Destination-Realm	Domaine pour lequel le message est destiné ; utilisé pour le routage.	RFC 6733 §6.6
296	Origin-Realm	Domaine de l'expéditeur 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 gagne.
Performance — Placez les règles les plus couramment correspondantes en premier pour réduire la surcharge d'évaluation.
Tests — Validez les motifs d'expressions régulières avant le déploiement.
Nommer — Utilisez des valeurs descriptives pour rule_name pour la clarté opérationnelle et la surveillance.
Surveillance — Suivez les taux de correspondance des règles pour confirmer 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​