Guide de Configuration HLR

← Retour à la Documentation Principale

Ce guide fournit la configuration pour utiliser OmniSS7 comme un Home Location Register (HLR/HSS) avec OmniHSS comme base de données d'abonnés en arrière-plan.

Intégration OmniHSS

Le mode HLR d'OmniSS7 fonctionne comme un frontend de signalisation SS7 qui s'interface avec OmniHSS, un serveur d'abonnés à domicile (HSS) complet. Cette architecture sépare les préoccupations :

• OmniSS7 (Frontend HLR) : Gère toute la signalisation du protocole SS7/MAP, le routage SCCP et la communication réseau
• OmniHSS (Backend HSS) : Gère les données des abonnés, l'authentification, le provisionnement et des fonctionnalités avancées

Pourquoi OmniHSS ?

OmniHSS fournit une gestion des abonnés de niveau opérateur avec des fonctionnalités incluant :

• Support Multi-IMSI : Chaque abonné peut avoir plusieurs IMSI associés à un seul MSISDN pour l'itinérance internationale, le changement de réseau et le provisionnement eSIM
• Authentification Flexible : Support pour les algorithmes d'authentification Milenage (3G/4G/5G) et COMP128 (2G)
• Suivi des Sessions Circuits & Paquets : Suivi indépendant des enregistrements réseau CS (circuit commuté) et PS (paquet commuté)
• Provisionnement Avancé : Profils de service personnalisables, services supplémentaires et données d'abonnement CAMEL
• Conception API-First : API HTTP RESTful pour l'intégration avec les systèmes de facturation, CRM et de provisionnement
• Mises à Jour en Temps Réel : Suivi de localisation, gestion de session et génération de vecteurs d'authentification

Toutes les données des abonnés, les informations d'authentification et les configurations de service sont stockées et gérées dans OmniHSS. OmniSS7 interroge OmniHSS via des appels API HTTPS pour répondre aux opérations MAP telles que UpdateLocation, SendAuthenticationInfo et SendRoutingInfo.

Important : Le mode HLR d'OmniSS7 est un frontend de signalisation uniquement. Toute la logique de gestion des abonnés, les algorithmes d'authentification, les règles de provisionnement et les opérations de base de données sont gérées par OmniHSS. Ce guide couvre la configuration du protocole SS7/MAP dans OmniSS7. Pour des informations sur le provisionnement des abonnés, la configuration de l'authentification, les profils de service et les opérations administratives, reportez-vous à la documentation d'OmniHSS.

Support Multi-IMSI

OmniHSS prend en charge nativement les configurations Multi-IMSI, permettant à un seul abonné (identifié par MSISDN) d'avoir plusieurs IMSI. Cela permet :

• Profils d'Itinérance Internationale : Différents IMSI pour différentes régions afin de réduire les coûts d'itinérance
• eSIM Multi-Profile : Plusieurs profils réseau sur un seul appareil capable d'eSIM
• Changement de Réseau : Changement sans couture entre les réseaux sans changer de MSISDN
• Coordination Dual SIM : Coordination entre plusieurs SIM physiques ou virtuelles
• Tests & Développement : Plusieurs IMSI de test pointant vers le même abonné

Comment ça fonctionne :

• Chaque IMSI a ses propres informations d'authentification (Ki, OPc, algorithme)
• Chaque IMSI peut avoir des enregistrements de session circuit et paquet indépendants
• Les services et profils d'abonnés peuvent être partagés ou personnalisés par IMSI
• OmniSS7 interroge OmniHSS par IMSI, et OmniHSS retourne les données d'abonné appropriées
• Les systèmes de facturation peuvent suivre l'utilisation par IMSI tout en associant tous les IMSI à un seul compte

Exemple de scénario Multi-IMSI :

