Aller au contenu principal

Interface Sh (Récupération des données d'abonné)

📖 Retour à la documentation principale

L'interface Sh fournit un accès aux données de profil d'abonné depuis le HSS/Référentiel via Diameter.

Documentation associée​

Documentation de base​

Intégration du traitement des appels​

Interfaces associées​

Surveillance​

Interface Sh (Récupération des données d'abonné)​

L'interface Sh est utilisée pour récupérer les données de profil d'abonné depuis le HSS/Référentiel avant le traitement des appels. Ces données incluent les identités des abonnés, les services et la configuration MMTel.

Qu'est-ce que l'interface Sh ?​

L'interface Sh est une interface Diameter standardisée par la 3GPP entre le TAS et le HSS/Référentiel (Repo). Elle fournit un accès en temps réel à :

  • Identités d'abonné IMS (IMPI/IMPU)
  • Paramètres de renvoi d'appels (MMTel-Config)
  • Autorisation de service d'abonné
  • Attribution S-CSCF

Quand les recherches Sh se produisent​

Les recherches Sh se produisent sur :

  • Appels MT : Recherche de la partie appelée (abonné de destination)
  • Appels MO : Recherche de la partie appelante (abonné source)
  • Appels d'urgence : Recherche de la partie appelante (pour la localisation/l'identité)

Dans tous les cas, le TAS émet exactement une UDR par jambe d'appel. Les appels MO et MT utilisent la même forme d'UDR multi-Data-Reference — seules les étiquettes métriques diffèrent.

UDR multi-Data-Reference (Notif-Eff)​

Selon la 3GPP TS 29.328 §6.1.1.1, lorsque l'AS et le HSS prennent en charge la fonctionnalité Notif-Eff (négociée via l'AVP Supported-Features), une seule UDR peut contenir plusieurs AVP Data-Reference et le HSS répond avec un UDA dont le User-Data-Sh est un document <Sh-Data> unique concaténant les sous-arbres par référence en tant que frères. Le TAS s'appuie sur cela — chaque recherche Sh récupère l'ensemble complet des références que le système sait consommer en un aller-retour.

Références de données demandées (TS 29.328 Tableau 7.6.1)​

