Un appareil 5G peut s’enregistrer sur le réseau sans créer immédiatement un chemin de données utilisateur. Cette petite évolution de conception en dit long sur la différence entre la gestion des sessions 5GC et les anciens cœurs mobiles. En 4G, la procédure d’attachement était étroitement liée à la création d’une connexion PDN par défaut et d’un bearer par défaut. En 5G, l’enregistrement et l’établissement de session sont plus clairement séparés, ce qui laisse au réseau davantage de liberté pour décider quand un chemin de plan utilisateur est réellement nécessaire.

La gestion des sessions 5GC est la couche de contrôle qui détermine comment un UE se connecte à un réseau de données, quelle session PDU est créée, quel DNN est utilisé, quelles informations de slice s’appliquent, quelles règles de QoS sont attribuées, quel UPF ancre le trafic et comment la continuité doit être assurée lorsque l’UE se déplace. Il ne s’agit pas seulement d’une nouvelle appellation de la gestion des bearers 4G, mais d’un cadre plus souple conçu pour le haut débit mobile, la voix sur 5G, l’accès d’entreprise, les services à faible latence, les réseaux de données locaux et le calcul en périphérie.

C’est pourquoi la gestion des sessions est l’un des concepts centraux du cœur 5G. La gestion de la mobilité indique au réseau où se trouve l’UE et s’il est joignable. La gestion des sessions lui indique le type de chemin de service dont l’UE a besoin, le réseau de données à atteindre, la manière de classifier le trafic et la façon de contrôler les ressources du plan utilisateur. Les deux fonctions coopèrent étroitement, mais ne sont plus traitées comme un seul bloc de contrôle combiné.

Pourquoi le contrôle des sessions a changé

Le principal changement architectural est la séparation de la gestion de la mobilité et de la gestion des sessions. Dans le cœur 5G, l’AMF est chargé de la gestion de mobilité NAS, tandis que le SMF prend en charge la gestion des sessions. Les messages NAS-SM ne sont pas entièrement traités dans l’AMF. Celui-ci transmet plutôt la signalisation de gestion de session au SMF via l’interface N11. L’AMF ne conserve donc plus le contexte de gestion de session de l’UE de la même manière que l’ancienne logique de contrôle combinée.

Cette séparation clarifie le cœur 5G. L’AMF peut se concentrer sur l’enregistrement, le contrôle d’accès, la joignabilité, l’état de mobilité et les procédures liées à la localisation. Le SMF peut se consacrer à l’établissement, à la modification et à la libération des sessions PDU, à la gestion des DNN, à la sélection de l’UPF, au contrôle des règles de QoS, à la continuité de session et aux paramètres liés à la taxation. Lorsque ces responsabilités sont séparées, le réseau peut faire évoluer chaque fonction selon sa propre charge.

Cette évolution correspond aussi à l’orientation de service de la 5G. Un smartphone, un capteur industriel, un véhicule, un équipement de réseau privé et une application de calcul en périphérie peuvent utiliser la 5G de façons très différentes. Certains appareils ont besoin de sessions de données fréquentes. D’autres peuvent s’enregistrer puis rester silencieux. Certains n’ont besoin que d’un accès local dans une zone définie. D’autres exigent une continuité IP stable pendant les déplacements. Un modèle unique consistant à « toujours créer un bearer par défaut à la mise sous tension » n’est pas assez flexible pour cette diversité.

En 5G, un UE peut s’enregistrer sans établir immédiatement de session PDU. Cela évite de créer des ressources de plan utilisateur avant qu’un service en ait réellement besoin. C’est particulièrement important pour l’IoT massif et les accès de type machine. Le réseau peut garder l’UE connu et joignable tout en évitant la mise en place inutile d’un chemin de données.

