Al diagnosticar las interfaces basadas en servicios de un núcleo 5G, muchos ingenieros se encuentran con el mismo problema. El cuerpo de una solicitud enviada desde un AMF a un SMF puede contener campos conocidos como SUPI, DNN, S-NSSAI, TAI, PDU Session ID y 5QI y, aun así, puede ser difícil determinar si el mensaje es realmente válido. ¿Debe codificarse un campo como cadena o como entero? ¿Tiene un rango de valores definido? ¿Puede utilizarse cualquier valor o debe proceder de una enumeración predefinida? ¿Puede un objeto contener otros parámetros anidados?

Las respuestas las definen los tipos de datos comunes de la SBI. Las interfaces basadas en servicios abarcan funciones de red como AMF, SMF, UDM, PCF y NRF, pero muchos de los parámetros subyacentes no son específicos de una única NF. Si cada servicio definiera estos valores de forma independiente, las especificaciones contendrían duplicaciones innecesarias y el mismo identificador de abonado o parámetro de QoS podría representarse de forma distinta entre APIs. Por eso, analizar el tráfico SBI exige algo más que revisar los métodos HTTP y los URI de recursos. HTTP/2 define cómo se transportan las solicitudes, JSON define cómo se representan los datos y los tipos de datos comunes responden a una cuestión más fundamental: qué formato y qué reglas de validación debe cumplir cada parámetro JSON.

¿Qué problemas resuelven los tipos de datos comunes?

Pueden entenderse como un «vocabulario de datos» compartido por todo el entorno de APIs basadas en servicios de 5GC. Un tipo de dato puede aparecer en una solicitud de AMF y también ser referenciado por SMF, UDM o PCF. No pertenece a una sola interfaz; proporciona una definición estandarizada que puede reutilizarse en múltiples servicios.

Pensemos en una dirección IPv4. Cada NF no debería definir su propia forma de representar la dirección como una cadena. Lo mismo ocurre con la información PLMN, donde MCC y MNC tienen longitudes y formatos específicos, y con identificadores de abonado y equipo como SUPI, GPSI y PEI, que siguen sus propias reglas de codificación. Las definiciones coherentes permiten que las APIs RESTful entre distintas NF intercambien información de forma fiable.

Los tipos de datos comunes también deben distinguirse de los tipos específicos de una NF. Los tipos comunes cubren objetos que aparecen repetidamente en distintas interfaces, mientras que los objetos de negocio exclusivos de una función de red concreta se definen en las especificaciones correspondientes de la serie 29. En la práctica, una misma API SBI suele hacer referencia a ambos tipos de datos.

Su alcance va mucho más allá de las direcciones de red. Las definiciones comunes abarcan parámetros genéricos, información de suscripción e identidad, datos de red 5G, QoS, tarificación, información de trazado y otros objetos reutilizables. En conjunto, forman un modelo de datos fundamental para los parámetros de los mensajes SBI.

¿En qué se diferencian las tres estructuras básicas de datos?

Desde el punto de vista estructural, los parámetros SBI pueden agruparse generalmente en tres categorías: tipos de datos simples, enumeraciones y tipos de datos estructurados. Comprender estas tres categorías es más útil que memorizar nombres de parámetros individuales, porque la mayoría de los campos que aparecen en capturas de Wireshark, documentación de APIs y definiciones OpenAPI encajan en este modelo.

Los tipos de datos simples son los componentes básicos de nivel más bajo. Incluyen cadena, entero, número, fecha, fecha-hora y booleano. En 5GC, estos tipos básicos suelen combinarse con restricciones adicionales, como rangos de valores, formatos de codificación o patrones de expresiones regulares.

Una dirección IPv4, por ejemplo, se representa técnicamente como una cadena, pero no cualquier cadena arbitraria es válida. Debe seguir el formato IPv4 requerido. Las direcciones IPv6, los prefijos IPv6 y las direcciones MAC tienen sus propios requisitos de formato. Uint16, Uint32 y Uint64 definen rangos para enteros sin signo. Un URI debe cumplir las reglas de formato de URI, mientras que los valores DateTime deben utilizar el formato de fecha y hora especificado.

