Cas d’usage hospitalier — Bouygues Telecom. La figure 1 a été récupérée sur le lien linkedIn d’Olivier Czechowski, Business Developer Smart Industries chez Bouygues Télécom.

Je remercie Olivier, Nicolas Boulenger (expert 5G) et son équipe pour la relecture de l’article et les corrections apportées.

Introduction — La 5G privée hybride en milieu hospitalier

La 5G privée s’impose progressivement comme l’infrastructure de connectivité de référence pour les réseaux de campus et les environnements critiques : usines, ports, campus universitaires, hôpitaux. Elle offre une latence maîtrisée, une isolation du trafic, et une qualité de service (QoS) garantie avec un nombre d’antennes moins important que le WiFi [1]. Le WiFi reste complémentaire à l’accès 5G.

L’architecture dite hybride correspond au modèle PNI-NPN (Public Network Integrated Non-Public Network), défini dans TS 23.501 §5.30.3. Elle distingue deux plans :

• Plan de contrôle (CP) : AMF, SMF, PCF, UDM, AUSF, NRF hébergés dans l’infrastructure opérateur (Bouygues Telecom).
• Plan utilisateur (UP) : l’UPF (User Plane Function) est déployée on-premise dans la salle informatique de l’hôpital, permettant un traitement local du trafic médical sensible.

Ce modèle est normalisé dans la spécification 3GPP TS 23.501 §5.6.5 (LADN — Local Area Data Network) et TS 23.548 (Edge Computing — MEC). Le schéma Bouygues Telecom illustre ce déploiement sur un bâtiment à 4 niveaux, chaque étage disposant d’un DAS 4G/5G, de small cells 5G NR et d’un UPF dédié (nommé LPG par Ericsson) situé dans l’hopital, permettant d’accéder au LAN de l’hôpital.

Figure 1 : Image issue d’un post linkedin de Olivier Czechowski

 

2. Les briques fondamentales du slicing 5G : S-NSSAI, DNN et SSC Mode

2.1 Le S-NSSAI — Single Network Slice Selection Assistance Information

Chaque tranche de réseau (slice) est identifiée par un indicateur de tranche S-NSSAI. Cet indicateur est défini dans la spécification 3GPP TS 23.501 §5.15.2. Il est composé de deux champs :

Champ	Taille	Description
SST (Slice/Service Type)	8 bits	Type de service standardisé ou propriétaire (voir tableau ci-dessous)
SD (Slice Differentiator)	24 bits — optionnel	Différenciateur permettant de distinguer plusieurs slices de même SST au sein d’un même PLMN (ex. deux slices URLLC distinctes)

 

SST standardisés (TS 23.501 Table 5.15.2.2-1) :

SST	Nom	Cas d’usage type
1	eMBB	Enhanced Mobile Broadband — haut débit (smartphones soignants, tablettes EHR, vidéo HD)
2	URLLC	Ultra-Reliable Low-Latency — IoT médical critique, MCX (Mission Critical Communications)
3	MIoT / mMTC	Massive IoT — très grand nombre de capteurs à faible débit (thermomètres, badges RTLS)
4	V2X	Vehicle-to-Everything — ambulances connectées (usage hospitalier marginal)
5	HMTC	High Performance MTC
6	HDLLC	High Data Low Latency Communication
7	GBRSS	Guaranteed Bit Rate Streaming Service.
128/ 255	Propriétaire	Valeurs réservées aux opérateurs pour des usages non standardisés

 

Le SD peut permettre à l’opérateur de définir des slices URLLC (SST=2) distinctes sans ambiguïté pour le réseau. Exemples :

• {SST=2, SD=0x000001} — IoT médical critique (pompes à perfusion, capteurs temps réel)
• {SST=2, SD=0x000002} — Communications MCX (voix/vidéo/alertes critiques)
• {SST=1, SD=0x000003} — eMBB soignants (EHR/HIS, tablettes)

