Une panne du réseau cœur n’est pas toujours due à un manque de puissance de traitement. Très souvent, le véritable problème est l’état. Si une fonction réseau tombe en panne mais que le contexte utilisateur existe toujours dans un emplacement fiable, une autre fonction peut poursuivre le service. Si le contexte disparaît avec le nœud défaillant, la reprise devient beaucoup plus difficile. C’est la logique qui sous-tend l’une des idées de conception importantes de la 5GC : séparer les ressources de calcul des ressources de stockage.

Dans un réseau cœur mobile, le contexte utilisateur peut comprendre l’état d’enregistrement, des informations de mobilité, des identités temporaires, des données liées aux sessions, des références de localisation et d’autres états de service. Ces valeurs permettent au réseau de savoir qui est l’UE, où il se trouve, quelle session il utilise et comment la signalisation ultérieure doit être traitée. Lorsqu’un tel contexte est étroitement lié à une seule instance locale de fonction réseau, cette instance devient plus qu’un nœud de traitement : elle devient un point unique de risque pour la continuité du service.

La 5GC réduit ce risque en prenant en charge davantage de fonctions réseau sans état. Cela ne signifie pas qu’une fonction réseau n’utilise jamais d’état pendant son fonctionnement. L’idée essentielle est plutôt que l’état durable ou récupérable ne doit pas rester enfermé dans une seule instance locale de calcul. En permettant de stocker et de récupérer via l’UDSF des données non structurées telles que le contexte UE, la 5GC offre à l’AMF et aux autres fonctions réseau un modèle de reprise plus souple.

Pourquoi l’état local devient risqué

L’exemple du MME 4G permet de comprendre facilement le problème. Dans un réseau LTE/EPC, après qu’un UE a terminé son attachement via MME1, ce MME crée et stocke localement le contexte UE. Ce contexte peut inclure des informations de gestion de mobilité et de session, telles que la localisation de l’UE, le GUTI et des paramètres liés à l’adresse IP de l’UE.

Si MME1 tombe en panne de manière inattendue, MME2 peut rester physiquement disponible dans le pool de MME. Toutefois, la présence d’un autre MME ne garantit pas automatiquement la continuité du service. Si le contexte UE n’existe que sur MME1, MME2 ne dispose pas d’informations suffisantes pour continuer à servir l’UE sans interruption. L’utilisateur peut devoir redémarrer l’appareil ou effectuer un nouvel attachement avant le rétablissement du service. Du point de vue de l’expérience utilisateur, ce modèle de reprise est médiocre.

Une solution traditionnelle consiste à utiliser un cluster de MME avec synchronisation actif-secours. Dans cette architecture, le contexte UE est synchronisé en temps réel entre le MME actif et le MME de secours. Si le MME actif tombe en panne, le nœud de secours peut prendre le relais à partir du contexte synchronisé. Cette approche peut réduire les interruptions de service, mais elle présente aussi des limites. Elle peut dépendre d’une mise en œuvre propre au fournisseur, manquer d’un large soutien normatif, augmenter les coûts et réduire la portabilité entre différents environnements système.

Le problème fondamental est que l’état local crée une relation étroite entre une instance de service et ses données. Dès que le nœud de calcul devient le seul détenteur pratique du contexte utilisateur, le basculement se complexifie. La 5GC évolue vers un modèle plus propre en plaçant l’état récupérable dans une fonction de stockage distincte, accessible aux fonctions réseau autorisées.

Ce que change l’UDSF

UDSF signifie Unstructured Data Storage Function, ou fonction de stockage de données non structurées. Elle permet à toute fonction réseau 5GC de stocker et de récupérer ses données non structurées, y compris le contexte UE. Dans ce modèle, l’AMF ou une autre NF peut traiter la signalisation en tant que fonction de calcul, tandis que l’UDSF fournit un emplacement indépendant pour conserver certaines informations d’état.

Ce concept est comparable à celui d’un poste de travail sans disque. Un tel poste dispose d’un CPU, de mémoire, d’une interface réseau et d’autres ressources d’exécution, mais ne conserve pas ses données de travail sur un disque dur local. Il démarre et récupère ses données depuis un serveur réseau. Le poste effectue les calculs, tandis que le stockage est séparé. Dans la 5GC, les fonctions réseau peuvent être conçues de manière similaire : la NF exécute la signalisation et la logique de service, tandis que les données de contexte peuvent être stockées hors de l’instance locale.