Las especificaciones también definen con frecuencia tipos con el sufijo Rm, como Ipv4AddrRm, DateTimeRm y Uint32Rm. Estos tipos utilizan el mismo formato subyacente que sus tipos base correspondientes, pero incluyen la propiedad nullable de OpenAPI, lo que permite que el campo contenga un valor null.

Los tipos de enumeración funcionan como campos de opción múltiple: el valor debe seleccionarse de un conjunto predefinido. AccessType, por ejemplo, distingue entre 3GPP_ACCESS y NON_3GPP_ACCESS. PduSessionType puede tomar valores como IPV4, IPV6, IPV4V6, UNSTRUCTURED o ETHERNET. CoreNetworkType puede indicar 5GC o EPC.

El objetivo de una enumeración es eliminar la ambigüedad. Un consumidor no puede inventar una cadena distinta que casualmente signifique lo mismo; debe utilizar uno de los valores definidos explícitamente por la especificación. Este es un caso habitual de diagnóstico: el nombre del campo es correcto, pero el valor de la enumeración no es válido, por lo que la API sigue rechazando o interpretando incorrectamente la solicitud.

Los tipos de datos estructurados combinan varios atributos en un objeto completo. Esos atributos pueden, a su vez, hacer referencia a tipos simples, enumeraciones u otros objetos estructurados, creando un modelo jerárquico.

ProblemDetails es un ejemplo típico. Puede incluir campos como type, title, status, detail, instance, cause e invalidParams. TAI es otro ejemplo, al combinar un PLMN ID con un TAC. GUAMI va un nivel más allá al combinar un PLMN ID con un AMF ID. En este nivel, el análisis SBI ya no puede centrarse únicamente en campos individuales; también importan las relaciones entre los atributos del objeto.

¿Cómo se construyen los parámetros de identidad y de red?

En capturas de paquetes reales, los datos relacionados con suscripción, identidad y red 5G se encuentran entre los parámetros SBI más habituales. SUPI identifica a un abonado, GPSI representa una identidad externa de abonado, PEI representa un identificador permanente de equipo, DNN identifica una red de datos y un NF Instance ID identifica de forma única una instancia de NF.

Muchos de estos campos pueden parecer simples cadenas, pero lo importante es la regla de codificación dentro de la cadena. Un SUPI puede contener una representación IMSI o NAI, mientras que un GPSI puede contener un MSISDN o un External Identifier. En otras palabras, que un campo se defina como cadena no significa que cualquier cadena sea válida.

Los tipos relacionados con la red 5G se apoyan en estos identificadores básicos para representar información de sesión y ubicación. PduSessionId identifica una PDU Session. MCC y MNC forman parte de una identidad PLMN. TAC identifica un Tracking Area Code, mientras que NrCellId y EutraCellId identifican respectivamente celdas NR y E-UTRA.

Los objetos estructurados combinan después estos parámetros básicos en modelos de datos de nivel superior. S-NSSAI utiliza un SST y un SD opcional para representar un segmento de red. TAI combina un PLMN ID y un TAC. NCGI combina un PLMN ID con un NR Cell ID para identificar una celda NR, mientras que ECGI cumple una función similar para E-UTRA.

UserLocation es una abstracción de nivel aún más alto. Según el tipo de acceso, puede contener una NR Location, una E-UTRA Location o una Non-3GPP Access Location. A su vez, una NR Location puede contener TAI, NCGI, una marca temporal de ubicación e información geográfica.

Esto ilustra el diseño modular de los modelos de datos SBI. Primero se estandarizan elementos básicos como MCC, MNC, TAC y Cell ID, y después se combinan en objetos de nivel superior como PLMN ID, TAI, NCGI y UserLocation. Las APIs pueden reutilizar directamente estos objetos en lugar de redefinir un conjunto completo de parámetros de ubicación para cada servicio.

¿Por qué también deben estandarizarse los datos de QoS, tarificación y trazado?

