¿Por qué la SBI del 5GC se basa en llamadas de servicio sobre HTTP/2?

La relación entre las funciones de red cambió de forma significativa cuando el núcleo 5G adoptó una arquitectura basada en servicios. Funciones como AMF, SMF, UDM, PCF, NSSF y AUSF ya no se limitan a intercambiar mensajes mediante interfaces de protocolo punto a punto fijas. En su lugar, cada NF expone sus capacidades como servicios que otras funciones de red pueden consumir cuando los necesitan.

En este modelo, una NF puede recuperar un recurso de otra NF, crear un contexto nuevo, actualizar un recurso existente o eliminar uno que ya no sea necesario. El patrón de comunicación pasa de forma natural a ser solicitud → operación sobre el recurso → respuesta. Los métodos HTTP, las URI, los códigos de estado y JSON ofrecen una forma práctica de representar este tipo de interacción entre servicios.

Una pila de protocolos SBI simplificada puede representarse así:

Aplicación/JSON → HTTP/2 → TCP → IP → Ethernet

JSON define cómo se representan los datos de aplicación. HTTP/2 organiza las solicitudes y respuestas para su transporte. TCP proporciona entrega fiable, IP se ocupa del direccionamiento y el enrutamiento, y Ethernet transporta las tramas por la red subyacente.

Esto es muy diferente de interfaces como N2, N3 y N4. N2 utiliza NGAP, N4 utiliza PFCP y el plano de usuario emplea habitualmente GTP-U. La interfaz basada en servicios utiliza HTTP/2 como marco de transporte para la comunicación entre servicios. No se trata simplemente de sustituir un protocolo, sino de un cambio más amplio en la filosofía de diseño del 5GC: pasar del intercambio de mensajes de interfaz predefinidos a la invocación de servicios.

Por ejemplo, cuando la AMF necesita datos de suscripción de gestión de acceso de un abonado, la AMF actúa como NF consumidora y solicita un recurso a la UDM, que actúa como NF productora. La consumidora necesita principalmente saber a qué recurso acceder, qué operación realizar y qué resultado se devuelve. No es necesario diseñar un mecanismo de transporte completamente independiente para cada procedimiento de servicio.

HTTP/2 también aporta una ventaja muy práctica en este entorno: varias solicitudes de servicio pueden compartir una única conexión TCP. Las interacciones SBI entre funciones de red son frecuentes, y establecer repetidamente nuevas conexiones TCP para cada llamada API generaría una sobrecarga innecesaria de gestión de conexiones.

¿Qué problemas de transporte resuelve HTTP/2 frente a HTTP/1.1?

HTTP/2 no sustituyó todo el modelo de aplicación de HTTP/1.1. Métodos como GET y POST siguen existiendo, y el modelo básico de solicitud y respuesta continúa siendo familiar. Los cambios principales están en la forma de organizar y transmitir los datos.

En 5GC, acelerar la carga de páginas web no es lo importante. El valor real es que HTTP/2 ofrece un modelo de conexión más eficiente para grandes cantidades de llamadas API simultáneas entre funciones de red.

Una sola conexión puede transportar varios Streams

HTTP/1.1 admite conexiones persistentes, pero la concurrencia dentro de una única conexión sigue teniendo limitaciones. En muchos despliegues tradicionales se abren varias conexiones TCP para aumentar el paralelismo, lo que añade sobrecarga de gestión tanto en el cliente como en el servidor.

HTTP/2 introduce la multiplexación. Una sola conexión TCP puede contener simultáneamente varios Streams independientes. Las solicitudes no tienen que esperar a que una transacción anterior finalice por completo para poder transmitir tráfico adicional. Las Frames de varios Streams pueden intercalarse dentro de la misma conexión.

En un entorno SBI de 5GC, una vez que una AMF establece una conexión HTTP/2 con otra NF, esa conexión no queda limitada a procesar una sola solicitud API cada vez. Varias operaciones de servicio pueden utilizar Streams distintos, cada uno con su propia solicitud y respuesta.