2.2 Le DNN — Data Network Name

Le DNN (Data Network Name) est défini dans les spécifications 3GPP TS 23.501 §5.8.2 et TS 23.003 §9A. Sa structure est identique à un FQDN (ex. hospital-iot, hospital-staff, hospital-mcx) avec une longueur maximale de 100 octets (TS 23.003 §9A.2).

En 4G, l’APN remplissait un rôle de résolution DNS : le MME construisait un FQDN à partir de l’APN (<APN>.apn.epc.mncXXX.mccYYY.3gppnetwork.org) pour résoudre l’adresse du PGW cible. En 5G, ce mécanisme DNS est remplacé par la fonction de découverte exposée par la fonction réseau NRF : la fonction AMF interroge la fonction NRF via le message REST Nnrf_NFDiscovery, en fournissant comme critères de sélection de la fonction SMF, le DNN, le S-NSSAI et le TAI (Tracking Area Identity) de l’UE. Le DNN conserve donc un rôle analogue à l’APN, mais combiné au S-NSSAI et au TAI, via une découverte de services REST plutôt que par DNS.

Le DNN remplit trois fonctions complémentaires :

• Identification du Data Network : fonction première (TS 23.501 §5.8.2) — le DNN désigne le réseau de destination accessible via l’interface N6 de l’UPF, typiquement le Cloud entreprise (EHR/HIS, MCX) ou Internet.
• Participation à la sélection du SMF et de l’UPF : le DNN est l’un des critères transmis par l’AMF au NRF lors de la découverte de la fonction SMF (avec le S-NSSAI et le TAI). Une fois la fonction SMF sélectionnée, celle-ci utilise le DNN, combiné au S-NSSAI, au SSC Mode et à la localisation de l’UE, pour choisir l’UPF approprié. Le DNN est donc un critère contributif — il n’est pas à lui seul déterminant.
• Vérification de souscription : l’UDM stocke, pour chaque abonné, la liste des DNN autorisés par S-NSSAI. Le SMF vérifie cette cohérence lors de l’établissement de la PDU Session (TS 23.502 §4.3.2).

 

DNN et architecture hybride PNI-NPN Dans une architecture PNI-NPN, un DNN hospital-iot sera associé à une fonction réseau SMF qui communique avec la fonction UPF on-premise de l’hôpital. Ces deux entités communiquent via l’interface N4/PFCP, mais elles n’appartiennent pas nécessairement au même plan d’adressage IP : l’UPF on-premise dispose d’une adresse dans le LAN de l’hôpital, tandis que la fonction réseau SMF est dans le plan d’adressage de l’opérateur. La joignabilité N4 entre eux est assurée par le MPLS L3 VPN (ou un VPN dédié plan de contrôle) qui interconnecte les deux domaines. L’UE reçoit une adresse IP allouée par la fonction réseau SMF dans un pool d’adresses IP dédié au DNN, typiquement dans le plan d’adressage du Data Network cible (le Cloud médical). Ce n’est pas l’adresse de l’UPF ni celle du SMF — c’est une adresse routée par l’UPF via l’interface N6 vers le Cloud. Ainsi, depuis le Cloud médical, l’UE est visible comme un hôte du réseau privé hospitalier. Un DNN internet pointera quant à lui vers une fonction UPF mutualisée dans le cœur opérateur avec sortie Internet directe, avec un pool d’adresses distinct. C’est cette configuration SMF — deux DNN, deux UPF, deux pools d’adresses, deux chemins N6 — qui matérialise concrètement la séparation des flux entre réseau privé médical et réseau public.

2.3 Le SSC Mode — Session and Service Continuity

Le Mode SSC définit le comportement de l’UPF anchor (PSA : PDN Session Anchor) lors d’un handover ou d’un déplacement de l’UE. Défini dans la spécification 3GPP TS 23.501 §5.6.9, le mode SSC s’applique par PDU Session.