La séparation du contrôle de mobilité et du contrôle de session affecte également les données d’abonnement. Les données d’abonnement UDM sont divisées entre une partie liée à la mobilité et une partie liée aux sessions. L’AMF reçoit les données d’abonnement de mobilité, le SMF utilise les données d’abonnement de gestion de session et l’AMF peut recevoir des données de sélection du SMF pour choisir le SMF approprié lors de l’établissement d’une session PDU. Cette structure rend le cœur plus modulaire et facilite son alignement sur le slicing, les politiques propres à chaque DNN et les modèles de services différenciés.

Du PDN à la PDU

De nombreux termes de gestion de session 5G proviennent de la 4G, mais la terminologie et la structure ont changé. La connexion PDN de la 4G devient une session PDU en 5G. Le PDN de la 4G devient le DN, ou réseau de données. L’ APN de la 4G devient le DNN, ou nom de réseau de données. Le bearer par défaut 4G est remplacé par le flux QoS par défaut, tandis que les bearers dédiés deviennent des flux QoS supplémentaires ou non par défaut.

Cette évolution n’est pas seulement cosmétique. Une session PDU est conçue pour prendre en charge différents types de connectivité d’unités de données de protocole. En 4G, le type PDN couvrait principalement IPv4, IPv6 et IPv4v6. En 5G, le type de session PDU apporte davantage de flexibilité en prenant en charge Ethernet et les données non structurées comme options non IP. Cette capacité est importante, car la 5G doit couvrir bien plus que l’accès Internet traditionnel. Les équipements industriels, les réseaux privés d’entreprise et les environnements de service spécialisés peuvent nécessiter des modèles qui ne se limitent pas à une connectivité IP classique.

Un UE peut établir une session PDU pour l’accès général à Internet et une autre pour IMS. Dans la session PDU liée à IMS, différents flux QoS peuvent être utilisés pour la signalisation SIP, l’audio VoNR et la vidéo VoNR. La différence importante est que la 5G n’associe plus chaque service à un bearer EPS distinct de la même manière. Le flux QoS devient l’unité essentielle de traitement des services, tandis que le mappage vers les DRB est contrôlé côté radio par le gNB.

Ce modèle offre un contrôle plus fin des services. Une seule session PDU peut transporter plusieurs flux QoS, et chacun peut recevoir un 5QI, un ARP et un traitement QoS différents. Pour les services d’entreprise et d’opérateur, il devient plus facile de prendre en charge plusieurs classes de trafic sans imposer à chaque service un modèle de bearers rigide.

Comment le SMF prend le contrôle

Le SMF est la principale fonction de contrôle de la gestion des sessions 5GC. Il gère l’établissement, la modification et la libération des sessions PDU. Il sélectionne ou contrôle l’utilisation des UPF, gère les interactions de politique liées à la session, attribue les règles de QoS et détermine la façon dont le plan utilisateur doit être construit. Lorsque l’AMF reçoit une signalisation NAS-SM de l’UE, il transmet ces informations au SMF au lieu de traiter localement toute la logique de session.

Cette conception fait fonctionner l’AMF et le SMF comme deux couches coordonnées. L’AMF connaît l’état d’accès et de mobilité de l’UE. Le SMF connaît les exigences de la session de service. Lorsqu’une session PDU est demandée, l’AMF aide à transporter la signalisation et fournit le contexte lié à l’accès, tandis que le SMF décide comment créer la session en fonction du DNN, du S-NSSAI, des données d’abonnement, du contrôle de politique et de la disponibilité du plan utilisateur.

Le SMF joue également un rôle central dans le choix du mode SSC. Ce choix n’est pas aléatoire. Il dépend du mode SSC demandé par l’UE, du mode SSC souscrit dans les données UDM et de l’ensemble des modes SSC autorisés. Une fois la session PDU établie, son mode SSC ne peut plus être modifié, ce qui rend la décision initiale importante.

