Sh RepositoryData (Datos Transparentes)

OmniHSS actúa como un repositorio transparente para los datos de servicio que los Servidores de Aplicaciones (AS) almacenan en relación con un suscriptor a través de la interfaz Sh. Documentos como MMTEL-Services (servicios suplementarios / desvío de llamadas, espera de llamadas, OIP/OIR, restricción) y IMS-ODB-Information (restricción determinada por el operador) son escritos por el AS, mantenidos por el HSS y leídos bajo demanda.

"Transparente" tiene un significado preciso en 3GPP TS 29.328: el HSS entiende estos datos sintácticamente pero no semánticamente. Es XML opaco propiedad del AS. OmniHSS almacena y devuelve la carga útil ServiceData byte por byte — nunca la vuelve a analizar ni a serializar — por lo que un documento que un AS etiqueta o suma de verificación (por ejemplo XCAP/MMTel) se devuelve exactamente como fue escrito.

Los mismos documentos también pueden ser gestionados fuera de banda por sistemas de aprovisionamiento/CRM a través de la REST Provisioning API.

Tabla de Contenidos

• Conceptos
• Modelo de Datos
• Flujos de Mensajes Sh
• SequenceNumber y Concurrencia
• REST Provisioning API
• Tablas de Referencia
• Resolución de Problemas

Conceptos

Un suscriptor puede tener cualquier número de documentos transparentes independientes, cada uno identificado por un Service-Indication (el "nombre del archivo"). Un documento tiene tres partes:

Elemento	Propietario	Significado
Service-Indication	Gestionado por HSS	Nombra el documento (por ejemplo, MMTEL-Services, IMS-ODB-Information).
SequenceNumber	Gestionado por HSS	Contador de versión utilizado para concurrencia optimista. Ver SequenceNumber y Concurrencia.
ServiceData	Propiedad del AS (opaco)	La carga útil XML en sí. Almacenada y devuelta tal cual.

El HSS solo interpreta Service-Indication y SequenceNumber. El cuerpo ServiceData se trata como bytes opacos.

Modelo de Datos

Todos los documentos transparentes de un suscriptor se mantienen en un solo campo, subscriber_state.sh_repository_data, como un objeto JSON indexado por Service-Indication. Cada entrada almacena la versión y la carga útil tal cual:

{
  "MMTEL-Services":      { "sequence_number": "0", "service_data": "<MMTelServices …>…</MMTelServices>" },
  "IMS-ODB-Information": { "sequence_number": "1", "service_data": "<OdbForImsOrientedServices xmlns=\"odb.mmtel.omnitou.ch\"/>" }
}

Campo	Descripción
sequence_number	La versión actual de este documento, según lo aceptado por última vez por el HSS. Devuelto en cada UDA y utilizado para validar actualizaciones.
service_data	El cuerpo XML opaco, almacenado exactamente como lo envió el AS (sin normalización de espacio de nombres, orden de atributos o espacios en blanco). Un documento sin elemento ServiceData (los datos de repositorio vacíos de la especificación) omite este campo.

Este modelo significa que un único suscriptor puede tener muchos documentos distintos, cada uno versionado de forma independiente, sin un esquema fijo impuesto por el HSS.

Flujos de Mensajes Sh

RepositoryData se transporta en el AVP User-Data como un documento XML Sh-Data. RepositoryData se selecciona con valor Data-Reference 0. Un AVP Service-Indication opcional restringe una solicitud a un solo documento.

Solicitud de Datos de Usuario (UDR/UDA) — Leer

El AS lee uno o todos los documentos transparentes. Con un Service-Indication, solo se devuelve el documento correspondiente; sin uno, se devuelven todos los documentos almacenados, cada uno como su propio elemento <RepositoryData>.

Un suscriptor desconocido o no IMS recibe Experimental-Result 5001 (DIAMETER_ERROR_USER_UNKNOWN).

Solicitud de Actualización de Perfil (PUR/PUA) — Escribir

El AS crea o actualiza un solo documento. La carga útil ServiceData se almacena tal cual. La actualización se acepta solo si su SequenceNumber es válido (ver más abajo).