Mode	Nom	Comportement UPF anchor	Cas d’usage hospitalier
SSC Mode 1	Anchor fixe	L’UPF anchor ne change pas. L’adresse IP de l’UE reste stable pendant toute la PDU Session.	IoT médical et MCX : stabilité de l’adresse IP indispensable pour les flux TCP persistants et les sessions applicatives longues.
SSC Mode 2	Break-before-make	L’ancienne PDU Session est libérée avant qu’une nouvelle soit établie avec un nouvel UPF anchor. L’UE obtient une nouvelle adresse IP.	Services non-critiques tolérant une courte interruption (portail patient, déplacement RDC → Étage 3).
SSC Mode 3	Make-before-break	Une nouvelle PDU Session est établie avant la libération de l’ancienne. Double tunnel transitoire. L’adresse IP change mais sans interruption de service.	Soignants en déplacement inter-étages : continuité de l’application EHR sans coupure visible, malgré le changement d’adresse IP.

 

Le Mode SSC effectif est négocié lors de l’établissement de la session PDU (PDU Session Establishment) : l’UE propose un mode (via l’URSP), le SMF vérifie la compatibilité avec la souscription UDM et retourne le mode retenu dans le PDU Session Establishment Accept.

 

3. Call Flow d’enregistrement — Comment l’UE récupère le S-NSSAI

Procédure décrite dans TS 23.502 §4.2.2 et TS 24.501 §5.5.1.

3.1 Les types de NSSAI

NSSAI	Description
Default Configured NSSAI	Préconfigurée dans l’USIM (EF_5GS3GPPLOC) ou poussée par OTA/OMA-DM avant le premier enregistrement. Utilisée si l’UE n’a pas encore de Configured NSSAI pour ce PLMN.
Configured NSSAI	Liste de S-NSSAI stockée persistamment dans l’UE pour un PLMN donné, après enregistrement réussi. Source : Registration Accept ou UE Configuration Update Command.
Requested NSSAI	Liste envoyée par l’UE dans le Registration Request, construite à partir de la Configured NSSAI courante.
Allowed NSSAI	Sous-ensemble retourné à l’UE dans le Registration Accept : slices effectivement utilisables pour les PDU Sessions.
Rejected NSSAI	S-NSSAIs présents dans la Requested NSSAI mais non autorisés, avec cause de rejet (TS 24.501 §9.11.3.46A).

 

3.2 Séquence détaillée (TS 23.502 §4.2.2)

Étape 1 — Registration Request (UE → AMF) :

L’UE envoie un Registration Request NAS (TS 24.501 §8.2.6) contenant :

• 5GS Registration Type : Initial / Periodic / Mobility
• SUCI (ou 5G-GUTI si déjà enregistré)
• Requested NSSAI : S-NSSAIs souhaités
• UE 5G Security Capability, Last Visited TAI

Étape 2 — Authentication (AMF ↔ AUSF ↔ UDM) :

L’AMF déclenche 5G-AKA ou EAP-AKA’ (TS 33.501 §6.1). L’AUSF interroge l’UDM pour générer les vecteurs d’authentification. Le SUPI est dérivé du SUCI.

Étape 3 — Récupération du profil de souscription (AMF → UDM) :

Via l’interface N8, l’AMF envoie Nudm_SDM_Get (TS 29.503) pour récupérer :

• Subscribed S-NSSAIs : slices souscrites (stockées dans l’UDR)
• DNN autorisés par S-NSSAI : liste des DNN valides pour chaque slice
• Access and Mobility Subscription Data, Session Management Subscription Data

Étape 4 — Validation du slice et consultation optionnelle du NSSF (AMF) :

