Saltar al contenido principal

Interfaz Sh (Recuperación de Datos del Suscriptor)

📖 Volver a la Documentación Principal

La interfaz Sh proporciona acceso a los datos del perfil del suscriptor desde el HSS/Repositorio a través de Diameter.

Documentación Relacionada​

Documentación Principal​

Integración de Procesamiento de Llamadas​

Interfaces Relacionadas​

Monitoreo​

Interfaz Sh (Recuperación de Datos del Suscriptor)​

La interfaz Sh se utiliza para recuperar datos del perfil del suscriptor desde el HSS/Repositorio antes de procesar llamadas. Estos datos incluyen identidades de suscriptores, servicios y configuración de MMTel.

¿Qué es la Interfaz Sh?​

La interfaz Sh es una interfaz Diameter estandarizada por 3GPP entre el TAS y el HSS/Repositorio (Repo). Proporciona acceso en tiempo real a:

  • Identidades de suscriptores IMS (IMPI/IMPU)
  • Configuraciones de desvío de llamadas (MMTel-Config)
  • Autorización de servicios del suscriptor
  • Asignación de S-CSCF

Cuándo Ocurren las Búsquedas Sh​

Las Búsquedas Sh Ocurren En:

  • Llamadas MT: Búsqueda de la parte llamada (suscriptor de destino)
  • Llamadas MO: Búsqueda de la parte que llama (suscriptor de origen)
  • Llamadas de Emergencia: Búsqueda de la parte que llama (para ubicación/identidad)

En cada caso, el TAS emite exactamente una UDR por pierna de llamada. Tanto MO como MT utilizan la misma forma de UDR multi-Data-Reference: solo difieren las etiquetas métricas.

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

Según 3GPP TS 29.328 §6.1.1.1, cuando tanto el AS como el HSS admiten la función Notif-Eff (negociada a través del AVP Supported-Features), un solo UDR puede llevar múltiples AVPs de Data-Reference y el HSS responde con un UDA cuyo User-Data-Sh es un único documento <Sh-Data> que concatena los subárboles por referencia como hermanos. El TAS se basa en esto: cada búsqueda Sh recupera el conjunto completo de referencias que el sistema sabe cómo consumir en un solo viaje de ida y vuelta.

Referencias de Datos solicitadas (TS 29.328 Tabla 7.6.1)​

RefElementoUsado por TAS para poblar
0RepositoryData (con Service-Indication = "MMTEL-Services")call_forward_all_destination, call_forward_not_reachable_destination, no_reply_timer
10IMSPublicIdentityims_public_identity, msisdn
11IMSUserStateims_user_state (valor enum crudo de TS 29.328 §7.6.3)
12SCSCFNamescscf_address, scscf_domain
13InitialFilterCriteria(cuerpo devuelto al TAS pero no actualmente expuesto como variable del plan de marcado)
14LocationInformationlocation_rat_type, location_mme_name, location_vplmn_id, location_age_seconds
15UserStateuser_state (valor enum crudo de TS 29.328 §7.6.7)
17MSISDN(verificado contra IMPU)
32IMSIimsi
33IMSPrivateUserIdentityims_private_identity, ims_domain (analizado desde el sufijo)

Todos los campos de cadena única se exponen al plan de marcado como variables de cadena cruda: el TAS no interpreta sus valores. Consulte la tabla Variables del Plan de Marcado Establecidas desde Datos Sh a continuación para la lista completa.

Ejemplo de cuerpo UDA (sanitizado)​

Una respuesta fusionada exitosa en el rastro en vivo se ve así: los subárboles por referencia aparecen bajo un único envoltorio <Sh-Data> en el orden en que se solicitaron las referencias:

[debug] Datos del llamante recuperados para +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>
      ... Entradas de 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>

Cómo consumen los analizadores el cuerpo fusionado​

El TAS no recorre el árbol XML. Cada analizador por referencia es independiente y basado en etiquetas: busca en el cuerpo fusionado un nombre de elemento específico (por ejemplo, <SCSCFName>, <IMSPublicIdentity>, <CallForwardUnconditional>, <CallForwardNoReplyTimer>, el bloque cp:rule not-reachable) y extrae solo el valor que le interesa. Los subárboles que el analizador no reconoce se ignoran silenciosamente.

