Pourquoi la SBI du 5GC est-elle organisée autour d’appels de service HTTP/2 ?

La relation entre les fonctions réseau a profondément changé lorsque le cœur 5G a adopté une architecture orientée services. Des fonctions telles que l’AMF, le SMF, l’UDM, le PCF, le NSSF et l’AUSF ne sont plus limitées à l’échange de messages sur des interfaces de protocole point à point fixes. Chaque NF expose désormais des capacités sous forme de services que d’autres fonctions réseau peuvent consommer selon leurs besoins.

Dans ce modèle, une NF peut récupérer une ressource auprès d’une autre NF, créer un nouveau contexte, mettre à jour une ressource existante ou supprimer une ressource devenue inutile. Le schéma de communication devient naturellement requête → opération sur la ressource → réponse. Les méthodes HTTP, les URI, les codes d’état et JSON offrent un moyen pratique de représenter ce type d’interaction de service.

Une pile de protocoles SBI simplifiée peut être représentée ainsi :

Application/JSON → HTTP/2 → TCP → IP → Ethernet

JSON définit la représentation des données applicatives. HTTP/2 organise les requêtes et les réponses pour le transport. TCP assure une livraison fiable, IP gère l’adressage et le routage, et Ethernet transporte les trames sur le réseau sous-jacent.

Cela diffère nettement d’interfaces telles que N2, N3 et N4. N2 utilise NGAP, N4 utilise PFCP et le plan utilisateur emploie couramment GTP-U. L’interface orientée services utilise HTTP/2 comme cadre de transport des communications de service. Il ne s’agit pas d’un simple remplacement de protocole, mais d’une évolution plus large de la philosophie de conception du 5GC : passer de l’échange de messages d’interface prédéfinis à l’invocation de services.

Par exemple, lorsque l’AMF a besoin de données d’abonnement de gestion d’accès pour un abonné, l’AMF agit comme NF consommatrice et demande une ressource à l’UDM qui joue le rôle de NF productrice. La consommatrice doit surtout savoir quelle ressource atteindre, quelle opération effectuer et quel résultat est renvoyé. Il n’est pas nécessaire de concevoir un mécanisme de transport entièrement distinct pour chaque procédure de service.

HTTP/2 apporte aussi un avantage très concret dans cet environnement : plusieurs requêtes de service peuvent partager une seule connexion TCP. Les interactions SBI entre fonctions réseau sont fréquentes ; ouvrir une nouvelle connexion TCP pour chaque appel d’API créerait donc une surcharge inutile de gestion des connexions.

Quels problèmes de transport HTTP/2 résout-il par rapport à HTTP/1.1 ?

HTTP/2 n’a pas remplacé l’ensemble du modèle applicatif de HTTP/1.1. Des méthodes comme GET et POST existent toujours et le modèle de base requête-réponse reste familier. Les principaux changements concernent la manière dont les données sont organisées et transmises.

Pour le 5GC, l’accélération du chargement de pages web n’est pas l’enjeu principal. La vraie valeur de HTTP/2 est de fournir un modèle de connexion plus efficace pour un grand nombre d’appels d’API simultanés entre fonctions réseau.

Une seule connexion peut transporter plusieurs Streams

HTTP/1.1 prend en charge les connexions persistantes, mais la concurrence sur une seule connexion reste limitée. Dans de nombreux déploiements traditionnels, plusieurs connexions TCP sont ouvertes pour augmenter le parallélisme, ce qui ajoute une surcharge de gestion côté client comme côté serveur.

HTTP/2 introduit le multiplexage. Une seule connexion TCP peut contenir simultanément plusieurs Streams indépendants. Une nouvelle requête n’a pas besoin d’attendre la fin complète d’une transaction précédente avant que du trafic supplémentaire soit transmis. Les Frames de plusieurs Streams peuvent être entrelacées sur la même connexion.