Rôle exact de l’AMF et du NSSF C’est la fonction AMF qui valide les S-NSSAIs : elle compare la Requested NSSAI de l’UE avec les Subscribed S-NSSAIs récupérés de l’UDM. Seule l’intersection constitue la base de l’Allowed NSSAI. La fonction NSSF (TS 29.531) est consultée via le message Nnssf_NSSelection_Get pour un rôle distinct : sélectionner l’AMF Set ou l’AMF cible capable de servir les slices demandées (contexte multi-AMF, roaming, AMF spécialisée par slice). Il peut aussi retourner les NSSAIs de réseaux disponibles, mais elle n’effectue pas la validation de souscription abonné — responsabilité exclusive de l’AMF, appuyée sur l’UDM.

 

Étape 5 — Registration Accept (AMF → UE) :

L’AMF retourne le Registration Accept (TS 24.501 §8.2.7) contenant :

• Allowed NSSAI : slices effectivement autorisées
• Configured NSSAI : à stocker dans l’UE pour ce PLMN
• Rejected NSSAI (si applicable) avec cause de rejet
• 5G-GUTI, T3512 (timer periodic registration)

 

4. Sélection de la SMF — Rôle de la NRF et critères de découverte

Lors de l’établissement d’une session PDU, l’AMF doit sélectionner la SMF appropriée via la fonction NRF (Network Repository Function) et la procédure Nnrf_NFDiscovery (TS 29.510).

4.1 Déclenchement

L’UE envoie une requête PDU Session Establishment Request NAS à l’AMF contenant :

• PDU Session ID : identifiant local UE (1–15)
• S-NSSAI : doit faire partie de l’Allowed NSSAI
• DNN : absent → SMF attribuera le DNN par défaut de la souscription
• PDU Session Type : IPv4, IPv6, IPv4v6, Ethernet, Unstructured
• SSC Mode : mode de continuité souhaité

4.2 Critères de découverte NRF (TS 29.510 §6.2.6)

Critère	Détail
NF Type = SMF	Filtre primaire : seuls les SMF sont retournés.
S-NSSAI	Le SMF doit supporter le S-NSSAI demandé. Un SMF peut être dédié à certains slices uniquement (ex. SMF URLLC distinct du SMF eMBB).
DNN	Le SMF doit être configuré pour servir ce DNN spécifique (hospital-iot, hospital-staff…).
TAI (Tracking Area Identity)	Le SMF doit couvrir la zone géographique de l’UE — permet de sélectionner l’UPF on-premise le plus proche.
PLMN ID	Pertinent en roaming : le SMF doit appartenir au PLMN home ou visité selon le modèle (HR, LBO).
Priorité / Capacité	Le NRF retourne les SMF triés par priorité et charge. L’AMF peut appliquer du load balancing.

 

4.3 Création du contexte SMF

L’AMF envoie Nsmf_PDUSession_CreateSMContext (TS 29.502) au SMF sélectionné, contenant SUPI, PDU Session ID, S-NSSAI, DNN, PDU Session Type, SSC Mode, et le NAS message original encapsulé.

Le SMF récupère ensuite le Session Management Subscription Data depuis l’UDM (Nudm_SDM_Get, TS 29.503) pour vérifier que le DNN et le S-NSSAI demandés sont bien autorisés pour cet abonné, et obtenir les paramètres de session par défaut (SSC Mode autorisé, PDU Session Type autorisé, règles QoS par défaut, DNN par défaut si absent de la requête).

 

5. URSP — UE Route Selection Policy

L’URSP permet à l’UE de sélectionner automatiquement le bon S-NSSAI et le bon DNN selon l’application qui génère le trafic. Références : TS 23.503 §6.6 et TS 24.526.

5.1 Architecture des acteurs

Entité	Rôle	Interface
PCF	Génère les règles URSP à partir des politiques stockées dans l’UDR (Npcf_UEPolicyControl)	N7 (PCF ↔ AMF), N36 (PCF ↔ UDR)
AMF	Transmet les règles URSP à l’UE via NAS — Registration Accept ou UE Configuration Update Command (TS 24.501 §8.2.29)	N1 (AMF ↔ UE)
UE	Stocke les règles URSP et les applique à chaque flux applicatif pour choisir la PDU Session cible	—