Un menor número de conexiones TCP significa menos sobrecarga de gestión, algo especialmente adecuado para las interacciones de servicio de alta frecuencia entre funciones de red del núcleo 5G.

Los mensajes HTTP se transportan como Frames binarios

HTTP/1.x está orientado en gran medida al texto. Las líneas de solicitud, las cabeceras y los cuerpos de los mensajes se representan claramente como estructuras textuales. HTTP/2 cambia el formato en el enlace y transporta la información del protocolo en Frames binarios.

Las cabeceras HTTP suelen transportarse en HEADERS Frames, mientras que la carga útil real de la aplicación puede ir en DATA Frames. El receptor utiliza la información de la cabecera de la Frame, incluido el identificador de Stream, para determinar a qué Stream pertenece una Frame concreta y después reconstruir el mensaje HTTP completo.

Por eso, una captura HTTP/2 en Wireshark a menudo no se parece a un bloque completo de texto HTTP. En su lugar, los ingenieros ven una secuencia de HEADERS, DATA y otros tipos de Frame.

Las cabeceras repetidas no tienen que enviarse completas cada vez

Las cabeceras HTTP aparecen repetidamente en el tráfico de las API SBI. Si cada solicitud incluyera íntegramente los mismos campos de cabecera, la sobrecarga duplicada crecería rápidamente.

HTTP/2 utiliza HPACK para comprimir las cabeceras. De forma simplificada, ambos extremos mantienen tablas de cabeceras, lo que permite representar campos repetidos con índices en lugar de retransmitir todo el texto cada vez.

Cuanto más repetitivas sean las cabeceras, mayor es el beneficio de la compresión. Cuando las funciones de red invocan repetidamente API similares, campos como métodos, rutas y cabeceras comunes aparecen una y otra vez, por lo que HPACK resulta especialmente eficaz para reducir transmisiones redundantes.

HTTP/2 también define Server Push

HTTP/2 incluye un mecanismo de Server Push y define la PUSH_PROMISE Frame, que permite al servidor proporcionar de forma proactiva recursos relacionados antes de que el cliente solicite explícitamente cada uno de ellos.

Sin embargo, para comprender la SBI del 5GC, Server Push no es el concepto principal. La reutilización de conexiones, la multiplexación, los Streams, las Frames, la compresión de cabeceras y el modelo de solicitud-respuesta de las API son mucho más importantes en el análisis práctico de SBI.

¿Cómo deben entenderse Connection, Stream, Message y Frame?

Una de las partes más confusas de HTTP/2 es que los términos Connection, Stream, Message y Frame suelen aparecer juntos. Es mucho más sencillo entenderlos como una jerarquía que memorizar cada definición por separado.

Una Connection es la conexión TCP subyacente. Una vez establecida la sesión TCP, el tráfico HTTP/2 circula por esa conexión.

Un Stream es un canal lógico bidireccional dentro de la Connection. Cada Stream tiene su propio identificador entero. En una sola conexión TCP pueden existir simultáneamente varios Streams, lo que constituye la base de la multiplexación de HTTP/2.

Un Message representa una solicitud o respuesta HTTP lógica. Por ejemplo, una AMF puede enviar a la UDM un mensaje de solicitud GET y la UDM devuelve el mensaje de respuesta correspondiente.

Una Frame es una unidad más pequeña utilizada por HTTP/2 para la transmisión real. Un Message puede estar formado por una o varias Frames. Algunos ejemplos habituales son:

• HEADERS Frame: transporta información de cabeceras HTTP.

• DATA Frame: transporta los datos de carga útil de la aplicación.

• Otros tipos de Frame: admiten la gestión de conexiones, el control de flujo y otras funciones de HTTP/2.

La relación puede resumirse así:

Una Connection contiene varios Streams. Un Stream transporta Messages de solicitud y respuesta, y cada Message se compone de una o más Frames.

La cabecera de una Frame HTTP/2 contiene campos como Length, Type, Flags, bits reservados y Stream Identifier. El Stream Identifier es especialmente importante porque indica al receptor a qué Stream lógico pertenece la Frame.

Aunque Frames de varios Streams lleguen intercaladas, el receptor puede utilizar el Stream ID para asociar y reensamblar correctamente los datos. Este es el mecanismo fundamental que permite a HTTP/2 transportar de forma eficiente varias transacciones simultáneas sobre una única conexión TCP.

Para los ingenieros de núcleo 5G, este concepto es especialmente importante durante el análisis de paquetes. El tráfico SBI no debe agruparse simplemente porque los paquetes aparezcan uno junto a otro en una captura. Deben considerarse conjuntamente el Stream ID, la URI, el método HTTP y el estado de la respuesta.

¿Cómo convierten JSON y las API RESTful las capacidades del 5GC en recursos?

HTTP/2 responde a la pregunta de cómo transportar eficazmente el tráfico de servicios. Lo que realmente define el modelo de aplicación de la SBI del 5GC es la combinación de API RESTful y un diseño orientado a recursos.

REST es un estilo arquitectónico. Una de sus ideas principales consiste en representar los objetos de negocio como recursos, asignar a cada recurso una URI única y utilizar métodos HTTP para realizar operaciones sobre esos recursos.

Un «recurso» en 5GC no se limita a los objetos que normalmente se asocian a sitios web. Puede representar datos de abonado, un SM Context, un objeto relacionado con una PDU Session u otro estado mantenido por una función de red.

Por ejemplo, los datos de suscripción de gestión de acceso de un abonado pueden tener una URI específica, mientras que los datos de suscripción de gestión de sesión pueden utilizar otra. Desde el punto de vista de la consumidora, la operación ya no es simplemente:

«Llamar a un procedimiento de señalización concreto de la UDM».

En su lugar, pasa a ser:

Realizar una operación GET, POST, PUT/PATCH o DELETE sobre un recurso específico.

Los métodos HTTP definen qué ocurre con un recurso

Las operaciones habituales pueden entenderse de la siguiente manera:

• GET: obtener o leer un recurso.

• POST: crear un recurso o invocar una operación definida.

• PUT / PATCH: actualizar un recurso existente.

• DELETE: eliminar un recurso.

Después de procesar la solicitud, el servidor devuelve un código de estado HTTP para indicar el resultado.

Una respuesta 200 suele indicar que el procesamiento fue correcto y que se devolvieron datos. Una respuesta 201 suele indicar que se creó correctamente un recurso. Una respuesta 204 puede indicar que la operación tuvo éxito sin devolver cuerpo de respuesta. Las respuestas 4xx suelen señalar problemas de solicitud, recurso o autorización, mientras que las 5xx suelen indicar problemas de procesamiento en el servidor.

Estos códigos de estado son muy útiles al diagnosticar 5GC. Que exista una conexión HTTP/2 establecida no significa que la operación del servicio haya tenido éxito. Los ingenieros aún deben comprobar la URI solicitada, el método HTTP y el código de estado devuelto por la NF productora.

JSON transporta los datos reales de negocio

Las cargas de aplicación SBI suelen representarse en JSON. JSON es un formato ligero de intercambio de datos basado en estructuras clave-valor. Puede representar cadenas, números, valores booleanos, matrices, objetos y estructuras de datos anidadas.

En otras palabras, la DATA Frame de HTTP/2 se encarga de transportar la carga útil, mientras que el JSON contenido en esa Frame define qué significan realmente los datos de aplicación.

Desde el punto de vista de ingeniería, HTTP/2 y JSON no deben tratarse como la misma capa de protocolo. HTTP/2 organiza el transporte, JSON representa los datos de aplicación y las API RESTful definen los recursos y las operaciones que se pueden realizar sobre ellos.