Dans un environnement SBI 5GC, lorsqu’un AMF établit une connexion HTTP/2 avec une autre NF, cette connexion n’est pas limitée au traitement d’une seule requête API à la fois. Plusieurs opérations de service peuvent utiliser des Streams différents, chacun transportant sa propre requête et sa propre réponse.

Moins de connexions TCP signifie moins de surcharge de gestion, ce qui convient bien aux interactions de service fréquentes entre les fonctions réseau du cœur 5G.

Les messages HTTP sont transportés sous forme de Frames binaires

HTTP/1.x est largement orienté texte. Les lignes de requête, les en-têtes et les corps de message sont clairement représentés sous forme de structures textuelles. HTTP/2 modifie le format sur le réseau et transporte les informations de protocole dans des Frames binaires.

Les en-têtes HTTP sont généralement transportés dans des HEADERS Frames, tandis que la charge applicative réelle peut être transportée dans des DATA Frames. Le récepteur utilise les informations de l’en-tête de Frame, notamment l’identifiant de Stream, pour déterminer à quel Stream appartient une Frame donnée puis reconstruire le message HTTP complet.

C’est pourquoi une capture HTTP/2 dans Wireshark ne ressemble souvent pas à un bloc complet de texte HTTP. L’ingénieur observe plutôt une suite de HEADERS, DATA et d’autres types de Frame.

Les en-têtes répétés n’ont pas besoin d’être renvoyés intégralement à chaque fois

Les en-têtes HTTP apparaissent de manière répétée dans le trafic des API SBI. Si chaque requête transportait intégralement les mêmes champs d’en-tête, la surcharge dupliquée deviendrait rapidement importante.

HTTP/2 utilise HPACK pour compresser les en-têtes. En simplifiant, les deux extrémités maintiennent des tables d’en-têtes, ce qui permet de représenter les champs fréquemment répétés par des index au lieu de retransmettre le texte complet à chaque fois.

Plus les en-têtes sont répétitifs, plus la compression est utile. Lorsque les fonctions réseau invoquent régulièrement des API similaires, des champs comme les méthodes, les chemins et les en-têtes courants reviennent souvent, ce qui rend HPACK particulièrement efficace pour réduire les transmissions redondantes.

HTTP/2 définit aussi le Server Push

HTTP/2 inclut un mécanisme de Server Push et définit la PUSH_PROMISE Frame, qui permet au serveur de fournir de manière proactive des ressources associées avant que le client ne les demande explicitement une par une.

Pour comprendre la SBI du 5GC, le Server Push n’est toutefois pas le concept prioritaire. La réutilisation des connexions, le multiplexage, les Streams, les Frames, la compression des en-têtes et le modèle requête-réponse des API sont bien plus importants pour l’analyse pratique de SBI.

Comment comprendre Connection, Stream, Message et Frame ?

L’un des aspects les plus déroutants de HTTP/2 est que les termes Connection, Stream, Message et Frame apparaissent souvent ensemble. Il est beaucoup plus simple de les comprendre comme une hiérarchie que de mémoriser chaque définition séparément.

Une Connection est la connexion TCP sous-jacente. Une fois la session TCP établie, le trafic HTTP/2 est transporté sur cette connexion.

Un Stream est un canal logique bidirectionnel à l’intérieur de la Connection. Chaque Stream possède son propre identifiant entier. Plusieurs Streams peuvent exister simultanément dans une même connexion TCP, ce qui constitue la base du multiplexage HTTP/2.

Un Message représente une requête ou une réponse HTTP logique. Par exemple, un AMF peut envoyer à l’UDM un message de requête GET, et l’UDM renvoie le message de réponse correspondant.

Une Frame est une unité plus petite utilisée par HTTP/2 pour la transmission effective. Un Message peut être constitué d’une ou plusieurs Frames. Exemples courants :

• HEADERS Frame : transporte les informations d’en-tête HTTP.

• DATA Frame : transporte les données de charge utile applicative.

• Autres types de Frame : assurent la gestion de connexion, le contrôle de flux et d’autres fonctions HTTP/2.