Abonné MSISDN : +1-555-123-4567
├─ IMSI 1 : 310260123456789 (Réseau Domicile US - Auth Milenage)
├─ IMSI 2 : 208011234567890 (Profil d'Itinérance France - Auth Milenage)
└─ IMSI 3 : 440201234567891 (Profil d'Itinérance UK - Auth COMP128)

Tous les trois IMSI peuvent être utilisés indépendamment pour l'enregistrement réseau, mais ils appartiennent tous au même compte d'abonné. OmniHSS gère la correspondance IMSI-abonné et garantit une authentification et un provisionnement appropriés pour chaque IMSI.

Table des Matières

1. Intégration OmniHSS
2. Support Multi-IMSI
3. Qu'est-ce que le Mode HLR ?
4. Activation du Mode HLR
5. Base de Données des Abonnés
6. Vecteurs d'Authentification
7. Mises à Jour de Localisation
8. Intégration CAMEL
9. Gestion des Abonnés en Itinérance
10. Opérations HLR

• Mapping des Champs de Réponse
  • SendRoutingInfo (SRI)
  • UpdateLocation / ISD
  • SendRoutingInfoForSM
• Résumé des Sources de Champs

---

Qu'est-ce que le Mode HLR ?

Le Mode HLR permet à OmniSS7 de fonctionner comme un Home Location Register pour :

• Gestion des Abonnés : Stocker et gérer les données des abonnés
• Authentification : Générer des vecteurs d'authentification pour l'accès au réseau
• Suivi de Localisation : Traiter les mises à jour de localisation des VLR
• Informations de Routage : Fournir des informations de routage pour les appels et SMS

Architecture HLR

---

Activation du Mode HLR

OmniSS7 peut fonctionner en différents modes (STP, HLR, SMSc). Le mode est sélectionné via un ensemble de drapeaux de mode et la configuration associée dans config/config.exs, le fichier de configuration par défaut de l'application.

Changement vers le Mode HLR

Pour exécuter OmniSS7 en tant que HLR, définissez les drapeaux de mode de manière à ce que les fonctionnalités HLR soient activées et que les fonctionnalités SMSc soient désactivées, puis ajoutez la configuration spécifique au HLR :

1. Ouvrir config/config.exs
2. Définir les drapeaux de mode sous config :omniss7 :
   • map_client_enabled: true — requis pour envoyer/recevoir des opérations MAP
   • hlr_mode_enabled: true — active la gestion spécifique au HLR
   • smsc_mode_enabled: false — désactive les fonctionnalités SMSc
3. Ajouter les paramètres de configuration HLR (point de terminaison API, adresses GT, paramètres ISD/CAMEL, connexion M3UA) montrés ci-dessous
4. Personnaliser les paramètres pour votre déploiement
5. Redémarrer l'application pour que les modifications prennent effet

Remarque : config/runtime.exs est un stub minimal utilisé uniquement pour les tests automatisés — il ne contient pas de définitions de mode opérationnel. Toute la configuration de mode et HLR se trouve dans config/config.exs (avec des remplacements spécifiques à l'environnement dans des fichiers tels que config/test.exs). Les déploiements en production fournissent leur propre config/config.exs.

Configuration du Mode HLR

La configuration HLR complète (dans config/config.exs) ressemble à ceci :

config :omniss7,
  # Drapeaux de mode - Activer uniquement les fonctionnalités HLR
  map_client_enabled: true,
  hlr_mode_enabled: true,
  smsc_mode_enabled: false,

  # Configuration de l'API Backend OmniHSS
  hlr_api_base_url: "https://10.180.2.140:8443",

  # Adresse GT du Centre de Service HLR pour les opérations SMS
  hlr_service_center_gt_address: "1234567890",

  # Configuration de la Correspondance MSISDN ↔ IMSI
  # Voir : section Correspondance MSISDN ↔ IMSI pour les détails
  hlr_imsi_plmn_prefix: "50557",
  hlr_msisdn_country_code: "61",
  hlr_msisdn_nsn_offset: 0,
  hlr_msisdn_nsn_length: 9,

  # Configuration InsertSubscriberData
  # Mode d'Accès Réseau : :packetAndCircuit, :packetOnly, ou :circuitOnly
  isd_network_access_mode: :packetAndCircuit,

  # Envoyer ISD #2 (données de Services Supplémentaires)
  isd_send_ss_data: true,

  # Envoyer ISD #3 (données de Barrage d'Appels)
  isd_send_call_barring: true,

  # Configuration CAMEL (pour les réponses SendRoutingInfo)
  # Clé de Service pour l'initiation de service CAMEL
  camel_service_key: 11_110,

  # Point de Détection de Déclenchement CAMEL
  # Options : :termAttemptAuthorized, :tBusy, :tNoAnswer, :tAnswer
  camel_trigger_detection_point: :termAttemptAuthorized,

  # Préfixes VLR Domicile
  # Liste des préfixes d'adresses VLR considérés comme réseau "domicile"
  # Si le VLR de l'abonné commence par l'un de ces préfixes, utilisez la réponse SRI standard
  # Sinon, l'abonné est en itinérance et nous devons envoyer PRN pour obtenir MSRN
  # Par défaut [] (aucun préfixe = tous les VLR traités comme itinérants) si omis
  home_vlr_prefixes: ["555123"],

  # Configuration de Connexion M3UA
  # Connectez-vous en tant qu'ASP pour recevoir des opérations MAP (UpdateLocation, SendAuthInfo, etc.)
  map_client_m3ua: %{
    mode: "ASP",
    callback: {MapClient, :handle_payload, []},
    process_name: :hlr_client_asp,
    # Point de terminaison local (système HLR)
    local_ip: {10, 179, 4, 11},
    local_port: 2905,
    # Point de terminaison STP distant
    remote_ip: {10, 179, 4, 10},
    remote_port: 2905,
    routing_context: 1
  }

Paramètres de Configuration à Personnaliser

Pour une référence complète de tous les paramètres de configuration, voir la Référence de Configuration.

Paramètre	Type	Par Défaut	Description	Exemple
hlr_api_base_url	Chaîne	Requis	Point de terminaison API OmniHSS en arrière-plan	"https://10.179.3.219:8443"
hlr_service_center_gt_address	Chaîne	Requis	Adresse GT HLR utilisée dans les réponses UpdateLocation	"5551234568"
smsc_service_center_gt_address	Chaîne	Requis	Adresse GT SMSC retournée dans les réponses SRI-for-SM	"5551234567"
hlr_smsc_alert_gts	Liste	[]	Liste des GTs SMSc pour envoyer alertServiceCenter après UpdateLocation	["15559876543", "15559876544"]
hlr_alert_location_expiry_seconds	Entier	172800	Temps d'expiration de la localisation (secondes) lorsque le SMSc reçoit alertServiceCenter	86400
hlr_imsi_plmn_prefix	Chaîne	"50557"	Préfixe PLMN (MCC+MNC) pour la correspondance MSISDN→IMSI (voir MSISDN ↔ IMSI Mapping)	"001001"
hlr_msisdn_country_code	Chaîne	"61"	Préfixe de code pays pour la correspondance inverse IMSI→MSISDN (voir MSISDN ↔ IMSI Mapping)	"1"
hlr_msisdn_nsn_offset	Entier	0	Décalage dans MSISDN pour l'extraction NSN (voir MSISDN ↔ IMSI Mapping)	0
hlr_msisdn_nsn_length	Entier	9	Longueur du Numéro National d'Abonné à extraire (voir MSISDN ↔ IMSI Mapping)	10
isd_network_access_mode	Atome	:packetAndCircuit	Mode d'accès réseau pour InsertSubscriberData	:packetOnly
isd_send_ss_data	Booléen	true	Envoyer ISD #2 avec des données de Services Supplémentaires	false
isd_send_call_barring	Booléen	true	Envoyer ISD #3 avec des données de Barrage d'Appels	false
camel_service_key	Entier	11_110	Clé de service CAMEL pour les réponses SendRoutingInfo	100
camel_trigger_detection_point	Atome	:termAttemptAuthorized	Point de détection de déclenchement CAMEL	:tBusy
home_vlr_prefixes	Liste	[]	Liste des préfixes d'adresses VLR considérés comme réseau "domicile" (vide = tous les VLRs traités comme itinérants)	["555123"]
local_ip	Tuple	Requis	Adresse IP de votre système HLR	{10, 179, 4, 12}
local_port	Entier	2905	Port SCTP local	2905
remote_ip	Tuple	Requis	Adresse IP STP pour la connectivité SS7	{10, 179, 4, 10}
remote_port	Entier	2905	Port SCTP distant	2905
routing_context	Entier	1	ID de contexte de routage M3UA	1

Que se Passe-t-il Lorsque le Mode HLR est Activé

Lorsque hlr_mode_enabled: true, l'interface utilisateur web affichera :

• ✅ Événements SS7 - Journalisation des événements
• ✅ Client SS7 - Test des opérations MAP
• ✅ Pairs - État de connexion (pairs M3UA/SCTP)
• ✅ Liens HLR - État de l'API HLR + gestion des abonnés ← spécifique au HLR
• ✅ Ressources - Surveillance du système
• ✅ Configuration - Visualiseur de configuration

Les onglets Routage, Test de Routage et Liens SMSc seront masqués.

Remarques Importantes

• Configuration Requise : Le paramètre hlr_service_center_gt_address est obligatoire. L'application échouera à démarrer s'il n'est pas configuré.
• Backend OmniHSS : L'API OmniHSS doit être accessible à l'URL hlr_api_base_url configurée
• Délai d'Attente des Requêtes API : Toutes les requêtes API OmniHSS ont un délai d'attente de 5 secondes codé en dur
• Délai d'Attente des Requêtes MAP : Toutes les requêtes MAP (SRI, UpdateLocation, SendAuthInfo, etc.) ont un délai d'attente de 10 secondes codé en dur
• Délai d'ISD : Chaque message InsertSubscriberData (ISD) dans une séquence UpdateLocation a un délai d'attente de 10 secondes codé en dur
• La connexion M3UA au STP est requise pour recevoir des opérations MAP
• Après avoir changé de modes, vous devez redémarrer l'application pour que les changements prennent effet
• Interface Web : Voir le Guide de l'Interface Web pour des informations sur l'utilisation de l'interface web
• Accès API : Voir le Guide API pour la documentation de l'API REST et l'accès à Swagger UI

---

Base de Données des Abonnés

OmniHSS gère toutes les données des abonnés y compris les identités, les informations d'authentification, les profils de service et les informations de localisation. OmniSS7 récupère ces données via des appels API RESTful.

Modèle d'Abonné OmniHSS

OmniHSS stocke des informations complètes sur les abonnés :

• Plusieurs IMSI par abonné : Support pour les configurations Multi-IMSI (eSIM, profils d'itinérance, changement de réseau)
• Informations d'authentification : Sélection de Ki, OPc et algorithme (Milenage ou COMP128)
• Profils de service : Catégorie d'abonné, services autorisés, paramètres QoS
• Suivi de localisation : Suivi indépendant de l'emplacement actuel VLR/MSC (session circuit) et SGSN/GGSN (session paquet)
• Données d'abonnement CAMEL : Clés de service, points de déclenchement et adresses gsmSCF
• Services supplémentaires : Renvoi d'appels, barrages, attente, configurations CLIP/CLIR
• État administratif : Activé/désactivé, restrictions de service, dates d'expiration

---

Vecteurs d'Authentification

Générer des Vecteurs d'Auth

OmniHSS génère des vecteurs d'authentification en utilisant les algorithmes Milenage ou COMP128 en fonction de la méthode d'authentification configurée pour chaque abonné. Lorsque OmniSS7 reçoit des requêtes MAP sendAuthenticationInfo :

1. OmniSS7 extrait l'IMSI de la requête MAP
2. OmniSS7 appelle l'API OmniHSS pour générer des vecteurs d'authentification
3. OmniHSS récupère les informations Ki et OPc de l'abonné
4. OmniHSS génère le nombre demandé de vecteurs (RAND, XRES, CK, IK, AUTN)
5. OmniSS7 encode les vecteurs au format MAP et les retourne au VLR/SGSN demandeur

Intégration de l'API OmniHSS

OmniSS7 communique avec OmniHSS via l'API REST HTTPS pour récupérer les informations des abonnés, mettre à jour les données de localisation et générer des vecteurs d'authentification :

config :omniss7,
  hlr_api_base_url: "https://omnihss-server:8443"

Lorsque OmniSS7 reçoit des opérations MAP du réseau SS7, il interroge OmniHSS pour :

• Récupérer les données de l'abonné par IMSI ou MSISDN
• Générer des vecteurs d'authentification en utilisant les informations Ki/OPc stockées
• Mettre à jour la localisation de la session circuit lorsque les abonnés effectuent UpdateLocation
• Vérifier l'état de l'abonné et les droits de service

---

Mises à Jour de Localisation

Traitement de la Mise à Jour de Localisation

Lors de la réception des requêtes MAP updateLocation, OmniSS7 coordonne avec OmniHSS pour enregistrer l'abonné à un nouveau VLR :

1. Extraire les informations de localisation de la requête UpdateLocation (IMSI, nouveau GT VLR, nouveau GT MSC)
2. Interroger OmniHSS pour vérifier que l'abonné existe et est activé
3. Mettre à jour la session circuit dans OmniHSS avec la nouvelle localisation VLR/MSC
4. Envoyer des messages InsertSubscriberData (ISD) pour provisionner l'abonné au nouveau VLR
5. Retourner la réponse UpdateLocation au VLR (inclut le GT HLR de hlr_service_center_gt_address)
6. Envoyer alertServiceCenter aux GTs SMSc configurés (si hlr_smsc_alert_gts est peuplé)

Remarque : Le paramètre de configuration hlr_service_center_gt_address spécifie le Titre Global du HLR qui est retourné dans les réponses UpdateLocation. Cela permet au VLR/MSC d'identifier et de router les messages de retour vers ce HLR.

Intégration du Centre de Service d'Alerte

Après une mise à jour de localisation réussie, le HLR peut automatiquement notifier les systèmes SMSc qu'un abonné est maintenant joignable en envoyant des messages alertServiceCenter (opcode MAP 64). Pour des informations sur la façon dont le SMSc gère ces alertes, voir Gestion du Centre de Service d'Alerte dans le Guide SMSc.

Configuration

Configurez la liste des Titres Globaux SMSc à notifier :

config :omniss7,
  # Liste des GTs SMSc pour envoyer alertServiceCenter après UpdateLocation
  hlr_smsc_alert_gts: [
    "15559876543",
    "15559876544"
  ],

  # Temps d'expiration de la localisation lorsque le SMSc reçoit alertServiceCenter (par défaut : 48 heures)
  hlr_alert_location_expiry_seconds: 172800

Diagramme de Flux

Comportement

Lorsqu'un abonné effectue UpdateLocation :

1. Le HLR envoie alertServiceCenter à chaque GT SMSc dans la liste hlr_smsc_alert_gts
2. Le message inclut le MSISDN de l'abonné
3. Le HLR utilise hlr_service_center_gt_address comme GT de l'appelant
4. Adressage SCCP : SSN appelant=6 (HLR), SSN appelé=8 (SMSc)

Le SMSc reçoit l'alerte et :

• Supprime le préfixe TON/NPI du MSISDN (par exemple, "19123123213" → "123123213")
• Marque l'abonné comme joignable dans sa base de données de localisation (via POST à /api/locations)
• Définit le champ user_agent sur le GT HLR lors de l'appel à l'API (pour suivre quel HLR a envoyé l'alerte)
• Définit le temps d'expiration de la localisation en fonction de hlr_alert_location_expiry_seconds
• Suit l'abonné dans le Tracker d'Abonnés SMSc pour la surveillance

Tests

Utilisez la page Abonnés Actifs dans l'interface Web pour envoyer manuellement des messages alertServiceCenter pour des tests :

1. Accédez à l'onglet "Abonnés Actifs"
2. Trouvez la section "Tester le Centre de Service d'Alerte"
3. Entrez MSISDN, GT SMSc et GT HLR (les valeurs par défaut sont pré-remplies à partir de la config)
   • GT SMSc par défaut au premier élément de hlr_smsc_alert_gts
   • GT HLR par défaut à hlr_service_center_gt_address
4. Cliquez sur "Envoyer alertServiceCenter"

Ceci est utile pour tester la gestion des alertes SMSc sans nécessiter un flux complet de mise à jour de localisation. Le formulaire utilise la validation phx-blur pour éviter d'afficher des erreurs pendant la saisie.

Configuration InsertSubscriberData (ISD)

Après une mise à jour de localisation réussie, le HLR envoie des données de provisionnement d'abonné au VLR en utilisant des messages InsertSubscriberData (ISD). La configuration ISD vous permet de personnaliser quelles données sont envoyées et comment.

Pour une référence des paramètres de configuration, voir Configuration ISD dans la Référence de Configuration.

Séquence ISD

Le HLR peut envoyer jusqu'à 3 messages ISD séquentiels :

1. ISD #1 (Toujours envoyé) - Données de base de l'abonné :

   • IMSI
   • MSISDN
   • Catégorie d'abonné
   • État de l'abonné (serviceGranted)
   • Liste des services de support
   • Liste des téléservices
   • Mode d'accès au réseau

2. ISD #2 (Optionnel) - Données de Services Supplémentaires (SS) :

   • Paramètres de renvoi d'appels (inconditionnel, occupé, pas de réponse, non joignable)
   • Attente d'appels
   • Mise en attente d'appels
   • Service multi-parties
   • État et fonctionnalités des services supplémentaires

3. ISD #3 (Optionnel) - Données de Barrage d'Appels :

   • Barrage de tous les appels sortants (BAOC)
   • Barrage des appels internationaux sortants (BOIC)
   • Données de restriction d'accès

Options de Configuration

# Configuration InsertSubscriberData
# Mode d'Accès Réseau : :packetAndCircuit, :packetOnly, ou :circuitOnly
isd_network_access_mode: :packetAndCircuit,

# Envoyer ISD #2 (données de Services Supplémentaires)
isd_send_ss_data: true,

# Envoyer ISD #3 (données de Barrage d'Appels)
isd_send_call_barring: true,

Mode d'Accès Réseau

Le paramètre isd_network_access_mode contrôle quel type d'accès réseau l'abonné est autorisé :

Valeur	Description	Cas d'Utilisation
:packetAndCircuit	À la fois commuté par paquets (GPRS/LTE) et commuté par circuits (voix)	Par défaut - Abonnés à service complet
:packetOnly	Commuté par paquets uniquement (données/LTE)	Cartes SIM uniquement pour données, dispositifs IoT
:circuitOnly	Commuté par circuits uniquement (voix/SMS)	Dispositifs hérités, plans uniquement voix

Contrôle des Messages ISD

Vous pouvez contrôler quels messages ISD sont envoyés en fonction de vos exigences réseau :

Envoyer tous les ISDs (Par défaut - Ensemble complet de fonctionnalités) :

isd_send_ss_data: true,
isd_send_call_barring: true,

Envoyer uniquement les données de base de l'abonné (Provisionnement minimal) :

isd_send_ss_data: false,
isd_send_call_barring: false,

Envoyer de base + services supplémentaires (Pas de barrage d'appels) :

isd_send_ss_data: true,
isd_send_call_barring: false,

Exemple de Flux ISD

Lorsque UpdateLocation est reçu :

VLR → HLR: UpdateLocation (DÉBUT)
HLR → VLR: InsertSubscriberData #1 (CONTINUER) - Données de base
VLR → HLR: ISD #1 ACK (CONTINUER)
HLR → VLR: InsertSubscriberData #2 (CONTINUER) - Données SS [si activé]
VLR → HLR: ISD #2 ACK (CONTINUER)
HLR → VLR: InsertSubscriberData #3 (CONTINUER) - Barrage d'appels [si activé]
VLR → HLR: ISD #3 ACK (CONTINUER)
HLR → VLR: Réponse UpdateLocation (FIN)

Si isd_send_ss_data ou isd_send_call_barring sont définis sur false, ces messages ISD sont sautés, et la FIN de UpdateLocation est envoyée plus tôt.

Meilleures Pratiques

• Configuration par Défaut : Utilisez :packetAndCircuit et activez tous les ISDs pour une compatibilité maximale
• IoT/M2M : Utilisez :packetOnly et désactivez les données SS/barrage d'appels pour les dispositifs uniquement pour données
• Interopérabilité : Certains anciens VLRs peuvent ne pas prendre en charge tous les services supplémentaires - désactivez isd_send_ss_data si des problèmes surviennent
• Performance : Désactiver les ISDs inutilisés réduit la surcharge des messages et accélère les mises à jour de localisation

---

Intégration CAMEL

Configuration CAMEL pour SendRoutingInfo

Lors de la réponse aux requêtes SendRoutingInfo (SRI) d'un GMSC (Gateway MSC), le HLR peut indiquer au GMSC d'invoquer des services CAMEL pour le routage intelligent des appels et le contrôle des services.

Pour une référence des paramètres de configuration, voir Configuration CAMEL dans la Référence de Configuration.

Qu'est-ce que CAMEL ?

CAMEL (Applications Personnalisées pour la Logique Améliorée des Réseaux Mobiles) est un protocole qui permet des services réseau intelligents dans les réseaux GSM/UMTS. Il permet aux opérateurs de réseau de mettre en œuvre des services à valeur ajoutée tels que :

• Facturation prépayée
• Filtrage et barrages d'appels
• Réseaux Privés Virtuels (VPN)
• Services à tarif premium
• Renvoi d'appels avec logique personnalisée
• Services basés sur la localisation

Options de Configuration

# Configuration CAMEL (pour les réponses SendRoutingInfo)
# Clé de Service pour l'initiation de service CAMEL
camel_service_key: 11_110,

# Point de Détection de Déclenchement CAMEL
# Options : :termAttemptAuthorized, :tBusy, :tNoAnswer, :tAnswer
camel_trigger_detection_point: :termAttemptAuthorized,

Clé de Service

La camel_service_key identifie quel service CAMEL doit être invoqué au gsmSCF (Service Control Function). Il s'agit d'un identifiant numérique configuré dans votre réseau :

Clé de Service	Cas d'Utilisation Typique
11_110	Contrôle des appels terminants prépayés (par défaut)
100	Service prépayé d'origine
200	Renvoi d'appels avec logique personnalisée
300	Réseau Privé Virtuel (VPN)
Personnalisé	Services spécifiques à l'opérateur

Exemple de Configuration :

# Pour le contrôle des appels terminants prépayés
camel_service_key: 11_110,

# Pour le service VPN
camel_service_key: 300,

Point de Détection de Déclenchement

Le camel_trigger_detection_point spécifie quand le service CAMEL doit être déclenché lors de la configuration de l'appel :

Point de Détection	Description	Quand Déclenché
:termAttemptAuthorized	Tentative d'appel autorisée (par défaut)	Avant que l'appel ne soit routé vers l'abonné
:tBusy	Occupé terminant	Lorsque l'abonné est occupé
:tNoAnswer	Pas de réponse terminante	Lorsque l'abonné ne répond pas
:tAnswer	Réponse terminante	Lorsque l'abonné répond à l'appel

Exemples de Configuration :

Contrôle prépayé standard (déclenchement avant le routage) :

camel_trigger_detection_point: :termAttemptAuthorized,

Gestion personnalisée des appels occupés (déclenchement lorsque occupé) :

camel_trigger_detection_point: :tBusy,

Facturation basée sur la réponse (déclenchement à la réponse) :

camel_trigger_detection_point: :tAnswer,

Réponse SRI avec CAMEL

Lorsqu'il est configuré, les réponses SendRoutingInfo incluent des informations d'abonnement CAMEL :

GMSC → HLR: SendRoutingInfo (DÉBUT)
HLR → GMSC: Réponse SRI (FIN) avec :
  - IMSI
  - Numéro VLR
  - État de l'abonné
  - Informations de routage CAMEL :
    * Clé de Service : 11_110
    * Adresse gsmSCF : <adresse configurée>
    * Point de Détection de Déclenchement : termAttemptAuthorized
    * Gestion des Appels par Défaut : continueCall

Le GMSC contacte gsmSCF au point de déclenchement pour exécuter le service CAMEL

Meilleures Pratiques

• Réseaux de Production : Utilisez des clés de service standardisées convenues avec votre fournisseur gsmSCF
• Tests : Utilisez :termAttemptAuthorized pour des tests les plus complets
• Services Prépayés : La clé de service 11_110 est une norme industrielle courante pour les appels terminants prépayés
• Gestion de Repli : defaultCallHandling: :continueCall garantit que les appels se poursuivent si gsmSCF est injoignable

---

Gestion des Abonnés en Itinérance

Détection VLR Domicile vs VLR en Itinérance

Lorsque le HLR reçoit une requête SendRoutingInfo (SRI), il doit déterminer si l'abonné est sur un VLR "domicile" (dans votre réseau) ou sur un VLR en itinérance (visite d'un autre réseau). Le comportement diffère en fonction de cette détermination :

Pour une référence des paramètres de configuration, voir Préfixes VLR Domicile dans la Référence de Configuration.

• VLR Domicile : Retourner une réponse SRI standard avec des informations de routage CAMEL
• VLR en Itinérance : Envoyer une requête Provide Roaming Number (PRN) pour obtenir un MSRN, puis le retourner dans la réponse SRI

Configuration

# Préfixes VLR Domicile
# Liste des préfixes d'adresses VLR considérés comme réseau "domicile"
# Si l'adresse VLR de l'abonné commence par l'un de ces préfixes, utilisez la réponse SRI standard
# Sinon, l'abonné est en itinérance et nous devons envoyer PRN pour obtenir MSRN
home_vlr_prefixes: ["555123"],

Exemple de Configuration :

# Un seul opérateur de réseau domicile
home_vlr_prefixes: ["555123"],

# Plusieurs opérateurs de réseau domicile (par exemple, différentes régions ou filiales)
home_vlr_prefixes: ["555123", "555124", "555125"],

Comment Ça Fonctionne

1. Flux Abonné Domicile (Standard)

Lorsque l'adresse VLR de l'abonné commence par un préfixe domicile configuré :

GMSC → HLR: SendRoutingInfo (MSISDN: "1234567890")
HLR interroge l'API backend pour les données de l'abonné
HLR vérifie l'adresse VLR : "5551234567"
HLR détermine : VLR commence par "555123" → Réseau domicile
HLR → GMSC: Réponse SRI avec informations de routage CAMEL :
  - IMSI
  - Numéro VLR : "5551234567"
  - Adresse gsmSCF (MSC) : "5551234501"
  - Clé de service CAMEL : 11_110
  - Point de détection de déclenchement : termAttemptAuthorized

2. Flux Abonné en Itinérance (PRN Requis)

Lorsque l'adresse VLR de l'abonné NE correspond PAS à un préfixe domicile :

GMSC → HLR: SendRoutingInfo (MSISDN: "1234567890")
HLR interroge l'API backend pour les données de l'abonné
HLR vérifie l'adresse VLR : "49170123456"
HLR détermine : VLR ne commence pas par "555123" → Itinérance
HLR → MSC: ProvideRoamingNumber (PRN) :
  - MSISDN : "1234567890"
  - IMSI : "999999876543210"
  - Numéro MSC : "49170123456"
  - Adresse GMSC : "5551234501"
MSC → HLR: Réponse PRN avec MSRN : "49170999888777"
HLR → GMSC: Réponse SRI avec informations de routage :
  - IMSI
  - Numéro VLR : "49170123456"
  - Numéro d'Itinérance (MSRN) : "49170999888777"

Différences de Structure de Réponse

Réponse SRI Abonné Domicile

%{
  imsi: "999999876543210",
  extendedRoutingInfo: {
    :camelRoutingInfo, %{
      gmscCamelSubscriptionInfo: %{
        "t-CSI": %{
          serviceKey: 11_110,
          "gsmSCF-Address": "5551234501",
          defaultCallHandling: :continueCall,
          "t-BcsmTriggerDetectionPoint": :termAttemptAuthorized
        }
      }
    }
  },
  subscriberInfo: %{
    locationInformation: %{"vlr-number": "5551234567"},
    subscriberState: {:notProvidedFromVLR, :NULL}
  }
}

Réponse SRI Abonné en Itinérance

%{
  imsi: "999999876543210",
  extendedRoutingInfo: {
    :routingInfo, %{
      roamingNumber: "49170999888777"  # MSRN de PRN
    }
  },
  subscriberInfo: %{
    locationInformation: %{"vlr-number": "49170123456"},
    subscriberState: {:notProvidedFromVLR, :NULL}
  }
}

Opération Provide Roaming Number (PRN)

Structure de la Requête PRN

La requête PRN envoyée au MSC/VLR contient :

Champ	Source	Description
MSISDN	Requête SRI	Numéro de téléphone de l'abonné
IMSI	API HLR	IMSI de l'abonné
Numéro MSC	API HLR	MSC servant l'abonné en itinérance (serving_msc)
Adresse GMSC	Requête SRI	GMSC effectuant la requête SRI d'origine
Numéro de Référence d'Appel	Statique	Identifiant de référence d'appel
Phases CAMEL Supportées	Statique	Phases CAMEL prises en charge par le GMSC

Gestion de la Réponse PRN

Le HLR s'attend à une réponse PRN contenant :

• MSRN (Numéro de Routage de Station Mobile) : Un numéro temporaire alloué par le réseau visité pour le routage de l'appel

Gestion des Erreurs :

• Si PRN expire → Retourne l'erreur 27 (Abonné Absent) dans la réponse SRI
• Si PRN échoue → Retourne l'erreur 27 (Abonné Absent) dans la réponse SRI
• Si MSRN ne peut pas être extrait → Retourne l'erreur 27 (Abonné Absent) dans la réponse SRI

Exemples de Configuration

Opérateur de Réseau Domicile Unique

# Tous les adresses VLR commençant par "555123" sont considérées comme domicile
home_vlr_prefixes: ["555123"],

• VLR 5551234567 → Domicile (réponse CAMEL)
• VLR 5551235001 → Domicile (réponse CAMEL)
• VLR 49170123456 → Itinérance (PRN + réponse MSRN)

Opérateur Multi-Régions

# Plusieurs réseaux domicile à travers différentes régions
home_vlr_prefixes: ["555123", "555124", "555125"],

• VLR 5551234567 → Domicile (région 1)
• VLR 5552341234 → Domicile (région 2)
• VLR 5553411111 → Domicile (région 3)
• VLR 44201234567 → Itinérance (international)

Configuration de Test

Pour tester la fonctionnalité PRN, définissez une liste vide pour traiter tous les VLRs comme itinérants :

# Tous les VLRs sont traités comme itinérants (pour tester le flux PRN)
home_vlr_prefixes: [],

Meilleures Pratiques

• Sélection de Préfixe : Utilisez le préfixe unique le plus court qui identifie les VLRs de votre réseau (par exemple, code pays + code réseau)
• Multiples Préfixes : Incluez tous les préfixes VLR dans votre réseau, y compris différentes régions et filiales
• Accords d'Itinérance : Assurez-vous que PRN est correctement pris en charge par les réseaux partenaires en itinérance
• Tests : Testez soigneusement les scénarios domicile et itinérance avant le déploiement en production
• Surveillance : Surveillez les taux d'expiration de PRN pour identifier les problèmes de connectivité avec les partenaires en itinérance

Dépannage

Symptôme : Tous les abonnés traités comme itinérants

• Cause : home_vlr_prefixes non configuré ou préfixes ne correspondent pas aux adresses VLR
• Solution : Vérifiez les adresses VLR dans votre base de données et mettez à jour les préfixes en conséquence

Symptôme : Les requêtes PRN expirent

• Cause : Problèmes de connectivité réseau vers le MSC/VLR partenaire en itinérance
• Solution : Vérifiez le routage M3UA/SCCP vers les adresses MSC distantes

Symptôme : MSRN invalide dans la réponse SRI

• Cause : Format de réponse PRN du partenaire en itinérance ne correspond pas à la structure attendue
• Solution : Examinez les journaux de réponse PRN et ajustez extract_msrn_from_prn/1 si nécessaire

---

Opérations HLR

Opérations MAP Supportées

OmniSS7 dispatches les opérations MAP entrantes par opcode (indépendamment de la phase TCAP). Les opérations entrantes suivantes sont gérées :

Opcode	Opération	But
2	updateLocation	Enregistrer la localisation VLR (déclenche la séquence ISD + alertServiceCenter optionnel)
23	updateGprsLocation	Enregistrer la localisation SGSN (commuté par paquet)
3	cancelLocation	Désenregistrer du vieux VLR
7	insertSubscriberData	Recevoir le profil d'abonné (par exemple, lors de l'action en tant que côté VLR)
22	sendRoutingInfo (SRI)	Fournir MSRN/routage CAMEL pour les appels (domicile vs itinérance)
45	sendRoutingInfoForSM (SRI-for-SM)	Fournir IMSI + GT SMSC pour le routage SMS
44	MT-Forward-SM	Livraison de SMS terminés mobiles
46	MO-Forward-SM	Réception de SMS d'origine mobile
47	reportSM-DeliveryStatus	Rapport de statut de livraison SMS-GMSC
64	alertServiceCenter	Alerte d'abonné joignable au SMSc
66	readyForSM	MSC/SGSN signale que l'abonné est prêt pour SMS
56	sendAuthenticationInfo	Générer des vecteurs d'authentification
57	restoreData	Restauration des données d'abonné VLR
67	purgeMS	Purger un enregistrement d'abonné au HLR
59	processUnstructuredSS-Request	USSD (géré via la passerelle USSD lorsque activé)
71	anyTimeInterrogation (ATI)	Interrogation de localisation/état de l'abonné
10	registerSS	Enregistrement de service supplémentaire (par exemple, Renvoi d'Appels Inconditionnel)

Les opcodes non gérés sont répondus avec une erreur facilityNotSupported (21).

Mapping des Champs de Réponse

Cette section détaille d'où provient chaque champ dans les réponses HLR.

Réponse SendRoutingInfo (SRI)

But : Fournit des informations de routage pour les appels entrants vers un abonné.

Le HLR fournit deux types de réponses différents en fonction de si l'abonné est sur un VLR domicile ou en itinérance :

Réponse Abonné Domicile (Routage CAMEL)

Utilisé lorsque l'adresse VLR de l'abonné commence par une valeur configurée dans home_vlr_prefixes.

Structure de la Réponse :

Champ	Source	Description	Exemple
IMSI	API OmniHSS	IMSI de l'abonné depuis la base de données OmniHSS	"999999876543210"
Numéro VLR	API OmniHSS	VLR actuel servant l'abonné (circuit_session.assigned_vlr)	"5551234567"
État de l'Abonné	Statique	Toujours notProvidedFromVLR	:notProvidedFromVLR
extendedRoutingInfo	-	Type : camelRoutingInfo	-
Adresse gsmSCF	API OmniHSS	MSC servant l'abonné (circuit_session.assigned_msc)	"5551234501"
Clé de Service	config.exs	Identifiant de service CAMEL (camel_service_key)	11_110
Point de Détection de Déclenchement	config.exs	Quand déclencher CAMEL (camel_trigger_detection_point)	:termAttemptAuthorized
Gestion des Capacités CAMEL	Statique	Niveau de support de phase CAMEL	3
Gestion des Appels par Défaut	Statique	Repli si gsmSCF injoignable	:continueCall

Réponse Abonné en Itinérance (Routage MSRN)

Utilisé lorsque l'adresse VLR de l'abonné NE correspond PAS à une valeur configurée dans home_vlr_prefixes.

Structure de la Réponse :

Champ	Source	Description	Exemple
IMSI	API OmniHSS	IMSI de l'abonné depuis la base de données OmniHSS	"999999876543210"
Numéro VLR	API OmniHSS	VLR actuel servant l'abonné (circuit_session.assigned_vlr)	"49170123456"
État de l'Abonné	Statique	Toujours notProvidedFromVLR	:notProvidedFromVLR
extendedRoutingInfo	-	Type : routingInfo	-
Numéro d'Itinérance (MSRN)	Réponse PRN	MSRN obtenu de la requête ProvideRoamingNumber	"49170999888777"

Logique de Décision de Routage :

1. OmniSS7 reçoit la requête SendRoutingInfo
2. OmniSS7 interroge les données de l'abonné depuis l'API OmniHSS
3. OmniSS7 vérifie l'adresse VLR contre home_vlr_prefixes :

   Si le VLR commence par le préfixe domicile :
     → Retourner les informations de routage CAMEL (flux abonné domicile)

   Si le VLR ne correspond à aucun préfixe domicile :
     → Envoyer ProvideRoamingNumber (PRN) au MSC
     → Extraire le MSRN de la réponse PRN
     → Retourner les informations de routage avec MSRN (flux abonné en itinérance)

Flux de Données :

• OmniSS7 interroge OmniHSS pour les informations de l'abonné
• OmniHSS retourne l'IMSI, la localisation actuelle VLR/MSC et l'état de l'abonné
• OmniSS7 utilise ces données pour construire la réponse MAP

Exigences de Configuration :

# Dans config/config.exs
home_vlr_prefixes: ["555123"],  # Liste des préfixes VLR domicile

Réponses d'Erreur :

• Si serving_vlr et serving_msc sont null : Retourne l'erreur 27 (Abonné Absent)
• Si l'abonné n'est pas trouvé : Retourne l'erreur 1 (Abonné Inconnu)
• Si la requête PRN expire (cas itinérance) : Retourne l'erreur 27 (Abonné Absent)
• Si la réponse PRN est invalide (cas itinérance) : Retourne l'erreur 27 (Abonné Absent)

---

Réponse UpdateLocation avec InsertSubscriberData

But : Enregistre l'abonné à un nouveau VLR et provisionne les données de l'abonné.

Réponse UpdateLocation FIN

Champ	Source	Description	Exemple
Numéro HLR	config.exs	Titre Global de ce HLR (hlr_service_center_gt_address)	"5551234568"
Type de Message TCAP	Statique	Réponse finale après tous les ISD	FIN

InsertSubscriberData #1 (Données de Base de l'Abonné)

Champ	Source	Description	Exemple
IMSI	Requête	Depuis la requête UpdateLocation	"999999876543210"
MSISDN	API OmniHSS	Numéro de téléphone de l'abonné depuis OmniHSS	"555123456"
Catégorie	Statique	Catégorie d'abonné	"\n" (0x0A)
État de l'Abonné	Statique	État de service	:serviceGranted
Liste des Services de Support	Statique	Services de support pris en charge	[<&lt;31>>]
Liste des Téléservices	Statique	Téléservices pris en charge	[<&lt;17>>, "!", "\""]
Mode d'Accès au Réseau	config.exs	Accès paquet/circuit (isd_network_access_mode)	:packetAndCircuit

InsertSubscriberData #2 (Services Supplémentaires) - Optionnel

Champ	Source	Description	Contrôlé Par
SS Provisionnés	Statique	Données de services supplémentaires	isd_send_ss_data: true
Renvoi d'Appels	Statique	Paramètres de renvoi (inconditionnel, occupé, pas de réponse, non joignable)	Config activée
Attente d'Appels	Statique	État du service d'attente d'appels	Config activée
Service Multi-parties	Statique	Support d'appel conférence	Config activée

InsertSubscriberData #3 (Barrage d'Appels) - Optionnel

Champ	Source	Description	Contrôlé Par
Informations de Barrage d'Appels	Statique	Configurations de barrage d'appels	isd_send_call_barring: true
BAOC	Statique	Barrage de Tous les Appels Sortants (SS code 146)	Config activée
BOIC	Statique	Barrage des Appels Internationaux Sortants (SS code 147)	Config activée
Données de Restriction d'Accès	Statique	Restrictions d'accès au réseau	Config activée

Contrôle de la Séquence ISD :

• ISD #1 : Toujours envoyé - Contient les données essentielles de l'abonné
• ISD #2 : Envoyé uniquement si isd_send_ss_data: true dans config/config.exs
• ISD #3 : Envoyé uniquement si isd_send_call_barring: true dans config/config.exs

---

Réponse SendRoutingInfoForSM (SRI-for-SM)

But : Fournit des informations de routage MSC/SMSC pour la livraison de SMS. Lorsqu'un SMSc doit livrer un SMS à un abonné, il envoie une requête SRI-for-SM au HLR pour déterminer où router le message.

Structure de la Réponse :

Champ	Source	Description	Comment Généré	Exemple
IMSI	Calculé	IMSI synthétique dérivé de MSISDN	PLMN_PREFIX + zero_padded_MSISDN	"001001555123456"
Numéro de Nœud Réseau	config.exs	Adresse GT SMSC pour le routage SMS	smsc_service_center_gt_address	"5551234567"

Paramètres de Configuration (depuis config/config.exs) :

# Adresse du Centre de Service GT (retournée dans les réponses SRI-for-SM)
# Cela indique au SMSc demandeur où envoyer les messages MT-ForwardSM
smsc_service_center_gt_address: "5551234567",  # Requis

# Configuration de la Correspondance MSISDN ↔ IMSI
# Préfixe PLMN : MCC (001 = Réseau de Test) + MNC (01 = Opérateur de Test)
hlr_imsi_plmn_prefix: "001001",                  # Seul paramètre de config nécessaire !

---

Correspondance MSISDN ↔ IMSI

Paramètres de Configuration :

Ces paramètres contrôlent comment OmniSS7 génère des IMSIs synthétiques à partir des MSISDNs pour les réponses SRI-for-SM :

• hlr_imsi_plmn_prefix : Le préfixe MCC+MNC à utiliser lors de la construction des IMSIs synthétiques (par exemple, "50557" pour MCC=505, MNC=57)
• hlr_msisdn_country_code : Code pays à préfixer lors de la correspondance inverse IMSI→MSISDN (par exemple, "61" pour l'Australie, "1" pour les États-Unis/Canada)
• hlr_msisdn_nsn_offset : Position du caractère où commence le Numéro National d'Abonné (NSN) dans le MSISDN (typiquement 0 si le MSISDN n'inclut pas le code pays, ou longueur du code pays s'il l'inclut)
• hlr_msisdn_nsn_length : Nombre de chiffres à extraire du MSISDN comme NSN

Pour des détails supplémentaires sur la configuration, voir Correspondance MSISDN ↔ IMSI dans la Référence de Configuration.

Pourquoi la Correspondance MSISDN à IMSI est-elle Nécessaire ?

Le protocole MAP pour SendRoutingInfoForSM (SRI-for-SM) exige que le HLR retourne un IMSI (Identité Internationale d'Abonné Mobile) dans sa réponse. Cependant, le SMSc demandeur ne connaît que le MSISDN de l'abonné (numéro de téléphone).

Dans un réseau traditionnel :

• Le SMSc envoie SRI-for-SM avec le MSISDN de destination (par exemple, "5551234567")
• Le HLR doit rechercher l'abonné dans sa base de données pour trouver son IMSI
• Le HLR retourne l'IMSI dans la réponse SRI-for-SM
• Le SMSc utilise ensuite cet IMSI lors de l'envoi de MT-ForwardSM au MSC/VLR

Approche d'OmniSS7 - IMSIs Synthétiques :

Au lieu de maintenir une base de données complète d'abonnés avec des correspondances MSISDN-IMSI, OmniSS7 utilise un schéma d'encodage simple pour calculer des IMSIs synthétiques directement à partir des MSISDN. Cette approche offre deux avantages clés :

1. Confidentialité : Les vrais IMSIs des abonnés stockés dans la base de données HLR ne sont jamais exposés dans les réponses SRI-for-SM envoyées sur le réseau SS7
2. Simplicité : Pas besoin d'interroger la base de données HLR pour les recherches IMSI lors des opérations SRI-for-SM - l'IMSI est calculé à la volée à partir du MSISDN

Comment Ça Fonctionne :

Les MSISDNs sont directement encodés dans la portion d'abonné de l'IMSI (les chiffres après MCC+MNC) :

IMSI = PLMN_PREFIX + zero_padded_MSISDN

Où :

• PLMN_PREFIX : MCC + MNC (par exemple, "001001" pour le Réseau de Test)
• MSISDN : Tous les chiffres numériques du numéro de téléphone
• Zero Padding : Complété à gauche avec des zéros pour remplir l'IMSI à exactement 15 chiffres

Exemple Étape par Étape :

# Configuration
plmn_prefix = "001001"  # MCC 001 + MNC 01

# Entrée : MSISDN de la requête SRI-for-SM (décodé TBCD)
msisdn = "555123456"    # 9 chiffres

# Étape 1 : Calculer l'espace disponible pour le numéro d'abonné
subscriber_digits = 15 - String.length("001001")  # = 9 chiffres

# Étape 2 : Compléter le MSISDN avec des zéros pour remplir la portion d'abonné
padded_msisdn = String.pad_leading("555123456", 9, "0")  # = "555123456" (aucun remplissage nécessaire)

# Étape 3 : Concaténer le préfixe PLMN + le MSISDN complété
imsi = "001001" <> "555123456"  # = "001001555123456" (exactement 15 chiffres)

Exemples Complets :

MSISDN d'Entrée	Préfixe PLMN	Chiffres d'Abonné Disponibles	MSISDN Complété	IMSI Final	Remarques
"555123456"	"001001" (6)	9	"555123456"	"001001555123456"	Ajustement exact, aucun remplissage
"99"	"001001" (6)	9	"000000099"	"001001000000099"	Complété à gauche avec des zéros
"999999999"	"001001" (6)	9	"999999999"	"001001999999999"	Ajustement exact
"91123456789"	"001001" (6)	9	"555123456"	"001001555123456"	Trop long, les 9 chiffres de droite sont conservés

Gestion des Cas Limites :

• MSISDNs Courtes : Complétés à gauche avec des zéros (par exemple, "99" → "000000099")
• MSISDNs Longues : Les chiffres les plus à droite sont conservés, les chiffres les plus à gauche sont tronqués (par exemple, "91123456789" → "555123456")
• Longueur IMSI : Toujours exactement 15 chiffres

Gestion Inverse (IMSI → MSISDN) :

Le SMSc peut inverser cette correspondance pour convertir les IMSIs en MSISDNs :

# Entrée : IMSI de la réponse SRI-for-SM
imsi = "001001555123456"

# Étape 1 : Supprimer le préfixe PLMN
plmn_prefix = "001001"
subscriber_portion = String.slice(imsi, 6, 9)  # = "555123456"

# Étape 2 : Supprimer les zéros à gauche pour obtenir le MSISDN réel
msisdn = String.replace_leading(subscriber_portion, "0", "")  # = "555123456"

Exemples de Correspondance Inverse :

IMSI d'Entrée	Préfixe PLMN	Portion d'Abonné	Supprimer les Zéros à Gauche	MSISDN Final
"001001555123456"	"001001"	"555123456"	"555123456"	"555123456"
"001001000000099"	"001001"	"000000099"	"99"	"99"
"001001999999999"	"001001"	"999999999"	"999999999"	"999999999"

Propriétés de Cette Correspondance :

• ✅ Déterministe : Le même MSISDN produit toujours le même IMSI
• ✅ Récupérable : Peut être converti de l'IMSI au MSISDN
• ✅ Configuration Minimale : Nécessite uniquement hlr_imsi_plmn_prefix
• ✅ Préservation de la Confidentialité : Les vrais IMSIs ne sont jamais exposés
• ✅ Pas de Recherche dans la Base de Données : Calcul rapide, aucun appel API nécessaire
• ✅ Toujours 15 Chiffres : L'IMSI est toujours exactement de 15 chiffres

Gestion des Entrées MSISDN :

Lorsque le HLR reçoit une requête SRI-for-SM, le MSISDN subit un décodage TBCD :

1. Décodage TBCD : Convertir le TBCD binaire en chaîne (peut inclure un préfixe TON/NPI comme "91")
2. Extraire les Chiffres : Conserver uniquement les chiffres numériques, supprimer tous les caractères non numériques
3. Normaliser : Si plus long que l'espace disponible, prendre les chiffres les plus à droite ; si plus court, compléter à gauche avec des zéros
4. Encoder : Concaténer le préfixe PLMN + MSISDN normalisé

Considérations de Sécurité :

Les IMSIs synthétiques retournés dans les réponses SRI-for-SM sont purement à des fins de routage. Ils ne sont PAS les vrais IMSIs stockés dans la base de données d'abonnés HLR. Cela fournit une couche de protection supplémentaire de la confidentialité, car les vrais IMSIs des abonnés ne sont exposés que lorsque cela est absolument nécessaire (par exemple, lors des opérations UpdateLocation ou SendAuthenticationInfo qui nécessitent de vrais vecteurs d'authentification).

Flux de Réponse :

1. SMSc → HLR: Requête SRI-for-SM
   - MSISDN (TBCD): "91123456789" (inclut TON/NPI)

2. Traitement HLR :
   - Décodage TBCD: "91123456789"
   - Extraire les chiffres: "91123456789" (11 chiffres)
   - Ajuster à 9 chiffres: "555123456" (ajustement exact)
   - Ajouter PLMN: "001001" + "555123456" = "001001555123456"
   - Obtenir GT SMSC depuis la config: "5551234567"

3. HLR → SMSc: Réponse SRI-for-SM
   - IMSI: "001001555123456" (synthétique, toujours 15 chiffres)
   - Numéro de Nœud Réseau: "5551234567" (où envoyer MT-ForwardSM)

4. SMSc envoie MT-ForwardSM à "5551234567" avec IMSI "001001555123456"

Configuration :

Les paramètres suivants sont utilisés dans config/config.exs :

# Préfixe PLMN : MCC (001 = Réseau de Test) + MNC (01 = Opérateur de Test)
hlr_imsi_plmn_prefix: "001001",

# Extraction NSN (si les MSISDN incluent le code pays)
hlr_msisdn_country_code: "1",      # Utilisé pour la correspondance inverse (IMSI→MSISDN)
hlr_msisdn_nsn_offset: 1,          # Ignorer 1 chiffre de code pays
hlr_msisdn_nsn_length: 10          # Extraire 10 chiffres NSN

Configuration d'Extraction NSN :

Si vos MSISDN incluent le code pays (par exemple, "68988000088" au lieu de juste "88000088"), vous devez configurer l'extraction NSN :

• hlr_msisdn_nsn_offset : Position où commence le NSN (typiquement la longueur de votre code pays)
• hlr_msisdn_nsn_length : Nombre de chiffres dans le NSN

Exemples :

Exemple	Code Pays	MSISDN Exemple	nsn_offset	nsn_length	NSN Extrait
Code Pays 1 chiffre	"9"	"95551234567"	1	10	"5551234567"
Code Pays 2 chiffres	"99"	"99412345678"	2	9	"412345678"
Code Pays 3 chiffres	"999"	"99988000088"	3	8	"88000088"

Comment Ça Fonctionne :

1. MSISDN → IMSI : Extraire le NSN du MSISDN, compléter avec des zéros, concaténer avec le préfixe PLMN

   MSISDN: "99988000088"
   NSN: String.slice("99988000088", 3, 8) = "88000088"
   Padded NSN: "088000088" (9 chiffres)
   IMSI: "547050" + "088000088" = "547050088000088"

2. IMSI → MSISDN : Supprimer le préfixe PLMN, retirer les zéros à gauche, préfixer le code pays

   IMSI: "547050088000088"
   Portion d'abonné: "088000088"
   Supprimer les zéros: "88000088"
   MSISDN: "+999" + "88000088" = "+99988000088"

Exigences de l'API : Aucune - SRI-for-SM utilise des valeurs calculées et la configuration uniquement. Aucun appel backend API n'est requis.

Résumé des Sources de Champs

Type de Source	Description	Exemples
API OmniHSS	Données dynamiques de la base de données d'abonnés OmniHSS	IMSI, MSISDN, VLR/MSC servant depuis circuit_session
config.exs	Paramètres de configuration OmniSS7	smsc_service_center_gt_address, camel_service_key, isd_network_access_mode
Statique	Valeurs codées en dur dans le générateur de réponse	État de l'abonné, services de support, codes SS
Requête	Champs extraits de la requête MAP entrante	IMSI depuis UpdateLocation, MSISDN depuis SRI
Calculé	Valeurs dérivées utilisant la logique	IMSI synthétique dans SRI-for-SM (hlr_imsi_prefix + NSN)

Dépendances de Configuration

Requis dans config/config.exs :

• hlr_service_center_gt_address - Utilisé dans les réponses UpdateLocation
• smsc_service_center_gt_address - Utilisé dans les réponses SRI-for-SM (où envoyer MT-ForwardSM)

Optionnel dans config/config.exs (avec valeurs par défaut) :

• camel_service_key - Par défaut : 11_110
• camel_trigger_detection_point - Par défaut : `