Network Slicing 5G : le guide complet — architecture, déploiement et réalité terrain

Stade de France, finale de la Coupe du monde de rugby. 80 000 personnes. Sur le même réseau physique, trois mondes coexistent sans se connaître. La slice URLLC transporte les flux vidéo des caméras de surveillance de la sécurité civile avec une latence inférieure a 15 ms. La slice eMBB offre aux spectateurs un streaming multi-angle en 4K a 100 Mbps garanti par cellule. La slice mMTC collecte les données de 12 000 capteurs de pression répartis sous les gradins pour le monitoring structurel en temps réel. Trois réseaux virtuels. Un seul réseau physique. Aucun ne sait que les autres existent.

C’est la promesse du network slicing 5G. Et comme beaucoup de promesses en télécom, elle est techniquement réalisable, architecturalement élégante, et commercialement presque nulle part en 2026.

Ce guide couvre l’architecture complète du slicing, du S-NSSAI au 5QI, du NSSF au NSACF, de la théorie 3GPP a la réalité du déploiement terrain. Pas de marketing. Des specs, des limites, et l’état réel.

L’analogie de l’avion : comprendre le slicing en 30 secondes

Le network slicing fonctionne comme un vol commercial. Un seul avion physique (le réseau), mais trois classes de service avec des SLA radicalement différents.

La première classe (URLLC) garantit un siège-lit, un repas gastronomique et un embarquement prioritaire. Le SLA est contractuel : si le service n’est pas fourni, il y a compensation. La classe affaires (eMBB) offre un siège large et un bon repas, mais sans la garantie absolue. La classe économique (mMTC) empile un maximum de passagers pour un coût minimal par siège.

Tous partagent le même avion, le même équipage, la même piste. Mais les ressources qui leur sont allouées (espace, nourriture, personnel) sont isolées. Le passager en première ne subit pas la file d’attente de l’économique. Le passager en économique ne peut pas occuper un siège de première, même si celui-ci est vide.

Le slicing réplique cette logique sur un réseau 5G SA. Meme infrastructure physique (gNB, transport, core), mais des ressources radio, des fonctions réseau et des politiques QoS dédiées par slice.

Architecture : comment un slice est identifié, sélectionné et admis

S-NSSAI : la carte d’identite du slice

Chaque slice est identifiée par un S-NSSAI (Single Network Slice Selection Assistance Information), défini dans la spécification 3GPP TS 23.501. Le S-NSSAI se compose de deux champs :

• SST (Slice/Service Type) : valeur sur 8 bits définissant la catégorie de service. Trois valeurs sont standardisées par le 3GPP : SST=1 (eMBB), SST=2 (URLLC), SST=3 (mMTC). La valeur SST=4 est réservée au V2X (Vehicle-to-Everything). Les valeurs 5 a 127 sont réservées pour de futurs usages standardisés. Les valeurs 128 a 255 sont libres pour les opérateurs.

• SD (Slice Differentiator) : valeur optionnelle sur 24 bits qui distingue plusieurs slices partageant le même SST. Exemple : un operateur déploie deux slices URLLC, une pour un hôpital (SD=0x000001) et une pour un constructeur automobile (SD=0x000002). Meme SST=2, deux slices complètement séparées.

Le terminal (UE) transmet son Requested NSSAI dans le message NAS Registration Request. Ce NSSAI est une liste de S-NSSAI auxquels le terminal souhaite accéder. L’operateur configuré le Default NSSAI dans l’USIM ou via l’UDM. Après négociation, l’AMF retourne l’Allowed NSSAI dans le Registration Accept.

NSSF : le routeur de slices

Le NSSF (Network Slice Selection Function) intervient quand l’AMF recevant la demande du terminal ne peut pas servir les S-NSSAI demandes. Le NSSF détermine :

1. L’ensemble des S-NSSAI que le terminal est autorisé a utiliser (intersection entre le Requested NSSAI, le Subscribed S-NSSAI dans l’UDM, et les S-NSSAI configurés sur le PLMN).
2. L’AMF cible capable de servir ces S-NSSAI (si l’AMF initiale ne le peut pas).
3. Le mapping entre le S-NSSAI de l’abonnement (HPLMN) et le S-NSSAI du réseau visite (VPLMN) en cas de roaming.