El tráfico SBI transporta mucho más que identidades de abonado y ubicación de red. Las políticas de QoS, la información de uso y los datos de trazado de red también circulan entre múltiples NF, por lo que estos valores necesitan definiciones de datos coherentes.

Entre los parámetros de QoS, QFI identifica un QoS Flow, 5QI representa el 5G QoS Identifier, BitRate representa una tasa mediante un valor y una unidad, Packet Delay Budget expresa un presupuesto de retardo, y Packet Error Rate y Packet Loss Rate describen la calidad de transmisión.

Las políticas de QoS también utilizan muchos tipos de enumeración. PreemptionCapability indica si un servicio puede apropiarse de recursos asignados en otro lugar. PreemptionVulnerability indica si recursos existentes pueden ser retirados por un servicio de mayor prioridad. QosResourceType distingue valores como NON_GBR, NON_CRITICAL_GBR y CRITICAL_GBR.

Estos campos básicos se combinan después en objetos estructurados como ARP, AMBR, Dynamic 5QI y Non-Dynamic 5QI. Esto permite que SMF, PCF y otras funciones de red relacionadas utilicen la misma representación al intercambiar conceptos como prioridad, tasa de bits, retardo y comportamiento de preempción.

Los datos de tarificación siguen el mismo principio de diseño. ChargingId, RatingGroup y ServiceId son tipos de datos simples relativamente directos, mientras que QoSFlowUsageReport puede incluir QFI, marcas temporales de inicio y fin de recopilación y volúmenes de tráfico ascendente y descendente. VolumeTimedReport puede representar el uso de una PDU Session durante un intervalo de tiempo definido.

Los tipos relacionados con el trazado estandarizan la información de seguimiento de red. TraceDepth utiliza valores enumerados para describir distintos niveles de trazado, mientras que TraceData combina parámetros como Trace Reference, Trace Depth y NE Type. Así se evita que cada NF defina su propio conjunto incompatible de campos de trazado.

Estos ejemplos muestran que los tipos de datos comunes hacen mucho más que estandarizar «unos pocos campos JSON». Estandarizan cómo entienden los distintos servicios del núcleo los mismos conceptos de negocio y de red. Si la QoS, la ubicación, la información de tarificación o los identificadores de abonado deben circular entre varias NF, primero necesitan un modelo de datos coherente.

¿Cómo pueden utilizarse los tipos de datos en el diagnóstico práctico?

Uno de los errores de ingeniería más habituales consiste en revisar un mensaje JSON únicamente para comprobar si un campo está presente, sin verificar el tipo de dato y las restricciones asociadas. Un método de diagnóstico más eficaz consiste en analizar conjuntamente la capa HTTP y el modelo de datos.

Empiece identificando el servicio invocado y el URI del recurso. Después localice el campo objetivo en el cuerpo de la solicitud o la respuesta. Una vez localizado, no se limite al valor. Compruebe qué tipo de dato referencia, si es obligatorio u opcional, su Cardinality, si se trata de una enumeración y si tiene restricciones de formato o Pattern.

Un campo IPv4 puede parecer una dirección IP a simple vista, pero si no cumple el formato definido sigue siendo una entrada no válida. Del mismo modo, un valor de PduSessionType puede ser comprensible en lenguaje natural, pero si no pertenece a los valores de enumeración especificados no cumple la definición de la API.

Los datos estructurados deben desplegarse de forma recursiva. Cuando aparezca UserLocation, determine si el objeto contiene información de ubicación NR, E-UTRA o Non-3GPP. Cuando aparezca TAI, examine PLMN ID y TAC. Cuando aparezca S-NSSAI, compruebe SST y el SD opcional. Solo siguiendo las referencias de tipo capa por capa puede un ingeniero determinar si el objeto JSON coincide con el modelo de la API.

Cuando un servidor rechaza una solicitud, también conviene examinar detenidamente ProblemDetails. Además del código de estado HTTP, puede proporcionar información en detail, cause e invalidParams. Cuando estos campos están presentes, el diagnóstico puede comenzar por el parámetro concreto que incumplió los requisitos de la API, en lugar de detenerse en una respuesta HTTP 4xx genérica.