Le contrôle des ressources du plan utilisateur constitue une autre responsabilité essentielle. Le SMF peut activer ou désactiver ces ressources, libérer une session PDU ou adapter le traitement de la session selon la mobilité, la zone de service, la politique et l’état d’accès. Pour un LADN, par exemple, lorsque le SMF apprend qu’un UE a quitté la zone de service LADN, il peut libérer la session PDU concernée ou désactiver les ressources du plan utilisateur.

Le SMF contrôle aussi l’orientation du trafic dans les scénarios de calcul en périphérie. Lorsque des UPF sont utilisés comme ancrages et classificateurs, le SMF peut installer des règles déterminant si le trafic doit aller vers un DN distant ou un réseau de services local. Le SMF est donc central aussi bien pour les sessions de données ordinaires que pour les modèles avancés de breakout local.

Les données d’abonnement guident la configuration

L’établissement d’une session dépend fortement des données d’abonnement. Comme la gestion de la mobilité et celle des sessions sont séparées, les données UDM sont elles aussi réparties en différentes zones logiques. L’AMF utilise les données d’abonnement liées à la mobilité, tandis que le SMF utilise les données d’abonnement de gestion de session. En outre, des données de sélection du SMF peuvent être fournies à l’AMF afin de choisir un SMF approprié lorsque l’UE demande une session PDU.

Les données d’abonnement de gestion de session comprennent plusieurs éléments importants. Le S-NSSAI identifie le contexte de slice souscrit. Les configurations DNN définissent la manière dont l’UE peut accéder à un réseau de données. Dans ces configurations, le réseau peut définir les types de session PDU par défaut et autorisés, les modes SSC par défaut et autorisés, les informations QoS souscrites, les limites de débit agrégé au niveau de la session et les caractéristiques de taxation.

Cette structure permet de façonner un service avant même la création de la session PDU. Un UE peut être autorisé à accéder à un DNN mais pas à un autre. Il peut être autorisé à utiliser IPv4v6 pour l’accès Internet et un autre type de PDU pour un service d’entreprise ou spécialisé. Il peut aussi avoir un mode SSC par défaut pour un DNN et un ensemble de modes autorisés différent pour un autre. Des profils Session-AMBR et QoS distincts peuvent également être appliqués selon le service souscrit.

Configurations DNN

La configuration DNN est l’une des parties les plus concrètes des données de gestion de session. Elle contrôle le comportement d’un nom de réseau de données donné pour l’utilisateur. Si le DNN représente un service Internet, la politique peut se concentrer sur le haut débit mobile classique. S’il représente IMS, elle peut prendre en charge la signalisation et la QoS liée à la voix. S’il représente un service local, il peut être lié au comportement LADN et à des restrictions géographiques.

Informations de slice

Le S-NSSAI relie la gestion des sessions au network slicing. Une session PDU n’est pas seulement associée à un DNN ; elle peut aussi être associée à un slice. Le réseau peut ainsi prendre en charge différentes catégories de services, différents clients professionnels ou différents domaines opérationnels au moyen de politiques propres aux slices.

Limites de débit et taxation

Le Session-AMBR définit les limites de débit agrégé au niveau de la session PDU. Les caractéristiques de taxation peuvent également faire partie du profil de gestion de session. Ces paramètres sont importants, car la gestion des sessions ne concerne pas uniquement la connectivité, mais aussi le contrôle des services, l’application des politiques et le traitement commercial.

Les sessions PDU structurent l’accès

Une session PDU est l’unité d’accès de base qui relie un UE à un DN à travers le cœur 5G. Elle contient des attributs de service tels que le DNN, le type de session PDU, le S-NSSAI, le mode SSC et l’identifiant de session PDU. Une fois créée, la session devient le conteneur d’un ou de plusieurs flux QoS. Le trafic utilisateur est alors traité selon les règles de QoS, les valeurs QFI, les filtres de paquets et le mappage côté radio.

Ce modèle est plus flexible qu’une simple connexion permanente. Un UE peut créer une session PDU uniquement lorsqu’un service en a besoin. Il peut établir des sessions PDU distinctes pour Internet et IMS. Il peut également établir une session vers un DNN propre à un service d’entreprise, local ou en périphérie si les règles d’abonnement et de zone l’autorisent.

