Guide de Configuration HLR

← Retour à la Documentation Principale

Ce guide fournit la configuration pour utiliser OmniSS7 en tant que 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, la provisionnement et les fonctionnalités avancées

Pourquoi OmniHSS ?

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

• Support Multi-IMSI : Chaque abonné peut avoir plusieurs IMSI associés à un seul MSISDN pour le roaming international, le changement de réseau et la provisionnement eSIM
• Authentification Flexible : Support pour les algorithmes d'authentification Milenage (3G/4G/5G) et COMP128 (2G)
• Suivi des Sessions Circuit & Paquet : 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 des sessions 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 de Roaming International : Différents IMSI pour différentes régions afin de réduire les coûts de roaming
• eSIM Multi-Profil : Plusieurs profils réseau sur un seul appareil compatible eSIM
• Changement de Réseau : Changement transparent 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 des abonnés peuvent être partagés ou personnalisés par IMSI
• OmniSS7 interroge OmniHSS par IMSI, et OmniHSS renvoie 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 de Roaming France - auth Milenage)
└─ IMSI 3 : 440201234567891 (Profil de Roaming 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 Roaming
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 les 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 afin 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 et recevoir des opérations MAP
   • hlr_mode_enabled: true : active le traitement 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) indiqué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 complète du HLR (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://omnihss.example.com:8443",

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

  # Configuration de Mapping MSISDN ↔ IMSI
  # Voir : section Mapping 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 des 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 du 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, utiliser la réponse SRI standard
  # Sinon, l'abonné est en roaming et nous devons envoyer PRN pour obtenir MSRN
  # Par défaut, [] (aucun préfixe = tous les VLR traités comme roaming) si omis
  home_vlr_prefixes: ["555123"],

  # Configuration de Connexion M3UA
  # Se connecter 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	String	Requis	Point de terminaison de l'API backend OmniHSS	"https://omnihss.example.com:8443"
hlr_service_center_gt_address	String	Requis	Adresse GT HLR utilisée dans les réponses UpdateLocation	"5551234568"
smsc_service_center_gt_address	String	Requis	Adresse GT SMSc renvoyée dans les réponses SRI-for-SM	"5551234567"
hlr_smsc_alert_gts	Liste	[]	Liste des GT SMSc pour envoyer alertServiceCenter après UpdateLocation	["15559876543", "15559876544"]
hlr_alert_location_expiry_seconds	Integer	172800	Temps d'expiration de localisation (secondes) lorsque le SMSc reçoit alertServiceCenter	86400
hlr_imsi_plmn_prefix	String	"50557"	Préfixe PLMN (MCC+MNC) pour le mapping MSISDN→IMSI (voir MSISDN ↔ IMSI Mapping)	"001001"
hlr_msisdn_country_code	String	"61"	Préfixe de code de pays pour le mapping inverse IMSI→MSISDN (voir MSISDN ↔ IMSI Mapping)	"1"
hlr_msisdn_nsn_offset	Integer	0	Décalage dans MSISDN pour l'extraction NSN (voir MSISDN ↔ IMSI Mapping)	0
hlr_msisdn_nsn_length	Integer	9	Longueur du Numéro d'Abonné National à extraire (voir MSISDN ↔ IMSI Mapping)	10
isd_network_access_mode	Atom	:packetAndCircuit	Mode d'accès réseau pour InsertSubscriberData	:packetOnly
isd_send_ss_data	Boolean	true	Envoyer ISD #2 avec des données de Services Supplémentaires	false
isd_send_call_barring	Boolean	true	Envoyer ISD #3 avec des données de Barrage d'Appels	false
camel_service_key	Integer	11_110	Clé de service CAMEL pour les réponses SendRoutingInfo	100
camel_trigger_detection_point	Atom	: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 VLR traités comme roaming)	["555123"]
local_ip	Tuple	Requis	Adresse IP de votre système HLR	{10, 179, 4, 12}
local_port	Integer	2905	Port SCTP local	2905
remote_ip	Tuple	Requis	Adresse IP STP pour la connectivité SS7	{10, 179, 4, 10}
remote_port	Integer	2905	Port SCTP distant	2905
routing_context	Integer	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 web affichera :