Le NSSF n’est pas un élément optionnel dans un réseau qui propose du slicing commercial. Sans lui, la sélection de slice repose entièrement sur la configuration statique de l’AMF, ce qui ne passe pas a l’échelle.

NSACF : le contrôle d’admission (Release 17)

L’NSACF (Network Slice Admission Control Function), introduit en 3GPP Release 17, résout un problème que la Release 15 avait laisse ouvert : combien de terminaux peuvent simultanement accéder a un slice donné ?

Sans NSACF, un slice URLLC configuré pour 500 sessions peut se retrouver avec 5 000 terminaux enregistrés. Le SLA s’effondre parce qu’il n’y a aucun mécanisme de comptage et de rejet a l’entree. L’NSACF maintient le nombre de terminaux enregistrés par S-NSSAI et refuse les nouveaux enregistrements quand la capacité maximale est atteinte.

C’est l’équivalent du contrôle d’embarquement de l’avion : même si 300 personnes ont un billet, l’avion n’a que 200 places.

Le framework 5QI : la QoS au niveau du flux

Le 5QI (5G QoS Identifier) remplace le QCI (QoS Class Identifier) de la 4G. Il définit les caractéristiques de traitement d’un flux de données au sein d’un slice. Un slice peut contenir plusieurs 5QI différents.

GBR vs non-GBR

Les flux sont divisés en deux categories :

• GBR (Guaranteed Bit Rate) : le réseau réserve de la bande passante. Si le flux ne l’utilise pas, la bande est gaspillée. Utilisé pour la voix, la vidéo temps réel, le contrôle industriel.
• Non-GBR : pas de reservation. Le flux obtient ce qu’il peut. Utilisé pour la navigation web, le streaming adaptatif, le trafic IoT.

Valeurs 5QI clés

5QI	Type	Latence budget	Taux erreur paquet	Usage type
1	GBR	100 ms	10^-2	Voix (VoNR)
2	GBR	150 ms	10^-3	Video conversationnelle
3	GBR	50 ms	10^-3	Jeu temps réel
5	Non-GBR	100 ms	10^-6	Signalisation IMS
9	Non-GBR	300 ms	10^-6	Streaming vidéo, web
82	GBR	10 ms	10^-4	Controle drone V2X
83	GBR	10 ms	10^-4	V2X conduite coopérative
85	Non-GBR	5 ms	10^-5	URLLC haute priorité

Le mapping QCI vers 5QI est direct pour les valeurs standardisées (QCI 1 = 5QI 1, etc.), mais la 5G ajoute des valeurs spécifiques aux nouveaux cas d’usage (V2X, URLLC industriel) qui n’existaient pas en 4G.

Un point critique pour les ingénieurs terrain : le 5QI configuré dans le PCF n’est pas forcément celui appliqué par le gNB. La verification nécessite la capture du message PDU Session Establishment Accept en signalisation NAS, qui contient le QoS Profile effectivement attribué.

Slicing de bout en bout : RAN, transport, core

Le vrai slicing est end-to-end. Il ne suffit pas de découper le core. Chaque segment du réseau doit porter l’isolation.

Slice RAN

Au niveau radio, le slicing repose sur deux mécanismes :

• BWP (Bandwidth Part) : le gNB peut attribuer des portions différentes du spectre a différents slices. Un slice URLLC peut recevoir un BWP étroit avec un SCS de 30 kHz (slots courts = latence faible), tandis qu’un slice eMBB obtient un BWP large avec un SCS de 15 kHz.
• Scheduling isolé : le scheduler du gNB alloue les PRB (Physical Resource Blocks) par slice selon les règles de priorité configurées. Un slice URLLC a toujours priorité sur un slice eMBB pour les mêmes PRB.

En pratique, la plupart des déploiements actuels n’utilisent pas de BWP séparées par slice. Le slicing RAN repose principalement sur la configuration du scheduler, ce qui offre une isolation logique mais pas physique. La différence est mesurable sur le terrain : sous congestion, un slice “prioritaire” peut quand même subir des dégradations si le scheduler n’est pas correctement dimensionné.