5.2 Structure d’une règle URSP (TS 24.526 §5.2)

Chaque règle contient un Traffic Descriptor et un ou plusieurs Route Selection Descriptors ordonnés par priorité. L’UE évalue les règles dans l’ordre croissant de leur valeur de priorité (valeur la plus faible = priorité la plus haute).

Composant	Sous-champ	Exemple hospitalier
Traffic Descriptor	IPv4/IPv6 destination + prefix	10.100.0.0/16 (plage IP Cloud médical)
	FQDN	ehr-hospital.fr, mcx.hopital.fr
	App Descriptor (OS App ID)	com.hospital.ehrclient (Android)
	Match-all	Trafic non classifié → slice par défaut
Route Selection Descriptor	S-NSSAI	{SST=2, SD=0x000001}
	DNN	hospital-iot, hospital-staff, hospital-mcx
	SSC Mode	1 (anchor fixe) — recommandé pour usages critiques
	PDU Session Type	IPv4, IPv6, Ethernet

 

Le Traffic Descriptor URSP supporte nativement un composant OS-Id + OS-App-Id, introduit depuis 3GPP Release 16 (TS 24.526 §5.2, TS 23.503 §6.6.2).

Cela permet de cibler le trafic d’une application spécifique identifiée par son identifiant système d’exploitation et son nom de package applicatif. Ainsi, le trafic est orienté vers le réseau IP pour un usage eMBB classique vers le réseau opérateur ou vers le réseau de l’hôpital (les serveurs applicatifs).

 

5.3 Exemples de règles URSP hospitalières

Règle 1 —trafic IoT médical critique

Traffic Descriptor : IPv4 dest = 10.100.0.0/16 Route Selection : S-NSSAI={SST=2, SD=0x000001}, DNN=hospital-iot, SSC Mode=1, PDU Type=IPv4 → Pompes à perfusion, capteurs de température → PDU Session sur l’UPF local, anchor fixe (SSC Mode 1) garantissant la stabilité de la session applicative.

Règle 2 — applications soignants (EHR/HIS)

Traffic Descriptor : FQDN = *.ehr-hospital.fr Route Selection : S-NSSAI={SST=1, SD=0x000003}, DNN=hospital-staff, SSC Mode=3, PDU Type=IPv4 → Smartphones et tablettes soignants → PDU Session sur l’UPF, transit vers Cloud via MPLS. SSC Mode 3 (make-before-break) pour les déplacements inter-étages sans coupure visible de l’application EHR.

 

Règle 3 — communications MCX

Traffic Descriptor : App Descriptor = com.hospital.mcx Route Selection : S-NSSAI={SST=2, SD=0x000002}, DNN=hospital-mcx, SSC Mode=1, PDU Type=IPv4 → Push-to-talk critique, vidéo alertes → PDU Session dédiée MCX. SSC Mode 1 obligatoire : un groupe MCX actif ne peut pas tolérer de changement d’adresse IP en cours de communication.

Règle 4 — Priorité 100 (défaut) : accès Internet pour les salariés qui ont une carte SIM dédiée (hopital)

Traffic Descriptor : Match-all Route Selection : S-NSSAI={SST=1}, DNN=internet, SSC Mode=2, PDU Type=IPv4v6 → Smartphones patients, portail patient, divertissement → slice eMBB public, sortie Internet via UPF mutualisé opérateur.

5.4 Provisionnement des règles URSP avec OS-Id et OS-App-Id — Déploiement à l’échelle hospitalière

Les règles URSP décrites doivent être présentes sur chaque UE des professionnels de santé dès la mise en service. L’enjeu du provisionnement de masse est triple :