La valeur de l’UDSF ne tient pas simplement à son rôle de base de données. Sa valeur architecturale réside dans la prise en charge de NF sans état, de la reprise de l’AMF et de déploiements cloud-native plus souples. Lorsque l’état est accessible via l’UDSF, une instance AMF peut tomber en panne sans provoquer nécessairement la perte définitive du contexte UE. Un nouvel AMF sélectionné peut récupérer le contexte requis et poursuivre le traitement lors de la transaction suivante.

L’UDSF s’inscrit également dans l’évolution plus large vers des réseaux cœur virtualisés et cloud-native. Dans un déploiement cloud, les instances de fonctions réseau peuvent être ajoutées, retirées, redémarrées ou déplacées dans l’infrastructure. Si chaque instance reste fortement propriétaire de son état local, l’automatisation devient difficile. Le découplage du calcul et du stockage rend la mise à l’échelle et la reprise plus faciles à gérer.

Comment les types de données diffèrent

Pour bien comprendre l’UDSF, il est important de distinguer les données structurées des données non structurées. Dans la terminologie 5GC, les données structurées sont celles dont la structure est définie par les spécifications 3GPP. Les données d’abonnement constituent un exemple typique, car la structure de leurs ressources et leur modèle d’accès sont clairement décrits.

Les données non structurées désignent des données dont la structure interne n’est pas définie par les spécifications 3GPP. Le contexte UE en est un exemple typique. Il est essentiel à la continuité du service, mais son organisation interne précise n’est pas normalisée de la même manière que les données d’abonnement. Il se prête donc au stockage via l’UDSF.

Cette différence influence la conception technique. Les données structurées peuvent être gérées au moyen de services de données normalisés reposant sur des modèles de ressources définis. Les données non structurées sont généralement produites et interprétées par la fonction réseau qui porte la logique de service. L’UDSF offre à cette fonction un emplacement pour enregistrer et récupérer les données sans imposer la transformation de tout le format interne en une arborescence de données standardisée.

Pour planifier un déploiement, les ingénieurs ne doivent pas considérer toutes les données 5GC comme une seule catégorie. Les données d’abonnement, les données de politique, l’état de session, le contexte utilisateur temporaire et les informations de reprise peuvent présenter des fréquences d’accès, des sensibilités à la latence, des structures, des responsabilités et des exigences de restauration différentes. L’UDSF se concentre principalement sur le stockage de l’état non structuré dont les fonctions réseau ont besoin pour assurer résilience et continuité.

Comment fonctionne la reprise de l’AMF

Un processus type de reprise d’AMF avec l’UDSF suit une séquence claire. Tout d’abord, un UE 5G s’enregistre via AMF1. AMF1 crée le contexte UE nécessaire à la gestion de l’accès et de la mobilité. Ensuite, AMF1 stocke ce contexte dans l’UDSF. À ce stade, l’état utilisateur n’est plus enfermé uniquement dans l’instance AMF locale.

Si AMF1 tombe en panne, le réseau d’accès 5G ou les fonctions homologues du plan de contrôle détectent la défaillance. L’AMF en panne n’est plus pris en compte pour la sélection. Lorsque le réseau doit choisir un autre AMF dans le même ensemble d’AMF, il peut sélectionner AMF2. C’est à ce niveau que l’UDSF modifie le comportement de reprise.

AMF2 n’a pas besoin de considérer l’UE comme un terminal totalement inconnu. Lorsqu’une transaction intervient avec l’UE, AMF2 peut récupérer le contexte UE depuis l’UDSF. Cette récupération peut utiliser des identifiants tels que SUPI, 5G-GUTI ou AMF UE NGAP ID. Après avoir obtenu le contexte, AMF2 peut traiter le message de l’UE et mettre à jour le 5G-GUTI auprès de l’UE si nécessaire.

Le résultat pratique est une meilleure continuité du service. Le réseau doit toujours disposer d’une détection correcte des pannes, d’une resélection de l’AMF et d’une logique fiable de récupération du contexte, mais la base de reprise est plus solide que dans un modèle où tout le contexte utilisateur est stocké uniquement dans le nœud défaillant. Pour l’utilisateur, le résultat idéal est une reprise qui ne nécessite ni redémarrage du terminal, ni nouvel attachement manuel, ni interruption perceptible du service.