Cuando un PUR se resuelve en múltiples suscriptores (una Identidad Pública con comodín), la actualización se aplica de forma atómica: si algún documento está fuera de sincronía, ninguno se persiste.

Solicitud de Notificaciones de Suscripción (SNR/SNA) — Suscribirse

El AS se suscribe a los datos de un suscriptor y puede solicitar que el valor actual se devuelva de inmediato (Send-Data-Indication). OmniHSS responde al SNR y, cuando se solicita, incluye el RepositoryData actual.

SequenceNumber y Concurrencia

El SequenceNumber proporciona control de concurrencia optimista para que dos Servidores de Aplicaciones no puedan sobrescribirse silenciosamente entre sí, según 3GPP TS 29.328.

• Crear un nuevo documento utiliza SequenceNumber 0 (el valor 0 está reservado exclusivamente para datos recién añadidos).
• Actualizar un documento existente debe llevar el sucesor inmediato del SequenceNumber almacenado (almacenado + 1).
• El contador envuelve de 65535 de vuelta a 1 (no a 0, ya que 0 está reservado).
• Una actualización cuyo SequenceNumber no es el sucesor esperado se rechaza con Experimental-Result 5105 (DIAMETER_ERROR_TRANSPARENT_DATA_OUT_OF_SYNC) y el documento almacenado queda sin cambios.

Ejemplo: un documento se almacena en SequenceNumber 0. Un PUR que lleva SequenceNumber 5 es rechazado con 5105 y nada cambia. Un PUR que lleva SequenceNumber 1 es aceptado y el documento avanza a la versión 1.

REST Provisioning API

Los mismos documentos pueden ser leídos y escritos directamente por sistemas de aprovisionamiento/CRM. El suscriptor se dirige por IMSI en la ruta; el documento se identifica por service_indication (en el cuerpo de la solicitud para actualizaciones, o la cadena de consulta para lecturas/eliminaciones). El opaco service_data se envía byte por byte, exactamente como a través de Sh.

Todas las respuestas utilizan el sobre estándar de la API:

{ "status": "success", "response": { } }

A diferencia de la ruta Sh, la API REST es un acceso de aprovisionamiento autoritativo y no aplica la verificación de desincronización del SequenceNumber — una escritura establece el documento directamente.

Listar Todos los Documentos

Devuelve todos los documentos almacenados para el suscriptor.

Endpoint: GET /api/subscriber/repository_data/:imsi

curl -k https://hss.example.com:8443/api/subscriber/repository_data/001001123456789

{
  "status": "success",
  "response": {
    "MMTEL-Services":      { "sequence_number": "0", "service_data": "<MMTelServices …/>" },
    "IMS-ODB-Information": { "sequence_number": "1", "service_data": "<OdbForImsOrientedServices xmlns=\"odb.mmtel.omnitou.ch\"/>" }
  }
}

Obtener un Solo Documento

Devuelve un documento por Service-Indication.

Endpoint: GET /api/subscriber/repository_data/:imsi?service_indication=:service_indication

curl -k "https://hss.example.com:8443/api/subscriber/repository_data/001001123456789?service_indication=MMTEL-Services"

{
  "status": "success",
  "response": { "sequence_number": "0", "service_data": "<MMTelServices …/>" }
}

Crear o Actualizar un Documento

Crea el documento si está ausente, o lo sobrescribe.

Endpoint: PUT /api/subscriber/repository_data/:imsi

curl -k -X PUT https://hss.example.com:8443/api/subscriber/repository_data/001001123456789 \
  -H "Content-Type: application/json" \
  -d '{
        "service_indication": "MMTEL-Services",
        "service_data": "<MMTelServices version=\"1\"/>",
        "sequence_number": "0"
      }'

Campo	Tipo	Requerido	Predeterminado	Descripción
service_indication	Cadena	Sí	-	El nombre del documento a crear/actualizar (por ejemplo, MMTEL-Services).
service_data	Cadena	No	-	La carga útil XML opaca, almacenada tal cual. Omitir para almacenar un documento vacío (solo Service-Indication y SequenceNumber).
sequence_number	Cadena	No	0	La versión a registrar para el documento.

