1. Introduction : que se passe-t-il lorsque nous ouvrons une application ?
Lorsqu’un utilisateur installe une application depuis un store, il ne se préoccupe généralement pas de la manière dont son smartphone communiquera avec les serveurs de l’application. Pourtant, plusieurs mécanismes interviennent :
- sélection du réseau de données,
- établissement éventuel d’une session PDU,
- identification des flux applicatifs et application des règles de qualité de service.
En 5G, ces opérations sont dissociées. Une application n’a pas nécessairement besoin de sa propre session PDU, et une même session peut transporter plusieurs flux bénéficiant de traitements QoS différents.
Cette possibilité de différencier les traitements QoS existait déjà en 4G, où une connexion PDN pouvait comporter plusieurs EPS bearers. La principale évolution introduite par la 5G réside dans une séparation plus souple entre la connectivité, les flux QoS et les ressources de transport. Les QoS flows constituent désormais l’unité de différenciation QoS et peuvent être associés aux ressources radio indépendamment de leur identification au sein de la session PDU (En 4G, chaque EPS bearer est associé à un E-RAB lorsqu’il est établi sur l’accès LTE. En 5G, plusieurs QoS flows peuvent être associés à un même DRB et partager un tunnel N3).
Prenons le cas d’une application de télémédecine. Elle peut transporter de la vidéo, de l’audio et des données médicales. Ces trois types de trafic n’ont pas nécessairement les mêmes exigences : l’audio est sensible au délai, la vidéo nécessite un débit suffisant et le transfert d’un document peut généralement tolérer davantage de latence.
Une session PDU, plusieurs traitements QoS
Exemple sur l’application de télémédecine : Audio · Vidéo · Documents
Session PDU
Figure 1 : Acheminement d’une applicationCet exemple illustre une possibilité du modèle 5G, et non un comportement automatique. Un opérateur peut parfaitement transporter ces trois trafics dans un seul flux QoS lorsque leurs exigences et sa politique le permettent.
2. De l’installation de l’application au choix de la session
2.1. Que se passe-t-il lors du téléchargement d’une application ?
Le téléchargement depuis un store utilise une session PDU donnant accès à Internet ou une connexion Wi-Fi déjà disponible.
Lorsque l’application s’installe, l’OS du terminal récupère l’identifiant de l’application.Pour l’application de télémédecine, on suppose l’identifiant de package : com.hopital.telemedecine. Celui-ci permet d’identifier l’application dans un store.
Toutefois, cet identifiant Android ne doit pas être confondu avec l’identifiant applicatif utilisé dans les politiques de routage définies par la 3GPP.
La 3GPP définit le couple OSId/OSAppId
- OSId identifie le système d’exploitation selon un format UUID de 128 bits.
- OSAppId identifie une application ou une catégorie reconnue par l’OS
La 3GPP laisse au système d’exploitation le soin de définir la signification des OSAppId. Un OSAppId peut désigner une application particulière, mais aussi une catégorie d’applications. L’OSAppID n’est pas obligatoirement attribuée à chaque application.
La correspondance entre l’identifiant de package Android et l’OSAppId dépend de l’implémentation du système d’exploitation. L’installation d’une application ne garantit donc pas qu’elle possède un OSAppId exploitable par les règles URSP.
Par exemple, dans une implémentation Android prenant en charge le découpage réseau, la catégorie ENTERPRISE va permettre d’identifier certains trafics professionnels. Plusieurs applications peuvent donc être associées au même OSAppId si elles le demandent et que l’OS l’y autorise ou si la MDM (Mobile Device Management) l’a placée dans un profil professionnel.
Cette identification peut ensuite être utilisée par les règles URSP pour sélectionner une session PDU adaptée au trafic applicatif, lorsque le terminal prend en charge ce mécanisme.
Figure 2 : Installation d’une application et ses identifiants
2.2 L’installation d’une application ne crée pas nécessairement une session
L’installation de l’application ne provoque pas, à elle seule, la création d’une session PDU spécifique. C’est lorsque l’application commence à utiliser le réseau que le terminal doit déterminer comment acheminer son trafic.
Il faut distinguer deux décisions :
- La sélection de la route : quelle session PDU doit transporter le trafic ?
- La classification QoS : quel traitement les paquets doivent-ils recevoir à l’intérieur de cette session ?
Ces décisions relèvent de mécanismes différents.
2.3. Les règles URSP – UE Route Selection Policy : sélectionner la route du trafic applicatif
Les UE Route Selection Policy (URSP), définies dans la TS 23.503, permettent de définir des politiques de routage applicatif dans le terminal.
Une règle URSP comprend un Traffic Descriptor, qui permet d’identifier le trafic concerné, et un ou plusieurs Route Selection Descriptors (RSD), qui décrivent les caractéristiques de la route recherchée.
Le Traffic Descriptor peut exploiter :
- un identifiant applicatif reconnu par le terminal (exemple
com.hopital.telemedecine) - des informations de destination IP, exemple l’adresse du serveur mail
- un domaine ou une capacité de connexion.
Le Route Selection Descriptor (RSD) définit les caractéristiques de la session PDU recherchée. Il peut notamment préciser :
- le DNN, qui identifie le réseau de données ;
- le S-NSSAI, qui identifie la tranche réseau ;
- le type de session PDU (IPv4, IPv6, IPv4v6, Ethernet ou Unstructured) ;
- le mode SSC, qui définit les modalités de continuité de la session ;
- les préférences d’accès (3GPP, non-3GPP ou multi-accès).
Le terminal recherche alors une session PDU existante compatible avec le RSD retenu. S’il en trouve une, il peut la réutiliser ; sinon, il peut tenter d’en établir une nouvelle.
Figure 3 : Correspondance entre application et les règles de trafic
Si un paramètre n’est pas précisé dans le RSD, la session va s’établir avec les informations de configuration ou des valeurs par défaut du terminal.
L’opérateur fournit les règles URSP au terminal selon l’une des 3 manières suivantes :
- Par le PCF : les règles sont transmises dynamiquement au terminal par la signalisation du réseau 5G, via l’AMF.
- Par l’USIM : les règles sont préconfigurées dans la carte SIM de l’opérateur.
- Par le terminal (ME, Mobile Equipment) : les règles sont préconfigurées dans le terminal, par exemple au moyen d’une configuration logicielle de l’opérateur.
Ces trois méthodes ne sont pas équivalentes. La 3GPP définit l’ordre de priorité indiqué par la numérotation ci-dessus :
- Règles fournies par le PCF prévalent sur les règles préconfigurées.
- Règles préconfigurées dans l’USIM sont utilisées en l’absence de règles fournies par le PCF
- Règles préconfigurées dans le terminal (ME) sont utilisées lorsqu’aucune des deux sources précédentes ne fournit de règles applicables.
Leur application effective dépend également des capacités du terminal et de son système d’exploitation. Il ne faut donc pas supposer que toute application téléchargée possède un identifiant exploitable par l’URSP ou qu’elle bénéficie automatiquement d’une tranche dédiée.
2.4. DNN et S-NSSAI : deux informations complémentaires
Le DNN (Data Network Name) désigne le réseau de données auquel le terminal souhaite accéder. Le S-NSSAI (Single Network Slice Selection Assistance Information) identifie une tranche de réseau.
Le couple DNN/S-NSSAI contribue à déterminer les fonctions de réseau et les politiques applicables à la session. Il ne constitue toutefois pas, à lui seul, un identifiant unique de session : un terminal peut établir plusieurs sessions PDU vers un même DNN et un même S-NSSAI.
On rappelle que le couple DNN/S-NSSAI constitue un critère central de découverte et de sélection du SMF, mais il ne suffit généralement pas à identifier une instance SMF unique. L’AMF peut s’appuyer sur le NRF pour découvrir les SMF compatibles, puis tenir compte d’autres paramètres, la localisation du terminal, les données d’abonnement, les capacités et la charge des SMF ainsi que les politiques de l’opérateur. Plusieurs sessions PDU peuvent partager le même DNN et le même S-NSSAI, tout en étant distinguées par leurs PDU Session ID
La session est identifiée, du point de vue du terminal, par son PDU Session ID.
3. Comment le réseau établit-il la session PDU ?
Considérons maintenant le cas où aucune session existante ne répond aux critères de routage.
La procédure décrite ici est celle d’un établissement demandé par le terminal, en situation non itinérante, conformément à la TS 23.502, section 4.3.2.2.1.
Les grandes étapes de l’établissement
-
Le terminal demande la session.
Le UE transmet à l’AMF un message NAS contenant le PDU Session ID, le DNN et le S-NSSAI demandés lorsqu’ils sont fournis, ainsi qu’un conteneur N1 SM comprenant le PDU Session Establishment Request.
-
L’AMF sélectionne le SMF.
Il s’appuie sur les informations d’abonnement, le DNN, le S-NSSAI, la localisation et la découverte des fonctions réseau. Le NSSF peut contribuer à la sélection du contexte de tranche ; le NRF permet de découvrir des SMF compatibles.
-
Le SMF vérifie et prépare la session.
Il vérifie les données d’abonnement auprès de l’UDM, détermine les politiques applicables, éventuellement avec le PCF, sélectionne le ou les UPF et prépare l’adressage IP si la session est de type IP.
-
Le SMF configure le plan usager.
Par N4/PFCP, il installe dans le ou les UPF les règles nécessaires à la détection, à l’acheminement, à la QoS et éventuellement à la mesure du trafic.
-
Le réseau configure l’accès radio et informe le terminal.
Le SMF fournit les informations N2 destinées au gNB et le message N1 SM PDU Session Establishment Accept destiné au terminal. Le gNB configure les ressources radio nécessaires et retourne les informations de tunnel permettant de finaliser le chemin descendant.
À l’issue de cette procédure, le terminal dispose d’une session PDU avec au moins un QoS flow associé à la règle QoS par défaut. Il peut alors transmettre le trafic correspondant à cette session.
La session PDU n’est pas nécessairement établie à chaque ouverture d’application. Elle peut rester disponible et être réutilisée par plusieurs applications.
L’établissement de la session et l’attribution de la QoS sont deux opérations conceptuellement distinctes, même si elles peuvent intervenir au cours de la même procédure.
4.1. Du besoin applicatif aux règles PCC
Le PCF (Policy Control Function) peut fournir au SMF des règles PCC (Policy and Charging Control). Elles permettent de caractériser des flux de service, de définir leur traitement QoS et de préciser les conditions de tarification applicables.
Le SMF traduit ces règles en instructions destinées aux différentes entités du réseau.
| Destinataire | Informations et rôle |
|---|---|
| UE | QoS rules pour classifier les paquets montants |
| UPF | Règles PDR, FAR, QER et éventuellement URR |
| gNB | QFI et profils QoS permettant de traiter les flux sur l’accès radio |
Le SMF réalise l’association des règles PCC aux flux QoS . Plusieurs règles PCC peuvent être associées à un même flux QoS lorsqu’elles sont compatibles.
4.2. Ne pas confondre QFI et 5QI
Le QFI identifie un flux QoS à l’intérieur d’une session PDU. Le 5QI caractérise le traitement QoS attendu, à travers des paramètres tels que la priorité, le délai et le taux d’erreur des paquets.
Deux flux QoS différents peuvent donc avoir le même 5QI. Inversement, un QFI n’est pas une mesure de priorité : le QFI 1 n’est pas intrinsèquement prioritaire sur le QFI 2.
Un flux QoS peut être non-GBR, sans débit garanti, ou GBR, avec des paramètres de débit garanti et maximal. Le profil QoS transmis au réseau d’accès contient le 5QI et l’ARP, ainsi que les paramètres de débit requis pour les flux GBR.
4.3. Le rôle des règles QoS dans le terminal
Une règle QoS permet au terminal de décider à quel flux QoS associer un paquet montant. Elle comporte un ensemble de filtres de paquets, une précédence et le QFI du flux correspondant.
La règle QoS par défaut permet de traiter le trafic qui ne correspond à aucune règle plus spécifique.
Dans notre exemple de télémédecine, le terminal pourrait ainsi disposer d’une règle spécifique pour le trafic audio et utiliser la règle par défaut pour les documents. Les filtres peuvent exploiter des informations telles que les adresses IP, les ports et les protocoles.
Les règles URSP et les règles QoS remplissent deux fonctions complémentaires. Les premières permettent au terminal de sélectionner une session PDU adaptée au trafic applicatif, notamment à partir du DNN et du S-NSSAI. Une fois cette session sélectionnée, les règles QoS permettent de classifier les paquets montants et de les associer aux QoS flows appropriés. Une même session PDU peut ainsi transporter plusieurs flux applicatifs bénéficiant de traitements QoS différents, sans nécessiter l’établissement d’une session distincte pour chacun d’eux
5. Réutiliser une session PDU : où se situe le gain de signalisation ?
C’est une évolution architecturale du modèle 5G : Imaginons qu’un utilisateur dispose déjà d’une session PDU pour accéder à Internet. Il ouvre ensuite une application de visioconférence. Trois situations sont possibles.
L’application utilise la session PDU déjà établie. Les paquets correspondent à une règle QoS existante, éventuellement la règle par défaut. Aucune nouvelle signalisation de session ou de QoS nécessaire
Le réseau souhaite classifier plus précisément le trafic, mais le traitement QoS requis est compatible avec un flux déjà établi. Le SMF peut mettre à jour les règles de classification au niveau du terminal et de l’UPF, tout en conservant le même QFI. Cette classification peut être l’adresse IP du serveur. Il peut y avoir un échange de Signalisation, sans nouvelle session ni nouveau QoS flow
Le service nécessite un traitement QoS distinct. Le SMF peut ajouter un flux QoS à la session existante, configurer les règles correspondantes et, lorsque nécessaire, transmettre son profil QoS au gNB.
La procédure de modification d’une session PDU est définie dans la TS 23.502, section 4.3.3. Le contrôle des QoS flows et les possibilités de préconfiguration sont décrits dans la TS 23.501, section 5.7.
5.1. Pourquoi un nouveau QoS flow ne nécessite-t-il pas forcément un nouveau DRB ?
Dans le réseau d’accès 5G, la couche SDAP assure l’association des flux QoS aux Data Radio Bearers (DRB). Le gNB peut transporter plusieurs flux QoS sur un même DRB si leurs exigences le permettent.
Ainsi, l’ajout d’un nouveau flux QoS ne signifie pas nécessairement la création d’un nouveau bearer radio. Il peut néanmoins nécessiter une mise à jour des informations QoS et de la configuration radio.
Il faut également distinguer le tunnel N3 de la session et les différents QoS flows qu’il transporte. Plusieurs QFI peuvent être multiplexés dans le tunnel N3 d’une même session, sans création d’un tunnel par QFI. Des architectures comportant plusieurs chemins ou tunnels constituent des cas particuliers.
Une modification QoS peut toujours nécessiter plusieurs échanges entre le SMF, l’UPF, le gNB et le terminal
5.2. La Reflective QoS : apprendre à partir du trafic descendant
5.2. La Reflective QoS : déduire les règles montantes du trafic descendant
La Reflective QoS permet au terminal de déduire certaines règles de classification du trafic montant à partir des paquets reçus en liaison descendante. Elle peut ainsi limiter la nécessité de transmettre explicitement de nouvelles règles QoS au terminal.
Prenons l’exemple de notre application de visioconférence. Le réseau a établi un flux QoS particulier pour le trafic vidéo. Lorsque le mécanisme de Reflective QoS est activé, le réseau peut indiquer au terminal, au moyen du Reflective QoS Indicator (RQI), qu’il doit appliquer ce mécanisme aux paquets descendants concernés.
À la réception de ces paquets, le terminal peut créer une règle QoS dérivée, en utilisant notamment les informations d’en-tête des paquets et leur QFI. Les paquets montants correspondant à cette règle sont alors associés au même QFI.
Contrairement à une règle QoS explicitement signalée au terminal, cette règle est déduite du trafic descendant et possède une durée de validité contrôlée par un temporisateur.
Ce mécanisme évite, dans certaines situations, de signaler explicitement chaque nouvelle règle de classification montante. Il ne dispense toutefois pas le réseau de configurer les flux QoS et les ressources nécessaires à leur traitement.
Cette approche peut éviter de signaler explicitement au terminal chaque nouvelle règle montante.
6. Pourquoi la 5G se distingue-t-elle de la connexion PDN en 4G ?
En 4G, une connexion PDN fournit au terminal une connectivité vers un réseau identifié par un APN. Elle est associée à un default EPS bearer et peut comporter plusieurs dedicated EPS bearers.
Lorsqu’un service nécessite un traitement QoS distinct, le réseau peut établir un dedicated bearer. Dans l’architecture EPC classique, cela implique une procédure de contrôle traversant le P-GW, le S-GW, le MME et le réseau d’accès, avec une configuration correspondante du terminal.
En 5G, le QoS flow devient l’unité de différenciation QoS. Il n’est plus nécessaire d’établir un bearer de bout en bout distinct pour chaque traitement QoS.
| Aspect | 4G EPC | 5G Core |
|---|---|---|
| Connectivité | Connexion PDN | Session PDU |
| Réseau de données | APN | DNN |
| Différenciation QoS | EPS bearer | QoS flow |
| Identification QoS | EBI et QCI | QFI et 5QI |
| Traitement par défaut | Default EPS bearer | QoS flow associé à la règle par défaut |
| Traitement supplémentaire | Dedicated bearer si nécessaire | QoS flow supplémentaire si nécessaire |
| Ressources radio | E-RAB associé au bearer | Mapping QoS flows vers DRB par le gNB |
| Contrôle de session | MME, S-GW, P-GW | SMF, avec AMF pour le relais et l’accès |
La 5G dissocie également l’enregistrement du terminal et l’établissement des sessions PDU. À la différence de l’attachement EPS classique, la procédure de Registration 5G n’impose pas l’établissement d’une session PDU.
Cette distinction doit néanmoins être nuancée : des optimisations CIoT ont également introduit en 4G la possibilité de s’attacher sans connexion PDN.
6.1. Comparaison sur un scénario identique
Prenons une application qui commence à transmettre un flux vidéo nécessitant un traitement QoS distinct, alors que le terminal possède déjà une connectivité Internet.
4G Connexion PDN existante
5G Session PDU existante
Le gain potentiel réside dans une plus grande indépendance entre les règles de classification, les QoS flows et les ressources de transport. Il ne faut pas en déduire qu’une modification QoS en 5G est systématiquement dépourvue de messages NAS, N2 ou N4.
7. Conclusion
Le passage de la connexion PDN 4G à la session PDU 5G ne constitue pas un simple changement de terminologie. Il introduit une organisation plus souple de la connectivité et de la qualité de service.
Les règles URSP permettent d’orienter le trafic applicatif vers une session appropriée. Les règles PCC et QoS déterminent ensuite le traitement des différents flux. Enfin, la séparation entre QoS flows, tunnels du cœur de réseau et ressources radio permet de faire évoluer le traitement des applications sans reconstruire systématiquement l’ensemble de leur connectivité.
La distinction essentielle est donc la suivante : une nouvelle application ne signifie pas une nouvelle session PDU, et un nouveau besoin QoS ne signifie pas nécessairement un nouveau QoS flow ou un nouveau DRB.
C’est cette indépendance entre connectivité, classification du trafic et ressources de transport qui permet à la 5G de répondre à des besoins applicatifs variés.
Références normatives
Les principales spécifications à citer dans l’article sont :
-
3GPP TS 23.501 : architecture du 5GS, modèle QoS (§5.7), sélection des fonctions et modes SSC.
-
3GPP TS 23.502, §4.3.2.2.1 : procédure d’établissement d’une session PDU demandée par le terminal.
-
3GPP TS 23.503 : politiques PCC et règles URSP.
-
3GPP TS 23.401 : connexion PDN et EPS bearers en 4G.