La relation peut donc se résumer ainsi :

Une Connection contient plusieurs Streams. Un Stream transporte des Messages de requête et de réponse, et chaque Message est constitué d’une ou plusieurs Frames.

L’en-tête d’une Frame HTTP/2 contient des champs tels que Length, Type, Flags, des bits réservés et le Stream Identifier. Ce dernier est particulièrement important, car il indique au récepteur à quel Stream logique appartient la Frame.

Même lorsque des Frames provenant de plusieurs Streams arrivent de manière entrelacée, le récepteur peut utiliser le Stream ID pour associer et réassembler correctement les données. C’est le mécanisme fondamental qui permet à HTTP/2 de transporter efficacement plusieurs transactions simultanées sur une seule connexion TCP.

Pour les ingénieurs du cœur 5G, ce concept est particulièrement important lors de l’analyse de paquets. Le trafic SBI ne doit pas être regroupé simplement parce que les paquets apparaissent côte à côte dans une capture. Il faut considérer ensemble le Stream ID, l’URI, la méthode HTTP et l’état de la réponse.

Comment JSON et les API RESTful transforment-ils les capacités du 5GC en ressources ?

HTTP/2 répond à la question de la manière de transporter efficacement le trafic de service. Ce qui définit réellement le modèle applicatif de la SBI du 5GC est la combinaison d’API RESTful et d’une conception orientée ressources.

REST est un style architectural. L’une de ses idées centrales consiste à représenter les objets métier sous forme de ressources, à attribuer une URI unique à chaque ressource puis à utiliser les méthodes HTTP pour effectuer des opérations sur ces ressources.

Une « ressource » dans le 5GC ne se limite pas au type d’objet généralement associé aux sites web. Elle peut représenter des données d’abonné, un SM Context, un objet lié à une PDU Session ou tout autre état maintenu par une fonction réseau.

Par exemple, les données d’abonnement de gestion d’accès d’un abonné peuvent disposer d’une URI donnée, tandis que les données d’abonnement de gestion de session utilisent une autre URI. Du point de vue de la consommatrice, l’opération n’est plus simplement :

« Appeler une procédure de signalisation UDM particulière. »

Elle devient plutôt :

Effectuer une opération GET, POST, PUT/PATCH ou DELETE sur une ressource précise.

Les méthodes HTTP définissent ce qui arrive à une ressource

Les opérations courantes peuvent être comprises ainsi :

• GET : récupérer ou lire une ressource.

• POST : créer une ressource ou invoquer une opération définie.

• PUT / PATCH : mettre à jour une ressource existante.

• DELETE : supprimer une ressource.

Après avoir traité la requête, le serveur renvoie un code d’état HTTP pour indiquer le résultat.

Une réponse 200 indique généralement un traitement réussi avec retour de données. Une réponse 201 indique couramment qu’une ressource a été créée avec succès. Une réponse 204 peut indiquer qu’une opération a réussi sans corps de réponse. Les réponses 4xx signalent le plus souvent un problème de requête, de ressource ou d’autorisation, tandis que les réponses 5xx indiquent généralement un problème de traitement côté serveur.

Ces codes d’état sont extrêmement utiles pour le dépannage 5GC. Le fait qu’une connexion HTTP/2 soit établie ne signifie pas que l’opération de service a réussi. Les ingénieurs doivent encore vérifier l’URI demandée, la méthode HTTP et le code d’état renvoyé par la NF productrice.

JSON transporte les données métier réelles

Les charges applicatives SBI sont généralement représentées en JSON. JSON est un format léger d’échange de données basé sur des structures clé-valeur. Il peut représenter des chaînes, des nombres, des valeurs booléennes, des tableaux, des objets et des structures imbriquées.

Autrement dit, la DATA Frame HTTP/2 transporte la charge utile, tandis que le JSON contenu dans cette Frame définit la signification réelle des données applicatives.