L’identifiant de session PDU identifie la session du point de vue de l’UE. Un UE peut disposer de plusieurs sessions PDU, chacune associée à un DNN, un slice ou un type de session différent. Par exemple, une session peut se connecter au DN Internet et une autre au DN IMS. À l’intérieur de ces sessions, les flux QoS peuvent représenter différents besoins de service.

Le type de session PDU étend également le modèle d’accès. IPv4, IPv6 et IPv4v6 restent des options familières, mais les types PDU Ethernet et non structuré rendent la 5G plus adaptée aux services non traditionnels. C’est particulièrement important dans les environnements d’entreprise et industriels, où les appareils peuvent avoir besoin d’un comportement de service de couche 2 ou du transport de charges utiles non IP.

La conception des sessions PDU influence aussi la manière dont le réseau traite la voix. Dans un modèle orienté VoNR, la signalisation IMS peut utiliser un flux QoS non-GBR, tandis que l’audio et la vidéo peuvent utiliser des flux QoS GBR avec des valeurs 5QI différentes. Le modèle de flux QoS permet de distinguer la signalisation, la voix et la vidéo dans le même contexte d’accès IMS sans reproduire directement la structure des bearers dédiés EPS.

Les modes SSC préservent l’expérience

SSC signifie continuité de session et de service. Cette expression recouvre deux idées liées mais différentes. La continuité de session signifie que la session PDU et l’adresse IP de l’UE restent inchangées. La continuité de service signifie que l’expérience utilisateur reste continue du point de vue de l’application. Une personne qui regarde une vidéo, passe un appel vocal ou utilise un service interactif se préoccupe surtout d’une éventuelle interruption, tandis que le réseau doit également savoir si la même session et la même adresse IP sont conservées.

Le mode SSC définit la manière dont le réseau gère la continuité lorsque le déplacement de l’UE entraîne un changement de chemin, d’ancrage ou d’accès au service. La 5G définit trois modes SSC. Chacun offre un équilibre différent entre continuité de session, continuité de service et flexibilité du plan utilisateur.

Mode SSC 1

Le mode SSC 1 préserve à la fois la continuité de session et la continuité de service. La même session PDU est maintenue et l’adresse IP de l’UE ne change pas. Il s’agit de l’option de continuité la plus forte, requise pour les services qui ne tolèrent aucune interruption. VoNR en est un exemple typique, car la voix dépend d’une continuité stable pendant la mobilité.

Mode SSC 2

Le mode SSC 2 ne préserve pas la continuité de session, mais cherche à maintenir la continuité de service du point de vue de l’utilisateur. Il suit une approche « break-before-make » : l’ancienne session PDU est libérée avant l’établissement de la nouvelle. Cette méthode peut convenir à certains services, mais elle reste moins favorable que les autres options pour l’expérience utilisateur.

Mode SSC 3

Le mode SSC 3 ne préserve pas non plus la même continuité de session, mais utilise une approche « make-before-break ». Une nouvelle session PDU est établie avant la libération de l’ancienne. Pendant la transition, l’UE peut temporairement maintenir deux sessions PDU. Dans de nombreux cas, cette approche offre une meilleure expérience que le mode SSC 2, car elle réduit l’interruption du service.

Du point de vue de l’expérience utilisateur, le mode SSC 1 offre la continuité la plus forte, le mode SSC 3 est généralement préférable au mode SSC 2, et le mode SSC 2 est le moins favorable des trois. Le choix appartient au SMF et repose sur la demande de l’UE, les données d’abonnement et l’ensemble des modes autorisés. Une fois la session établie, le mode SSC reste fixe pour cette session PDU.

Le LADN limite la portée locale