• Cohérence : tous les UE d’un même profil (soignant, technicien biomédical, agent MCX) appliquent les mêmes règles.
• Mise à jour : toute évolution applicative (nouvel OS-App-Id, nouvelle slice) doit se propager sans intervention manuelle.
• Traçabilité : l’opérateur et l’IT hospitalier doivent pouvoir auditer les règles effectivement en vigueur sur les UE.

Deux canaux de provisionnement coexistent en 5G : le provisionnement réseau (PCF → UE via NAS) et le provisionnement OTA/MDM hors-bande.

Le provisionnement réseau

La politique est stockée dans l’UDR (Unified Data Repository) sous forme de UE Policy par abonné ou par groupe d’abonnés (Policy Group).

Pour une 5G privée hospitalière, l’IT provisionnera typiquement 3 profils de groupe :

Groupe	OS-App-Id inclus	S-NSSAI cible
soignants	com.hospital.ehrclient, com.hospital.his	SST=1, SD=0x000003
biomédical	com.hospital.iotmanager, com.hospital.devicemonitor	SST=2, SD=0x000001
Mcx	com.hospital.mcx, com.hospital.pushtoalk	SST=2, SD=0x000002

Un abonné appartient à un groupe via son SUPI → profil UDM → Policy Group ID → PCF récupère les règles URSP du groupe au niveau de l’UDM/UDR.

Provisionnement OTA via OMA-DM / MDM (canal complémentaire)

Le provisionnement réseau (PCF) gère les règles URSP au sens 3GPP. Mais l’OS-Id/OS-App-Id implique une coordination avec l’OS de l’UE (Android/iOS) qui, lui, est géré par un MDM (Mobile Device Management).

Pourquoi le MDM est indispensable :

L’UE ne peut appliquer une règle URSP basée sur un OS-App-Id que si :

1. L’application hospital.ehrclient est installée sur l’UE.
2. L’OS Android expose l’identité de l’application à la couche NAS (interface OS-URSP, TS 24.526 §4.2).
3. Le profil MDM autorise cette exposition (certains profils MDM restrictifs désactivent l’API OS-URSP).

Le MDM (typiquement Microsoft Intune, VMware Workspace ONE, ou SOTI MobiControl en milieu hospitalier) gère :

Fonction MDM	Lien avec URSP OS-App-Id
Déploiement de l’application	Installe com.hospital.ehrclient via App Store managé
Profil réseau Android (AOSP Network Policy)	Active l’exposition OS-App-Id à la couche modem
Configuration APN/DNN de fallback	Garantit un DNN par défaut si URSP non encore reçu
Mise à jour des App-IDs	En cas de changement de package name applicatif

5.5 OS-Id standardisés — Référence GSMA NG.114

L’OS-Id est un UUID de 16 octets alloué par la GSMA (registre GSMA NG.114). Les valeurs pour les OS courants en milieu hospitalier :

OS	OS-Id (UUID)
Android (AOSP)	97a498e3-fc92-5c94-8986-0333d379d3ae
iOS / iPadOS	4daf3eb8-2d37-4a95-b951-5e44b3f93f0e
Windows	fe0b4dfa-06f6-4ad1-9dc4-c85d0e0d4d76

Pour un déploiement Android Enterprise (profil professionnel hospitalier), seul l’OS-Id Android est pertinent. L’OS-App-Id correspond au package name de l’application (identifiant applicationId dans le build.gradle de l’app).

Encodage dans le Traffic Descriptor (TS 24.526 §5.2.1, type 0x02) :

Octet 1     : Type = 0x02 (OS-Id + OS-App-Id)Octets 2–17 : OS-Id (16 octets UUID)              = 97 A4 98 E3 FC 92 5C 94 89 86 03 33 D3 79 D3 AEOctet 18    : longueur OS-App-Id (UTF-8)Octets 19–N : OS-App-Id = « com.hospital.ehrclient » (UTF-8)

6. Établissement de session PDU— Rôle de l’UPF et du SMF