Slice transport

Le segment transport (entre gNB et core) utilise des mécanismes classiques de segmentation réseau :

• VLAN tagging : chaque slice correspond a un VLAN distinct sur le backhaul et le midhaul.
• MPLS / Segment Routing : pour les réseaux de transport IP/MPLS, chaque slice est mappé sur un LSP ou un SID-list spécifique.
• FlexE (Flexible Ethernet) : pour une isolation physique au niveau de la couche Ethernet, avec des calendriers de transmission dédiés.

Slice core

Au niveau du 5G Core, chaque slice peut disposer de :

• SMF dédié : gestion de session indépendante.
• UPF dédié : plan utilisateur isolé, avec une passerelle de sortie distincte.
• PCF dédié : politiques QoS spécifiques par slice.
• Instances NF partagées ou dédiées : selon le niveau d’isolation requis, l’AMF, le NRF et l’AUSF peuvent etre partages entre slices (isolation logique) ou dupliqués (isolation physique).

NFV et SDN : les préalables techniques

Le network slicing n’existerait pas sans deux technologies qui l’ont rendu possible :

NFV (Network Functions Virtualization) permet de déployer les fonctions réseau (AMF, SMF, UPF) sous forme de conteneurs ou machines virtuelles, instanciables à la demande. Sans NFV, créer un nouveau slice signifierait déployer du matériel physique, un processus de semaines ou mois.

SDN (Software-Defined Networking) permet de configurer les chemins de données dans le transport de manière programmable. Le contrôleur SDN peut créer un chemin isolé entre le gNB et l’UPF d’un slice en quelques secondes, là où une configuration manuelle de routeurs prendrait des heures.

Ensemble, NFV et SDN transforment le réseau en une plateforme programmable ou un slice peut etre créé, modifié et supprimé par API. C’est la base de l’orchestration MANO (Management and Network Orchestration) définie par l’ETSI.

État réel du déploiement en 2026

La réalité du slicing commercial en 2026 est moins flamboyante que les keynotes du MWC.

Ce qui est réellement vendu :

• Des slices eMBB enterprise avec débit garanti. C’est essentiellement un VPN mobile avec SLA. Les opérateurs asiatiques (China Mobile, SK Telecom, KT) le commercialisent à grande échelle. En Europe, Deutsche Telekom et Vodafone proposent des offres pilotes, principalement pour les événements sportifs et les campus industriels.
• Des slices de type “boost temporaire” pour les événements (stades, salons). T-Mobile US a annoncé un système de slicing dynamique pour 2026, mais les détails de tarification restent flous.

Ce qui reste au stade pilote :

• Le slicing URLLC commercial. La latence de 1 ms spécifiée dans le 3GPP n’est pas atteinte de bout en bout en conditions réelles. Les déploiements pilotes mesurent typiquement 5-15 ms, ce qui reste excellent mais ne correspond pas à la promesse marketing.
• Le slicing inter-opérateurs pour les entreprises multinationales. La GSMA travaille sur les spécifications, mais le roaming de slice n’est pas opérationnel en production.

Ce qui n’existe pas encore :

• Le slicing mMTC commercial dédié. Les capteurs IoT utilisent des slices partageant l’infrastructure standard, sans SLA spécifique.
• Le slicing dynamique à la demande via API (le concept CAMARA/NEF). Annoncé partout, déployé nulle part.

La question du business model

Comment tarifier un slice ? C’est la question à plusieurs milliards que personne n’a résolue.

Les modèles explorés incluent :

• Tarification par SLA : le client paie pour des garanties (50 Mbps minimum, 20 ms de latence maximum) plutôt que pour un volume de données. C’est logique, mais complexe à mesurer et à garantir.
• Tarification par événement : un slice actif pendant 3 heures pour un match de football à 80 000 spectateurs. Le prix est négocié au cas par cas. Pas scalable.
• Tarification par API : le modèle CAMARA ou une application demande un boost de QoS en temps réel et paie à l’usage. Élégant en théorie, inexistant en pratique.
• Forfait entreprise avec slice incluse : un abonnement 5G Business qui inclut une slice eMBB avec débit garanti. C’est ce qui se vend le mieux aujourd’hui, mais la différenciation avec un simple APN dédié est faible.