¿Cómo está estructurada una URI de recurso de la SBI del 5GC?

Una vez claro el concepto de recurso, la estructura de una URI SBI resulta mucho más fácil de entender. Las rutas de recursos no son arbitrarias; siguen una jerarquía estructurada.

Un formato típico puede representarse así:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

Cada parte cumple una función específica:

• apiRoot: dirección raíz utilizada para acceder al servicio, normalmente con el formato http(s)://host(:port).

• apiName: nombre de la API o servicio SBI concreto expuesto por la función de red.

• apiVersion: versión de la API, por ejemplo v1.

• apiSpecificResourceUriPart: ruta que identifica el recurso u operación específicos.

Por ejemplo, los datos de suscripción de gestión de acceso y los de gestión de sesión pueden ser proporcionados ambos por la UDM, pero utilizan rutas de recurso diferentes. La URI permite así identificar con precisión qué recurso está solicitando la consumidora.

Los servicios de PDU Session de la SMF siguen la misma idea general. Diferentes SM Contexts y recursos relacionados con PDU Session tienen sus propias URI, y se utilizan distintos métodos HTTP para crearlos, obtenerlos, modificarlos o liberarlos.

Este diseño orientado a recursos cambia la forma en que los ingenieros deben pensar las interfaces SBI. En lugar de memorizar únicamente una secuencia tradicional como «Mensaje A → Mensaje B», una interacción SBI puede analizarse como:

Servicio → Recurso → Método → URI → Código de estado → Cuerpo JSON

Si se aborda la SBI del 5GC únicamente con la mentalidad tradicional de telecomunicaciones de emparejar nombres de mensajes de solicitud con nombres de mensajes de respuesta, la arquitectura puede parecer fragmentada. Cuando se contempla como un modelo de recursos basado en API, la lógica se vuelve mucho más clara.

¿Cómo deben los ingenieros seguir una transacción SBI en Wireshark?

Una vez comprendidos los conceptos de HTTP/2, el siguiente paso es aplicarlos al análisis real de paquetes. Como una sola conexión TCP puede transportar varios Streams HTTP/2 simultáneamente, filtrar únicamente por direcciones IP de origen y destino puede dejar mezcladas varias transacciones SBI no relacionadas en la misma captura.

Un enfoque práctico consiste en identificar primero las direcciones IP de la NF consumidora y la NF productora, y después restringir el análisis mediante el Stream ID correspondiente.

Por ejemplo, si una solicitud concreta utiliza el Stream ID 1, se puede combinar la dirección del servidor con ese Stream ID para aislar las Frames que pertenecen a la transacción de solicitud-respuesta correspondiente.

Después de filtrar el tráfico, conviene centrarse en la siguiente información:

• Stream ID: confirma si las Frames pertenecen al mismo Stream lógico.

• HEADERS: muestra el método HTTP, la ruta y otros campos de cabecera.

• DATA: muestra si la transacción transporta una carga de aplicación JSON.

• Código de estado: indica cómo procesó la solicitud la NF productora.

• URI: identifica el servicio exacto, la versión de API y el recurso al que se accede.

Una secuencia de diagnóstico útil consiste en comenzar por la capa de transporte y avanzar hacia arriba. Primero, confirme que la conexión TCP está establecida. Si TCP no está disponible, no existe base para la comunicación HTTP/2 ni para las API RESTful.

A continuación, compruebe que la capa HTTP/2 contiene HEADERS y DATA Frames normales, y utilice el Stream ID para asociarlas con la transacción correcta.

Después, compruebe si el método HTTP y la URI coinciden con la operación esperada. Muchos problemas SBI no están causados por la conectividad de red, sino por una ruta de recurso incorrecta, una versión de API equivocada o un método HTTP inadecuado.

