Network Slicing 5G et NIS2 : sécuriser les tranches d'infrastructure critique

Un hôpital du nord de l’Europe déploie une tranche 5G URLLC pour la chirurgie assistée à distance. La tranche est configurée pour une latence inférieure à 10 ms avec une fiabilité de 99,999 %. Sur le même gNB, une tranche eMBB grand public gère le streaming vidéo de milliers d’abonnés. Un vendredi soir, un concert dans le stade adjacent sature la tranche eMBB. La latence sur la tranche chirurgicale bondit à 200 ms. Le chirurgien signale un décalage. Le patient est stable, mais la confiance dans l’isolation de la tranche est brisée.

Personne n’a détecté l’interférence inter-slices avant qu’un humain ne la ressente. Aucune alarme ne s’est déclenchée. Aucun seuil KPI n’a été franchi dans l’OSS. L’isolation existait dans la configuration. Elle n’existait pas dans le spectre radio.

C’est le problème exact où le network slicing 5G et NIS2 entrent en collision : comment prouver qu’un réseau virtuel dédié à une infrastructure critique est réellement isolé en conditions réelles ?

Ce qu’est réellement le network slicing 5G

Le network slicing est défini dans la spécification 3GPP TS 23.501 (Architecture système pour le système 5G). Il permet à une infrastructure physique 5G SA (Standalone) unique d’héberger plusieurs réseaux virtuels logiquement isolés de bout en bout, chacun adapté à une catégorie de service spécifique.

Chaque tranche est identifiée par un S-NSSAI (Single Network Slice Selection Assistance Information), composé de deux champs :

• SST (Slice/Service Type) : une valeur sur 8 bits identifiant la catégorie de service. Les valeurs standardisées incluent SST=1 (eMBB), SST=2 (URLLC), SST=3 (mMTC). Les valeurs définies par l’opérateur vont de 128 à 255.
• SD (Slice Differentiator) : une valeur optionnelle sur 24 bits qui distingue les tranches partageant le même SST. Par exemple, deux tranches URLLC pour des clients entreprise différents partagent SST=2 mais ont des valeurs SD distinctes.

Le processus de sélection de slice implique l’AMF (Access and Mobility Management Function), qui reçoit le S-NSSAI demandé par le terminal lors de l’enregistrement et dirige le terminal vers l’instance de tranche appropriée. Le NSSF (Network Slice Selection Function) assiste l’AMF lorsque l’AMF desservant ne peut pas fournir les S-NSSAI demandés.

Au niveau du réseau cœur, chaque tranche peut disposer de ses propres instances SMF (Session Management Function), UPF (User Plane Function) et règles de politique via PCF (Policy Control Function). Au niveau RAN, le slicing repose sur le scheduler du gNB pour allouer les ressources radio par tranche selon les paramètres SLA configurés. C’est là que théorie et pratique divergent.

NIS2 et les obligations des infrastructures critiques

La directive NIS2 (Directive 2022/2555 du Parlement européen et du Conseil, adoptée en décembre 2022) a remplacé la directive NIS originale et élargi considérablement la portée et la rigueur des obligations de cybersécurité dans l’UE.

Les opérateurs de télécommunications sont classés comme entités essentielles sous NIS2. Cette classification déclenche des obligations contraignantes au titre de l’Article 21 :

• Mesures de sécurité basées sur les risques couvrant la chaîne d’approvisionnement, la gestion des incidents, la continuité d’activité et la sécurité réseau
• Notification d’incidents dans les 24 heures (alerte précoce), 72 heures (notification complète) et un mois (rapport final) au CSIRT désigné
• Sécurité de la chaîne d’approvisionnement, incluant la validation des composants et services tiers
• Responsabilité des organes de direction : le conseil d’administration des entités essentielles assume la responsabilité directe de la gestion des risques cyber