LADN signifie réseau de données local. Il s’agit d’un service de réseau de données disponible uniquement dans une zone de service donnée, composée d’une ou plusieurs Tracking Areas. Lorsque l’UE se trouve dans la zone LADN, il peut accéder au DNN correspondant si l’abonnement et la configuration l’autorisent. Lorsqu’il quitte cette zone, il ne peut plus accéder au service 5G du DN concerné.

Le LADN est utile parce que certains services n’ont de sens que dans une région locale. Un service de conduite autonome peut n’être disponible que dans une zone d’essai. Un service de télésanté peut être lié à l’enceinte d’un hôpital. Une application d’usine peut n’être valable que dans un campus industriel privé. Dans ces situations, le réseau de données n’est pas un service Internet mobile mondial, mais un service local dont la disponibilité dépend de la position.

L’UE et le réseau doivent tous deux connaître les informations liées au LADN. L’UE peut être configuré pour savoir si un DNN est un DNN LADN et quelle application lui est associée. La zone de service et le DNN LADN sont configurés dans l’AMF pour chaque DN. L’AMF peut fournir les informations LADN à l’UE pendant les procédures d’enregistrement ou de mise à jour de configuration.

Du point de vue de la gestion des sessions, le LADN comporte trois états de localisation. Dans la zone signifie que l’UE se trouve dans la zone LADN. Hors de la zone signifie que l’UE a quitté la zone LADN. Inconnu peut s’appliquer lorsque l’UE se trouve dans un état tel que CM-IDLE et que le réseau ne dispose pas d’une indication précise de sa position actuelle. Le SMF peut utiliser les informations de l’AMF pour déterminer si l’UE se trouve encore dans la zone de service.

Si l’UE se trouve hors de la zone de service LADN, il ne doit pas demander l’activation du plan utilisateur pour ce DNN LADN ni demander l’établissement ou la modification d’une session PDU pour ce DNN. Si l’UE ne dispose d’aucune information de zone de service pour un DNN LADN, il doit se considérer hors de la zone. Lorsque le SMF reçoit une demande de session liée au LADN sans indication valable que l’UE se trouve dans la zone de service, il considère l’UE comme étant hors zone et rejette la demande.

Les chemins périphériques ont besoin d’ancrages

La prise en charge du calcul en périphérie est l’une des raisons pour lesquelles la gestion des sessions 5GC nécessite une conception plus flexible du plan utilisateur. Un service peut exiger qu’une partie du trafic soit envoyée vers un serveur distant et qu’une autre reste locale. Par exemple, les journaux ordinaires peuvent être transmis à un centre de données distant, tandis que le trafic de contrôle à faible latence peut être dirigé vers un serveur d’application local proche du réseau d’accès.

Le concept de PSA, ou PDU Session Anchor, est important ici. Un PSA est un UPF qui ancre une session PDU et fournit une interface N6 vers le réseau de données. Tous les UPF ne sont pas automatiquement des PSA. Certains peuvent remplir d’autres rôles, comme la classification ou le transfert. La conception du plan utilisateur dépend de l’agencement des UPF et de la manière dont le trafic doit atteindre les DN locaux ou distants.

Deux méthodes d’orientation sont importantes. ULCL, ou Uplink Classifier, classe le trafic montant selon des règles. Il peut être utilisé pour le trafic IPv4 et IPv6. Le SMF peut installer des règles ULCL afin que le trafic correspondant à une destination ou à une classe de service donnée soit envoyé vers la bonne branche. Par exemple, le trafic vers une destination peut être envoyé à un serveur distant, tandis que celui destiné à une autre adresse est dirigé vers un service périphérique local.

La deuxième méthode est l’approche du point de branchement , fondée sur le branchement par préfixe IPv6. Cette méthode ne s’applique qu’à IPv6. Elle permet d’orienter le trafic selon la logique des préfixes IPv6 et convient donc aux architectures où l’adressage IPv6 peut identifier des branches de service locales ou distantes.