Référence : TS 23.502 §4.3.2.

6.1 Séquence

Étape 1 — PDU Session Establishment Request (UE → AMF) :

• NAS contenant : PDU Session ID, S-NSSAI, DNN, PDU Session Type, SSC Mode

Étape 2 — Sélection du SMF (AMF → NRF → SMF) :

• L’AMF interroge le NRF via Nnrf_NFDiscovery (S-NSSAI, DNN, TAI) — voir section 4.

Étape 3 — Session Context Creation (AMF → SMF) :

• L’AMF envoie Nsmf_PDUSession_CreateSMContext (TS 29.502).
• Le SMF vérifie le profil de souscription UDM (TS 29.503) : DNN autorisé, SSC Mode, QoS par défaut.

Étape 4 — Configuration de l’UPF (SMF → UPF via N4/PFCP) :

• Le SMF sélectionne l’UPF on-premise selon DNN et TAI, puis pousse via PFCP (TS 29.244) :
  • PDR (Packet Detection Rules), FAR (Forwarding Action Rules), QER (QoS Enforcement), URR (Usage Reporting)

Étape 5 — PDU Session Establishment Accept (SMF → AMF → UE) :

• L’UE reçoit l’adresse IP attribuée, les paramètres QoS (5QI, ARP, GFBR, MFBR) et les informations de tunnel N3 (TEID, adresse UPF).

 

7. Routage entreprise — MPLS L3 VPN entre l’UPF et le Cloud

Le trafic sortant de l’UPF via l’interface N6 est acheminé soit vers le LAN de l’hôpital, soit vers le réseau de l’opérateur.

La signalisation entre le SMF et l’UPF via l’interface N4 est échangée entre le cœur de réseau de l’opérateur et l’UPF dédié.

La technologie de transport privilégiée repose sur le MPLS L3 VPN (RFC 4364), garantissant la sécurisation de la signalisation en isolant les flux et par le chiffrement et l’intégrité. Les flux initiaux N4 ou N6 sont encapsulés en IPSEC et chiffrés.

Par ailleurs, la résilience de l’architecture est assurée par l’utilisation de deux fibres distinctes, chacune reliant un UPF au SMF.

7.1 Pourquoi MPLS L3 VPN ?

Critère	Justification pour la 5G privée hospitalière
Isolation du trafic	VRF dédié : isolation totale du trafic médical vis-à-vis du trafic Internet public. Conforme RGPD et HDS (Hébergeur Données de Santé).
SLA garanti	L’opérateur engage des niveaux de service (latence, jitter, disponibilité) contractuels sur le backbone MPLS.
QoS end-to-end	Classes de service MPLS (EXP/TC bits) : priorisation des flux MCX critiques sur le backbone opérateur.
Scalabilité	Ajout de sites (nouveaux UPF) sans reconfiguration du cœur : le PE intègre le nouveau site dans le VRF existant via MP-BGP.
Sécurité	Trafic encapsulé dans les labels MPLS ; pas d’exposition Internet. Complémentaire avec IPsec pour le chiffrement des données de santé.

 

7.2 Architecture MPLS L3 VPN (RFC 4364)

• CE (Customer Edge) : routeur hôpital, connecté au PE via liaison dédiée.
• PE (Provider Edge) : routeur opérateur en bordure du backbone. Maintient un VRF dédié par client. Distribue les routes via MP-BGP (AFI=1, SAFI=128).
• P (Provider Core) : routeurs cœur MPLS — forwarding sur labels uniquement, aucune connaissance des routes privées client.

7.3 Mécanisme de forwarding

1. UPF → CE (N6) : paquet IP natif, routage local vers le CE.
2. CE → PE ingress : le PE identifie le VRF client et impose deux labels en empilement (label stacking) :

• Label externe (transport label) : label du LSP vers le PE de sortie, distribué par LDP ou RSVP-TE.
• Label interne (VPN label) : identifie le VRF de destination sur le PE de sortie, distribué par MP-BGP avec les Route Targets (RT).

