Por que a SBI do 5GC é construída em torno de chamadas de serviço HTTP/2?

A relação entre as funções de rede mudou significativamente quando o núcleo 5G adotou uma arquitetura baseada em serviços. Funções como AMF, SMF, UDM, PCF, NSSF e AUSF deixaram de ficar limitadas à troca de mensagens por interfaces fixas de protocolo ponto a ponto. Em vez disso, cada NF expõe suas capacidades como serviços que outras funções de rede podem consumir quando necessário.

Nesse modelo, uma NF pode recuperar um recurso de outra NF, criar um novo contexto, atualizar um recurso existente ou excluir um recurso que não seja mais necessário. O padrão de comunicação passa naturalmente a ser solicitação → operação sobre o recurso → resposta. Métodos HTTP, URIs, códigos de status e JSON oferecem uma forma prática de representar esse tipo de interação de serviço.

Uma pilha de protocolos SBI simplificada pode ser representada como:

Aplicação/JSON → HTTP/2 → TCP → IP → Ethernet

JSON define como os dados da aplicação são representados. HTTP/2 organiza solicitações e respostas para transporte. TCP fornece entrega confiável, IP trata do endereçamento e roteamento, e Ethernet transporta os quadros pela rede subjacente.

Isso é bem diferente de interfaces como N2, N3 e N4. N2 usa NGAP, N4 usa PFCP e o plano de usuário normalmente usa GTP-U. A Interface Baseada em Serviços usa HTTP/2 como estrutura de transporte para a comunicação entre serviços. Isso não é apenas uma substituição de protocolo. Reflete uma mudança mais ampla na filosofia de projeto do 5GC: sair da troca de mensagens predefinidas de interface e passar para a invocação de serviços.

Por exemplo, quando a AMF precisa de dados de assinatura de gerenciamento de acesso de um assinante, a AMF atua como NF consumidora e solicita um recurso à UDM, que atua como NF produtora. A consumidora precisa principalmente saber qual recurso acessar, qual operação executar e qual resultado é retornado. Não há necessidade de projetar um mecanismo de transporte completamente separado para cada procedimento de serviço.

HTTP/2 também oferece uma vantagem bastante prática nesse ambiente: várias solicitações de serviço podem compartilhar uma única conexão TCP. As interações SBI entre funções de rede são frequentes, e estabelecer repetidamente novas conexões TCP para cada chamada de API criaria uma sobrecarga desnecessária de gerenciamento de conexões.

Quais problemas de transporte o HTTP/2 resolve em comparação com o HTTP/1.1?

HTTP/2 não substituiu todo o modelo de aplicação do HTTP/1.1. Métodos como GET e POST continuam existindo, e o modelo básico de solicitação e resposta permanece conhecido. As principais mudanças estão na forma como os dados são organizados e transmitidos.

No 5GC, carregar páginas da web mais rapidamente não é o ponto importante. O valor real é que HTTP/2 oferece um modelo de conexão mais eficiente para um grande número de chamadas de API simultâneas entre funções de rede.

Uma conexão pode transportar vários Streams

HTTP/1.1 oferece conexões persistentes, mas a simultaneidade em uma única conexão ainda tem limitações. Em muitas implantações tradicionais, várias conexões TCP são abertas para aumentar o paralelismo, o que acrescenta sobrecarga de gerenciamento tanto no cliente quanto no servidor.

HTTP/2 introduz multiplexação. Uma única conexão TCP pode conter vários Streams independentes ao mesmo tempo. As solicitações não precisam aguardar a conclusão total de uma transação anterior para que tráfego adicional seja transmitido. Frames de vários Streams podem ser intercalados na mesma conexão.

Em um ambiente SBI de 5GC, depois que uma AMF estabelece uma conexão HTTP/2 com outra NF, essa conexão não fica limitada a processar apenas uma solicitação de API por vez. Várias operações de serviço podem usar Streams diferentes, cada um transportando sua própria solicitação e resposta.

Menos conexões TCP significam menor sobrecarga de gerenciamento, algo adequado às interações de serviço de alta frequência entre as funções de rede do núcleo 5G.

Mensagens HTTP são transportadas como Frames binários

HTTP/1.x é em grande parte orientado a texto. Linhas de solicitação, cabeçalhos e corpos de mensagem são representados claramente como estruturas textuais. HTTP/2 altera o formato de transmissão e transporta informações de protocolo em Frames binários.

Os cabeçalhos HTTP normalmente são transportados em HEADERS Frames, enquanto a carga útil real da aplicação pode ser transportada em DATA Frames. O receptor usa as informações do cabeçalho da Frame, incluindo o identificador de Stream, para determinar a qual Stream uma determinada Frame pertence e então reconstruir a mensagem HTTP completa.