Valeur technique et limites

La principale valeur technique du découplage du calcul et du stockage est la résilience. Si une instance AMF tombe en panne, l’état du service peut rester disponible via l’UDSF. Cela réduit la dépendance à l’état local du nœud et aide le réseau à se rétablir avec moins d’impact. Le modèle prend aussi en charge l’élasticité, car de nouvelles instances de fonctions réseau peuvent être ajoutées sans devoir synchroniser localement à l’avance tout l’historique d’état.

La deuxième valeur est la portabilité architecturale. Par rapport à une synchronisation actif-secours propre à un fournisseur, l’UDSF fait partie de l’architecture 5GC et s’aligne mieux sur une conception normalisée de réseau cœur cloud-native. Elle permet d’aborder plus ouvertement le stockage et la reprise de l’état, au lieu d’enfermer la haute disponibilité dans un mécanisme de cluster privé.

Toutefois, l’UDSF ne supprime pas toute la complexité. Elle devient un composant critique de la chaîne de reprise. Si elle est lente, indisponible, incohérente ou insuffisamment protégée, elle peut créer un nouveau goulet d’étranglement. L’UDSF elle-même doit donc être conçue avec une haute disponibilité, de bonnes performances de lecture et d’écriture, une réplication fiable, un contrôle d’accès sécurisé et des capacités de reprise après sinistre.

Le choix de la base de données est également important. Des bases relationnelles ou non relationnelles peuvent être utilisées dans les conceptions liées à l’UDSF, selon la mise en œuvre du fournisseur et les exigences du système. La question essentielle n’est pas uniquement le type de base de données choisi, mais la capacité de l’ensemble de la couche de stockage à satisfaire les exigences de latence, de fiabilité, de cohérence et de reprise propres aux télécommunications.

Pour les ingénieurs, les vérifications les plus importantes consistent à confirmer que le contexte UE est écrit dans l’UDSF au bon moment, que le nouvel AMF sélectionné peut le récupérer correctement, que la sélection dans l’ensemble d’AMF fonctionne comme prévu, que les identifiants sont gérés de façon cohérente et que le basculement est réellement invisible, ou presque, pour l’utilisateur. Le découplage n’a de valeur que si l’intégralité du chemin de reprise est testée de bout en bout.

FAQ

L’UDSF est-elle utilisée uniquement par l’AMF ?

Non. L’UDSF est conçue pour toute fonction réseau qui doit stocker et récupérer des données non structurées. La reprise de l’AMF à partir du contexte UE n’est que l’un des exemples les plus explicites.

Pourquoi le contexte UE est-il considéré comme une donnée non structurée ?

Le contexte UE est important, mais sa structure interne n’est pas entièrement définie comme une structure de données 3GPP normalisée. Il convient donc au stockage sous forme de données non structurées.

L’UDSF remplace-t-elle tout l’état local des fonctions réseau ?

Pas entièrement. Les fonctions réseau peuvent encore utiliser un état local temporaire pendant le traitement. L’UDSF sert principalement à préserver les données non structurées récupérables qui ne doivent pas disparaître avec une seule instance de calcul.

L’UDSF peut-elle garantir une absence totale d’interruption de service ?

Pas à elle seule. Elle améliore la base de reprise, mais la continuité réelle dépend aussi de la détection des pannes, de la resélection de l’AMF, de la fraîcheur des données, du comportement de signalisation et de la disponibilité de l’UDSF.

Que faut-il tester avant de déployer l’UDSF en production ?

Les essais doivent couvrir le moment d’écriture du contexte, sa récupération, la détection d’une panne d’AMF, la resélection dans l’ensemble d’AMF, le basculement de la base de données, la latence de lecture et d’écriture, la sécurité des accès et l’expérience réelle de l’UE pendant la reprise.

Le découplage du calcul et du stockage dans la 5GC dépasse largement un simple ajustement de base de données. Il modifie la manière dont le réseau cœur considère l’état, les défaillances et la reprise. En utilisant l’UDSF pour stocker des données non structurées telles que le contexte UE, les fonctions réseau deviennent moins dépendantes du stockage local et mieux adaptées à des déploiements cloud-native résilients. L’idée essentielle est simple : les instances de calcul peuvent tomber en panne ou changer, mais l’état utilisateur doit rester récupérable.