Pour les opérateurs déployant le network slicing 5G pour des secteurs critiques (santé, énergie, transport, sécurité publique), NIS2 signifie que l’isolation de slice n’est pas une fonctionnalité de performance. C’est une obligation de sécurité. Si la tranche URLLC d’un hôpital peut être dégradée par le trafic grand public, l’opérateur a failli à mettre en œuvre des mesures de gestion des risques adéquates au titre de l’Article 21.

L’intersection avec le network slicing est directe : si un opérateur promet une tranche URLLC isolée à un client d’infrastructure critique, NIS2 exige que l’isolation soit démontrable, pas présumée. Un fichier de configuration montrant l’attribution S-NSSAI est nécessaire. La preuve que l’isolation tient sous congestion, mobilité et conditions d’interférence est ce que les auditeurs NIS2 rechercheront.

Où l’isolation de slice échoue en pratique

L’architecture 3GPP pour le network slicing est bien définie au niveau du réseau cœur. Des instances dédiées SMF et UPF par tranche fournissent une séparation réelle du trafic au-dessus de l’interface N3. Le problème se situe au niveau RAN, où les ressources radio physiques sont partagées.

Partage des ressources radio

Un gNB dessert plusieurs tranches sur le même spectre. Le scheduler MAC est responsable de l’allocation des PRBs (Physical Resource Blocks) aux terminaux selon le SLA de leur tranche. Mais la capacité radio totale est finie. Quand la tranche eMBB consomme 90 % des PRBs disponibles lors d’un pic de trafic, la tranche URLLC peut ne pas recevoir le minimum garanti, selon l’implémentation du scheduler et la configuration RRM (Radio Resource Management) de l’opérateur.

La spécification 3GPP TS 28.541 définit le modèle de gestion des sous-réseaux de slices. Les paramètres maxNumberOfUEs et resourceAllocationStrategy sont configurables par tranche. Mais l’application dépend de l’implémentation du scheduler par le fournisseur, et il n’existe aucune méthodologie de test standardisée pour vérifier la conformité sous charge.

Défaillances de l’application QoS

Chaque session PDU au sein d’une tranche est associée à des flux QoS, identifiés par QFI (QoS Flow Identifier). Le 5QI (5G QoS Identifier) correspond à des caractéristiques standardisées : budget de délai de paquet, taux d’erreur de paquet et priorité de planification. Le trafic URLLC utilise typiquement 5QI=82 (GBR critique en délai, budget de 10 ms) ou 5QI=83 (10 ms, fiabilité supérieure).

En pratique, la chaîne d’application QoS a plusieurs points de défaillance : l’UPF peut correctement marquer les paquets, mais le scheduler du gNB peut ne pas respecter la priorité sous congestion. Le RAN peut respecter la priorité pour le flux GBR mais laisser les flux non-GBR de la même tranche entrer en compétition avec les flux GBR d’une autre tranche.

Fuite de signalisation inter-slices

Les messages RRC et NAS ne sont pas intrinsèquement conscients des slices dans leur transport. Un terminal enregistré sur plusieurs tranches reçoit des messages RRC Reconfiguration qui peuvent référencer des ressources à travers les tranches. Si le gNB ne sépare pas correctement les rapports de mesure et les paramètres de resélection de cellule par tranche, un terminal sur une tranche URLLC peut être dirigé vers des mesures optimisées pour une tranche eMBB, dégradant la latence.

Exigences par type de tranche : ce que les chiffres imposent

Chaque type de tranche a des cibles de performance quantifiées qui définissent si la tranche fonctionne conformément aux spécifications. Ces cibles proviennent de 3GPP TS 22.261 (Exigences de service pour le système 5G) et ITU-R M.2410.

L’écart entre la cible URLLC de 1 ms / 99,999 % et la cible eMBB de 4 ms / 99,9 % n’est pas marginal. C’est deux ordres de grandeur de différence en fiabilité. Prouver qu’une tranche URLLC atteint sa cible en coexistant avec du trafic eMBB sur le même gNB exige des mesures sous congestion, pas uniquement en conditions de repos.

Méthodologie de validation terrain