É por isso que uma captura HTTP/2 no Wireshark muitas vezes não parece um bloco completo de texto HTTP. Em vez disso, o engenheiro vê uma sequência de HEADERS, DATA e outros tipos de Frame.

Cabeçalhos repetidos não precisam ser enviados por inteiro todas as vezes

Os cabeçalhos HTTP aparecem repetidamente no tráfego de API SBI. Se cada solicitação carregasse integralmente os mesmos campos de cabeçalho, a sobrecarga duplicada rapidamente se tornaria significativa.

HTTP/2 usa HPACK para compressão de cabeçalhos. De forma simplificada, os dois lados mantêm tabelas de cabeçalhos, permitindo que campos repetidos com frequência sejam representados por índices em vez de retransmitir o texto completo em todas as solicitações.

Quanto mais repetitivos forem os cabeçalhos, maior será o benefício da compressão. Quando funções de rede invocam APIs semelhantes repetidamente, campos como métodos, caminhos e cabeçalhos comuns aparecem várias vezes, tornando o HPACK especialmente eficaz para reduzir transmissões redundantes.

HTTP/2 também define Server Push

HTTP/2 inclui um mecanismo de Server Push e define a PUSH_PROMISE Frame, permitindo que um servidor forneça proativamente recursos relacionados antes de o cliente solicitar explicitamente cada um deles.

Para compreender a SBI do 5GC, porém, Server Push não é o conceito principal. Reutilização de conexões, multiplexação, Streams, Frames, compressão de cabeçalhos e o modelo de solicitação-resposta das APIs são muito mais importantes para a análise prática de SBI.

Como entender Connection, Stream, Message e Frame?

Uma das partes mais confusas do HTTP/2 é que os termos Connection, Stream, Message e Frame aparecem frequentemente juntos. É muito mais fácil entendê-los como uma hierarquia do que memorizar cada definição de forma isolada.

Uma Connection é a conexão TCP subjacente. Depois que a sessão TCP é estabelecida, o tráfego HTTP/2 é transportado por essa conexão.

Um Stream é um canal lógico bidirecional dentro da Connection. Cada Stream tem seu próprio identificador inteiro. Vários Streams podem existir simultaneamente dentro de uma única conexão TCP, o que constitui a base da multiplexação do HTTP/2.

Um Message representa uma solicitação ou resposta HTTP lógica. Por exemplo, uma AMF pode enviar uma mensagem de solicitação GET à UDM, e a UDM retorna a mensagem de resposta correspondente.

Uma Frame é uma unidade menor usada pelo HTTP/2 para a transmissão efetiva. Um Message pode ser formado por uma ou mais Frames. Exemplos comuns incluem:

• HEADERS Frame: transporta informações de cabeçalho HTTP.

• DATA Frame: transporta os dados da carga útil da aplicação.

• Outros tipos de Frame: dão suporte ao gerenciamento de conexões, controle de fluxo e outras funções do HTTP/2.

A relação pode ser resumida da seguinte forma:

Uma Connection contém vários Streams. Um Stream transporta Messages de solicitação e resposta, e cada Message é composto por uma ou mais Frames.

O cabeçalho de uma Frame HTTP/2 contém campos como Length, Type, Flags, bits reservados e Stream Identifier. O Stream Identifier é especialmente importante porque informa ao receptor a qual Stream lógica a Frame pertence.

Mesmo quando Frames de vários Streams chegam em ordem intercalada, o receptor pode usar o Stream ID para associar e remontar os dados corretos. Esse é o mecanismo central que permite ao HTTP/2 transportar várias transações simultâneas com eficiência sobre uma única conexão TCP.

Para engenheiros de núcleo 5G, esse conceito é especialmente importante na análise de pacotes. O tráfego SBI não deve ser agrupado simplesmente porque os pacotes aparecem próximos uns dos outros em uma captura. Stream ID, URI, método HTTP e status da resposta devem ser considerados em conjunto.

Como JSON e APIs RESTful transformam capacidades do 5GC em recursos?

HTTP/2 responde à questão de como o tráfego de serviços é transportado com eficiência. O que realmente define o modelo de aplicação da SBI do 5GC é a combinação de APIs RESTful com um projeto orientado a recursos.

REST é um estilo de arquitetura. Uma de suas principais ideias é representar objetos de negócio como recursos, atribuir a cada recurso uma URI exclusiva e então usar métodos HTTP para executar operações sobre esses recursos.

Um “recurso” no 5GC não se limita ao tipo de objeto normalmente associado a sites da web. Ele pode representar dados de assinante, um SM Context, um objeto relacionado a uma PDU Session ou outro estado mantido por uma função de rede.

Por exemplo, os dados de assinatura de gerenciamento de acesso de um assinante podem ter uma URI específica, enquanto os dados de assinatura de gerenciamento de sessão podem usar outra. Do ponto de vista da consumidora, a operação deixa de ser simplesmente:

“Chamar um procedimento específico de sinalização da UDM.”

Em vez disso, passa a ser:

Executar uma operação GET, POST, PUT/PATCH ou DELETE em um recurso específico.

Métodos HTTP definem o que acontece com um recurso

As operações comuns podem ser entendidas da seguinte forma:

• GET: obter ou ler um recurso.

• POST: criar um recurso ou invocar uma operação definida.

• PUT / PATCH: atualizar um recurso existente.

• DELETE: remover um recurso.

Após processar a solicitação, o servidor retorna um código de status HTTP para indicar o resultado.

Uma resposta 200 normalmente indica processamento bem-sucedido e retorno de dados. Uma resposta 201 geralmente indica que um recurso foi criado com sucesso. Uma resposta 204 pode indicar que uma operação foi concluída sem retornar corpo de resposta. Respostas 4xx normalmente apontam para problemas de solicitação, recurso ou autorização, enquanto respostas 5xx geralmente indicam problemas de processamento no lado do servidor.

Esses códigos de status são extremamente úteis na solução de problemas do 5GC. Uma conexão HTTP/2 estabelecida não significa que a operação do serviço tenha sido bem-sucedida. O engenheiro ainda precisa verificar a URI solicitada, o método HTTP e o código de status retornado pela NF produtora.

JSON transporta os dados reais de negócio

As cargas de aplicação SBI são normalmente representadas em JSON. JSON é um formato leve de intercâmbio de dados baseado em estruturas de chave-valor. Ele pode representar strings, números, valores booleanos, arrays, objetos e estruturas de dados aninhadas.

Em outras palavras, a DATA Frame do HTTP/2 é responsável por transportar a carga útil, enquanto o JSON dentro dessa Frame define o que os dados da aplicação realmente significam.

Do ponto de vista de engenharia, HTTP/2 e JSON não devem ser tratados como a mesma camada de protocolo. HTTP/2 organiza o transporte, JSON representa os dados da aplicação e APIs RESTful definem os recursos e as operações que podem ser realizadas sobre eles.

Como é estruturada uma URI de recurso da SBI do 5GC?

Depois que o conceito de recurso está claro, a estrutura de uma URI SBI fica muito mais fácil de entender. Caminhos de recurso não são arbitrários; eles seguem uma hierarquia estruturada.

Um formato típico pode ser representado como:

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

Cada parte tem uma função específica:

• apiRoot: endereço raiz usado para acessar o serviço, normalmente no formato http(s)://host(:port).

• apiName: nome da API ou do serviço SBI específico exposto pela função de rede.

• apiVersion: versão da API, por exemplo v1.

• apiSpecificResourceUriPart: caminho que identifica o recurso ou a operação específica.

Por exemplo, dados de assinatura de gerenciamento de acesso e de gerenciamento de sessão podem ser fornecidos pela UDM, mas utilizam caminhos de recurso diferentes. A URI, portanto, permite identificar claramente qual recurso a consumidora está solicitando.

Os serviços de PDU Session da SMF seguem a mesma ideia geral. Diferentes SM Contexts e recursos relacionados a PDU Session têm suas próprias URIs, e diferentes métodos HTTP são usados para criá-los, recuperá-los, modificá-los ou liberá-los.

Esse projeto orientado a recursos muda a forma como engenheiros devem pensar sobre interfaces SBI. Em vez de memorizar apenas uma sequência tradicional como “Mensagem A → Mensagem B”, uma interação SBI pode ser analisada como:

Serviço → Recurso → Método → URI → Código de status → Corpo JSON

Se a SBI do 5GC for analisada apenas com a mentalidade tradicional de telecomunicações de associar nomes de mensagens de solicitação aos nomes de mensagens de resposta, a arquitetura pode parecer fragmentada. Quando é vista como um modelo de recursos baseado em API, a lógica fica muito mais clara.

Como engenheiros devem rastrear uma transação SBI no Wireshark?

Depois de entender os conceitos de HTTP/2, o próximo passo é aplicá-los à análise real de pacotes. Como uma única conexão TCP pode transportar vários Streams HTTP/2 ao mesmo tempo, filtrar apenas pelos endereços IP de origem e destino ainda pode deixar várias transações SBI sem relação misturadas na mesma captura.

Uma abordagem prática é identificar primeiro os endereços IP da NF consumidora e da NF produtora e depois restringir a análise usando o Stream ID relevante.

Por exemplo, se uma determinada solicitação estiver usando Stream ID 1, o endereço do servidor e esse Stream ID podem ser usados em conjunto para isolar os Frames que pertencem à transação de solicitação-resposta correspondente.

Depois de filtrar o tráfego, concentre-se nas seguintes informações:

• Stream ID: confirma se os Frames pertencem à mesma Stream lógica.

• HEADERS: revela o método HTTP, o caminho e outros campos do cabeçalho.

• DATA: mostra se a transação transporta uma carga de aplicação JSON.

• Código de status: indica como a NF produtora processou a solicitação.

• URI: identifica o serviço exato, a versão da API e o recurso acessado.

Uma sequência útil de solução de problemas é começar pela camada de transporte e avançar para cima. Primeiro, confirme que a conexão TCP está estabelecida. Se TCP não estiver disponível, não há base para comunicação HTTP/2 nem para APIs RESTful.

Em seguida, verifique se a camada HTTP/2 contém HEADERS e DATA Frames normais e use o Stream ID para associá-los à transação correta.

Depois, verifique se o método HTTP e a URI correspondem à operação esperada. Muitos problemas de SBI não são causados por conectividade de rede, mas por caminho de recurso incorreto, versão de API errada ou método HTTP inadequado.

Depois disso, examine o código de status HTTP. Uma resposta 4xx deve direcionar a investigação para a sintaxe da solicitação, recursos ausentes, autorização ou parâmetros da aplicação. Uma resposta 5xx aponta com mais força para o processamento dentro da NF produtora.

Somente depois de confirmar que a solicitação HTTP foi entregue corretamente a carga JSON deve ser analisada em detalhes.

O caminho completo de solução de problemas SBI pode ser resumido como:

TCP → Conexão HTTP/2 → Stream → HEADERS → Método/URI → DATA/JSON → Código de status

Essa abordagem transforma o que inicialmente pode parecer um protocolo 5GC muito “ao estilo da Internet” em um problema conhecido de engenharia em camadas. Verifique a conectividade na base, o comportamento de transporte HTTP/2 no meio e os recursos de API e dados de negócio no topo. Assim, o limite da falha fica muito mais fácil de identificar.

De uma perspectiva mais ampla da arquitetura 5GC, a SBI não usa HTTP/2 simplesmente por ele ser mais novo que HTTP/1.1. A razão mais profunda é que o núcleo 5G organiza as capacidades das NFs como serviços e, portanto, precisa de um modelo de comunicação capaz de suportar com eficiência chamadas frequentes de API, interações simultâneas entre serviços e acesso orientado a recursos.

HTTP/2 fornece Connections, Streams e Frames. A multiplexação melhora a utilização da conexão, HPACK reduz a sobrecarga de cabeçalhos repetidos e o enquadramento binário oferece um formato de transporte estruturado. JSON transporta os dados da aplicação, enquanto APIs RESTful definem os recursos e as operações executadas sobre eles. Juntos, esses elementos formam o modelo completo de comunicação usado pela Interface Baseada em Serviços do 5GC.

Perguntas frequentes

HTTP/2 e APIs RESTful são a mesma coisa?

Não. HTTP/2 é um protocolo de transporte HTTP que define mecanismos como Connections, Streams e Frames. REST é um estilo de arquitetura de API que define como objetos de aplicação são representados como recursos e como esses recursos são acessados por URIs e métodos HTTP. A SBI do 5GC usa APIs de estilo RESTful sobre HTTP/2.

O Stream ID 0 pode transportar uma solicitação normal de aplicação SBI?

Não. O Stream ID 0 tem uma função especial no nível do protocolo e não é usado como Stream normal de aplicação. Ao analisar solicitações SBI reais, os engenheiros devem se concentrar nos Stream IDs diferentes de zero atribuídos às transações de negócio.

O apiRoot da SBI precisa conter um endereço IP?

Não necessariamente. A forma lógica de apiRoot é http(s)://host(:port). O host identifica o endpoint de serviço relevante de acordo com a arquitetura de rede e o mecanismo de descoberta de serviços. Ao analisar uma URI, é útil separar apiRoot de apiName, apiVersion e do caminho específico do recurso.

Se HTTP/2 usa enquadramento binário, por que ainda é possível ver JSON dentro de DATA Frames?

O enquadramento binário se refere a como HTTP/2 organiza e transporta os dados do protocolo. Isso não exige que a carga da camada de aplicação também use um formato binário. Uma DATA Frame ainda pode transportar JSON. JSON define os campos de aplicação do 5GC, enquanto HTTP/2 coloca essa carga na Stream apropriada para transporte.

Uma resposta HTTP 200 prova que todo o procedimento 5GC foi bem-sucedido?

Não. HTTP 200 indica apenas que aquela solicitação HTTP específica foi processada com sucesso naquele ponto. Um procedimento 5GC completo pode envolver várias chamadas de serviço entre diversas funções de rede. Os engenheiros ainda precisam avaliar a URI, o conteúdo JSON e a sequência de sinalização ao redor antes de concluir que todo o procedimento de ponta a ponta foi concluído com sucesso.