Guide de Configuration HLR

← Retour à la Documentation Principale

Ce guide fournit la configuration pour utiliser OmniSS7 comme un Home Location Register (HLR/HSS) avec OmniHSS comme base de données d'abonnés en 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, le provisioning 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 le provisioning eSIM
• Authentification Flexible : Support pour les algorithmes d'authentification Milenage (3G/4G/5G) et COMP128 (2G)
• Suivi des Sessions Circuits & Paquets : Suivi indépendant des enregistrements réseau CS (circuit-switched) et PS (packet-switched)
• Provisioning 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 provisioning
• 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 comme 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 provisioning 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 provisioning 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-Profile : 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 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 retourne les données appropriées de l'abonné
• 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 de Roaming France - Authentification Milenage)
└─ IMSI 3 : 440201234567891 (Profil de Roaming 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 assure une authentification et un provisioning 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 provenant 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. Ouvrez config/runtime.exs
2. Trouvez 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. Commentez la configuration actuellement active (ajoutez # à chaque ligne)
4. Décommentez la configuration HLR (supprimez # des lignes 87-123)
5. Personnalisez les paramètres de configuration selon vos besoins
6. Redémarrez l'application : iex -S mix

Configuration du Mode HLR

La configuration HLR complète ressemble à ceci :

config :omniss7,
  # Flags 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 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 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, utilisez la réponse SRI standard
  # Sinon, l'abonné est en roaming 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 d'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 retournée dans les réponses SRI-for-SM	"5551234567"
hlr_smsc_alert_gts	Liste	[]	Liste des GTs SMSc pour envoyer alertServiceCenter après UpdateLocation	["15559876543", "15559876544"]
hlr_alert_location_expiry_seconds	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 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	["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 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 codé en dur de 5 secondes
• Délai d'Attente des Requêtes MAP : Toutes les requêtes MAP (SRI, UpdateLocation, SendAuthInfo, etc.) ont un délai d'attente codé en dur de 10 secondes
• Délai d'ISD : Chaque message InsertSubscriberData (ISD) dans une séquence UpdateLocation a un délai d'attente codé en dur de 10 secondes
• La connexion M3UA au STP est requise pour recevoir les opérations MAP
• Après avoir changé de modes, 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 : 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'information de localisation actuelle 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 retourne 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 de l'abonné par IMSI ou MSISDN
• Générer des vecteurs d'authentification en utilisant les informations Ki/OPc stockées
• Mettre à jour la localisation de la session circuit lorsque les abonnés effectuent UpdateLocation
• Vérifier l'état de l'abonné et les droits de service

---

Mises à Jour de Localisation

Traitement de la Mise à Jour de Localisation

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

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

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

Intégration du Centre de Service d'Alerte

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

Configuration

Configurez la liste des Global Titles 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 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/location)
• Définit le champ user_agent sur le GT HLR lors de l'appel à l'API (pour le suivi de 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 les tests :

1. Accédez à l'onglet "Abonnés Actifs"
2. Trouvez la section "Tester le Centre de Service d'Alerte"
3. Entrez MSISDN, GT SMSc et GT HLR (les valeurs par défaut sont pré-remplies à partir de la config)
   • GT SMSc par défaut est la première entrée dans hlr_smsc_alert_gts
   • 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 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 provisioning 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é
   • État de l'abonné (serviceGranted)
   • Liste des services de support
   • Liste des téléservices
   • Mode d'accès réseau

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

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

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

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

Options de Configuration

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

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

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

Mode d'Accès Réseau

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

Valeur	Description	Cas d'Utilisation
:packetAndCircuit	À la fois commuté par paquets (GPRS/LTE) et commuté par circuits (voix)	Par défaut - Abonnés à service complet
:packetOnly	Commuté par paquets uniquement (données/LTE)	Cartes SIM uniquement pour données, 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é (Provisioning minimal) :

isd_send_ss_data: false,
isd_send_call_barring: false,

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

isd_send_ss_data: true,
isd_send_call_barring: false,

Exemple de Flux ISD

Lorsqu'une mise à jour de localisation est reçue :

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

Si isd_send_ss_data ou isd_send_call_barring sont définis sur false, ces messages ISD sont ignorés, et la FIN de la mise à jour de localisation 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 pour données
• Interopérabilité : Certains VLR plus anciens 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 la 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 des appels entrants prépayés (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 des appels entrants prépayés
camel_service_key: 11_110,

# Pour le service VPN
camel_service_key: 300,

Point de Détection de Déclenchement

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

Point de Détection	Description	Quand Déclenché
:termAttemptAuthorized	Tentative d'appel autorisée (par défaut)	Avant que l'appel ne soit routé vers l'abonné
:tBusy	Occupé à la terminaison	Lorsque l'abonné est occupé
:tNoAnswer	Pas de réponse à la terminaison	Lorsque l'abonné ne répond pas
:tAnswer	Réponse à la 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

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

Meilleures Pratiques

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

---

Gestion des Abonnés en Roaming

Détection VLR à Domicile vs VLR en Roaming

Lorsque le HLR reçoit une requête SendRoutingInfo (SRI), il doit déterminer si l'abonné est sur un VLR "domestique" (dans 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 la 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 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, 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 :

# 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 Ça 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 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 à aucun 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" → 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 Provide Roaming Number (PRN)

Structure de la Requête PRN

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

Champ	Source	Description
MSISDN	Requête SRI	Numéro de téléphone de l'abonné
IMSI	API HLR	IMSI de l'abonné
Numéro MSC	API HLR	MSC servant l'abonné en roaming (serving_msc)
Adresse GMSC	Requête SRI	GMSC effectuant la requête 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 le GMSC

Gestion de la Réponse PRN

Le HLR attend une réponse PRN contenant :

• MSRN (Numéro de Roaming de la 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 → Roaming (PRN + réponse MSRN)

Opérateur Multi-Région

# Plusieurs réseaux domestiques dans 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)
• Multiples Préfixes : 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 à la fois les scénarios domestiques et en roaming de manière approfondie avant le déploiement en production
• Surveillance : Surveillez les taux de délai d'attente du 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 correspondant 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 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 correspondant 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'auth
• sendRoutingInfo (Opcode 22) - Fournir MSRN pour les appels avec support CAMEL
• sendRoutingInfoForSM (Opcode 45) - Fournir GT MSC pour SMS
• cancelLocation (Opcode 3) - Désenregistrer du VLR ancien
• insertSubscriberData (Opcode 7) - Pousser le profil de l'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 vers 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 roaming :

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 de phase CAMEL	3
Gestion des Appels par Défaut	Statique	Repli si gsmSCF injoignable	:continueCall

Réponse Abonné en Roaming (Routage MSRN)

Utilisé lorsque l'adresse VLR de l'abonné ne correspond à aucun préfixe home_vlr_prefixes configuré.

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 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 un préfixe domestique :
     → Retourner les infos de routage CAMEL (flux abonné domestique)

   Si le VLR ne correspond à aucun préfixe domestique :
     → Envoyer ProvideRoamingNumber (PRN) au MSC
     → Extraire le 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 les informations sur l'abonné
• OmniHSS retourne IMSI, localisation actuelle VLR/MSC et é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 en roaming) : Retourne l'erreur 27 (Abonné Absent)
• Si la réponse PRN est invalide (cas en roaming) : 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	Global Title 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 de Support	Statique	Services de support pris en charge	[<&lt;31>>]
Liste des Téléservices	Statique	Téléservices pris en charge	[<&lt;17>>, "!", "\""]
Mode d'Accès Réseau	runtime.exs	Accès par 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	Configurations de transfert (inconditionnel, occupé, pas de réponse, non joignable)	Config activé
Appel en Attente	Statique	État du service d'appel en attente	Config activé
Service Multi-Parties	Statique	Support d'appel conférence	Config activé

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)
• Appel en attente (code SS 43)
• Service multi-parties (code SS 51)
• Services CLIP/CLIR

InsertSubscriberData #3 (Barrage d'Appels) - Optionnel

Champ	Source	Description	Contrôlé Par
Infos 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é
BOIC	Statique	Barrage 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 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 Noeud Réseau	runtime.exs	Adresse GT SMSC pour le routage SMS	smsc_service_center_gt_address	"5551234567"

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

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

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

---

Mapping 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 du mapping 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 Mapping MSISDN ↔ IMSI dans la Référence de Configuration.

Pourquoi le Mapping MSISDN vers IMSI est-il 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 (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 mappings MSISDN vers IMSI, OmniSS7 utilise un schéma d'encodage simple pour calculer des IMSI synthétiques directement à partir des MSISDN. Cette approche offre deux avantages clés :

1. Confidentialité : Les véritables 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 d'interroger la base de données HLR pour les recherches IMSI lors des opérations SRI-for-SM - l'IMSI est calculé à la volée à partir du MSISDN

Comment Ça Fonctionne :

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

IMSI = PLMN_PREFIX + zero_padded_MSISDN

Où :

• PLMN_PREFIX : MCC + MNC (par exemple, "001001" pour 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

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

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

# Étape 2 : Compléter le MSISDN avec des zéros pour remplir la portion d'abonné
padded_msisdn = String.pad_leading("555123456", 9, "0")  # = "555123456" (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 d'Abonné 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 à gauche (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

Mapping Inverse (IMSI → MSISDN) :

Le SMSc peut inverser ce mapping 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 Mapping Inverse :

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

Propriétés de Ce Mapping :

• ✅ Déterministe : Le même MSISDN produit toujours le même IMSI
• ✅ Récupérable : Peut être converti en retour de IMSI à MSISDN
• ✅ Configuration Minimale : Nécessite uniquement hlr_imsi_plmn_prefix
• ✅ Préservation de la Confidentialité : Les véritables IMSI 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 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 tout caractère non numérique
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 retourné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 supplémentaire de protection de la vie privée, 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 depuis la config : "5551234567"

3. HLR → SMSc: Réponse SRI-for-SM
   - IMSI : "001001555123456" (synthétique, toujours 15 chiffres)
   - Numéro de Noeud 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 le mapping 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 simplement "88000088"), vous devez configurer l'extraction NSN :

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

Exemples :

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

Comment Ça Fonctionne :

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

   MSISDN : "99988000088"
   NSN : String.slice("99988000088", 3, 8) = "88000088"
   MSISDN 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 d'Abonné : "088000088"
   Supprimer les zéros : "88000088"
   MSISDN : "+999" + "88000088" = "+99988000088"

Exigences de l'API : Aucune - SRI-for-SM utilise des valeurs calculées et la config uniquement. 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 provenant de la base de données des abonnés OmniHSS	IMSI, MSISDN, VLR/MSC servant depuis 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 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 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 le mapping MSISDN↔IMSI)

Requis de la part d'OmniHSS :

OmniHSS doit fournir des points d'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 provisioning, 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 provisioning de service et les capacités de gestion Multi-IMSI.

---

OmniSS7 par Omnitouch Network Services