• ✅ Événements SS7 - Journalisation des événements
• ✅ Client SS7 - Test des opérations MAP
• ✅ Pairs - État de la 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 - Visionneuse de configuration

Les onglets Routage, Test de Routage et Liens SMSc seront caché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 backend OmniHSS doit être accessible à l'URL configurée hlr_api_base_url
• Délai d'Expiration de la Requête API : Toutes les requêtes API OmniHSS ont un délai d'expiration codé en dur de 5 secondes
• Délai d'Expiration de la Requête MAP : Toutes les requêtes MAP (SRI, UpdateLocation, SendAuthInfo, etc.) ont un délai d'expiration codé en dur de 10 secondes
• Délai d'Expiration ISD : Chaque message InsertSubscriberData (ISD) dans une séquence UpdateLocation a un délai d'expiration codé en dur de 10 secondes
• La connexion M3UA au STP est requise pour recevoir des opérations MAP
• Après avoir changé de mode, vous devez redémarrer l'application pour que les modifications 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 de roaming, changement de réseau)
• Informations d'authentification : Ki, OPc et sélection d'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'Authentification

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 renvoie au VLR/SGSN demandeur

Intégration de l'API OmniHSS

OmniSS7 communique avec OmniHSS via l'API REST HTTPS pour récupérer des informations sur les 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 des abonnés 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 GT 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 HLR qui est renvoyé 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

Configurer la liste des Titres Globaux SMSc à notifier :

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

  # Temps d'expiration de 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 une mise à jour de localisation :

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 localisation basé sur hlr_alert_location_expiry_seconds
• Suit l'abonné dans le Tracker d'Abonnés du 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 configuration)
   • Le GT SMSc par défaut est la première entrée dans hlr_smsc_alert_gts
   • Le GT HLR par défaut est hlr_service_center_gt_address
4. Cliquez sur "Envoyer alertServiceCenter"

Ceci est utile pour tester la gestion des alertes par le 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 des abonnés au VLR en utilisant des messages InsertSubscriberData (ISD). La configuration ISD vous permet de personnaliser quelles données sont envoyées et comment.

Pour la 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é
   • Statut de l'abonné (serviceGranted)
   • Liste des services de transport
   • Liste des services télématiques
   • Mode d'accès au réseau

2. ISD #2 (Optionnel) - Données des Services Complémentaires (SS) :

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

3. ISD #3 (Optionnel) - Données de Blocage d'Appel :

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

Options de Configuration

# Configuration InsertSubscriberData
# Mode d'accès au réseau : :packetAndCircuit, :packetOnly, ou :circuitOnly
isd_network_access_mode: :packetAndCircuit,

# Envoyer ISD #2 (Données des Services Complémentaires)
isd_send_ss_data: true,

# Envoyer ISD #3 (Données de Blocage d'Appel)
isd_send_call_barring: true,

Mode d'Accès au Réseau