Vérifier l’isolation de slice sur le terrain nécessite de capturer et analyser la signalisation Layer 3 au niveau du terminal. La méthodologie suivante fournit les preuves que la conformité NIS2 exige.

Étape 1 : Analyse du PDU Session Establishment

Lors de l’établissement d’une session PDU par le terminal, le message NAS (PDU Session Establishment Accept, défini dans 3GPP TS 24.501) contient le S-NSSAI attribué par le réseau. Celui-ci peut différer du S-NSSAI demandé par le terminal si le NSSF du réseau remplace la sélection.

Capturez le message Registration Accept et vérifiez que l’Allowed NSSAI correspond à la configuration de slice attendue. Puis capturez le PDU Session Establishment Accept et vérifiez le S-NSSAI attribué et les règles QoS (incluant 5QI, ARP et valeurs GBR/MBR).

Étape 2 : Vérification des flux QoS sous charge

Avec une session PDU active sur la tranche cible, générez du trafic saturant la tranche eMBB sur la même cellule. Surveillez la tranche URLLC pour détecter la dégradation de latence, l’augmentation de la gigue et la perte de paquets. La signalisation L3 révélera si le gNB envoie des messages RRC Reconfiguration modifiant les paramètres de scheduling du terminal URLLC en réponse à la congestion eMBB.

Étape 3 : Mobilité avec continuité de slice

Effectuez des handovers (intra-fréquence et inter-fréquence) pendant que le terminal est actif sur une tranche spécifique. Vérifiez que la cellule cible maintient la même attribution S-NSSAI après le handover. Le message RRC Reconfiguration durant le handover doit porter l’information de slice, et la modification de session PDU subséquente (le cas échéant) doit préserver les paramètres QoS.

Étape 4 : Détection d’interférence inter-slices

Utilisez une configuration dual-SIM ou multi-terminaux pour mesurer simultanément les performances sur deux tranches différentes desservies par la même cellule. Corrélez les pics de latence sur la tranche URLLC avec les rafales de débit sur la tranche eMBB. Les captures L3 alignées temporellement des deux terminaux fournissent la preuve de la tenue ou non de l’isolation.

L’outil critique pour ce processus est un décodeur de protocole L3 capable de parser les messages NAS et RRC en temps réel, directement depuis le chipset du terminal via le protocole DIAG de Qualcomm. Cela offre une visibilité sur la signalisation réellement échangée entre le terminal et le réseau, pas la vue abstraite présentée par les systèmes OSS des fournisseurs.

Pour les tests réseau 5G à l’échelle, les outils terrain sur smartphone capturent simultanément la signalisation L3 et les KPIs RF (RSRP, RSRQ, SS-SINR par faisceau) pendant les drive tests, permettant la validation des slices sur de grandes zones de couverture sans matériel scanner dédié.

Conclusion

Le network slicing 5G transforme une infrastructure physique partagée en réseaux virtuels dédiés aux secteurs critiques. L’architecture est solide. Les spécifications sont complètes. Mais la configuration n’est pas l’isolation, et la validation en laboratoire n’est pas la preuve terrain.

NIS2 a changé le paysage de la conformité. Les opérateurs desservant des entités essentielles avec des réseaux 5G découpés en tranches doivent désormais démontrer que l’isolation de slice tient en conditions réelles : congestion, mobilité, interférence et intégration multi-fournisseurs. Les obligations de gestion des risques de l’Article 21 s’appliquent directement aux mécanismes de gestion des ressources radio et d’application QoS qui déterminent si une tranche URLLC délivre réellement 1 ms de latence et 99,999 % de fiabilité quand cela compte.

La preuve vient du terrain. Les messages PDU Session Establishment, l’analyse RRC Reconfiguration et la corrélation de performance inter-slices fournissent les données vérifiables que les auditeurs NIS2 exigent.

Alors que les déploiements 5G SA se multiplient et que les infrastructures critiques s’appuient de plus en plus sur la connectivité découpée en tranches, une question définit la posture de conformité de l’opérateur : pouvez-vous prouver que vos slices sont isolées, ou le croyez-vous simplement ?