La respuesta refleja el documento almacenado:

{
  "status": "success",
  "response": { "sequence_number": "0", "service_data": "<MMTelServices version=\"1\"/>" }
}

Eliminar un Documento

Elimina un solo documento por Service-Indication.

Endpoint: DELETE /api/subscriber/repository_data/:imsi

curl -k -X DELETE https://hss.example.com:8443/api/subscriber/repository_data/001001123456789 \
  -H "Content-Type: application/json" \
  -d '{ "service_indication": "MMTEL-Services" }'

Campo	Tipo	Requerido	Predeterminado	Descripción
service_indication	Cadena	Sí	-	El documento a eliminar.

La respuesta devuelve los documentos restantes para el suscriptor.

Tablas de Referencia

Valores de Data-Reference (RepositoryData)

Valor	Nombre	Descripción	Referencia
0	RepositoryData	Datos de servicio transparentes identificados por Service-Indication	3GPP TS 29.328 §7.6

Códigos de Resultado y Experimental-Result

Código	Nombre	Significado	Referencia
2001	DIAMETER_SUCCESS	UDR/PUR/SNR procesados con éxito	RFC 6733 §7.1.1
5001	DIAMETER_ERROR_USER_UNKNOWN	Suscriptor no encontrado o no habilitado para IMS	3GPP TS 29.329
5105	DIAMETER_ERROR_TRANSPARENT_DATA_OUT_OF_SYNC	El SequenceNumber de actualización no es el sucesor del valor almacenado	3GPP TS 29.329

ID de Aplicación

ID	Interfaz	Descripción	Referencia
16777217	Sh	AS ↔ HSS datos de usuario	3GPP TS 29.329

Indicaciones de Servicio Comunes

Service-Indication	Contenido Típico
MMTEL-Services	Servicios suplementarios de MMTel (desvío de llamadas, espera/comunicación en espera/restricción, OIP/OIR, conferencias) — XML de simservs
IMS-ODB-Information	Información de restricción determinada por el operador para servicios orientados a IMS

Los valores de Service-Indication son definidos por el Servidor de Aplicaciones y su correspondiente esquema XML; el HSS no impone ninguna lista fija.

Resolución de Problemas

El Servidor de Aplicaciones recibe 5105 en la actualización

Síntomas: Un PUR es respondido con Experimental-Result 5105 y el documento no cambia.

Causas posibles:

• El AS envió un SequenceNumber que no es el sucesor inmediato del valor almacenado en el HSS (su copia en caché está obsoleta).
• Una actualización concurrente de otro AS avanzó el SequenceNumber.

Resolución:

1. Lea el documento actual con un UDR para obtener el SequenceNumber actualizado.
2. Reemita el PUR con SequenceNumber = almacenado + 1.
3. Para forzar un valor administrativamente, configúrelo a través de la REST API, que no aplica la verificación de concurrencia.

ServiceData devuelto difiere de lo que fue escrito

Síntomas: El AS cree que la carga útil fue alterada por el HSS.

Causas posibles:

• Esto no debería ocurrir — OmniHSS almacena y devuelve ServiceData byte por byte. Las diferencias aparentes generalmente provienen de la propia biblioteca XML del AS que vuelve a serializar el documento (cambiando los prefijos de espacio de nombres, el orden de atributos o los espacios en blanco) antes de la comparación.

Resolución:

1. Compare los bytes crudos devueltos en la respuesta UDA/REST contra los bytes crudos enviados, no una representación reanalizada.
2. Confirme que el AS no está normalizando el XML en su lado antes de la comparación.

Documento no encontrado a través de REST

Síntomas: GET …/repository_data/:imsi?service_indication=… devuelve un error.

Causas posibles:

• No hay documento con esa Service-Indication almacenado para el suscriptor.
• El IMSI no corresponde a un suscriptor existente.

Resolución:

1. Liste todos los documentos con GET /api/subscriber/repository_data/:imsi para ver qué está almacenado.
2. Verifique el IMSI con Obtener Suscriptor por IMSI.