Le paramètre isd_network_access_mode contrôle quel type d'accès au 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 vocaux

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 les données de base + services complémentaires (Pas de blocage d'appel) :

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) - Blocage d'appel [si activé]
VLR → HLR: ISD #3 ACK (CONTINUER)
HLR → VLR: UpdateLocation Response (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/le blocage d'appel pour les dispositifs uniquement de données
• Interopérabilité : Certains VLR plus anciens peuvent ne pas prendre en charge tous les services complé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 demandes SendRoutingInfo (SRI) d'un GMSC (Gateway MSC), le HLR peut instruire le GMSC d'invoquer des services CAMEL pour un routage d'appel intelligent et un contrôle de service.

Pour 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 blocage 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 du 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 d'appel prépayé entrant (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 d'appel prépayé entrant
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 acheminé vers l'abonné
:tBusy	Occupé en terminaison	Lorsque l'abonné est occupé
:tNoAnswer	Pas de réponse en terminaison	Lorsque l'abonné ne répond pas
:tAnswer	Réponse en terminaison	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 occupations (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é
  - Infos 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

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 courante de l'industrie pour les appels prépayés entrants
• Gestion de Repli : defaultCallHandling: :continueCall garantit que les appels se poursuivent si gsmSCF est inaccessible

---

Gestion des Abonnés en Roaming

Détection du VLR Domicile vs VLR en Roaming

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

Pour 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 Roaming : Envoyer une demande de Fourniture de Numéro en Roaming (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 roaming et nous devons envoyer PRN pour obtenir MSRN
home_vlr_prefixes: ["555123"],

Exemple de Configuration :

# Réseau domicile unique
home_vlr_prefixes: ["555123"],

# Réseaux domiciles multiples (par exemple, différentes régions ou filiales)
home_vlr_prefixes: ["555123", "555124", "555125"],

Comment Cela 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 infos 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 Roaming (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" → Roaming
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 infos de routage :
  - IMSI
  - Numéro VLR : "49170123456"
  - Numéro en Roaming (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 Roaming

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

Opération de Fourniture de Numéro en Roaming (PRN)

Structure de Demande PRN

La demande PRN envoyée au MSC/VLR contient :

Champ	Source	Description
MSISDN	Demande 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 roaming (serving_msc)
Adresse GMSC	Demande SRI	GMSC effectuant la demande SRI originale
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 GMSC

Gestion de la Réponse PRN

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

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

Gestion des Erreurs :

• Si le PRN expire → Retourne l'erreur 27 (Abonné Absent) dans la réponse SRI
• Si le PRN échoue → Retourne l'erreur 27 (Abonné Absent) dans la réponse SRI
• Si le 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 → Roaming (PRN + réponse MSRN)

Opérateur Multi-Régions

# Plusieurs réseaux domiciles à 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 → Roaming (international)

Configuration de Test

Pour tester la fonctionnalité PRN, définissez une liste vide pour traiter tous les VLR comme en roaming :

# Tous les VLR sont traités comme en roaming (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 VLR de votre réseau (par exemple, code pays + code réseau)
• Préfixes Multiples : Incluez tous les préfixes VLR de votre réseau, y compris différentes régions et filiales
• Accords de Roaming : Assurez-vous que le PRN est correctement pris en charge par les réseaux partenaires en roaming
• Tests : Testez soigneusement les scénarios domicile et roaming avant le déploiement en production
• Surveillance : Surveillez les taux de dépassement de délai PRN pour identifier les problèmes de connectivité avec les partenaires en roaming

Dépannage

Symptôme : Tous les abonnés traités comme en roaming

• 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 demandes PRN expirent

• Cause : Problèmes de connectivité réseau vers le MSC/VLR partenaire en roaming
• 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 roaming 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 + alerte optionnelle du Service Center)
23	updateGprsLocation	Enregistrer la localisation SGSN (commuté par paquets)
3	cancelLocation	Désinscrire de l'ancien VLR
7	insertSubscriberData	Recevoir le profil de l'abonné (par exemple, lors de l'action en tant que VLR)
22	sendRoutingInfo (SRI)	Fournir MSRN/CAMEL routage pour les appels (domicile vs roaming)
45	sendRoutingInfoForSM (SRI-for-SM)	Fournir IMSI + SMSC GT pour le routage SMS
44	MT-Forward-SM	Livraison de SMS mobile-terminé
46	MO-Forward-SM	Réception de SMS mobile-initié
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 lorsqu'il est activé)
71	anyTimeInterrogation (ATI)	Interrogation de la localisation/état de l'abonné
10	registerSS	Enregistrement de service complémentaire (par exemple, Renvoi d'Appel Inconditionnel)

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

Mappage 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 à 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 roaming :

Réponse Abonné Domicile (Routage CAMEL)

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

Structure de Réponse :

Champ	Source	Description	Exemple
IMSI	API OmniHSS	IMSI de l'abonné provenant de 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 inaccessible	:continueCall

Réponse Abonné en Roaming (Routage MSRN)

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

Structure de Réponse :

Champ	Source	Description	Exemple
IMSI	API OmniHSS	IMSI de l'abonné provenant de 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 en Roaming (MSRN)	Réponse PRN	MSRN obtenu de la demande ProvideRoamingNumber	"49170999888777"

Logique de Décision de Routage :

1. OmniSS7 reçoit la demande SendRoutingInfo
2. OmniSS7 interroge les données de l'abonné depuis l'API OmniHSS
3. OmniSS7 vérifie l'adresse VLR par rapport aux home_vlr_prefixes :

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

   Si VLR ne correspond PAS à un préfixe domicile :
     → Envoyer ProvideRoamingNumber (PRN) au MSC
     → Extraire MSRN de la réponse PRN
     → Retourner les infos de routage avec MSRN (flux abonné en roaming)

Flux de Données :

• OmniSS7 interroge OmniHSS pour des informations sur 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 demande PRN expire (cas de roaming) : Retourne l'erreur 27 (Abonné Absent)
• Si la réponse PRN est invalide (cas de roaming) : Retourne l'erreur 27 (Abonné Absent)

---

Réponse UpdateLocation avec InsertSubscriberData

But : Enregistre l'abonné au 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 ISDs	FIN

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

Champ	Source	Description	Exemple
IMSI	Demande	Provenant de la demande UpdateLocation	"999999876543210"
MSISDN	API OmniHSS	Numéro de téléphone de l'abonné provenant d'OmniHSS	"555123456"
Catégorie	Statique	Catégorie de l'abonné	"\n" (0x0A)
Statut de l'Abonné	Statique	Statut du service	:serviceGranted
Liste des Services de Transport	Statique	Services de transport pris en charge	[<<31>>]
Liste des Services Télématiques	Statique	Télservices pris en charge	[<<17>>, "!", "\""]
Mode d'Accès au Réseau	config.exs	Accès paquets/circuits (isd_network_access_mode)	:packetAndCircuit

InsertSubscriberData #2 (Services Complémentaires) - Optionnel

Champ	Source	Description	Contrôlé Par
SS Provisionnés	Statique	Données des services complémentaires	isd_send_ss_data: true
Renvoi d'Appels	Statique	Configurations de renvoi (inconditionnel, occupé, pas de réponse, non joignable)	Config activé
Attente d'Appel	Statique	Statut du service d'attente d'appel	Config activé
Service Multi-parties	Statique	Support des appels en conférence	Config activé

ISD #2 inclut :

• Renvoi d'appels inconditionnel (code SS 21)
• Renvoi d'appels en cas d'occupation (code SS 41)
• Renvoi d'appels en cas de non réponse (code SS 42)
• Renvoi d'appels en cas de non joignable (code SS 62)
• Attente d'appel (code SS 43)
• Service multi-parties (code SS 51)
• Services CLIP/CLIR

InsertSubscriberData #3 (Blocage d'Appel) - Optionnel

Champ	Source	Description	Contrôlé Par
Infos de Blocage d'Appel	Statique	Configurations de blocage d'appels	isd_send_call_barring: true
BAOC	Statique	Blocage de tous les appels sortants (code SS 146)	Config activé
BOIC	Statique	Blocage des appels internationaux sortants (code SS 147)	Config activé
Données de Restriction d'Accès	Statique	Restrictions d'accès au réseau	Config activé

Contrôle de Séquence ISD:

• ISD #1: Toujours envoyé - Contient des données essentielles sur 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ù acheminer le message.

Le HLR répond dans l'un des deux modes, décidé par le GT de la partie appelante SCCP de la requête :

1. Routage domicile (par défaut : chaque émetteur externe). Ce mode retourne un IMSI synthétique plus le GT propre au IP-SM-GW comme numéro de nœud réseau. Le HLR n'expose jamais de vrais IMSI et nœuds de service aux opérateurs externes. Le MT-ForwardSM revient au IP-SM-GW, qui gère ensuite la livraison. C'est le comportement correct pour le trafic d'interconnexion et d'itinérance.

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

2. Routage direct sur le réseau (uniquement lorsque la requête provient de l'un de nos propres nœuds SMSc / IP-SM-GW). Lorsque le GT appelant correspond à la liste configurée home_smsc_gts, le HLR recherche l'abonné dans son backend et retourne le vrai IMSI et le vrai MSC de service comme numéro de nœud réseau, afin que notre SMSc puisse envoyer le MT-ForwardSM directement au MSC. Si aucun MSC de service n'est disponible pour cet abonné, il revient au routage domicile.

Champ	Source	Description	Exemple
IMSI	Backend HLR	Vrai IMSI de l'abonné	"505570123456789"
Numéro de Nœud Réseau	Backend HLR	Vrai serving_msc de la dernière updateLocation	"5559876543"

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

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

# Routage direct sur le réseau : GTs SCCP appelants de nos propres nœuds SMSc / IP-SM-GW.
# Un SRI-for-SM provenant de l'un de ceux-ci obtient le VRAI MSC de service au lieu du routage domicile.
# Tout le monde est routé à domicile. Laissez vide ([]) pour tout routage à domicile.
home_smsc_gts: ["5551234567"],                 # Optionnel (par défaut [])

# 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 configuration nécessaire !

Remarque : Le routage direct sur le réseau ne fonctionne que si le HLR détient réellement le serving_msc de l'abonné. C'est-à-dire que le MSC de service a effectué un MAP updateLocation vers ce HLR. Si le MSC s'enregistre via un autre mécanisme (par exemple, GSUP vers un HLR séparé), le backend n'a pas la localisation et la requête est routée à domicile.

---

Correspondance MSISDN ↔ IMSI

Paramètres de Configuration:

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

• hlr_imsi_plmn_prefix: Le préfixe MCC+MNC à utiliser lors de la construction des IMSI synthétiques (par exemple, "50557" pour MCC=505, MNC=57)
• hlr_msisdn_country_code: Code de pays à préfixer lors de la réalisation 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ù le Numéro d'Abonné National (NSN) commence dans le MSISDN (typiquement 0 si le MSISDN n'inclut pas le code de pays, ou la longueur du code de pays s'il l'inclut)
• hlr_msisdn_nsn_length: Nombre de chiffres à extraire du MSISDN en tant que NSN

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

Pourquoi la Correspondance MSISDN vers 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 des abonnés avec des correspondances MSISDN vers IMSI, OmniSS7 utilise un schéma d'encodage simple pour calculer des IMSI synthétiques directement à partir du MSISDN. Cette approche offre deux avantages clés :

1. Confidentialité: Les vrais IMSI 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 de requêter 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 Cela Fonctionne:

Les MSISDN sont encodés directement dans la partie 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 Réseau de Test)
• MSISDN: Tous les chiffres numériques du numéro de téléphone
• Zero Padding: Complété par des zéros à gauche pour remplir l'IMSI à exactement 15 chiffres

Exemple Étape par Étape:

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

# Input: 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 abonnée
padded_msisdn = String.pad_leading("555123456", 9, "0")  # = "555123456" (pas de remplissage nécessaire)

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

Exemples Complets:

MSISDN d'Entrée	Préfixe PLMN	Chiffres Abonnés Disponibles	MSISDN Complété	IMSI Final	Remarques
"555123456"	"001001" (6)	9	"555123456"	"001001555123456"	Ajustement exact, pas de remplissage
"99"	"001001" (6)	9	"000000099"	"001001000000099"	Complété par 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:

• MSISDN Courts: Complétés par des zéros (par exemple, "99" → "000000099")
• MSISDN Longs: Les chiffres de droite sont conservés, les chiffres de gauche sont tronqués (par exemple, "91123456789" → "555123456")
• Longueur IMSI: Toujours exactement 15 chiffres

Correspondance Inverse (IMSI → MSISDN):

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

# Input: 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 vrai MSISDN
msisdn = String.replace_leading(subscriber_portion, "0", "")  # = "555123456"

Exemples de Correspondance Inverse:

IMSI d'Entrée	Préfixe PLMN	Portion Abonnée	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éciproque: Peut convertir de l'IMSI au MSISDN
• ✅ Configuration Minimale: Nécessite uniquement hlr_imsi_plmn_prefix
• ✅ Préservation de la Confidentialité: Les vrais IMSI 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. Extraction des Chiffres: Conserver uniquement les chiffres numériques, supprimer tout caractère non numérique
3. Normalisation: Si plus long que l'espace disponible, prendre les chiffres de droite ; si plus court, compléter par des zéros
4. Encodage: 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 uniquement à des fins de routage. Ils ne sont PAS les vrais IMSIs stockés dans la base de données des abonnés HLR. Cela fournit une couche supplémentaire de protection 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"
   - Extraction des chiffres: "91123456789" (11 chiffres)
   - Ajustement à 9 chiffres: "555123456" (9 de droite)
   - Ajout de PLMN: "001001" + "555123456" = "001001555123456"
   - Obtenir le GT du SMSC à partir de 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 de pays)
hlr_msisdn_country_code: "1",      # Utilisé pour la correspondance inverse (IMSI→MSISDN)
hlr_msisdn_nsn_offset: 1,          # Ignorer le code de pays d'un chiffre
hlr_msisdn_nsn_length: 10          # Extraire le NSN de 10 chiffres

Configuration d'Extraction NSN:

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

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

Exemples:

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

Comment Cela Fonctionne:

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

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

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

   IMSI: "547050088000088"
   Portion Abonnée: "088000088"
   Supprimer les zéros: "88000088"
   MSISDN: "+999" + "88000088" = "+99988000088"

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

Résumé des Sources de Champ

Type de Source	Description	Exemples
API OmniHSS	Données dynamiques de la base de données des abonnés OmniHSS	IMSI, MSISDN, VLR/MSC de service à partir de 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	Statut de l'abonné, services de support, codes SS
Requête	Champs extraits de la requête MAP entrante	IMSI de UpdateLocation, MSISDN de SRI
Calculé	Valeurs dérivées à l'aide de 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ù MT-ForwardSM doit être routé)

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 : :termAttemptAuthorized
• isd_network_access_mode - Par défaut : :packetAndCircuit
• isd_send_ss_data - Par défaut : true
• isd_send_call_barring - Par défaut : true
• hlr_imsi_plmn_prefix - Par défaut : "001001" (préfixe PLMN pour la correspondance MSISDN↔IMSI)

Requis de la part d'OmniHSS:

OmniHSS doit fournir des points de terminaison API REST pour :

• Recherche d'abonné par IMSI et MSISDN
• Mises à jour de localisation de session de circuit (assignation VLR/MSC)
• Génération de vecteurs d'authentification
• Requêtes de statut d'abonné et de profil de service

---

Documentation Connexe

Documentation OmniSS7 :

• ← Retour à la Documentation Principale
• Guide des Fonctionnalités Communes
• Guide du Client MAP
• Référence Technique
• Référence de Configuration

Documentation OmniHSS : Pour la gestion des abonnés, la configuration de provisionnement, d'authentification, et les opérations administratives, référez-vous à la documentation produit OmniHSS. OmniHSS contient toute la logique de base de données des abonnés, les algorithmes d'authentification, les règles de provisionnement de service, et les capacités de gestion Multi-IMSI.

---

OmniSS7 par Omnitouch Network Services