RefÉlémentUtilisé par TAS pour peupler
0RepositoryData (avec Service-Indication = "MMTEL-Services")call_forward_all_destination, call_forward_not_reachable_destination, no_reply_timer
10IMSPublicIdentityims_public_identity, msisdn
11IMSUserStateims_user_state (valeur énumérée brute de TS 29.328 §7.6.3)
12SCSCFNamescscf_address, scscf_domain
13InitialFilterCriteria(corps retourné au TAS mais pas actuellement exposé comme variable de plan de numérotation)
14LocationInformationlocation_rat_type, location_mme_name, location_vplmn_id, location_age_seconds
15UserStateuser_state (valeur énumérée brute de TS 29.328 §7.6.7)
17MSISDN(vérifié par rapport à l'IMPU)
32IMSIimsi
33IMSPrivateUserIdentityims_private_identity, ims_domain (analysé à partir du suffixe)

Tous les champs à chaîne unique sont exposés au plan de numérotation en tant que variables de chaîne brutes — le TAS n'interprète pas leurs valeurs. Voir le tableau Variables de plan de numérotation définies à partir des données Sh ci-dessous pour la liste complète.

Exemple de corps UDA (sanitisé)​

Une réponse fusionnée réussie dans la trace en direct ressemble à ceci — les sous-arbres par référence apparaissent sous un seul wrapper <Sh-Data> dans l'ordre dans lequel les références ont été demandées :

[debug] Données de l'appelant récupérées pour +614xxxxxxxx
        (Data-Ref [0, 10, 11, 12, 13, 14, 15, 17, 32, 33],
         SI="MMTEL-Services"): 4453 bytes

<?xml version="1.0" encoding="UTF-8"?>
<Sh-Data>
  <RepositoryData></RepositoryData>
  <PublicIdentifiers>
    <IMSPublicIdentity>sip:+614xxxxxxxx@ims.mnc001.mcc999.3gppnetwork.org</IMSPublicIdentity>
    <IMSPublicIdentity>tel:+614xxxxxxxx</IMSPublicIdentity>
  </PublicIdentifiers>
  <ShIMSData>
    <IMSUserState>1</IMSUserState>
  </ShIMSData>
  <ShIMSData>
    <SCSCFName>sip:scscf01.ims.mnc001.mcc999.3gppnetwork.org:5060</SCSCFName>
  </ShIMSData>
  <IMSSubscription>
    <PrivateID>9999990000xxxxx@ims.mnc001.mcc999.3gppnetwork.org</PrivateID>
    <ServiceProfile>
      ... Entrées InitialFilterCriteria ...
    </ServiceProfile>
  </IMSSubscription>
  <ShIMSData>
    <LocationInformation>
      <RAT-Type>eutran</RAT-Type>
      <MMEName>mme01.epc.mnc001.mcc999.3gppnetwork.org</MMEName>
      <VPLMNId>999001</VPLMNId>
      <AgeOfLocationInformation>NNNN</AgeOfLocationInformation>
    </LocationInformation>
  </ShIMSData>
  <IMSPrivateUserIdentity>9999990000xxxxx@ims.mnc001.mcc999.3gppnetwork.org</IMSPrivateUserIdentity>
</Sh-Data>

Comment les analyseurs consomment le corps fusionné​

Le TAS ne parcourt pas l'arbre XML. Chaque analyseur par référence est indépendant et basé sur des tags : il recherche dans le corps fusionné un nom d'élément spécifique (par exemple <SCSCFName>, <IMSPublicIdentity>, <CallForwardUnconditional>, <CallForwardNoReplyTimer>, le bloc cp:rule not-reachable) et extrait uniquement la valeur qui l'intéresse. Les sous-arbres que l'analyseur ne reconnaît pas sont silencieusement ignorés.

Le résultat de chaque analyseur est une carte de données d'abonné partielle ; les parties sont fusionnées dans l'ordre sur une carte de valeurs par défaut. Cela rend la recherche robuste face aux implémentations HSS hétérogènes et aux réponses partielles — voir la section dégradations gracieuses ci-dessous.

Données récupérées de l'interface Sh​

Le TAS émet une seule UDR multi-Data-Reference par jambe d'appel (voir UDR multi-Data-Reference (Notif-Eff) ci-dessus pour la forme de la demande et la réponse fusionnée). Les champs que le TAS extrait du corps fusionné <Sh-Data> se répartissent en trois groupes :

1. Identités IMS :

  • IMPI (Identité Privée) : analysé à partir de l'élément <IMSPrivateUserIdentity>. Format : {IMSI}@{IMS-domain}. Le TAS divise sur @ pour récupérer l'IMSI et le domaine IMS indépendamment.
  • IMPU (Identité Publique) : analysé à partir de l'élément <IMSPublicIdentity>. Format : sip:+{MSISDN}@{IMS-domain}. Le MSISDN est dépouillé du préfixe + et exposé comme la variable de plan de numérotation msisdn.

2. Attribution S-CSCF :

  • Nom et domaine du serveur S-CSCF où l'abonné est actuellement enregistré, analysés à partir de l'élément <SCSCFName> (Data-Reference 12). Utilisé par le MT plan de numérotation pour acheminer l'INVITE directement vers le S-CSCF enregistré plutôt que de se répandre dans le domaine IMS.
  • Remarque : le nom d'élément XML canonique dans l'Annexe D de la TS 29.328 est SCSCFName (sans tiret). La forme avec tiret "S-CSCF" n'apparaît que dans le texte de spécification.

3. Services MMTel (Configuration de téléphonie multimédia) :

  • Retourné à l'intérieur de <RepositoryData> indexé par Service-Indication = "MMTEL-Services".
  • Règles de renvoi d'appels spécifiques à l'abonné :
    • Renvoi d'appels tous (CFA) : Renvoi inconditionnel vers un autre numéro
    • Renvoi d'appels occupé (CFB) : Renvoi lorsque l'abonné est occupé
    • Renvoi d'appels sans réponse (CFNRy) : Renvoi après un délai d'attente (valeur du minuteur extraite de <CallForwardNoReplyTimer>)
    • Renvoi d'appels non joignable (CFNRc) : Renvoi lorsque l'abonné est hors ligne/non enregistré (extrait du bloc not-reachable <cp:rule> à l'intérieur du document de référentiel MMTel)

Qu'est-ce que MMTel-Config ?​

MMTel-Config est la configuration du service de téléphonie multimédia de l'abonné stockée en tant que données transparentes (référentiel) dans le HSS, indexée par Service-Indication = "MMTEL-Services". Elle est récupérée dans le cadre de la même UDR multi-Data-Reference que la recherche d'identité (Data-Reference 0 plus l'AVP d'indication de service). Le document suit le schéma OMA / 3GPP simservs XCAP et contient généralement un bloc complete-communication-diversion avec une ou plusieurs entrées cp:rule (busy, noanswer, unregistered, notreachable), une valeur <NoReplyTimer> optionnelle, et d'autres sous-services MMTel tels que la restriction de communication et la présentation d'identité.

Services MMTel communs que le TAS reconnaît :

  • CDIV (Communication Diversion) : Règles de renvoi d'appels — le seul bloc actuellement analysé de bout en bout dans les variables de plan de numérotation. Le règle notreachable remplit call_forward_not_reachable_destination et <NoReplyTimer> remplit no_reply_timer.
  • OIP (Originating Identity Presentation) : Règles de présentation de l'identité de l'appelant (retournées dans le corps mais pas actuellement consommées).
  • TIP (Terminating Identity Presentation) : Règles de numéro de la partie appelée (retournées dans le corps mais pas actuellement consommées).

Variables de plan de numérotation définies à partir des données Sh​

Après une recherche Sh réussie, ces variables sont peuplées :

VariableSourceExemple de valeurDescription
ims_private_identityIMPI9999990000xxxxx@ims.mnc001.mcc999.3gppnetwork.orgIdentité utilisateur privée pour l'authentification
ims_public_identityIMPUsip:+614xxxxxxxx@ims.mnc001.mcc999.3gppnetwork.orgIdentité utilisateur publique pour le routage
msisdnIMPU (analysé)614xxxxxxxxNuméro d'abonné (préfixe + supprimé)
imsiIMPI (analysé)9999990000xxxxxIMSI de l'identité privée
ims_domainIMPI/IMPUims.mnc001.mcc999.3gppnetwork.orgDomaine IMS
scscf_addressSCSCFNamesip:scscf01.ims.mnc001.mcc999.3gppnetwork.org:5060 ou "none"Adresse du serveur S-CSCF (enregistré)
scscf_domainSCSCFName (analysé)scscf01.ims.mnc001.mcc999.3gppnetwork.org ou "none"Hôte S-CSCF (enregistré)
call_forward_all_destinationMMTel CDIVnumérique ou "none"Numéro de destination CFA
call_forward_not_reachable_destinationMMTel CDIVnumérique ou valeur par défaut de configurationDestination CFNRc (messagerie vocale)
no_reply_timerMMTel CDIVsecondes, ou valeur par défaut de configurationDélai avant que CFNRy ne s'active
ims_user_stateIMSUserState (Data-Ref 11)"0"/"1"/"2"/"3" ou "none"État d'enregistrement IMS enum. 1 = ENREGISTRÉ, 0 = NON_ENREGISTRÉ, 2 = AUTHENTIFICATION_EN_COURS, 3 = ENREGISTRÉ_SERVICES_NON_ENREGISTRÉS (TS 29.328 §7.6.3). Chaîne brute, le TAS n'interprète pas.
user_stateUserState (Data-Ref 15)chaîne brute ou "none"État utilisateur CS/PS (TS 29.328 §7.6.7). Chaîne brute, le TAS n'interprète pas.
location_rat_typeLocationInformation/RAT-Type"eutran", "utran", "geran", "wlan", ... ou "none"Technologie d'accès radio de la dernière inscription connue.
location_mme_nameLocationInformation/MMENameFQDN MME ou "none"Hôte MME servant l'abonné.
location_vplmn_idLocationInformation/VPLMNIdchaîne de chiffres MCCMNC ou "none"Identifiant PLMN visité (utile pour la détection de roaming dans le plan de numérotation).
location_age_secondsLocationInformation/AgeOfLocationInformationchaîne numérique ou "none"Secondes depuis que les informations de localisation ont été signalées pour la dernière fois au HSS.

Priorité : Données Sh vs Valeurs par défaut de configuration​

Le TAS utilise cet ordre de priorité pour les données de renvoi d'appels :

  1. MMTel-Config de Sh — priorité la plus élevée, paramètres spécifiques à l'abonné.
  2. Données HLR de SS7 MAP — remplace Sh pour les appels MT si le roaming ou le renvoi d'appels est actif dans le réseau visité. Voir SS7 MAP.
  3. Valeurs par défaut de configuration — priorité la plus basse, utilisées lorsque ni Sh ni HLR ne fournissent de valeur (ou lorsque le sous-arbre correspondant était manquant dans la réponse Sh ��� voir dégradation gracieuse ci-dessous). Les valeurs par défaut sont configurées dans runtime.exs sous config :tas — call_forward_not_reachable_destination et default_no_reply_timer.

Que se passe-t-il lorsque la recherche Sh échoue​

Scénarios d'échec de demande entière :

  1. Abonné non provisionné dans le HSS :

    • Le HSS retourne Experimental-Result-Code 5001 (DIAMETER_ERROR_USER_UNKNOWN)
    • Le TAS considère la jambe d'appel comme non résoluble
    • Variable hangup_case définie sur "UNALLOCATED_NUMBER"
    • Appel rejeté avec la réponse SIP appropriée

  2. HSS inaccessible / Délai d'attente :

    • La demande Sh expire (par défaut : 5000 ms, voir request_timeout Diameter dans runtime.exs)
    • Erreur enregistrée et métrique enregistrée
    • La jambe d'appel échoue de la même manière que le cas (1)

  3. Le HSS ne prend pas en charge les UDR multi-Data-Reference :

    • Le HSS retourne soit une erreur, soit abandonne la demande silencieusement (dépend du HSS)
    • Du côté du TAS, cela ressemble au cas (1) ou (2) — la recherche échoue complètement et la jambe d'appel est rejetée
    • Le HSS doit mettre en œuvre la fonctionnalité Notif-Eff pour que le TAS fonctionne. Voir TS 29.328 §6.1.1.1 pour la définition de la fonctionnalité.

Dégradation gracieuse par sous-arbre​

Lorsque l'UDR elle-même réussit (Result-Code: 2001) mais que des sous-arbres individuels du corps fusionné <Sh-Data> sont manquants, le TAS ne échoue pas l'appel. Chaque analyseur par référence est indépendant et revient à une valeur par défaut définie lorsque son tag est absent. Les opérateurs n'ont à se soucier que des échecs de demande entière (voir ci-dessus) ; la dégradation des données partielles est automatique et observable dans les logs de débogage.

Sous-arbre manquantRésultat
<SCSCFName> (Data-Ref 12)scscf_address et scscf_domain définis sur "none"
<IMSPrivateUserIdentity> (Data-Ref 33)ims_private_identity, imsi, ims_domain définis sur "none"
<CallForwardUnconditional> à l'intérieur de MMTel RepositoryDatacall_forward_all_destination défini sur "none"
Bloc not-reachable/<cp:rule> à l'intérieur de MMTel RepositoryDatacall_forward_not_reachable_destination revient à Tas.Config.call_forward_not_reachable_destination()
<CallForwardNoReplyTimer> à l'intérieur de MMTel RepositoryDatano_reply_timer revient à Tas.Config.default_no_reply_timer()
<RepositoryData></RepositoryData> videTous les champs dérivés de MMTel reviennent aux valeurs par défaut de configuration
<IMSUserState>, <LocationInformation>, <InitialFilterCriteria> vides/absentsActuellement aucun effet secondaire dans le plan de numérotation (analysé mais pas encore intégré)

La seule exigence stricte est que la réponse contienne un élément <IMSPublicIdentity>. Si ce tag est manquant, la recherche retourne {:error, :sh_parse_failed} et la jambe d'appel est considérée comme non résoluble (même comportement en aval que le cas 1 ci-dessus). Tous les autres champs sont "demandez librement, prenez ce que vous pouvez obtenir".

Cela rend le TAS résilient face aux déploiements HSS hétérogènes : un HSS qui met en œuvre Notif-Eff mais ne remplit que IMSPublicIdentity, MSISDN et SCSCFName (par exemple) produira toujours un appel fonctionnel ; le plan de numérotation retombe simplement sur les valeurs par défaut de configuration pour les variables dérivées de MMTel.

Surveillance de l'interface Sh​

Métriques clés :

# Taux de succès des recherches Sh
rate(subscriber_data_lookups_total{result="success"}[5m]) /
rate(subscriber_data_lookups_total[5m]) * 100

# Latence de recherche Sh (P95)
histogram_quantile(0.95,
  rate(subscriber_data_duration_milliseconds_bucket[5m]))

# Taux d'erreur Sh
rate(subscriber_data_lookups_total{result="error"}[5m])

Seuils d'alerte :

  • Latence P95 > 100 ms : Réponses HSS lentes
  • Taux d'erreur > 5 % : Problèmes de connectivité HSS
  • Taux d'erreur > 20 % : Échec critique du HSS

Dépannage :

  1. Vérifiez l'état du pair Diameter dans l'interface Web (/diameter)
  2. Testez la recherche Sh dans l'interface Web (/sh_test) avec un abonné connu
  3. Consultez les logs pour les erreurs "Données d'abonné"
  4. Vérifiez que le HSS/Référentiel est accessible depuis le TAS
  5. Vérifiez la métrique subscriber_data_lookups_total pour des motifs

Test de l'interface Sh​

Utilisez l'outil de test Sh de l'interface Web (/sh_test) :

  1. Accédez à /sh_test dans le panneau de contrôle
  2. Entrez le MSISDN de l'abonné (par exemple, +614xxxxxxxx)
  3. Cliquez sur "Interroger Sh"
  4. Examinez les données retournées :
    • Identités IMPI/IMPU
    • Attribution S-CSCF
    • Services MMTel
    • Configuration de renvoi d'appels

Scénarios de test courants :

  • Vérifiez que les abonnés nouvellement provisionnés sont dans le HSS
  • Vérifiez les paramètres de renvoi d'appels pour un abonné spécifique
  • Validez l'attribution S-CSCF après l'enregistrement IMS
  • Testez la connectivité HSS et les temps de réponse