Ces mécanismes rendent le calcul en périphérie pratique dans la gestion des sessions 5GC. Le SMF contrôle les règles de session, l’UPF assure le transfert et la classification des paquets, et le PSA fournit l’ancrage vers le DN. Le chemin de service peut ainsi être façonné selon le type de trafic au lieu d’envoyer tous les flux vers un unique ancrage de cœur distant.

Le flux QoS apporte de la granularité

Le flux QoS est la principale granularité de contrôle de la QoS en 5G. Au lieu d’utiliser les bearers EPS comme unité centrale de différenciation des services, la 5G emploie des flux QoS identifiés par un QFI. Chaque flux QoS peut transporter son propre profil et être mappé à un DRB par le gNB. Le nombre de DRB ne doit pas nécessairement être égal au nombre de QFI. Le gNB peut décider de mapper plusieurs flux QoS vers le même DRB ou vers des DRB différents selon les conditions radio et la politique.

Un exemple de service typique peut comprendre des applications Internet ordinaires, du trafic de services coopératifs et des services propres à l’opérateur. Le trafic général des applications peut utiliser un flux QoS non-GBR. Les flux plus exigeants, tels que les services VR, AR ou de jeu en temps réel, peuvent utiliser un flux QoS GBR. L’audio et la vidéo VoNR peuvent employer des flux QoS GBR différents avec des valeurs 5QI propres à chaque service. Le réseau dispose ainsi d’un moyen plus précis de traiter les différents flux.

Les paramètres de QoS sont organisés à plusieurs niveaux. Au niveau du flux QoS, les paramètres courants comprennent le 5QI et l’ ARP. Le 5QI correspond à des caractéristiques telles que le niveau de priorité, le budget de délai des paquets, le taux d’erreur des paquets, la fenêtre de moyennage et le volume maximal de données en rafale. L’ARP aide à déterminer la priorité d’allocation et de rétention lorsque les ressources sont limitées.

Les paramètres des flux GBR comprennent le GFBR, ou débit garanti du flux, et le MFBR, ou débit maximal du flux. Ces paramètres sont obligatoires pour les flux GBR. Le contrôle de notification et le taux maximal de perte de paquets peuvent aussi apparaître comme paramètres optionnels. Pour les flux non-GBR, le RQA, ou attribut de QoS réflexive, peut être utilisé. À un niveau de limitation plus large, le UE-AMBR et le Session-AMBR contrôlent le comportement du débit agrégé pour le trafic non-GBR.

Cette granularité constitue l’une des différences majeures entre la logique des bearers 4G et celle des sessions 5G. Dans la VoLTE 4G, les bearers par défaut et dédiés étaient associés à l’APN, au QCI, à l’EBI, à l’E-RAB, au DRB et aux tunnels du plan utilisateur. En 5G, la session PDU, le QFI, le type de flux QoS, le tunnel N3 et le mappage DRB forment une structure différente. Le résultat est plus flexible, mais dépend davantage d’une politique SMF correcte, de l’installation des règles de QoS et du comportement de mappage du gNB.

Comment les sessions sont établies

Une session PDU n’est pas établie isolément. Le réseau doit prendre plusieurs décisions avant que le plan utilisateur ne devienne utilisable. L’UE demande une session à l’aide du DNN, du type de session PDU et de paramètres associés. L’AMF transporte le message NAS-SM vers le SMF. Le SMF vérifie les données d’abonnement, la politique, les informations de slice et la configuration DNN. Il choisit ensuite les ressources du plan utilisateur, attribue les règles de QoS et contrôle la connexion de la session au DN.

Le processus peut être compris comme une suite de décisions. Premièrement, le réseau vérifie si l’UE est autorisé à utiliser le DNN demandé. Deuxièmement, il vérifie si le type de session PDU demandé est autorisé. Troisièmement, il prend en compte les informations de slice via le S-NSSAI. Quatrièmement, il sélectionne ou confirme le mode SSC. Cinquièmement, il décide quel UPF ou quel chemin d’ancrage utiliser. Sixièmement, il applique les informations de QoS et de contrôle du débit.

