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 backend.

Intégration OmniHSS

Le mode HLR d'OmniSS7 fonctionne comme un frontend de signalisation SS7 qui interagit 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 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 de réseau CS (circuit-switched) et PS (packet-switched)
• 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 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 de 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 cela fonctionne :

• Chaque IMSI a ses propres informations d'authentification (Ki, OPc, algorithme)
• Chaque IMSI peut avoir des enregistrements de sessions circuits et paquets 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 National US - authentification Milenage)
├─ IMSI 2 : 208011234567890 (Profil d'Itinérance France - authentification Milenage)
└─ IMSI 3 : 440201234567891 (Profil d'Itinérance UK - authentification 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 les SMS

Architecture HLR

---

Activation du Mode HLR

OmniSS7 peut fonctionner en différents modes. Pour l'utiliser comme HLR, vous devez activer le mode HLR dans la configuration.

Changement vers le Mode HLR

Le fichier config/runtime.exs d'OmniSS7 contient trois modes opérationnels préconfigurés. Pour activer le mode HLR :

1. Ouvrir config/runtime.exs
2. Trouver les trois sections de configuration (lignes 53-174) :
   • Configuration 1 : Mode STP (lignes 53-85)
   • Configuration 2 : Mode HLR (lignes 87-123)
   • Configuration 3 : Mode SMSc (lignes 125-174)
3. Commenter la configuration actuellement active (ajouter # à chaque ligne)
4. Décommenter la configuration HLR (retirer # des lignes 87-123)
5. Personnaliser les paramètres de configuration selon les besoins
6. Redémarrer l'application : iex -S mix

Configuration du Mode HLR

La configuration complète HLR 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 de 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 "domestique"
  # 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 itinérance et nous devons envoyer PRN pour obtenir MSRN
  home_vlr_prefixes: ["123456"],

  # Configuration de Connexion M3UA
  # Se connecter en tant qu'ASP pour recevoir les 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	OmniHSS point de terminaison API backend	"https://10.179.3.219: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	List	[]	Liste des GTs SMSc pour envoyer alertServiceCenter après UpdateLocation	["15559876543", "15559876544"]
hlr_alert_location_expiry_seconds	Integer	172800	Temps d'expiration de localisation (secondes) lorsque SMSc reçoit alertServiceCenter	86400
hlr_imsi_plmn_prefix	String	"50557"	Préfixe PLMN (MCC+MNC) pour la correspondance MSISDN→IMSI (voir MSISDN ↔ IMSI Mapping)	"001001"
hlr_msisdn_country_code	String	"61"	Préfixe de code de pays pour la correspondance 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	List	["5551231"]	Liste des préfixes d'adresses VLR considérés comme réseau "domestique"	["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
• ✅ M3UA - État de la connexion
• ✅ 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 cach��s.

Notes 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 backend 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 les opérations MAP
• Après avoir changé de mode, 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 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 : Transfert 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 d'authentification 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 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 d'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 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 des Mises à 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 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 manière 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 GTs SMSc pour envoyer alertServiceCenter après UpdateLocation
  hlr_smsc_alert_gts: [
    "15559876543",
    "15559876544"
  ],

  # Temps d'expiration de localisation lorsque 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/location)
• 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 le premier élément de hlr_smsc_alert_gts
   • Le GT HLR par défaut est hlr_service_center_gt_address
4. Cliquez sur "Envoyer alertServiceCenter"

Cela est utile pour tester la gestion des alertes SMSc sans nécessiter un flux complet de UpdateLocation. 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 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 porteurs
   • 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 transfert 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 de données, appareils IoT
:circuitOnly	Commuté par circuits uniquement (voix/SMS)	Appareils anciens, plans uniquement vocaux

Contrôle des Messages ISD

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

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

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 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 réglés sur false, ces messages ISD sont ignorés, et la FIN de UpdateLocation est envoyée plus tôt.

Meilleures Pratiques

• Configuration par Défaut : Utilisez :packetAndCircuit et activez tous les ISD pour une compatibilité maximale
• IoT/M2M : Utilisez :packetOnly et désactivez les données SS/barrage d'appels pour les appareils uniquement de données
• Interopérabilité : Certains anciens VLR peuvent ne pas prendre en charge tous les services supplémentaires - désactivez isd_send_ss_data si vous rencontrez des problèmes
• Performance : Désactiver les ISD 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 demander au GMSC d'invoquer des services CAMEL pour un routage d'appels 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 barrage d'appels
• Réseaux Privés Virtuels (VPN)
• Services à tarif premium
• Transfert 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 d'appel prépayé entrant (par défaut)
100	Service prépayé d'origine
200	Transfert 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 routé 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 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 le 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 prépayés entrants
• Gestion des Retours : defaultCallHandling: :continueCall garantit que les appels se poursuivent si le gsmSCF est injoignable

---

Gestion des Abonnés en Itinérance

Détection du 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 "domestique" (au sein de 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 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 "domestique"
# Si l'adresse VLR de l'abonné commence par l'un de ces préfixes, utiliser 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 domestique
home_vlr_prefixes: ["555123"],

# Plusieurs opérateurs de réseau domestique (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 domestique 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 domestique
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 domestique :

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 en 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 la requête PRN
    }
  },
  subscriberInfo: %{
    locationInformation: %{"vlr-number": "49170123456"},
    subscriberState: {:notProvidedFromVLR, :NULL}
  }
}

Opération Provide Roaming Number (PRN)

Structure de 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 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 Domestique Unique

# Tous les adresses VLR commençant par "555123" sont considérées comme domestiques
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 domestiques à 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 VLR comme en itinérance :

# Tous les VLR sont traités comme en itinérance (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 d'Itinérance : Assurez-vous que le PRN est correctement pris en charge par les réseaux partenaires en itinérance
• Tests : Testez soigneusement les scénarios domestiques et en itinérance avant le déploiement en production
• Surveillance : Surveillez les taux de délai d'attente 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 en itinérance

• 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 : Le 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

• updateLocation (Opcode 2) - Enregistrer la localisation VLR
• sendAuthenticationInfo (Opcode 56) - Générer des vecteurs d'authentification
• sendRoutingInfo (Opcode 22) - Fournir MSRN pour les appels avec support CAMEL
• sendRoutingInfoForSM (Opcode 45) - Fournir GT MSC pour les SMS
• cancelLocation (Opcode 3) - Désenregistrer du vieux VLR
• insertSubscriberData (Opcode 7) - Pousser le profil d'abonné

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 à un abonné.

Le HLR fournit deux types de réponses différents en fonction de si l'abonné est sur un VLR domestique 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 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	runtime.exs	Identifiant de service CAMEL (camel_service_key)	11_110
Point de Détection de Déclenchement	runtime.exs	Quand déclencher CAMEL (camel_trigger_detection_point)	:termAttemptAuthorized
Gestion des Capacités CAMEL	Statique	Niveau de support des phases CAMEL	3
Gestion des Appels par Défaut	Statique	Retour 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 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 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 par rapport aux home_vlr_prefixes :

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

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

Flux de Données :

• OmniSS7 interroge OmniHSS pour les informations sur l'abonné
• OmniHSS renvoie 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 runtime.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 d'itinérance) : Retourne l'erreur 27 (Abonné Absent)
• Si la réponse PRN est invalide (cas d'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	runtime.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	Provenant de la requête UpdateLocation	"999999876543210"
MSISDN	API OmniHSS	Numéro de téléphone de l'abonné provenant d'OmniHSS	"555123456"
Catégorie	Statique	Catégorie d'abonné	"\n" (0x0A)
État de l'Abonné	Statique	État de service	:serviceGranted
Liste des Services Porteurs	Statique	Services porteurs 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	runtime.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 des services supplémentaires	isd_send_ss_data: true
Transfert d'Appels	Statique	Paramètres de transfert (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

ISD #2 inclut :

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

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 (code SS 146)	Config activée
BOIC	Statique	Barrage des Appels Internationaux Sortants (code SS 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 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 runtime.exs
• ISD #3 : Envoyé uniquement si isd_send_call_barring: true dans runtime.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 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	runtime.exs	Adresse GT du SMSC pour le routage SMS	smsc_service_center_gt_address	"5551234567"

Paramètres de Configuration (provenant de runtime.exs) :

# Adresse du Centre de Service GT (renvoyé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 configuration nécessaire !

---

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 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 d'Abonné National (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 vers IMSI est-elle N��cessaire ?

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

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 renvoie 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 vers IMSI, OmniSS7 utilise un schéma d'encodage simple pour calculer les IMSIs synthétiques directement à partir des MSISDN. Cette approche offre deux avantages clés :

1. Confidentialité : Les véritables 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 des 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ée de l'IMSI (les chiffres après MCC+MNC) :

IMSI = PLMN_PREFIX + MSISDN avec zéros ajoutés

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
• Ajout de Zéros : 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

# 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 abonnée
padded_msisdn = String.pad_leading("555123456", 9, "0")  # = "555123456" (aucun 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 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é 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 de l'IMSI : Toujours exactement 15 chiffres

Gestion de la Correspondance Inverse (IMSI → MSISDN) :

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

# 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 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é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 véritables IMSIs ne sont jamais exposés
• ✅ Aucune 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 de droite ; si plus court, compléter par des zéros
4. Encoder : Concaténer le préfixe PLMN + MSISDN normalisé

Considérations de Sécurité :

Les IMSIs synthétiques renvoyés dans les réponses SRI-for-SM sont uniquement à des fins de routage. Ils ne sont PAS les véritables IMSIs stockés dans la base de données des abonnés HLR. Cela fournit une couche de protection supplémentaire de la confidentialité, car les véritables 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 véritables 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)
   - Adapter à 9 chiffres : "555123456" (9 chiffres de droite)
   - Ajouter PLMN : "001001" + "555123456" = "001001555123456"
   - Obtenir GT SMSC à partir de la configuration : "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 runtime.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 du 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	Exemple MSISDN	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 Cela Fonctionne :

1. MSISDN → IMSI : Extraire le NSN du MSISDN, compléter par des zéros, 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, supprimer les zéros à gauche, préfixer le code pays

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

Exigences API : Aucune - SRI-for-SM utilise uniquement des valeurs calculées et des configurations. Aucun appel à la base de données 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 à partir de circuit_session
runtime.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 porteurs, codes SS
Requête	Champs extraits de la requête MAP entrante	IMSI de UpdateLocation, MSISDN de 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 runtime.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ù les MT-ForwardSM doivent être routés)

Optionnel dans runtime.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 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 circuit (assignation VLR/MSC)
• Génération de vecteurs d'authentification
• Requêtes sur l'état de l'abonné et les profils de service

---

Documentation Connexe

Documentation OmniSS7 :

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

Documentation OmniHSS : Pour la gestion des abonnés, le provisionnement, la configuration de l'authentification et les opérations administratives, reportez-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