D’un point de vue d’ingénierie, HTTP/2 et JSON ne doivent pas être considérés comme une même couche de protocole. HTTP/2 organise le transport, JSON représente les données applicatives et les API RESTful définissent les ressources ainsi que les opérations possibles sur celles-ci.

Comment une URI de ressource SBI du 5GC est-elle structurée ?

Une fois le concept de ressource compris, la structure d’une URI SBI devient beaucoup plus facile à lire. Les chemins de ressources ne sont pas arbitraires ; ils suivent une hiérarchie structurée.

Un format type peut être représenté ainsi :

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

Chaque partie joue un rôle précis :

• apiRoot : adresse racine utilisée pour accéder au service, généralement sous la forme http(s)://host(:port).

• apiName : nom de l’API ou du service SBI spécifique exposé par la fonction réseau.

• apiVersion : version de l’API, par exemple v1.

• apiSpecificResourceUriPart : chemin identifiant la ressource ou l’opération précise.

Par exemple, les données d’abonnement de gestion d’accès et celles de gestion de session peuvent toutes deux être fournies par l’UDM, mais utilisent des chemins de ressources différents. L’URI permet donc d’identifier précisément la ressource demandée par la consommatrice.

Les services PDU Session du SMF suivent le même principe général. Les différents SM Contexts et ressources liées aux PDU Sessions disposent de leurs propres URI, et différentes méthodes HTTP servent à les créer, les récupérer, les modifier ou les libérer.

Cette conception orientée ressources change la façon dont les ingénieurs doivent aborder les interfaces SBI. Au lieu de mémoriser uniquement une séquence traditionnelle comme « Message A → Message B », une interaction SBI peut être analysée comme suit :

Service → Ressource → Méthode → URI → Code d’état → Corps JSON

Si l’on aborde la SBI du 5GC uniquement avec la logique télécom traditionnelle consistant à associer des noms de messages de requête à des noms de messages de réponse, l’architecture peut sembler fragmentée. Dès qu’on la considère comme un modèle de ressources basé sur des API, la logique devient beaucoup plus claire.

Comment les ingénieurs doivent-ils suivre une transaction SBI dans Wireshark ?

Une fois les concepts HTTP/2 compris, l’étape suivante consiste à les appliquer à l’analyse réelle des paquets. Comme une seule connexion TCP peut transporter plusieurs Streams HTTP/2 simultanément, un filtrage limité aux adresses IP source et destination peut encore laisser plusieurs transactions SBI sans rapport mélangées dans la même capture.

Une méthode pratique consiste à identifier d’abord les adresses IP de la NF consommatrice et de la NF productrice, puis à affiner l’analyse à l’aide du Stream ID concerné.

Par exemple, si une requête précise utilise le Stream ID 1, l’adresse du serveur et cet identifiant peuvent être utilisés ensemble pour isoler les Frames appartenant à la transaction requête-réponse correspondante.

Après filtrage du trafic, concentrez-vous sur les informations suivantes :

• Stream ID : confirme si les Frames appartiennent au même Stream logique.

• HEADERS : révèle la méthode HTTP, le chemin et les autres champs d’en-tête.

• DATA : indique si la transaction transporte une charge applicative JSON.

• Code d’état : indique comment la NF productrice a traité la requête.

• URI : identifie le service exact, la version de l’API et la ressource consultée.

Une séquence de dépannage utile consiste à commencer par la couche de transport et à remonter. Vérifiez d’abord que la connexion TCP est établie. Sans TCP, il n’existe aucune base pour HTTP/2 ni pour la communication par API RESTful.

Vérifiez ensuite que la couche HTTP/2 contient des HEADERS et DATA Frames normales et utilisez le Stream ID pour les associer à la bonne transaction.

Contrôlez ensuite si la méthode HTTP et l’URI correspondent à l’opération attendue. De nombreux problèmes SBI ne sont pas dus à la connectivité réseau, mais à un chemin de ressource incorrect, une mauvaise version d’API ou une méthode HTTP inadaptée.