Le résultat est une session qui est bien plus qu’un tunnel. Elle contient l’identité du service, l’identité du réseau de données, le chemin du plan utilisateur, les règles de QoS, le comportement de continuité, les caractéristiques de taxation et d’éventuelles restrictions de zone. Si la session concerne un service local, les règles LADN peuvent s’appliquer. Si elle concerne le calcul en périphérie, les comportements PSA et ULCL peuvent s’appliquer. Si elle concerne la voix, IMS et les flux QoS deviennent essentiels.

La session peut également être modifiée après son établissement. Un flux QoS peut être ajouté ou modifié. Les ressources du plan utilisateur peuvent être activées ou désactivées. Une session peut être libérée lorsqu’elle n’est plus nécessaire, lorsque l’UE quitte une zone de service ou lorsque la politique l’exige. Puisque le SMF contrôle la session, il constitue la fonction clé qui transforme les règles d’abonnement et de politique en comportement réel du chemin de données.

Cela explique pourquoi le dépannage des problèmes de session 5GC ne peut pas se limiter à l’accès radio. Les ingénieurs peuvent devoir examiner le transfert par l’AMF, la sélection du SMF, les données UDM, la configuration DNN, le S-NSSAI, le chemin UPF, l’installation des règles de QoS, la présence LADN, le mode SSC et les règles N4 vers l’UPF. Une défaillance dans l’un de ces domaines peut empêcher la session, provoquer un fonctionnement incorrect ou supprimer le traitement QoS attendu.

Notes de planification pour les ingénieurs

Une bonne planification de la gestion des sessions 5GC commence par la séparation des services. Tous les services ne doivent pas être forcés à utiliser le même DNN, le même slice, le même modèle QoS et le même mode de continuité. L’accès Internet, IMS, l’accès privé d’entreprise, les applications locales de campus, le trafic de contrôle industriel et les services périphériques peuvent avoir des exigences différentes. Une conception claire doit identifier ces différences avant de configurer les DNN et les données d’abonnement.

La priorité suivante consiste à déterminer le niveau de continuité de session requis. Certains services ont besoin d’une adresse IP UE stable et d’un fonctionnement ininterrompu. D’autres peuvent tolérer une nouvelle session si l’application peut récupérer. Certains bénéficient du make-before-break, alors que d’autres acceptent le break-before-make. Le mode SSC doit être traité comme un choix de conception du service, et non comme un simple paramètre dans un tableau.

La planification LADN doit commencer par la géographie du service. La zone de service doit être construite à partir de Tracking Areas, et l’AMF doit recevoir la configuration du DNN LADN et de la zone de service pour chaque DN. L’UE doit également disposer de la configuration locale correcte afin de savoir si un DNN est un DNN LADN et quelle application doit l’utiliser. Si les informations de zone de service LADN sont absentes, l’UE doit se considérer hors de la zone, ce qui peut entraîner l’échec prévu des tentatives de service.

La planification en périphérie nécessite une logique claire d’orientation du trafic. Les règles ULCL doivent correspondre au trafic réel des applications, et non à de vagues hypothèses de service. Si du trafic local et distant est mélangé dans une même session PDU, le comportement du SMF et de l’UPF doit être configuré avec soin. Le choix du PSA, la connectivité N6, les chemins N9 et l’emplacement du serveur local influencent tous la latence et la continuité du service.

La planification de la QoS mérite la même attention. Définir une valeur 5QI ne suffit pas. Les ingénieurs doivent savoir si le flux est GBR ou non-GBR, si le GFBR et le MFBR sont requis, si le Session-AMBR et l’UE-AMBR sont adaptés, comment le QFI est attribué et comment le gNB mappe les flux QoS vers les DRB. Si le mappage radio ne correspond pas aux attentes du service, la session peut être correctement établie tout en offrant une mauvaise expérience.