A continuación, examine el código de estado HTTP. Una respuesta 4xx debe orientar la investigación hacia la sintaxis de la solicitud, recursos ausentes, autorización o parámetros de aplicación. Una respuesta 5xx apunta con más fuerza al procesamiento dentro de la NF productora.

Solo después de confirmar que la solicitud HTTP se entregó correctamente debería examinarse en detalle la carga JSON.

Por tanto, la ruta completa de diagnóstico SBI puede resumirse como:

TCP → Conexión HTTP/2 → Stream → HEADERS → Método/URI → DATA/JSON → Código de estado

Este enfoque convierte lo que inicialmente puede parecer un protocolo 5GC muy «al estilo de Internet» en un problema de ingeniería por capas conocido. Verifique la conectividad en la parte inferior, el comportamiento de transporte HTTP/2 en la parte intermedia y los recursos API y datos de negocio en la parte superior. Así resulta mucho más sencillo localizar el límite del fallo.

Desde una perspectiva más amplia de la arquitectura 5GC, SBI no utiliza HTTP/2 simplemente porque sea más nuevo que HTTP/1.1. La razón de fondo es que el núcleo 5G organiza las capacidades de las NF como servicios y, por ello, necesita un modelo de comunicación capaz de admitir eficazmente llamadas API frecuentes, interacciones simultáneas entre servicios y acceso orientado a recursos.

HTTP/2 proporciona Connections, Streams y Frames. La multiplexación mejora el aprovechamiento de la conexión, HPACK reduce la sobrecarga de cabeceras repetidas y el entramado binario aporta un formato de transporte estructurado. JSON transporta los datos de aplicación, mientras que las API RESTful definen los recursos y las operaciones realizadas sobre ellos. En conjunto, estos elementos forman el modelo completo de comunicación utilizado por la interfaz basada en servicios del 5GC.

Preguntas frecuentes

¿HTTP/2 y las API RESTful son lo mismo?

No. HTTP/2 es un protocolo de transporte HTTP que define mecanismos como Connections, Streams y Frames. REST es un estilo arquitectónico de API que define cómo se representan los objetos de aplicación como recursos y cómo se accede a ellos mediante URI y métodos HTTP. La SBI del 5GC utiliza API de estilo RESTful sobre HTTP/2.

¿Puede el Stream ID 0 transportar una solicitud normal de aplicación SBI?

No. El Stream ID 0 tiene una función especial a nivel de protocolo y no se utiliza como Stream normal de aplicación. Al analizar solicitudes SBI reales, los ingenieros deben centrarse en los Stream ID distintos de cero asignados a las transacciones de negocio.

¿Debe apiRoot de SBI contener una dirección IP?

No necesariamente. La forma lógica de apiRoot es http(s)://host(:port). El host identifica el punto de servicio correspondiente de acuerdo con la arquitectura de red y el mecanismo de descubrimiento de servicios. Al analizar una URI, es útil separar apiRoot de apiName, apiVersion y la ruta específica del recurso.

Si HTTP/2 utiliza entramado binario, ¿por qué todavía puede verse JSON dentro de las DATA Frames?

El entramado binario se refiere a cómo HTTP/2 organiza y transporta los datos del protocolo. No exige que la carga de la capa de aplicación utilice también un formato de datos binario. Una DATA Frame puede seguir transportando JSON. JSON define los campos de aplicación del 5GC, mientras que HTTP/2 coloca esa carga en el Stream correspondiente para su transporte.

¿Una respuesta HTTP 200 demuestra que todo el procedimiento 5GC tuvo éxito?

No. HTTP 200 solo indica que esa solicitud HTTP concreta se procesó correctamente en ese punto. Un procedimiento 5GC completo puede implicar varias llamadas de servicio entre distintas funciones de red. Los ingenieros aún deben evaluar la URI, el contenido JSON y la secuencia de señalización circundante antes de concluir que todo el procedimiento de extremo a extremo terminó correctamente.