Le problème fondamental est que la plupart des entreprises ne savent pas ce qu’est un slice, ne savent pas ce qu’elles pourraient en faire, et ne voient pas la différence avec une connexion 4G avec QoS configurée. Le travail d’éducation du marché est massivement sous-estimé.

La tension : promesse vs réalité

Le network slicing est standardisé depuis la Release 15 du 3GPP (2018). Huit ans plus tard, le nombre de slices commerciales vendues dans le monde se compte en centaines, pas en millions.

Les raisons de cet écart ne sont pas techniques. L’architecture fonctionne. Les spécifications sont complètes. Les équipements supportent le slicing. Le problème est triple :

1. La chaîne BSS/OSS n’est pas prête. Provisionner, superviser et facturer un slice en temps réel nécessite une refonte des systèmes back-end que la plupart des opérateurs n’ont pas achevée.
2. La demande n’est pas structurée. Les verticaux (industrie, santé, transport) n’ont pas encore formulé de besoin clair en termes de slicing. Ils demandent de la connectivité, pas des slices.
3. Le ROI n’est pas démontré. Les premiers déploiements n’ont pas encore prouvé qu’un slice génère plus de revenus qu’un APN dédié avec QoS. La concentration de 91% des revenus slicing en Asie-Pacifique (essentiellement Chine) le confirme.

Ce que cela signifie pour les ingénieurs terrain

Pour un ingénieur RF ou un technicien terrain, le slicing change la nature de la validation réseau. Il ne suffit plus de mesurer le RSRP, le RSRQ et le SINR. Il faut vérifier que le slice est correctement sélectionné, que la QoS est appliquée, et que l’isolation tient sous contrainte.

Concrètement, les vérifications terrain incluent :

1. Capturer le Registration Accept : vérifier que l’Allowed NSSAI contient les S-NSSAI attendus pour le terminal sous test.
2. Capturer le PDU Session Establishment Accept : vérifier le S-NSSAI attribué, le 5QI, et les parametres GBR/MBR/AMBR.
3. Test de charge inter-slices : saturer un slice eMBB tout en mesurant la latence et le jitter sur un slice URLLC partageant le même gNB. Toute correlation entre la charge eMBB et la dégradation URLLC indique un defaut d’isolation.
4. Handover avec slice : vérifier que le S-NSSAI est préservé apres un handover intra-fréquence ou inter-fréquence. Le message RRC Reconfiguration doit porter l’information de slice.

Ces vérifications nécessitent un décodeur de protocole L3 capable de parser les messages NAS et RRC en temps réel. Les outils de diagnostic réseau sur smartphone permettent cette capture directement depuis le chipset Qualcomm du terminal, sans equipement scanner dédié.

Pour approfondir l’intersection entre slicing et sécurité des infrastructures critiques, consultez notre article sur le network slicing 5G et la directive NIS2.

Conclusion

Le network slicing est l’idée la plus ambitieuse de la 5G. Découper un réseau physique en réseaux virtuels isolés, chacun avec son SLA garanti de bout en bout, est un concept architecturalement élégant et techniquement réalisable.

L’architecture est la. Le S-NSSAI, le NSSF, le NSACF, le framework 5QI, le slicing RAN/transport/core : les pièces du puzzle sont définies depuis des années. Les équipements les supportent.

Mais la réalité commerciale de 2026 est sobre. Le slicing se vend en Chine, se teste en Europe, et se promet partout ailleurs. Le business model reste flou. La chaîne BSS/OSS n’est pas prête. La demande entreprise n’est pas structurée.

Pour les opérateurs, la question n’est pas de savoir si le slicing fonctionne. Il fonctionne. La question est de savoir comment le vendre, comment le tarifer, et comment prouver au client que ce qu’il paie en plus d’un APN dédié vaut la différence.

Pour les ingénieurs terrain, le slicing ajoute une dimension a la validation réseau. La signalisation L3 n’est plus optionnelle : elle est la seule façon de vérifier que le slice existe au-delà de la configuration.