El resultado de cada analizador es un mapa de datos del suscriptor parcial; los parciales se fusionan en orden sobre un mapa de valores predeterminados. Esto hace que la búsqueda sea robusta ante implementaciones heterogéneas de HSS y respuestas parciales: consulte la sección de degradación elegante a continuación.

Datos Recuperados de la Interfaz Sh​

El TAS emite un único UDR multi-Data-Reference por pierna de llamada (consulte UDR Multi-Data-Reference (Notif-Eff) arriba para la forma de solicitud y la respuesta fusionada). Los campos que el TAS extrae del cuerpo fusionado <Sh-Data> se dividen en tres grupos:

1. Identidades IMS:

  • IMPI (Identidad Privada): analizada del elemento <IMSPrivateUserIdentity>. Formato: {IMSI}@{IMS-domain}. El TAS separa en @ para recuperar el IMSI y el dominio IMS de forma independiente.
  • IMPU (Identidad Pública): analizada del elemento <IMSPublicIdentity>. Formato: sip:+{MSISDN}@{IMS-domain}. El MSISDN se despoja del + inicial y se expone como la variable del plan de marcado msisdn.

2. Asignación de S-CSCF:

  • Nombre del servidor S-CSCF y dominio donde el suscriptor está actualmente registrado, analizado del elemento <SCSCFName> (Data-Reference 12). Usado por el plan de marcado MT para enrutar la INVITE directamente al S-CSCF registrado en lugar de dispersarse en el ámbito IMS.
  • Nota: el nombre del elemento XML canónico en el Anexo D de TS 29.328 es SCSCFName (sin guion). La forma con guion "S-CSCF" solo aparece en la prosa de la especificación.

3. Servicios MMTel (Configuración de Telefonía Multimedia):

  • Devuelto dentro de <RepositoryData> con la clave Service-Indication = "MMTEL-Services".
  • Reglas de desvío de llamadas específicas del suscriptor:
    • Desvío de Llamadas Todas (CFA): Desvío incondicional a otro número
    • Desvío de Llamadas Ocupado (CFB): Desvío cuando el suscriptor está ocupado
    • Desvío de Llamadas Sin Respuesta (CFNRy): Desvío después de un tiempo de espera (valor del temporizador extraído de <CallForwardNoReplyTimer>)
    • Desvío de Llamadas No Alcanzables (CFNRc): Desvío cuando el suscriptor está fuera de línea/no registrado (extraído del bloque not-reachable <cp:rule> dentro del documento de servicios MMTel)

¿Qué es MMTel-Config?​

MMTel-Config es la configuración del servicio de Telefonía Multimedia del suscriptor almacenada como datos transparentes (repositorio) en el HSS, con la clave Service-Indication = "MMTEL-Services". Se recupera como parte del mismo UDR multi-Data-Reference que la búsqueda de identidad (Data-Reference 0 más el AVP de indicación de servicio). El documento sigue el esquema OMA / 3GPP simservs XCAP y típicamente contiene un bloque complete-communication-diversion con una o más entradas cp:rule (busy, noanswer, unregistered, notreachable), un valor opcional <NoReplyTimer>, y otros sub-servicios MMTel como Prohibición de Comunicación y Presentación de Identidad.

Servicios MMTel Comunes que Reconoce TAS:

  • CDIV (Desvío de Comunicación): Reglas de desvío de llamadas: el único bloque actualmente analizado de extremo a extremo en variables del plan de marcado. La regla notreachable llena call_forward_not_reachable_destination y <NoReplyTimer> llena no_reply_timer.
  • OIP (Presentación de Identidad de Origen): Reglas de presentación de ID de llamada (devueltas en el cuerpo pero no consumidas actualmente).
  • TIP (Presentación de Identidad de Terminación): Reglas del número de la parte llamada (devueltas en el cuerpo pero no consumidas actualmente).

Variables del Plan de Marcado Establecidas desde Datos Sh​

Después de una búsqueda Sh exitosa, estas variables se poblan:

VariableFuenteValor de EjemploDescripción
ims_private_identityIMPI9999990000xxxxx@ims.mnc001.mcc999.3gppnetwork.orgIdentidad de usuario privada para autenticación
ims_public_identityIMPUsip:+614xxxxxxxx@ims.mnc001.mcc999.3gppnetwork.orgIdentidad de usuario pública para enrutamiento
msisdnIMPU (analizado)614xxxxxxxxNúmero del suscriptor (+ despojado)
imsiIMPI (analizado)9999990000xxxxxIMSI de la identidad privada
ims_domainIMPI/IMPUims.mnc001.mcc999.3gppnetwork.orgDominio IMS
scscf_addressSCSCFNamesip:scscf01.ims.mnc001.mcc999.3gppnetwork.org:5060 o "none"Dirección del servidor S-CSCF (registrado)
scscf_domainSCSCFName (analizado)scscf01.ims.mnc001.mcc999.3gppnetwork.org o "none"Host S-CSCF (registrado)
call_forward_all_destinationMMTel CDIVnumérico o "none"Número de destino CFA
call_forward_not_reachable_destinationMMTel CDIVnumérico o valor predeterminado de configuraciónDestino CFNRc (buzón de voz)
no_reply_timerMMTel CDIVsegundos, o valor predeterminado de configuraciónTiempo de espera antes de que se active CFNRy
ims_user_stateIMSUserState (Data-Ref 11)"0"/"1"/"2"/"3" o "none"Enum del estado de registro IMS. 1 = REGISTRADO, 0 = NO_REGISTRADO, 2 = AUTENTICACIÓN_PENDIENTE, 3 = REGISTRADO_SERVICIOS_NO_REGISTRADOS (TS 29.328 §7.6.3). Cadena cruda, el TAS no interpreta.
user_stateUserState (Data-Ref 15)cadena cruda o "none"Estado del usuario CS/PS (TS 29.328 §7.6.7). Cadena cruda, el TAS no interpreta.
location_rat_typeLocationInformation/RAT-Type"eutran", "utran", "geran", "wlan", ... o "none"Tecnología de acceso radio del último registro conocido.
location_mme_nameLocationInformation/MMENameFQDN de MME o "none"Host MME que atiende al suscriptor.
location_vplmn_idLocationInformation/VPLMNIdcadena de dígitos MCCMNC o "none"Identificador PLMN visitado (útil para detección de roaming en el plan de marcado).
location_age_secondsLocationInformation/AgeOfLocationInformationcadena numérica o "none"Segundos desde que la información de ubicación fue reportada por última vez al HSS.

Prioridad: Datos Sh vs Valores Predeterminados de Configuración​

El TAS utiliza este orden de prioridad para los datos de desvío de llamadas:

  1. MMTel-Config desde Sh — mayor prioridad, configuraciones específicas del suscriptor.
  2. Datos de HLR desde SS7 MAP — anula Sh para llamadas MT si el roaming o el desvío de llamadas están activos en la red visitada. Consulte SS7 MAP.
  3. Valores Predeterminados de Configuración — menor prioridad, utilizados cuando ni Sh ni HLR proporcionan un valor (o cuando el subárbol correspondiente faltaba en la respuesta de Sh — consulte la degradación elegante a continuación). Los valores predeterminados se configuran en runtime.exs bajo config :tas — call_forward_not_reachable_destination y default_no_reply_timer.

Qué Ocurre Cuando la Búsqueda Sh Falla​

Escenarios de falla de solicitud completa:

  1. Suscriptor No Provisionado en HSS:

    • HSS devuelve Experimental-Result-Code 5001 (DIAMETER_ERROR_USER_UNKNOWN)
    • TAS trata la pierna de llamada como no resoluble
    • Variable hangup_case establecida en "UNALLOCATED_NUMBER"
    • Llamada rechazada con la respuesta SIP apropiada

  2. HSS Inalcanzable / Tiempo de Espera:

    • La solicitud Sh se agota (predeterminado: 5000ms, consulte request_timeout de Diameter en runtime.exs)
    • Error registrado y métrica registrada
    • La pierna de llamada falla de la misma manera que el caso (1)

  3. HSS no admite UDRs multi-Data-Reference:

    • HSS devuelve un error o silencia la solicitud (dependiente del HSS)
    • Desde el lado del TAS, esto se ve como el caso (1) o (2): la búsqueda falla en su totalidad y la pierna de llamada es rechazada
    • El HSS debe implementar la función Notif-Eff para que el TAS funcione. Consulte TS 29.328 §6.1.1.1 para la definición de la función.