Enfin, la gestion des sessions doit être testée dans des scénarios réalistes de mobilité et de service. Un appel statique en laboratoire ne valide pas le comportement SSC. Une seule session Internet ne valide pas la restriction LADN. Un simple test de débit ne valide pas la différenciation des flux QoS. Les ingénieurs doivent tester l’enregistrement sans établissement de session, plusieurs sessions PDU, l’entrée et la sortie d’une zone LADN, le comportement des modes SSC, le breakout en périphérie, l’ajout de flux QoS, l’activation du plan utilisateur et la libération de session.

Vue technique finale

La gestion des sessions 5GC est la partie du cœur qui transforme l’intention de service en connectivité de données. Elle crée et contrôle les sessions PDU, sélectionne l’accès DNN, applique les règles de slice et d’abonnement, choisit le mode SSC, gère les chemins UPF, prend en charge les restrictions locales et attribue le traitement des flux QoS. Elle donne à la 5G la flexibilité nécessaire aux smartphones, aux services vocaux, aux équipements industriels, aux réseaux d’entreprise, aux accès locaux et au calcul en périphérie.

Le passage de la logique des bearers 4G à celle des sessions PDU 5G n’est pas une simple mise à jour terminologique. Il modifie la création de la connectivité, la séparation des services, l’application de la QoS et l’orientation des chemins du plan utilisateur. La séparation AMF-SMF rend l’architecture plus modulaire. Les données d’abonnement UDM deviennent plus structurées. Le mode SSC fournit différents modèles de continuité. Le LADN ajoute un accès aux services fondé sur la zone. L’ULCL et le PSA rendent possibles les chemins périphériques. Le flux QoS remplace une logique centrée sur les bearers par une classification plus fine des services.

La meilleure façon de comprendre la gestion des sessions 5GC consiste à suivre un service depuis sa demande jusqu’au plan utilisateur. L’UE demande une session PDU. L’AMF transporte le message de session. Le SMF vérifie l’abonnement, le DNN, le slice, le type PDU et le mode SSC. L’UPF crée le chemin vers le DN. Les règles de QoS classent le trafic. Le gNB mappe les flux QoS vers les bearers radio. Les changements de mobilité et de localisation influencent ensuite la continuité, l’accès aux services locaux et le routage en périphérie. Chaque étape appartient à la même chaîne de gestion des sessions.

FAQ

Pourquoi un UE peut-il s’enregistrer sans créer de session PDU ?

L’enregistrement indique seulement au réseau que l’UE est connu et joignable. Une session PDU n’est nécessaire que lorsqu’un service de données utilisateur est demandé ; la 5G peut donc éviter de créer des ressources de plan utilisateur avant qu’elles soient utiles.

Pourquoi l’AMF transmet-il les messages NAS-SM au lieu de les traiter entièrement ?

L’AMF est conçu autour du contrôle de l’accès et de la mobilité, tandis que le SMF possède la logique de session. La transmission de la signalisation NAS-SM maintient cette séparation des responsabilités et rend l’architecture plus modulaire.

Pourquoi le DNN est-il plus qu’un APN renommé ?

Le DNN est lié aux règles de session 5G, au contexte de slice, aux types de session PDU, au comportement LADN, au contrôle de politique et à la sélection du SMF. Son rôle est donc plus large que celui d’un simple nom d’accès.

Quand faut-il préférer le mode SSC 3 au mode SSC 2 ?

Le mode SSC 3 convient lorsqu’un service peut tolérer un changement de session, mais bénéficie d’un fonctionnement make-before-break qui réduit l’interruption par rapport à la libération préalable de l’ancienne session.

Pourquoi le LADN exige-t-il une connaissance côté UE ?

L’UE doit savoir si un DNN est un DNN LADN et s’il se trouve dans la zone de service configurée avant de demander l’établissement ou la modification d’une session, ou l’activation du plan utilisateur.