3. Backbone MPLS : routeurs P — commutation sur le label externe uniquement (Penultimate Hop Popping — PHP sur le dernier P).
4. PE egress → CE Cloud : décapsulation MPLS, lookup IP dans la VRF FIB, transmission vers l’endpoint Cloud.

7.4 Interfaces 5GC et backbone MPLS

Interface 3GPP	Protocole	Rôle et remarque
N6	IP natif (après décapsulation GTP-U par l’UPF)	Trafic utilisateur UE → Cloud. Traverse le MPLS L3 VPN via le CE hôpital.
N4	PFCP (UDP/IP, port 8805)	Contrôle SMF → UPF on-premise. Recommandé dans un VRF séparé dédié au plan de contrôle, avec QoS prioritaire.
N3	GTP-U (UDP/IP)	Trafic gNB → UPF. Interne au LAN hospitalier pour un UPF on-premise — ne traverse pas le backbone opérateur.

 

Interface N4 et disponibilité L’interface N4/PFCP entre le SMF (opérateur) et l’UPF (on-premise hôpital) est critique : toute interruption empêche le SMF de mettre à jour les règles de forwarding de l’UPF. Il est fortement recommandé de la faire transiter via un VRF séparé distinct du VRF de données utilisateur, avec une priorité QoS élevée sur le backbone MPLS.  Il faut aussi assurer une sécurisation du CE sur le transport (2 chemins de transport) afin de maintenir un taux de disponibilité élevé

 

8. Synthèse de l’architecture end-to-end

Trajet complet d’un paquet généré par un capteur IoT médical (Étage 2 — Soins intensifs) vers le Cloud EHR :

#	Segment	Technologie	Détail
1	Capteur IoT → Small cell	5G NR (TS 38.211)	Liaison radio NR, slot format URLLC
2	Small cell → UPF Étage 2 (N3)	GTP-U / UDP / IP	Tunnel GTP-U entre gNB et UPF local (LAN hôpital)
3	UPF → CE hôpital (N6)	IP natif	Décapsulation GTP-U, lookup VRF, vers CE
4	CE hopital → Serveurs EHR	IP (Serveur)	Routage vers le serveur local de l’hopital

 

9. Références normatives

Référence	Titre et section pertinente
TS 23.501	System Architecture for 5G — §5.15 (Slicing), §5.6.5 (LADN), §5.6.9 (SSC), §5.8.2 (DNN), §5.30.3 (PNI-NPN)
TS 23.002	Network Architecture — §4A (DNN/APN)
TS 23.003	Numbering, Addressing — §9A (DNN structure, 100 octets max)
TS 23.502	Procedures for 5G — §4.2.2 (Registration), §4.3.2 (PDU Session Establishment)
TS 23.503	Policy and Charging Control — §6.6 (URSP)
TS 23.548	5G System Enhancements for Edge Computing (MEC)
TS 24.501	NAS Protocol for 5G — §5.5.1, §8.2.6/8.2.7, §8.2.29, §9.11.3.46A
TS 24.526	UE policies for 5G — §5.2 (URSP Traffic Descriptors, Route Selection Descriptors)
TS 29.244	Interface CP / UP nodes — PFCP, N4
TS 29.502	SMF Services — Nsmf_PDUSession
TS 29.503	UDM Services — Nudm_SDM (profil souscription)
TS 29.510	NRF Services — Nnrf_NFDiscovery, critères SMF/UPF
TS 29.531	NSSF Services — Nnssf_NSSelection (sélection AMF Set)
TS 33.501	Security Architecture for 5G — §6.1 (5G-AKA), §6.2 (EAP-AKA’)
RFC 4364	BGP/MPLS IP Virtual Private Networks (L3 VPN)
RFC 3031	Multiprotocol Label Switching Architecture (MPLS)