Degradación elegante por subárbol​

Cuando el UDR en sí tiene éxito (Result-Code: 2001) pero faltan subárboles individuales del cuerpo fusionado <Sh-Data>, el TAS no falla la llamada. Cada analizador por referencia es independiente y recurre a un valor predeterminado definido cuando su etiqueta está ausente. Los operadores solo tienen que preocuparse por fallas de solicitud completa (arriba); la degradación de datos parciales es automática y observable en los registros de depuración.

Subárbol faltanteResultado
<SCSCFName> (Data-Ref 12)scscf_address y scscf_domain establecidos en "none"
<IMSPrivateUserIdentity> (Data-Ref 33)ims_private_identity, imsi, ims_domain establecidos en "none"
<CallForwardUnconditional> dentro de MMTel RepositoryDatacall_forward_all_destination establecido en "none"
Bloque not-reachable/<cp:rule> dentro de MMTel RepositoryDatacall_forward_not_reachable_destination recurre a Tas.Config.call_forward_not_reachable_destination()
<CallForwardNoReplyTimer> dentro de MMTel RepositoryDatano_reply_timer recurre a Tas.Config.default_no_reply_timer()
<RepositoryData></RepositoryData> vacíoTodos los campos derivados de MMTel recurren a valores predeterminados de configuración
<IMSUserState>, <LocationInformation>, <InitialFilterCriteria> vacíos/ausentesActualmente sin efecto secundario en el plan de marcado (analizados pero aún no conectados)

El único requisito estricto es que la respuesta contenga un elemento <IMSPublicIdentity>. Si esa etiqueta falta, la búsqueda devuelve {:error, :sh_parse_failed} y la pierna de llamada se trata como no resoluble (el mismo comportamiento posterior que el caso 1 anterior). Cada otro campo es "pregunta libremente, toma lo que puedas obtener".

Esto hace que el TAS sea resistente a implementaciones heterogéneas de HSS: un HSS que implementa Notif-Eff pero solo llena IMSPublicIdentity, MSISDN y SCSCFName (por ejemplo) aún producirá una llamada funcional; el plan de marcado simplemente recurre a valores predeterminados de configuración para las variables derivadas de MMTel.

Monitoreo de la Interfaz Sh​

Métricas Clave:

# Tasa de éxito de búsqueda Sh
rate(subscriber_data_lookups_total{result="success"}[5m]) /
rate(subscriber_data_lookups_total[5m]) * 100

# Latencia de búsqueda Sh (P95)
histogram_quantile(0.95,
  rate(subscriber_data_duration_milliseconds_bucket[5m]))

# Tasa de error de búsqueda Sh
rate(subscriber_data_lookups_total{result="error"}[5m])

Umbrales de Alerta:

  • Latencia P95 > 100ms: Respuestas lentas del HSS
  • Tasa de error > 5%: Problemas de conectividad con el HSS
  • Tasa de error > 20%: Falla crítica del HSS

Solución de Problemas:

  1. Verifique el estado del par Diameter en la interfaz web (/diameter)
  2. Pruebe la búsqueda Sh en la interfaz web (/sh_test) con un suscriptor conocido
  3. Revise los registros en busca de errores de "Datos del Suscriptor"
  4. Verifique que el HSS/Repositorio sea alcanzable desde el TAS
  5. Verifique la métrica subscriber_data_lookups_total en busca de patrones

Pruebas de la Interfaz Sh​

Utilice la herramienta de prueba Sh de la interfaz web (/sh_test):

  1. Navegue a /sh_test en el Panel de Control
  2. Ingrese el MSISDN del suscriptor (por ejemplo, +614xxxxxxxx)
  3. Haga clic en "Consultar Sh"
  4. Revise los datos devueltos:
    • Identidades IMPI/IMPU
    • Asignación de S-CSCF
    • Servicios MMTel
    • Configuración de desvío de llamadas

Escenarios de Prueba Comunes:

  • Verifique que los suscriptores recién provisionados estén en el HSS
  • Verifique las configuraciones de desvío de llamadas para un suscriptor específico
  • Valide la asignación de S-CSCF después del registro IMS
  • Pruebe la conectividad y los tiempos de respuesta del HSS