¿Por qué es más útil pensar en modelos de datos que memorizar tablas de parámetros?

La cantidad de tipos de datos comunes de la SBI de 5GC es suficientemente grande como para que memorizar cada campo, expresión regular y rango de valores se vuelva rápidamente ineficiente. Un enfoque mejor es adoptar una mentalidad de modelo de datos: los tipos simples definen las unidades de datos más pequeñas, las enumeraciones restringen los estados válidos y los tipos estructurados combinan esas unidades en objetos que los servicios de 5GC pueden utilizar directamente.

Con este marco, SUPI, MCC, TAC y QFI dejan de ser parámetros aislados. Se convierten en bloques de construcción de modelos de abonado, ubicación, sesión, QoS, tarificación y trazado. Una de las razones por las que distintas NF pueden invocar servicios de forma coherente a través de SBI es que estos tipos comunes aportan una semántica de datos estable y reutilizable.

Al leer una API de 5GC desconocida, la primera pregunta más útil no es «¿Cuántos campos tiene este mensaje?». En su lugar, hay que determinar a qué tipos hacen referencia esos campos, cómo se anidan los objetos y qué restricciones deciden si el JSON resultante es válido. Una vez dominado este método, incluso un servicio SBI nunca visto puede analizarse siguiendo capa por capa las definiciones de OpenAPI y de tipos de datos, en lugar de memorizar una tabla de parámetros completamente nueva.

Preguntas frecuentes

¿Qué especificación 3GPP define los tipos de datos comunes de SBI?

Se definen principalmente en TS 29.571, 5G System; Common Data Types for Service Based Interfaces. Esta especificación define estructuras de datos reutilizables compartidas entre servicios SBI. Los servicios y tipos de datos específicos de una NF se definen en las especificaciones 29.5xx correspondientes, como TS 29.502 para servicios SMF y TS 29.503 para servicios UDM.

¿Cómo aparece la propiedad nullable de OpenAPI en un mensaje JSON real?

Un campo definido como nullable, normalmente mediante un tipo con sufijo Rm, puede contener explícitamente un valor null en el cuerpo JSON para indicar que actualmente no tiene asignado un valor válido. Esto es distinto de que el campo esté completamente ausente. Un campo ausente puede significar que el parámetro no es aplicable o no se proporcionó, mientras que un null explícito puede tener un significado semántico concreto, como borrar un valor configurado previamente.

¿Pueden diferir entre fabricantes los tipos de datos comunes de SBI?

Las definiciones están estandarizadas a nivel de especificación, pero en productos reales todavía pueden aparecer diferencias de implementación. Algunos fabricantes pueden implementar solo un subconjunto de campos opcionales, ciertas APIs pueden incluir extensiones específicas del fabricante y el rigor de la validación de enumeraciones puede variar. Estas diferencias son puntos habituales de investigación durante las pruebas de interoperabilidad.

¿Cómo saber rápidamente si un campo utiliza un tipo común o un tipo específico de una NF?

El método más directo es inspeccionar la ruta $ref de la definición OpenAPI. Si la referencia apunta a un esquema común definido para TS 29.571, normalmente se trata de un tipo de dato SBI compartido. Si apunta a un esquema definido dentro de la especificación del servicio actual, por lo general es específico de la NF. Conocer tipos reutilizados con frecuencia, como SUPI, TAI, S-NSSAI y ProblemDetails, también facilita reconocerlos durante el análisis de paquetes.

¿Cuál es la diferencia entre un tipo Rm y un tipo normal en una captura de paquetes?

Cuando el valor no es null, la representación JSON es prácticamente la misma porque ambos tipos utilizan el mismo formato subyacente. La diferencia existe en el modelo OpenAPI: un tipo Rm permite que el campo contenga null. Si un campo capturado contiene explícitamente un valor null, debe estar utilizando una definición nullable. Si contiene un valor válido normal, ese valor por sí solo no basta para determinar si el esquema referencia el tipo normal o el tipo Rm correspondiente.