Examinez ensuite le code d’état HTTP. Une réponse 4xx doit orienter l’enquête vers la syntaxe de la requête, une ressource absente, l’autorisation ou les paramètres applicatifs. Une réponse 5xx pointe plus fortement vers le traitement interne de la NF productrice.

La charge JSON ne doit être examinée en détail qu’après avoir confirmé que la requête HTTP a été correctement délivrée.

Le chemin complet de dépannage SBI peut donc être résumé ainsi :

TCP → Connexion HTTP/2 → Stream → HEADERS → Méthode/URI → DATA/JSON → Code d’état

Cette approche transforme ce qui peut d’abord sembler être un protocole 5GC très « Internet » en un problème d’ingénierie en couches bien connu. Vérifiez la connectivité en bas, le comportement du transport HTTP/2 au milieu, puis les ressources d’API et les données métier en haut. La limite de la panne devient beaucoup plus facile à localiser.

D’un point de vue plus global de l’architecture 5GC, la SBI n’utilise pas HTTP/2 simplement parce qu’il est plus récent que HTTP/1.1. La raison profonde est que le cœur 5G organise les capacités des NF sous forme de services et a donc besoin d’un modèle de communication capable de gérer efficacement des appels API fréquents, des interactions de services simultanées et un accès orienté ressources.

HTTP/2 fournit des Connections, des Streams et des Frames. Le multiplexage améliore l’utilisation des connexions, HPACK réduit la surcharge des en-têtes répétés et le découpage binaire fournit un format de transport structuré. JSON transporte les données applicatives, tandis que les API RESTful définissent les ressources et les opérations qui leur sont appliquées. Ensemble, ces éléments forment le modèle complet de communication utilisé par l’interface orientée services du 5GC.

Questions fréquentes

HTTP/2 et les API RESTful sont-ils la même chose ?

Non. HTTP/2 est un protocole de transport HTTP qui définit des mécanismes tels que Connections, Streams et Frames. REST est un style architectural d’API qui définit comment les objets applicatifs sont représentés comme des ressources et comment ces ressources sont accessibles via des URI et des méthodes HTTP. La SBI du 5GC utilise des API de style RESTful au-dessus de HTTP/2.

Le Stream ID 0 peut-il transporter une requête applicative SBI normale ?

Non. Le Stream ID 0 a un rôle particulier au niveau du protocole et n’est pas utilisé comme Stream applicatif normal. Lors de l’analyse de requêtes SBI réelles, les ingénieurs doivent se concentrer sur les Stream ID non nuls attribués aux transactions métier.

L’apiRoot de la SBI doit-il contenir une adresse IP ?

Pas nécessairement. La forme logique de apiRoot est http(s)://host(:port). Le host identifie le point de terminaison de service pertinent selon l’architecture réseau et le mécanisme de découverte de services. Lors de l’analyse d’une URI, il est utile de distinguer apiRoot de apiName, apiVersion et du chemin propre à la ressource.

Si HTTP/2 utilise des Frames binaires, pourquoi voit-on encore du JSON dans les DATA Frames ?

Le découpage binaire décrit la manière dont HTTP/2 organise et transporte les données du protocole. Il n’impose pas à la charge applicative d’utiliser elle-même un format de données binaire. Une DATA Frame peut toujours transporter du JSON. JSON définit les champs applicatifs du 5GC, tandis que HTTP/2 place cette charge dans le Stream approprié pour la transporter.

Une réponse HTTP 200 prouve-t-elle que toute la procédure 5GC a réussi ?

Non. HTTP 200 indique uniquement que la requête HTTP précise a été traitée avec succès à ce point. Une procédure 5GC complète peut impliquer plusieurs appels de service entre plusieurs fonctions réseau. Les ingénieurs doivent encore évaluer l’URI, le contenu JSON et la séquence de signalisation environnante avant de conclure que toute la procédure de bout en bout s’est achevée correctement.