Archives du mot-clef 5G

De l’application mobile à la session PDU : comprendre la connectivité et la QoS en 5G

Posté le by - 192 vues
Répondre

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 :

  1. sélection du réseau de données,
  2. établissement éventuel d’une session PDU,
  3. 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

Cet 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 :

  1. Par le PCF : les règles sont transmises dynamiquement au terminal par la signalisation du réseau 5G, via l’AMF.
  2. Par l’USIM : les règles sont préconfigurées dans la carte SIM de l’opérateur.
  3. 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 :

  1. Règles fournies par le PCF prévalent sur les règles préconfigurées.
  2. Règles préconfigurées dans l’USIM sont utilisées en l’absence de règles fournies par le PCF
  3. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

4. Comment la QoS est-elle attribuée aux flux ?

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.

Situation A : Le trafic utilise un flux QoS existant

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

Situation B : Une nouvelle règle est nécessaire, sans nouveau flux QoS 

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

Situation C : Un nouveau flux QoS est nécessaire

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.

* Selon les règles déjà présentes, une mise à jour du terminal peut être nécessaire.
** Dans le scénario considéré, sans ajout d’un chemin de transport particulier.
L’ajout d’un flux QoS à une session PDU existante peut nécessiter une procédure de modification comprenant de la signalisation NAS (N1), NGAP (N2) et PFCP (N4). Il n’impose cependant ni l’établissement d’une nouvelle session PDU, ni la création systématique d’un nouveau DRB ou d’un nouveau tunnel N3.

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

Nouveau dedicated bearer
Signalisation EPC, NAS et radio
Ressources du bearer

5G Session PDU existante

Nouveau QoS flow si nécessaire
Modification des règles et profils nécessaires
Réutilisation possible du DRB et du tunnel N3

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.

EDGEAPP : comment la 5G permet-elle aux applications d’exploiter l’Edge Computing ?

Posté le by - 108 vues
Répondre

L’Edge Computing constitue une évolution importante introduite avec la 5G. Son principe paraît simple : plutôt que d’envoyer systématiquement les données d’une application vers un serveur situé dans un cloud central, une partie des traitements peut être réalisée dans une infrastructure informatique située plus près de l’utilisateur.

Cette proximité peut réduire la latence, raccourcir le chemin suivi par les données dans le réseau et améliorer l’expérience utilisateur. Le principe devient particulièrement intéressant pour des applications telles que la réalité étendue (XR), le cloud gaming, les applications industrielles, les véhicules connectés ou encore certaines applications utilisant l’intelligence artificielle.

Mais rapprocher les serveurs des utilisateurs introduit un nouveau problème : dans une architecture cloud classique, une application peut connaître à l’avance le serveur sur lequel elle doit se connecter. Dans un environnement Edge, il peut au contraire exister plusieurs instances du même service, déployées dans différents sites géographiques.

Le serveur optimal pour un utilisateur situé à Poitiers n’est donc pas nécessairement celui qu’il devra utiliser quelques minutes plus tard s’il se déplace vers Tours.

Il faut pouvoir déterminer :

  • quels environnements Edge sont accessibles ;
  • quels services y sont disponibles ;
  • quel serveur Edge convient à l’application ;
  • comment exploiter les informations fournies par le réseau 5G ;
  • et éventuellement comment changer de serveur lorsque l’utilisateur se déplace, sans interrompre son service.

C’est précisément l’un des objectifs de l’architecture EDGEAPP, spécifiée par le 3GPP dans la TS 23.558.

Le 3GPP définit EDGEAPP comme une architecture de couche applicative destinée à permettre le déploiement et l’utilisation d’applications Edge au-dessus des réseaux 3GPP. Elle complète donc les mécanismes Edge du réseau 5G définis dans la TS 23.548.

L’objectif de cet article est de comprendre cette architecture de bout en bout.

1. Pourquoi une architecture spécifique pour les applications Edge ?

Imaginons une application de réalité augmentée. La caméra d’un terminal capture une scène. L’application transmet certaines données à un serveur qui réalise des traitements complexes : reconstruction de la scène, reconnaissance d’objets, génération d’éléments graphiques ou inférence par intelligence artificielle.

Avec un cloud central, le chemin pourrait être schématiquement : UE transmet ses données au gNB vers l’UPF jusqu’au serveur applicatif dans le cloud

Une partie importante de la latence provient du transport des données jusqu’au centre de données. Avec l’Edge Computing, le serveur applicatif peut être rapproché du réseau d’accès. Mais le service peut disposer de plusieurs serveurs, l’un sur Paris, l’autre sur Bordeaux, un autre sur Lyon et un dernier sur Marseille ou Malestroit.

Cette sélection ne dépend pas uniquement de la distance géographique. Elle peut également prendre en compte la topologie du réseau, les ressources disponibles, la zone de service, les caractéristiques de l’application et les politiques du fournisseur Edge.

Deux problématiques complémentaires apparaissent alors :

  • La découverte applicative : comment le terminal identifie-t-il les environnements Edge et les serveurs capables de fournir le service demandé ?
  • La connectivité réseau : comment le système 5G permet-il d’acheminer les paquets vers les ressources Edge sélectionnées ?

Le terminal doit donc pouvoir découvrir une instance du service appropriée à son contexte, en fonction de sa localisation, de la topologie réseau et des caractéristiques du service.

2. Architecture générale EDGEAPP

L’architecture EDGEAPP, définie par le 3GPP dans la spécification TS 23.558, permet à une application exécutée sur un terminal mobile d’accéder à des services hébergés à la périphérie du réseau (Edge Computing).

L’architecture repose sur cinq entités complémentaires.

Le terminal utilisateur (UE) héberge :

  • l’Application Client (AC)
  • l’entité Edge Enabler Client (EEC).

Le réseau Edge (EDN) héberge :

  • l’entité Edge Application Server (EAS)
  • l’entité Edge Enabler Server (EES).

Enfin, l’entité Edge Configuration Server (ECS) fournit les informations permettant au terminal de découvrir les environnements Edge disponibles.

Le principe consiste à séparer les échanges applicatifs des mécanismes nécessaires à leur établissement. L’architecture distingue donc deux niveaux.

  1. La couche applicative assure les échanges entre l’AC et l’EAS. Elle fournit le service effectivement utilisé : jeu vidéo, réalité augmentée, application industrielle ou traitement d’intelligence artificielle.
  2. La couche Edge Enabler Layer (EEL) facilite l’accès à ces services. Elle regroupe les entités fonctionnelles EEC, EES et ECS, qui interviennent dans la configuration de l’environnement Edge, la découverte des serveurs applicatifs et certaines procédures de continuité de service.

2. Deux architectures complémentaires : EDGEAPP et 5GC

La TS 23.558 (EDGEAPP) définit les mécanismes applicatifs de découverte, de configuration et de continuité.

La TS 23.548 décrit les mécanismes du système 5G permettant la sélection du chemin utilisateur, l’utilisation d’un UPF local, l’identification des points d’accès aux réseaux de données par les DNAI et la découverte DNS des serveurs applicatifs.

3. Les fonctions du EDGEAPP

3.1 AC – Application Client

L’Application Client est l’application présente dans le terminal.

Il peut s’agir par exemple d’une application :

  • XR ;
  • cloud gaming ;
  • industrielle ;
  • automobile ;
  • multimédia ;
  • d’intelligence artificielle.

L’AC communique avec son serveur applicatif. L’AC est une application téléchargée d’un store (Google Play, Apple Store).

L’AC échange les données nécessaires à son fonctionnement avec un serveur applicatif, appelé Edge Application Server (EAS).

Cependant, l’AC n’a pas nécessairement connaissance des mécanismes permettant de découvrir l’infrastructure Edge. Il peut s’appuyer sur l’EEC pour identifier un serveur adapté à ses besoins.

L’interface EDGE-5 gère les interactions entre l’AC et l’EEC.

3.2 Entité EEC – Edge Enabler Client

L’entité Edge Enabler Client est située dans le terminal. Elle joue un rôle central dans l’accès aux services Edge.

L’entité EEC participe :

  • au service provisioning ;
  • à l’enregistrement auprès d’une entité EES ;
  • à la découverte des serveurs EAS ;
  • à certaines procédures de continuité de service.

Un terminal peut contenir plusieurs entités EEC. Une même entité EEC peut également communiquer avec plusieurs entités EES.

L’entité EEC utilise principalement deux interfaces : EDGE-4 pour communiquer avec l’entité ECS et EDGE-1 pour communiquer avec l’entité EES.

3.3 L’entité ECS – Edge Configuration Server

L’entité Edge Configuration Server intervient en amont de la découverte des applications.

Son rôle principal est de fournir à l’entité EEC les informations de configuration nécessaires pour accéder à un environnement Edge approprié, l’identification du réseau EDGE -EDN, sa zone de service et les informations permettant de joindre un ou plusieurs entités EES.

Le service provisioning permet précisément de configurer l’entité EEC avec les informations relatives aux services Edge disponibles en fonction :

  • de la localisation de l’UE ;
  • des besoins du service ;
  • des préférences ;
  • de la connectivité.

Une entité ECS peut prendre en charge plusieurs réseaux EDN et fournir à l’entité EEC les informations relatives à plusieurs entités EES.

Il ne faut donc pas confondre l’entité ECS et l’entité EES : la première permet de découvrir et de configurer l’accès à l’environnement Edge, tandis que la seconde facilite la découverte des applications hébergées dans cet environnement.

3.4 Entité EES – Edge Enabler Server

L’entité Edge Enabler Server est déployée dans l’environnement Edge.

Il fournit aux entités EEC les fonctions nécessaires à l’utilisation des services Edge.

L’entité EES connaît les serveurs EAS qui lui sont associés. Les serveurs EAS peuvent s’enregistrer auprès de l’entité EES avec leurs informations de disponibilité, y compris certaines contraintes temporelles ou géographiques. Il permet ensuite à l’entité client EEC de découvrir un serveur EAS.

On peut donc considérer l’entité EES comme un point d’entrée vers les services applicatifs d’un environnement Edge. Mais son rôle va au-delà d’un simple annuaire : il intervient également dans l’exposition de capacités réseau, certaines demandes de QoS et la continuité de service.

3.5 Le Serveur EAS – Edge Application Server

L’Edge Application Server constitue le serveur applicatif avec lequel  l’Application Client communique.

Plusieurs instances d’un même service peuvent être déployées dans différents réseaux EDN. Chacune peut posséder ses propres caractéristiques, sa zone de service et ses conditions de disponibilité.

Le serveur EAS peut également exploiter certaines capacités du réseau 3GPP, directement lorsque les conditions de confiance le permettent, par l’intermédiaire de l’entité EES ou au moyen des fonctions d’exposition du réseau, telles que la NEF.

3.6. L’Edge Data Network : où sont hébergées les applications ?

L’EDN – Edge Data Network correspond au réseau de données dans lequel les ressources Edge sont accessibles.

Il peut héberger une ou plusieurs entités EES et plusieurs serveurs EAS. Un fournisseur Edge peut ainsi proposer différents services applicatifs au sein d’un même EDN.

L’EDN constitue donc l’environnement réseau dans lequel les applications Edge sont déployées et rendues accessibles aux terminaux.

4. Les interfaces EDGEAPP

Pour permettre à ces fonctions de coopérer, la spécification TS 23.558 définit plusieurs points de référence appelés EDGE-1 à EDGE-9

L’interface EDGE-1 permet l’enregistrement/désenregistrement de l’EEC, la récupération d’informations de configuration EAS, la découverte des EAS et certaines procédures de continuité de service.

L’interface EDGE-2 relie l’Edge Enabler Server (EES) aux fonctions du cœur de réseau 3GPP. Elle permet à l’entité EES d’accéder aux capacités réseau exposées par l’opérateur, par exemple pour obtenir des informations de localisation ou interagir avec des mécanismes de QoS et d’influence sur le routage du trafic. Selon le modèle de déploiement, ces interactions peuvent passer par le NEF, qui expose certaines capacités du 5GC aux applications autorisées, ou utiliser des interfaces directes lorsque l’entité EES appartient au domaine de confiance de l’opérateur.

L’interface EDGE-3 permet l’enregistrement des EAS, la découverte d’un EAS cible lors d’une relocalisation, l’accès à certaines informations réseau et des opérations relatives à la QoS et à la continuité.

L’interface EDGE-4 permet à l’entité EEC de récupérer les environnements Edge auxquels il peut accéder auprès de l’entité ECS; A partir de ces informations, l’entité EEC pourra contacter les entités EES appropriées. Cette interface intervient donc en amont de la découverte des EAS.

L’interface EDGE-5 permet à l’application de s’enregistrer auprès de l’entité EEC, de demander la découverte d’un EAS, de déclencher une procédure de relocalisation du contexte applicatif (ACR) ou de s’abonner aux services proposés par l’EEC.

L’interface EDGE-6 permet à une entité EES de s’enregistrer auprès de l’entité ECS avec les informations correspondantes. L’entité EES peut évidemment se désenregistrer ou récupérer des informations concernant un EES cible (Target EES, T-EES).

Les interfaces EDGE-7 et EDGE-8 permettent de communiquer avec le cœur de réseau.

L’interface EDGE-9 permet la coopération entre plusieurs entités EES.

5. Comment un terminal découvre-t-il son environnement Edge

Lorsqu’un utilisateur démarre une application compatible Edge, plusieurs opérations peuvent être nécessaires avant que l’AC communique avec son serveur applicatif.

  1. Découverte de l’ECS : c’est le premier problème de la phase d’initialisation qui permet à l’EEC de savoir quel ECS contacter pour commencer à utiliser EDGEAPP.
  2. Service Provisioning : L’ECS fournit les informations relatives aux environnements Edge et aux EES appropriés.
  3. EEC Registration : L’EEC s’enregistre auprès de l’EES sélectionné si cet enregistrement est requis.
  4. EAS Discovery : L’EEC interroge l’EES afin de découvrir un serveur applicatif correspondant aux besoins de l’AC.
  5. Communication applicative : L’AC peut commencer ses échanges avec l’EAS découvert.

5.1. Première étape : découvrir l’ECS

Avant de demander les informations relatives aux environnements Edge, l’EEC doit savoir quel ECS contacter.

La TS 23.558 prévoit plusieurs possibilités pour obtenir ses informations de configuration. Elles peuvent être préconfigurées dans l’EEC, fournies par une application compatible Edge, renseignées par l’utilisateur ou provisionnées par l’opérateur au travers du système 5G.

Les informations peuvent comprendre une URI, un FQDN, une adresse IP ou encore l’identifiant du fournisseur ECS.

Une possibilité particulièrement intéressante consiste à obtenir l’adresse de l’ECS directement auprès du réseau 5G.

Comment le 5GC peut-il fournir l’adresse de l’ECS ?

La TS 23.548 prévoit un mécanisme appelé ECS Address Provisioning.

Lors de l’établissement d’une session PDU, un terminal compatible peut indiquer sa capacité à recevoir des informations de configuration ECS et à les transmettre à son EEC.

Le SMF peut alors fournir ces informations au terminal au moyen des PCO (Protocol Configuration Options), lors de l’établissement ou de la modification de la session PDU.

Les informations fournies peuvent être associées à certaines conditions de validité, notamment géographiques.

Cette procédure permet au réseau 5G de contribuer à la découverte de l’infrastructure Edge. Elle n’est toutefois pas l’unique méthode de configuration de l’ECS.

5.2. Deuxième étape : le Service Provisioning

Une fois l’ECS identifié, l’EEC peut demander les informations nécessaires pour accéder à un environnement Edge.

Cette opération, appelée Service Provisioning, permet d’obtenir les informations relatives aux EDN et aux EES appropriés.

L’ECS peut tenir compte de plusieurs paramètres : le profil de l’Application Client, la localisation du terminal, les besoins du service, la connectivité disponible et les politiques du fournisseur Edge.

Les zones de service

La proximité d’un serveur Edge ne se résume pas à une distance géographique.

EDGEAPP distingue plusieurs zones de service :

  • L’EDN Service Area définit la zone depuis laquelle l’accès à un EDN est autorisé.
  • L’EES Service Area correspond à la zone de service d’un EES. Elle est égale ou incluse dans celle de l’EDN.
  • L’EAS Service Area définit la zone de service d’un EAS. Elle est égale ou incluse dans celle de l’EES qui le dessert.

Ces zones peuvent être exprimées à partir d’informations géographiques ou topologiques, selon leur nature.

Un serveur géographiquement proche du terminal n’est donc pas nécessairement éligible. Il faut également qu’il soit accessible dans la zone considérée et qu’il puisse fournir le service demandé.

Le rôle du fournisseur Edge

Le fournisseur de services Edge, ou ECSP (Edge Computing Service Provider), peut être l’opérateur mobile lui-même ou un fournisseur tiers.

Un opérateur peut conclure des accords avec plusieurs ECSP et un ECSP peut travailler avec plusieurs opérateurs.

L’ECS est configuré selon la politique de Service Provisioning de l’ECSP. Le 3GPP définit le cadre permettant d’appliquer cette politique, mais ne spécifie pas son contenu détaillé.

5.3. Deux modèles de Service Provisioning

La TS 23.558 prévoit deux modèles de fonctionnement : Request/Response et Subscribe/Notify.

  • Request/Response Une demande ponctuelle

L’EEC interroge l’ECS pour obtenir les informations de configuration nécessaires. L’ECS retourne les informations correspondant à la demande. L’EEC peut ensuite conserver certaines informations reçues pendant leur durée de validité afin d’éviter de répéter inutilement la procédure.

  • Subscribe/Notify Une mise à jour sur événement

L’EEC peut s’abonner aux notifications de l’ECS afin d’être informé lorsque des changements justifient une nouvelle configuration.

Par exemple, le 5GC peut signaler un changement du chemin utilisateur. À partir d’un nouveau DNAI, l’ECS peut déterminer que d’autres EES sont devenus plus appropriés et en informer l’EEC.

Le second modèle présente un intérêt particulier pour les applications mobiles. Le terminal n’a pas besoin d’interroger constamment l’ECS pour savoir si son environnement Edge est toujours approprié.

  1. Enregistrement et découverte du serveur applicatif

Après le Service Provisioning, l’EEC dispose des informations lui permettant de contacter un ou plusieurs EES.

Il reste à déterminer quel serveur applicatif pourra fournir le service demandé.

6.1. L’enregistrement de l’EEC

L’EEC peut effectuer une procédure d’enregistrement auprès de l’EES sélectionné.

Cet enregistrement permet de fournir à l’EES les informations nécessaires à certains services Edge. Il n’est cependant pas systématiquement obligatoire : la procédure générale prévoit que l’EEC s’enregistre lorsque le profil de l’EES indique que cet enregistrement est requis.

Il convient de distinguer trois types d’enregistrement dans l’architecture : l’enregistrement de l’EEC auprès de l’EES, celui de l’EAS auprès de l’EES et celui de l’EES auprès de l’ECS.

6.2. L’enregistrement des EAS

Pour répondre aux demandes de découverte, l’EES doit disposer d’informations concernant les serveurs applicatifs disponibles.

Les EAS peuvent donc s’enregistrer auprès de l’EES par l’interface EDGE-3.

Ils transmettent leurs informations de disponibilité, leurs caractéristiques et certaines contraintes géographiques ou temporelles.

L’EES dispose ainsi des informations nécessaires pour identifier les EAS susceptibles de répondre aux demandes des EEC.

6.3. EAS Discovery : trouver le serveur applicatif

À ce stade, l’EEC connaît l’ECS, dispose des informations relatives à l’EDN et sait quel EES contacter.

Il lui reste à découvrir un EAS correspondant au service demandé par l’Application Client.

L’EEC envoie une demande de découverte à l’EES via EDGE-1. L’EES identifie les EAS correspondant aux critères de la demande et retourne les informations nécessaires pour les joindre.

L’EEC peut alors transmettre à l’AC les informations dont il a besoin.

L’application dispose désormais des éléments nécessaires pour communiquer avec son serveur applicatif.

  1. Comment le réseau 5G achemine-t-il les paquets vers l’Edge ?

La découverte d’un EAS ne suffit pas à garantir un chemin réseau approprié.

Il faut également que le trafic de la session PDU puisse être acheminé vers le réseau de données hébergeant le serveur applicatif.

La TS 23.548 définit plusieurs modèles de connectivité Edge permettant au système 5G de répondre à cette problématique.

7.1. Session Breakout et UPF local

Dans une architecture de Session Breakout, certains flux de la session PDU peuvent être dirigés vers un UPF local afin d’accéder à un EDN.

Un UL CL (Uplink Classifier) ou un Branching Point, selon le modèle de connectivité, permet de différencier les flux et de les orienter vers les points d’ancrage appropriés.

Le trafic destiné à un service Edge peut ainsi être acheminé vers un PSA UPF local, tandis que d’autres flux continuent à utiliser un chemin différent.

Ce mécanisme permet de rapprocher le point de sortie du trafic du serveur applicatif.

7.2. DNAI : identifier le point d’accès au réseau de données

Le DNAI (Data Network Access Identifier) identifie un point d’accès au réseau de données.

Il permet au système 5G de représenter les différents points d’accès possibles à un environnement Edge et intervient dans les mécanismes de sélection du chemin utilisateur.

Lorsqu’un terminal se déplace, le point d’accès approprié peut changer. Le 5GC peut alors adapter le chemin du trafic vers un autre point d’accès au réseau de données.

Cette évolution peut également avoir des conséquences au niveau applicatif : un autre environnement Edge ou un autre EAS peut devenir plus approprié.

C’est ici qu’apparaît l’une des principales complémentarités entre le 5GC et EDGEAPP.

7.3. Une autre méthode de découverte : DNS et EASDF

La TS 23.548 prévoit également un mécanisme de découverte des serveurs applicatifs reposant sur le DNS.

Il fait intervenir l’EASDF (Edge Application Server Discovery Function), qui permet au système 5G de coordonner certaines procédures de résolution DNS avec les informations de connectivité Edge.

Le terminal peut ainsi obtenir l’adresse IP d’un EAS approprié à partir d’une requête DNS.

Ne pas confondre EES et EASDF

Deux mécanismes de découverte situés à des niveaux différents.

EES TS 23.558 : Découverte applicative des EAS par l’intermédiaire de l’EEC, au sein de l’architecture EDGEAPP.

EASDF TS 23.548 Découverte des adresses IP des EAS par DNS, coordonnée avec les mécanismes Edge du système 5G.

La découverte DNS via l’EASDF ne constitue donc pas une étape supplémentaire obligatoire de la procédure EDGEAPP. Il s’agit de mécanismes distincts qui peuvent être utilisés selon le modèle de déploiement.

7.4. L’exposition des capacités du réseau 3GPP

La couche Edge Enabler peut également exploiter certaines capacités du cœur de réseau.

Les entités EDGEAPP peuvent avoir besoin d’informations relatives à la localisation du terminal, aux événements réseau, à la qualité de service ou aux changements du chemin utilisateur.

Trois interfaces interviennent principalement : EDGE-2 entre l’EES et le cœur 3GPP, EDGE-7 entre l’EAS et le cœur 3GPP, et EDGE-8 entre l’ECS et le cœur 3GPP.

Ces interactions peuvent s’appuyer sur les API exposées par les fonctions SCEF ou NEF. Dans certains modèles de déploiement, un accès direct à certaines fonctions du cœur peut également être possible lorsque les conditions de confiance appropriées sont réunies.

  1. Mobilité et continuité de service

L’un des intérêts de l’Edge Computing est de pouvoir fournir des services à faible latence à des utilisateurs mobiles.

Cependant, lorsqu’un terminal se déplace, le serveur Edge initialement sélectionné peut ne plus être le plus approprié.

Un changement du chemin utilisateur, de DNAI ou d’environnement Edge peut alors nécessiter la découverte d’un autre serveur applicatif.

EDGEAPP prévoit des mécanismes permettant d’accompagner cette évolution, l’Application Context Relocation (ACR).

Lorsqu’une application possède un contexte d’exécution sur un serveur, un changement d’EAS peut nécessiter le transfert de ce contexte vers un nouveau serveur.

L’ACR permet d’organiser cette relocalisation entre un EAS source (S-EAS) et un EAS cible (T-EAS). Les EES source et cible peuvent également coopérer, au moyen de l’interface EDGE-9.

L’objectif est de permettre la poursuite du service avec une interruption minimale, sous réserve que l’application et l’infrastructure prennent en charge les mécanismes nécessaires.

  1. Étude de cas : une application XR dans un véhicule connecté

Reprenons l’ensemble de l’architecture à travers un exemple.

Un passager utilise une application de réalité augmentée dans un véhicule circulant entre Poitiers et Tours. L’application transmet certaines données à un serveur Edge chargé de réaliser des traitements graphiques et de reconnaissance d’objets.

Du lancement de l’application à la mobilité

1- Établissement de la session PDU

Le terminal se connecte au réseau 5G. S’il prend en charge le mécanisme approprié, le SMF peut lui fournir les informations de configuration ECS par les PCO.

2- Découverte de l’ECS

Le terminal transmet les informations reçues à l’EEC. Celui-ci peut désormais contacter le serveur de configuration.

3- Service Provisioning

L’EEC transmet les informations nécessaires à l’ECS, le profil de l’application XR. L’ECS identifie les environnements Edge et les EES appropriés en tenant compte des paramètres disponibles.

4- Enregistrement auprès de l’EES

Si le profil de l’EES l’exige, l’EEC effectue son enregistrement auprès du serveur sélectionné.

5- Découverte de l’EAS

L’EEC demande à l’EES d’identifier un serveur capable de fournir le service XR. L’EES retourne les informations nécessaires pour joindre un EAS approprié.

6 – Début des échanges applicatifs

L’AC communique avec l’EAS découvert. Le trafic est acheminé par le système 5G vers le réseau de données hébergeant ce serveur.

7- Déplacement du véhicule

Lorsque le véhicule se rapproche de Tours, le chemin réseau initial peut devenir moins approprié. Le 5GC peut adapter le chemin utilisateur et déterminer un nouveau DNAI.

Dans le modèle Subscribe/Notify, l’ECS peut exploiter les informations réseau reçues pour déterminer si d’autres EES sont désormais plus adaptés et notifier l’EEC.

8 – Relocalisation du contexte applicatif

Si l’application prend en charge les mécanismes de continuité nécessaires, un nouvel EAS peut être sélectionné. Le contexte applicatif peut être transféré de l’EAS source vers l’EAS cible au moyen des procédures ACR.

Cet exemple montre que la mobilité Edge ne se limite pas à modifier le routage des paquets. Elle peut nécessiter une coordination entre les mécanismes du réseau 5G et les procédures applicatives EDGEAPP.

Conclusion

L’Edge Computing ne consiste pas uniquement à rapprocher les serveurs des utilisateurs. Il nécessite également des mécanismes permettant aux applications de découvrir les ressources disponibles, d’y accéder et, lorsque cela est nécessaire, de poursuivre leur service lors des déplacements.

L’architecture EDGEAPP, définie dans la TS 23.558, apporte les mécanismes de configuration, de découverte et de continuité au niveau applicatif grâce à l’EEC, l’ECS et l’EES.

La TS 23.548 complète cette architecture en définissant les mécanismes du système 5G nécessaires à l’accès aux ressources Edge, la sélection du chemin utilisateur, les UPF locaux, les DNAI et la découverte DNS via l’EASDF.

La complémentarité entre ces deux spécifications permet de relier la découverte des services applicatifs à la connectivité réseau, afin de rendre les environnements Edge accessibles aux applications mobiles.

Références

[1] 3GPP TS 23.558 — Architecture for enabling Edge Applications  Architecture EDGEAPP, fonctions, interfaces, Service Provisioning, découverte et continuité de service.

[2] 3GPP TS 23.548 — 5G System Enhancements for Edge Computing- Connectivité Edge, découverte DNS, EASDF, DNAI et provisioning de l’adresse ECS.

[3] 3GPP TS 23.501 — System Architecture for the 5G System

[4] 3GPP TS 23.502 — Procedures for the 5G System

[5] 3GPP TS 23.503 — Policy and Charging Control Framework for the 5G System

De la 5G à la 6G : vers une nouvelle génération d’algorithmes de chiffrement avec l’AEAD ?

Posté le by - 145 vues
Répondre

La 6G va permettre de nouveaux usages nécessitant des débits très élevés et des temps de réponse très faibles. Dans ce contexte, la protection des données ne doit pas devenir un facteur limitant : il faut pouvoir chiffrer et authentifier les données avec une latence et une consommation énergétique aussi faibles que possible.

C’est dans ce cadre que le 3GPP étudie l’utilisation d’une approche cryptographique appelée AEAD – Authenticated Encryption with Associated Data, que l’on peut traduire par chiffrement authentifié avec données associées.

Pour comprendre l’intérêt de cette évolution, commençons par regarder comment les données sont protégées aujourd’hui.

1. Les algorithmes de sécurité en 5G ?

Dans un réseau mobile, deux propriétés de sécurité doivent être assurées :

  • la confidentialité : un utilisateur non autorisé qui intercepte les données ne doit pas pouvoir les comprendre ;
  • l’intégrité : le récepteur doit pouvoir vérifier que les informations reçues n’ont pas été modifiées.

En 5G, ces deux fonctions reposent sur des mécanismes cryptographiques distincts.

Le 3GPP définit notamment :

  • 128-NEA1, 128-NEA2 et 128-NEA3 pour le chiffrement ;
  • 128-NIA1, 128-NIA2 et 128-NIA3 pour la protection de l’intégrité.

Dans la pile protocolaire radio, ces mécanismes sont notamment appliqués au niveau de la couche PDCP – Packet Data Convergence Protocol.

De manière très simplifiée :

Données PDCP
      |
      +----> chiffrement
      |
      +----> protection d'intégrité

Ces mécanismes sont déjà fortement optimisés. Le problème posé par la 6G n’est donc pas que la cryptographie 5G serait inefficace, mais que les nouvelles contraintes du réseau conduisent à étudier une autre manière d’organiser ces fonctions de sécurité.

2. Pourquoi AEAD pour la 6G ?

Une piste consiste à assurer le chiffrement et l’authentification au sein d’une même construction cryptographique.

Une opération AEAD peut être représentée simplement :

Message
   +
Clé
   +
Nonce
   +
Données associées
   |
   v
  AEAD
   |
   v
Message chiffré + Tag d'authentification

Le message est chiffré et le tag d’authentification permet au récepteur de vérifier qu’il n’a pas été modifié.

L’intérêt d’AEAD réside dans la conception d’une primitive assurant conjointement chiffrement et authentification. Selon l’algorithme et son implémentation, cette intégration peut permettre de mutualiser certains traitements.

Et les « Associated Data » ?

AEAD permet également d’authentifier des informations sans nécessairement les chiffrer.

Prenons un exemple volontairement simplifié :

En-tête
visible mais authentifié
        +
Données utilisateur
chiffrées et authentifiées

Certaines informations peuvent ainsi rester accessibles pour permettre le traitement du paquet, tout en étant protégées contre une modification.

Dans un véritable réseau 6G, déterminer quelles informations pourraient jouer le rôle d’Associated Data sera une question d’architecture.

Avec le network slicing, différentes classes de service ou de nouvelles fonctions distribuées, certaines métadonnées peuvent devoir rester accessibles à certaines entités du réseau.

La question est alors : quelles informations le réseau doit-il pouvoir lire tout en étant certain qu’elles n’ont pas été modifiées ?

3. Comment AEAD pourrait-il s’intégrer dans la 6G ?

Introduire AEAD ne consiste pas seulement à choisir un algorithme. Il faut aussi déterminer comment le terminal et le réseau négocient son utilisation et comment la protection est activée.

En 5G, la mise en place de la sécurité repose notamment sur :

  • le NAS Security Mode Command, entre l’AMF et l’UE ;
  • l’AS Security Mode Command, entre le gNB et l’UE.

Le principe général est le suivant :

UE                              gNB
 |                               |
 |---- capacités de sécurité --->|
 |                               |
 |<---- Security Mode Command ---|
 |                               |
 |---- Security Mode Complete -->|
 |                               |
 |       Sécurité activée         |

Une piste pour la 6G consiste à faire évoluer ce principe plutôt qu’à reconstruire entièrement les procédures de sécurité.

Le futur aNB pourrait par exemple sélectionner un algorithme AEAD parmi ceux supportés par le terminal :

UE                                     aNB
 |                                      |
 |---- capacités AEAD supportées ------>|
 |                                      |
 |<---- Security Mode Command ----------|
 |      algorithme AEAD sélectionné     |
 |                                      |
 |---- Security Mode Complete --------->|
 |                                      |
 |                              Activation
 |                              protection

L’algorithme négocié pourrait ensuite être utilisé au niveau où la protection est requise, notamment pour le trafic utilisateur au niveau PDCP selon l’architecture finalement retenue.

Il ne s’agit pas d’une architecture 6G déjà normalisée. Le 3GPP étudie encore plusieurs possibilités dans le cadre des travaux FS_AEAD, menés au sein du groupe SA3 chargé de la sécurité.

L’intérêt est surtout de constater qu’AEAD pourrait s’inscrire dans la continuité des mécanismes existants, plutôt que provoquer une rupture complète avec la 5G.

4. Rocca-S et SNOW-Axn : des algorithmes pour le très haut débit

En parallèle des travaux de normalisation 3GPP menés dans SA3 (FS_AEAD), plusieurs équipes académiques proposent des constructions AEAD alternatives adaptées aux très hauts débits. Deux d’entre elles retiennent particulièrement l’attention : Rocca-S et SNOW-Axn.

Ces propositions n’ont pas le statut d’algorithmes normalisés : il s’agit
de candidates académiques en phase de recherche et d’évaluation. Leur
intérêt réside dans les débits qu’elles peuvent théoriquement atteindre,
mais le choix final du 3GPP reste ouvert.

Rocca-S

Rocca-S s’appuie notamment sur certaines opérations cryptographiques utilisées dans AES. Celles-ci peuvent être accélérées directement par des instructions disponibles dans les processeurs modernes, ce qui permet d’atteindre des débits de traitement très élevés.

SNOW-Axn

La famille SNOW est particulièrement intéressante pour les télécommunications puisqu’elle est historiquement liée aux mécanismes cryptographiques des réseaux mobiles.

SNOW-Axn adapte cette approche au chiffrement authentifié et certaines variantes atteignent également plusieurs centaines de Gbit/s sur les plateformes testées.

Mesurées en C++ sur processeur Intel haute gamme (i5-1145G7,
single-thread) :

  • SNOW-Ax4 atteint **421 Gbps** en mode chiffrement seul sur
    messages de 256 KB, mais descend à **184 Gbps** sur messages
    de 16 KB (taille plus réaliste en trafic 6G).
  • En mode AEAD complet (chiffrement + authentification), SNOW-Ax4 mesure 311 Gbps sur grands messages.
  • Rocca-S atteint 197 Gbps en AEAD, soit une alternative compétitive mais moins ambitieuse en débit.

Important: Ces débits reflètent des conditions optimales (messages longs, cache warm, pas de contexte-switching). Le débit réel dépendra de la distribution des tailles de paquets et de la charge système.

Se référer à : https://cic.iacr.org/p/3/1/31/pdf

Ces chiffres doivent toutefois être interprétés correctement. Un débit cryptographique de 200 Gbit/s ne signifie pas qu’un smartphone pourra transmettre à 200 Gbit/s.

Ces benchmarks mesurent la vitesse de traitement de la primitive cryptographique sur une plateforme donnée. Ils ne représentent pas les performances de l’ensemble de la chaîne :

Le choix d’un futur algorithme devra donc également prendre en compte sa latence sur les petits paquets, sa consommation énergétique et son coût d’implémentation dans un équipement réel.

Rocca-S et SNOW-Axn illustrent les recherches actuelles mais, à ce jour, rien ne permet d’affirmer qu’ils seront retenus pour la 6G.

5. AEAD, mobilité et NTN : s’appuyer sur les mécanismes existants

La nécessité de disposer de paramètres cryptographiques variant avec les paquets n’est pas nouvelle dans les réseaux mobiles. En 5G, les algorithmes de chiffrement et d’intégrité utilisent déjà différents paramètres, notamment le COUNT, le bearer et la direction de transmission.

La pile protocolaire doit également maintenir correctement le contexte de sécurité lorsque le terminal change de cellule ou lorsque plusieurs chemins de transmission coexistent, par exemple avec le DAPS handover – Dual Active Protocol Stack ou la duplication PDCP.

L’introduction d’AEAD devra s’inscrire dans cette continuité. Un algorithme AEAD utilise notamment une clé et un nonce, dont les contraintes de réutilisation dépendent de la construction cryptographique retenue.

Une future intégration pourrait donc s’appuyer sur les informations déjà disponibles dans le contexte de sécurité et dans la pile protocolaire :

Contexte de sécurité
        +
Paramètres liés au paquet
(ex. COUNT, bearer, direction en 5G)
        ↓
Paramètres nécessaires à AEAD
        ↓
AEAD
        ↓
Données chiffrées + tag

Ce schéma reste volontairement conceptuel : la manière dont le nonce et les autres paramètres d’un futur algorithme AEAD seraient construits et gérés en 6G n’est pas encore définie.

L’enjeu n’est donc pas de réinventer la gestion du contexte de sécurité, mais de déterminer comment AEAD pourra s’intégrer aux mécanismes déjà utilisés dans les réseaux mobiles.

Et avec les réseaux NTN ?

La même logique peut s’appliquer aux NTN – Non-Terrestrial Networks.

Les communications par satellite introduisent des scénarios de mobilité supplémentaires : changement de satellite, changement de cellule ou transition entre réseau terrestre et réseau non terrestre.

Ces situations ne modifient pas directement le fonctionnement cryptographique d’AEAD. Elles nécessitent en revanche de maintenir correctement le contexte de sécurité au cours de ces transitions.

L’enjeu pour la 6G sera donc de faire en sorte que l’utilisation d’AEAD reste compatible avec les mécanismes de mobilité terrestres et non terrestres, tout en respectant les propriétés de sécurité de l’algorithme finalement retenu.

6. Pourquoi des clés de 256 bits ?

La préparation des réseaux aux futures capacités des ordinateurs quantiques constitue un autre enjeu.

Il faut cependant distinguer deux problématiques.

  1. La cryptographie asymétrique, utilisée notamment pour l’authentification et l’établissement de secrets, pourrait être fortement affectée par un ordinateur quantique suffisamment puissant. C’est pourquoi de nouveaux algorithmes post-quantiques sont développés.
  2. Pour la cryptographie symétrique, comme AES, le problème est différent.

L’algorithme de Grover permet théoriquement d’accélérer la recherche exhaustive d’une clé. L’utilisation de clés symétriques de 256 bits permet alors de conserver une marge de sécurité importante.

Certaines constructions AEAD étudiées, comme Rocca-S ou SNOW-Axn, utilisent ou peuvent utiliser des clés de cette taille.

Il faut cependant éviter un raccourci : AEAD n’est pas synonyme de cryptographie post-quantique.

AEAD et la migration post-quantique répondent à des problématiques différentes, même si elles participent toutes deux à l’évolution de la sécurité des futurs réseaux.

Conclusion

L’évolution vers AEAD ne signifie pas que les mécanismes cryptographiques de la 5G seraient devenus inefficaces.

La question posée par la 6G est différente : peut-on concevoir une protection mieux intégrée, capable d’assurer conjointement confidentialité et authentification tout en répondant aux nouvelles contraintes de débit, de latence et de consommation ?

AEAD constitue une piste particulièrement intéressante pour répondre à cette question.

Des constructions comme Rocca-S et SNOW-Axn montrent que le chiffrement authentifié peut atteindre des débits très importants. Mais les performances brutes ne suffiront pas.

Il faudra également déterminer comment AEAD s’intégrera concrètement aux mécanismes du réseau mobile : négociation de l’algorithme, gestion des clés et des paramètres cryptographiques, mobilité, handovers, NTN et définition des données qui pourront rester visibles tout en étant authentifiées.

La 6G étant encore en cours de définition, le choix des algorithmes et leur intégration dans les protocoles restent ouverts.

C’est précisément ce qui rend les travaux actuels du 3GPP intéressants : il ne s’agit pas seulement de choisir un algorithme plus rapide, mais de déterminer comment faire évoluer l’architecture de sécurité des réseaux mobiles pour accompagner la 6G.

Pour aller plus loin

  • 3GPP – travaux SA3 et étude FS_AEAD – TR 33.771
  • 3GPP TS 33.501 – Security architecture and procedures for 5G System
  • 3GPP TS 38.323 – Packet Data Convergence Protocol (PDCP) specification
  • 3GPP TS 38.331 – Radio Resource Control (RRC)
  • Travaux de recherche sur Rocca-S
  • Travaux de recherche sur SNOW-Axn
  • Travaux 3GPP sur les Non-Terrestrial Networks (NTN)

Réduire le PAPR en uplink 5G/6G : la solution FDSS

Posté le by - 112 vues
Répondre

1. L’amplification de puissance au niveau du smartphone

Dans un réseau cellulaire, le bilan de liaison montre que la transmission sur le lien montant est plus difficile à assurer par rapport à la transmission sur le lien descendant.

Une station de base dispose généralement d’une puissance d’émission, d’un gain d’antenne et de capacités de beamforming bien supérieurs à ceux d’un terminal mobile. L’UE est au contraire fortement contraint en puissance d’émission, en consommation énergétique et par les exigences RF. En bord de cellule, chaque décibel de puissance uplink devient donc précieux.

Avec l’augmentation de la fréquence, l’atténuation est encore plus élevée. La mise en oeuvre du Massive MIMO permet d’apporter une couverture dans une direction donnée et d’apporter un gain vers le récepteur.

Ou alors, une solution proposée en 5G est la transmission SUL : Supplementary UpLink. Le smartphone est contrôlé par la station de base pour émettre sur une fréquence montante plus basse que la liaison de service.

Quoi qu’il en soit, chaque décibel de puissance UL devient donc précieux, et augmenter simplement la puissance moyenne du signal n’est pas toujours possible.

La raison tient notamment au Peak-to-Average Power Ratio, ou PAPR c’est à dire la puissance maximale sur la puissance moyenne :

Le PAPR mesure l’écart entre la puissance instantanée maximale du signal et sa puissance moyenne. Si le signal possède des pics importants, l’amplificateur de puissance du terminal risque d’entrer dans sa région non linéaire.

Ce problème est connu depuis la 3G, avec des solutions de prédistorsion du signal. Pour la 4G, la solution proposée est l’étalement DFT-S-OFDM dont l’objectif est de rendre l’enveloppe du signal la plus constante possible avant amplification.

D’autres solutions sont possibles comme diminuer la puissance moyenne transmise. En pratique, on applique un power back-off ce qui pénalise la couverture.

L’étalement DFT-s-OFDM

Le principe consiste à ajouter une transformée de Fourier discrète (DFT) avant la modulation OFDM. La DFT répartit l’énergie de chaque symbole de modulation sur l’ensemble des sous-porteuses allouées.

Le signal résultant conserve donc la structure fréquentielle de l’OFDM mais présente en temporel un comportement plus proche d’un signal single-carrier (SC-FDMA proposée en 4G – Single Carrier FDMA et conservée en 5G/6G). Cette propriété permet ainsi d’obtenir un PAPR inférieur à celui du CP-OFDM.

Mais avec les constellations QAM classiques, le PAPR reste suffisamment important pour continuer à limiter la puissance moyenne de l’UE. L’article [1] propose d’agir sur la forme spectrale du signal.

3 – Frequency-Domain Spectral Shaping (FDSS)

La 3GPP s’est intéressée au problème dans le cadre des travaux Further NR coverage enhancements. Le FDSS présente une caractéristique particulièrement intéressante pour NR : l’implémentation exacte du shaping peut rester interne à l’UE.

Le Frequency-Domain Spectral Shaping (FDSS) consiste à appliquer des coefficients W[k] aux composantes fréquentielles du signal DFT-s-OFDM. Il s’agit d’un fenêtrage (Windowing). Cette idée n’est pas nouvelle, le fenêtrage permet d’atténuer progressivement les composantes situées vers les bords du spectre (par exemple des solutions comme le FFT–FBMC ( Filter Bank Multi-Carrier). La solution  FBMC a été proposée comme alternative dans plusieurs projets de recherche (5GNOW, PHYDYAS, etc.), cependant cette solution n’a pas été retenue par la 5G NR car :

  1. Complexité accrue d’implémentation
  2. Problèmes de synchronisation et de décodage de canal plus complexes
  3. OFDM avec CP reste plus robuste et pratique pour les déploiements
  4. Écosystème et compatibilité avec les équipements existants

Pourtant elle offrait théoriquement :

  • Meilleure localisation temps-fréquence
  • Pas de cyclic prefix (gain en efficacité spectrale)
  • Moins d’émission hors-bande

Conceptuellement, les méthodes FBMC et FDSS appliquent un filtrage fréquentiel par sous-porteuse, mais ces méthodes n’ont pas le même objectif : les objectifs du FDSS : Shaping/spreading pour réduire PAPR ou réduire les interférences. L’avantage du FDSS est que cette méthode est moins complexe que le FBMC.

4- Le prix du FDSS : les pulses ne sont plus parfaitement orthogonaux

La fenêtre FDSS W[k] pondère les coefficients fréquentiels issus de la DFT avant leur mapping sur les sous-porteuses et l’IFFT. Sans shaping, lorsque W[k]=1, les pulses temporels associés aux symboles sont orthogonaux. L’application d’une fenêtre FDSS modifie leur forme et introduit généralement un chevauchement et une auto-interférence contrôlée.

En reprenant l’article sur la modulation OTFS, vous verrez l’importance de l’orthogonalité. Dans le cas de la technique FDSS, la perte d’orthogonalité est inévitable.

AInsi, le rôle du FDSS est de réduire le PAPR et de manière complémentaire, on utilise la technique SE Spectrum evolution pour réduire d’avantage le PAPR. C’est une technique de pré-distorsion connue qui consiste à rajouter des sous-porteuses  (se référer aux travaux du laboratoire XLIM avec M Duvanaud et M Bachir).

5. Spectrum Extension : ajouter des composantes fréquentielles redondantes

Supposons que l’on dispose de Ndata coefficients issus de la DFT. Au lieu de les mapper sur exactement Ndata sous-porteuses, on construit un signal occupant Nsc sous-porteuses, avec Nsc​​>Ndata.

Ainsi, Ne​=Nsc​−Ndata​ représente la taille du Spectrum Extension.

Les coefficients supplémentaires ne transportent pas de nouvelles données. Ils sont obtenus par extension périodique de la séquence DFT.

Chaîne de transmission FDSS

6) Pourquoi cela peut-il diminuer le PAPR ?

On rappelle que la multiplication dans le domaine fréquentiel se traduit par une convolution dans le domaine temporel. A titre d’exemple, le spectre Y(f) d’un signal X(f) en sortie d’un filtre H(f) s’écrit Y(f)=H(f).X(f). En temporel, on écrit la convolution du signal x(t) avec la fonction de transfert h(t) du filtre h, soit en discret :

Le signal discret à l’instant n, y[n] se calcule par le produit de x[m] avec le décalage du filtre n-m.

Le Spectrum Extension quant à lui rajoute un nombre de sous porteuses supplémentaires. On injecte les Ndata symboles sur Nsc sous porteuses avec un décalage optimisé de L sous porteuses. Ainsi le symbole de la 1ère sous-porteuses Ndata(1) sera transmis sur la sous porteuses L+1 Nsc(L). Ce décalage circulaire se traduit par une rotation de la phase. La valeur de L reste à optimiser pour réduire la PAPR.

Pourquoi cela agit-il sur le PAPR ? Les pulses ne sont pas parfaitement localisés à un seul instant : ils possèdent un lobe principal ainsi que des lobes secondaires. Plusieurs pulses peuvent donc contribuer simultanément au signal s[n]. Si leurs contributions complexes sont en phase, elles s’additionnent constructivement et peuvent produire un pic important. Si leurs phases diffèrent, elles peuvent au contraire se compenser partiellement. Le Spectrum Extension modifie la forme et le chevauchement de ces pulses, tandis que le shift L modifie leurs phases relatives. Ces deux paramètres peuvent ainsi être optimisés afin de réduire les pics du signal temporel.

Par conséquent, en intégrant la convolution (le décalage n-m) et la rotation circulaire dans ue fonction nommée pulse le signal de sortie peut s’écrire sous la forme suivant:

Le pulse subit un décalage temporel et une rotation de phase par rapport à un pulse de référence.

Le choix de L est de réduire le PAPR mais il dépend de la constellation puisque les symboles modulés disposent déjà d’une rotation particulière (par exemple modulation pi/2 BPSK).

Ainsi, le signal s’écrit comme une superposition de pulses temporels décalés (cf. article [1]).

Les auteurs avaient déjà proposé cette approche dans les contributions Huawei/HiSilicon :

  • R1-2208412, RAN1 AH 110bis-e, octobre 2022 ;
  • R1-2300090, RAN1 #113, mai 2023.

Mais, il existe enfin une discussion intéressante autour de la métrique elle-même.

Historiquement, la 3GPP utilise largement le Cubic Metric (CM) pour estimer le power de-rating nécessaire à un amplificateur.

Lorsque le shaping devient plus agressif :

  • le PAPR évolue de manière cohérente ;
  • le CM peut présenter une évolution non monotone, notamment pour QPSK

Or,  la grandeur réellement pertinente pour la conformité RF du groupe de travail RAN4 et la puissance exploitable reste le power de-rating/MPR.

[1] Renaud-Alexandre Pitaval, Fredrik Berggren and Branislav M. Popovic, Optimum Spectrum Extension for PAPR Reduction of DFT-s-OFDM, https://arxiv.org/pdf/2509.19064v1

[2] 3GPP TR 38.830 V17.0.0 (2020-12)

 

UE-SAT-UE Communication

Posté le by - 464 vues
Répondre

ATTENTION : Cet article suit une recommandation et non une spécification. C’est donc seulement une étude qui a pour objectif de préparer l’écriture d’un autre article sur la communication UE-UE par satellite mais qui sera défini par la spécification R.19.

Cet article est écrit suite à la publication d’un essai de communication satellitaire 5G-NTN : Ericsson, Qualcomm et Thales Alenia Space franchissent une étape clé dans la connectivité par satellite : « Parmi les applications potentielles, cette technologie pourrait prendre en charge les appels vocaux de haute qualité et les services de streaming vidéo en temps réel. »

https://www.ericsson.com/fr/press-releases/3/2025/ericsson-qualcomm-thales-achieve-space-connectivity-milestone

L’article décrit ici s’appuie sur la recommandation TR 23.700-29.

Cette solution permet la communication directe entre équipements utilisateurs via satellites sans transit par les réseaux terrestres. Elle répond au problème concernant le support de la communication UE-satellite-UE.

I) Architecture et principes

L’architecture déploie des gNB (stations de base 5G) et des **UPF (User Plane Functions) directement sur les satellites. Les UE peuvent être desservis par le même satellite ou par des satellites différents connectés via des liens inter-satellites (ISL).

Principe fondamental : La signalisation des UE transite vers les réseaux 5GC et IMS au sol, mais le trafic utilisateur entre les deux UE est routé uniquement par les satellites.

Ces deux points sont fondamentaux et nécessite des hypothèses importantes :

 Hypothèses principales
– Les deux UE sont servis par le même PLMN (réseau domestique)
– Les deux UE utilisent la même instance SMF ou I/V-SMF
– Le système IMS détermine pendant l’établissement d’appel s’il faut utiliser la communication UE-Satellite-UE
– La passerelle média IMS (IMS AGW) reste au sol, ce qui signifie que le transcodage n’est pas supporté

Sélection intelligente des UPF

Le document décrit un mécanisme d’association de satellites organisés en groupes. Chaque groupe comprend :
– Des satellites avec gNB embarqués
– Un satellite avec UPF embarqué accessible via ISL
– Des DNAI (Data Network Access Identifier) accessibles

Le SMF sélectionne les UL CL/BP/PSA UPF locaux basés sur :
– L’ID du satellite embarquant le gNB
– Les informations d’association de satellites préconfigurées
– Le DNN fourni par l’UE

Gestion de l’itinérance satellite (Section 6.28.2.3)

La procédure I/V-SMF commun au sol traite un cas complexe d’itinérance où UE1 est dans son réseau domestique et UE2 est en itinérance home-routed dans le PLMN de UE1.

Étapes critiques de la procédure :

1. Établissement séparé des sessions PDU : Chaque UE établit sa session avec des UPF terrestres différents (UPFx pour UE1, UPFy pour UE2 en itinérance)

2. Détection de non-service : SMF1 servant UE1 détecte qu’il ne sert pas l’UE pair (UE2) lors de la demande de communication UE-SAT-UE

3. Sélection I-SMF coordonné : Un SMF dédié (I/V-SMF) supportant la communication UE-SAT-UE est sélectionné pour coordonner les deux sessions

4. Insertion UPF satellites : L’I/V-SMF insère UPF1 sur SAT1 pour UE1 et UPF2 sur SAT2 pour UE2

5. Re-sélection V-SMF : Le SMF2 servant UE2 déclenche également la sélection du même I/V-SMF

6. Chemin média optimisé : Le trafic final suit : UE1 ↔ SAT1(gNB1+UPF1) ↔ SAT2(gNB2+UPF2) ↔ UE2

Innovation technique : Cette procédure montre comment maintenir l’optimisation du trafic spatial même dans des scénarios d’itinérance complexes, en utilisant un SMF coordonnateur qui comprend les spécificités satellite.

Gestion des handovers satellite

Quand le satellite de service change, la procédure maintient la communication en :
– Sélectionnant un nouveau UPF sur le satellite cible
– Mettant à jour les chemins de signalisation
– Gérant la libération des ressources source avec un timer de garde pour éviter les pertes de paquets

5G-Advanced R.19 : AIoT – Partie 1

Posté le by - 498 vues
Répondre

La Release 19 (5G advanced) introduit un nouveau dispositif IoT nommé IoT Ambiant (Ambient IoT). À la différence des autres dispositifs IoT comme le LTE-M, NB-IoT ou le RedCap, il s’agit de dispositifs IoT qui fonctionnent sans batterie conventionnelle ou avec un stockage d’énergie très limité (comme un condensateur), et qui tirent leur énergie de l’environnement via diverses techniques de récupération d’énergie.

Pourquoi l’IoT Ambiant est-il important ?

L’IoT Ambiant répond à plusieurs défis critiques des réseaux IoT actuels :

  1. Réduction de l’impact environnemental : en éliminant les batteries traditionnelles, on réduit les déchets électroniques et la nécessité de remplacer et recycler les batteries.
  2. Diminution des coûts de maintenance : les dispositifs sans batterie ou avec des capacités de stockage très limitées peuvent fonctionner pendant de longues périodes (plus de 10 ans) sans nécessiter d’intervention humaine.
  3. Miniaturisation : sans batterie conventionnelle, les dispositifs peuvent être beaucoup plus petits, légers et moins complexes.
  4. Déploiement dans des environnements difficiles : ces dispositifs peuvent être déployés dans des endroits où le remplacement de batterie serait impossible ou très coûteux.

Comment fonctionne la récupération d’énergie dans l’IoT Ambiant ?

Les dispositifs IoT Ambiant utilisent différentes sources d’énergie ambiante :

1. Énergie RF (Radio-Fréquence)

  • Les dispositifs récupèrent l’énergie des ondes radio présentes dans l’environnement (3 kHz à 300 GHz)
  • L’énergie récupérée est généralement de l’ordre de quelques microwatts à des dizaines de microwatts
  • Un circuit redresseur convertit les signaux RF en courant continu utilisable
  • L’efficacité de conversion varie de 1,2% à 49% selon les technologies

2. Énergie solaire/lumière

  • Utilisation de cellules photovoltaïques pour convertir la lumière en électricité
  • En extérieur, l’énergie solaire peut fournir jusqu’à 100 mW/cm²
  • En intérieur, l’éclairage peut fournir environ 100 μW/cm²
  • L’efficacité de conversion est typiquement de 10-40%

3. Énergie thermique

  • Exploitation des différences de température via l’effet Seebeck
  • L’efficacité est relativement faible (environ 5-6%)
  • La densité de puissance varie de 25 à 1000 μW/cm² selon les conditions environnementales.

4. Vibration mécanique

  • Utilisation de l’effet piézoélectrique pour générer de l’électricité à partir des déformations mécaniques
  • Typiquement, ces générateurs peuvent produire environ 250 μW/cm³
  • Sources : vibrations, mouvements humains, vent, ondes acoustiques

Architecture et communication

L’IoT Ambiant s’intègre dans les réseaux 5G de différentes façons :

Modes de communication

  1. Communication directe avec le réseau : Le dispositif IoT Ambiant communique directement avec le réseau 5G.
  2. Communication indirecte via un UE : Le dispositif communique d’abord avec un équipement utilisateur (UE) qui relaie ensuite l’information au réseau 5G.
  3. Communication device-to-device : communication directe entre un dispositif IoT Ambiant et un UE sans passer par le réseau.

Scénarios de disponibilité

  1. Fonctionnement normal : Le dispositif a de l’énergie disponible en continu ou pendant des périodes significatives.
  2. Fonctionnement déclenché par le dispositif : Le dispositif n’a de l’énergie que par intermittence et décide lui-même quand communiquer.
  3. Fonctionnement à la demande : Le réseau 5G réveille et déclenche le dispositif pour qu’il communique, le dispositif ne pouvant pas déterminer lui-même quand communiquer.

MOOC 5G – Professeur Xavier Lagrange

Posté le by - 1 014 vues
Répondre
Dans le cadre du projet IMTFor5G+ (https://imtfor5g.wp.imt.fr/), M Le professeur Xavier Lagrange propose une nouvelle formation sur l’accès radio 5G
Ce cours a été développé dans le cadre du projet CMA France2030 IMTFor5G+ https://lnkd.in/dMCX7F7U

Ouverture du cours : mardi 18 février. : https://www.fun-mooc.fr/fr/cours/explorer-la-5g/

Les inscriptions ont démarré

5G : Principes de l’interface radio et du réseau d’accès

Apprentissage visées

  • Lister les raisons de l’augmentation de débit en 5G par rapport aux générations précédentes
  • Calculer l’ordre de grandeur du débit atteignable en 5G pour une configuration simple en FDD et en TDD
  • Estimer une borne minimale de la latence en 5G sur des configurations et des architectures simples
  • Démontrer à l’aide d’un exemple la différence fondamentale de consommation énergétique entre 4G et 5G
  • Justifier en quoi la technique « massive MIMO » représente un saut technologique de la 5G et lister les contreparties à l’augmentation de débit
  • Analyser un scénario simple de connexion et de déconnexion sur la voie radio

Le programme

  • Semaine 1 : Introduction et principe de l’OFDM
  • Semaine 2 : Chaîne de transmission et architecture du réseau d’accès
  • Semaine 3 : Principe du MIMO
  • Semaine 4 : Protocole de l’interface radio
  • Semaine 5 : Etablissement et maintien de la connexion radio

Pour compléter cette formation par des articles du blog, contactez moi : frederic.launay@univ-poitiers.fr

 

L’IoT – Evolutions R16 et R17

Posté le by - 1 009 vues
Répondre

Introduction

Le standard 3GPP a démarré ses travaux de normalisation pour l’IoT à partir de la R.10 pour définir une liste de spécifications pour les terminaux et le cœur de réseau afin d’éviter la congestion (Extended Access Barring), d’avoir moins d’impact sur les smartphones (LAPI), réduire la complexité (Half Duplex, réduction de la puissance, bande plus petite …), avoir une meilleure sensibilité pour une transmission à faible débit (bande plus petite).

Dans la R.11, la 3GPP propose une méthode de réveil de terminaux et une transmission de données par SMS.

Dans la R.12, la 3GPP propose des optimisations pour la réduction de la consommation énergétique (UEPCOP : mode PSM et eDRX) et une méthode de transmission de données de taille réduite (Small Data)

Figure 1 : Le standard 3GPP R10 à R12 pour l’IoT

Dans la R.13, la 3GPP une optimisation du cœur de réseau pour prendre en charge la transmission de données :

  • dans le plan de contrôle Control-Plane CIoT EPS Optimization ;
  • dans le plan de trafic User-Plane CIoT EPS Optimization.

L’optimisation CP CIoT EPS Optimization propose de transmettre des données dans un message NAS entre l’UE et le MME. Sur l’interface radioélectrique, le message NAS est encapsulé dans un message RRC, lorsque le mobile est à l’état RRC_CONNECTED, c’est-à-dire à la suite de la procédure d’accès aléatoire. Dans l’optimisation CP CIoT EPS Optimization , la mise en sécurité AS n’est pas mise en œuvre, c’est-à-dire la connexion RRC n’est ni chiffrée, ni authentifié (intégrité).

L’optimisation UP CIoT EPS Optimization permet de transmettre des données entre l’UE et le MME lorsque le mobile est à l’état RRC_CONNECTED avec la mise en sécurité AS. Cela suppose que le contexte AS soit conservé au niveau du terminal UE et de la station de base. La R.13 propose une procédure de suspension/reprise de la connexion RRC lorsque le mobile passe de l’état RRC_CONNECTED à l’état RRC_IDLE.

Figure 2 : L’optimisation du coeur de réseau

Sur l’interface LTE, l’optimisation CIoT EPS Optimization permet de transporter les données sur la couche RRC. Le MME peut ensuite transférer les données vers le plan de transport SGW ou l’entité SCEF (Service Capability Exposure Function).

La R.14 introduit les spécifications à mettre en oeuvre pour le 5G MTC.

Figure 3 : Les améliorations proposées de la spécification R.10 à la R.14

La transmission EDT

Pour réduire la signalisation, la transmission EDT (Early Data Transmission [1]) propose de transmettre les données dans un message RRC au cours de la procédure d’accès aléatoire (RACH EDT). On distingue la transmission CP-EDT s’appuyant sur l’optimisation du plan de contrôle CP-EDT (sans chiffrement) de l’optimisation du plan utilisateur UP-EDT (avec chiffrement).

L’inconvénient de la procédure EDT est la transmission du message sur le canal de contrôle commun. Celle-ci est donc interférée par les demande d’accès aléatoire pouvant simultanément avoir lieu sur les mêmes bandes de fréquences.

La transmission UP-EDT est :

    • soit à l’initiative du terminal (Mobile Originated MO-EDT) spécifiée dans la R.15
    • soit à destination du terminal (Mobile Terminated MT-EDT) spécifiée dans la R.16.

La transmission EDT a été proposée dans la R.15 pour optimiser la transmission de messages courts lors de la procédure d’accès aléatoire. Au cours de cette procédure, le mobile reste à l’état RRC_IDLE sans contexte AS (CP EDT – Contol Plane EDT) ou en ayant conservé le contexte AS (UP EDT – User Plane EDT). A l’issue de la demande d’accès aléatoire, la transmission EDT étant finalisée, le mobile rester à l’état RRC_IDLE. Si d’autres données doivent être émises ou reçues, le terminal passe à l’état RRC_CONNECTED.

Dans ce cas, le premier paquet est transmis selon la procédure EDT, les autres paquets seront transmis de manière traditionnel.

La transmission PUR (Preconfigured Uplink Resource) consiste à pré-configurer les ressources du lien montant (UL) au cours d’une première connexion radioélectrique (RRC_CONNECTED). Cela signifie que la transmission PUR nécessite qu’en amont le terminal ait été dans l’état RRC_CONNECTED afin de recevoir la pré-configuration désirée.

La transmission PUR est utilisable par le terminal à l’état RRC_IDLE sans nécessité de procédure d’accès aléatoire mais en ayant conservé un contexte AS et l’allocation UL.

Ensuite, lorsque le mobile est en mode de veille, il peut utiliser les ressources qui lui sont réservées pour transmettre ses données sans avoir à mettre en œuvre la procédure d’accès aléatoire

Sur un cœur de réseau 5GC, la 3GPP propose un nouvel état radioélectrique du mobile nommé RRC_INACTIVE dédié aux terminaux IoT.

Le cœur de réseau 5GC pouvant être connecté à l’interface radioélectrique 4G E-UTRA et 5G-NR, l’état RRC_INACTVE s’appliquera à l’UE sur chacune des interfaces.

La transmission SDT (Small Data Transmission) est une procédure permettant de transmettre des petites quantités de données entre un terminal UE et le cœur de réseau 5GC en passant soit par l’accès radioélectrique 4G E-UTRA ou l’accès radioélectrique 5G-NR lorsque le terminal UE reste à l’état RRC_INACTIVE. La transmission SDT peut se faire sur l’interface E-UTRA comme sur l’interface 5G-NR.

La transmission non SDT correspond à la transmission traditionnelle de données entre un UE et le cœur de réseau 5GC via l’établissement de bearers lorsque l’UE est à l’état RRC_CONNECTED.

La transmission SDT sur l’interface 5G-NR a été introduite dans la spécification R.16 sous le nom NR SDT. La spécification R.17 propose deux technologies nommées RA-SDT (RACH SDT) et CG-SDT (Configured Grant SDT) lorsque le mobile est à l’état RRC_INACTIVE.

Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G

[1] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

Les informations UCI portées par le canal PUCCH

Posté le by - 2 454 vues
Répondre

Canal PUCCH et les données UCI

Le mobile UE (User Equipment) émet vers la station de base des informations de contrôle (du lien montant) UCI (Uplink Control Information) parmi la liste suivante :

  • ACK/NAK confirmant ou non la bonne réception du message descendant précédent
  • Le rapport de mesure CSI (Channel State Information) permettant à la station de base d’adapter le mode de transmission et le schéma de modulation et de codage MCS (Modulation Coding Scheme) à partir de l’indicateur CQI (Channel Quality Indicatot), le rang de la matrice de transmission RI (Rank Indicator) et le rang du code pour le précodage PMI (Pre-coding Matrix Indicator) estimé par le mobile.
  • SR (Scheduling Request) pour une demande de transmission de données en UL.

Ces informations de contrôle sont portées en général par le canal physique PUCCH (Physical Uplink Control Channel), mais elles peuvent être transmises par le canal physique PUSCH si celui-ci est présent.

Selon la taille des informations de contrôle UCI à transmettre,le canal PUCCH est défini parmi l’un des 4 différents formats suivant (format de contrôle 0 à 4) :

Figure 1 : Le canal PUCCH et les différents formats

Le format permet de spécifier la taille du message, le codage canal, le type de modulation et le multiplexage avec le signal de référence DMRS si possible : les formats 1 et 4 autorisent le multiplexage de l’UCI avec le signal de référence DMRS dans le PRB afin d’améliorer la démodulation (détection synchrone). Le format 0 ne met pas en œuvre de détection synchrone, car le gain de démodulation n’est pas suffisamment important.

Les formats 0 et 2 sont nommés format courts (SHORT PUCCH) car ils n’occupent qu’un seul ou deux symbole OFDM (soit 12 à 24 éléments de ressources), en général sur le dernier ou les deux derniers symboles d’un slot.

Les formats 1, 3 et 4 sont nommés format long car ils occupent 4 à 14 symboles OFDM. Un format long est utilisé pour des informations de tailles importantes ou par répétition pour améliorer la couverture (exemple format 1).

Figure 2 : La transmission du canal PUCCH court/long sur l’interface NR

Au niveau de l’interface LTE, le canal PUCCH est transmis dans les bandes de fréquences PRB extrêmes permettant une diversité sur les fréquences hautes/basses et une diversité temporelle au niveau des slots.

Au niveau de l’interface NR, le format PUCCH court est transmis sur un ou deux symboles dans un slot et le format PUCCH long sur 4 à 14 symboles du slot (figure 2).

Avant d’être transmis sur le bloc physique de ressource PRB, les informations de contrôles UCI sont modulées par une chaîne de transmission comprenant :

  • un générateur de séquence de longueur 12 basé sur l’algorithme de Zadoff-Chu.
  • une modulation (formats 1,2,3 et 4) ;
  • un code DFT d’embrouillage (formats 2,3,4).

Figure 3 : Chaine de traitement de l’information de contrôle UCI (Source Matlab 1)

Le codage canal est un codage :

  • De répétition si la taille de l’UCI est de 1 bit;
  • Code correcteurs linéaires : code simplexe (taille de 2 bits) ou Reed Muller (Taille de 3 à 11 bits) ;
  • Code polaire (taille > 11 bis).

La chaîne de transmission est codée par :

  • Une séquence de Zadoff Chu (générateur de séquence s) ;
  • Un déphasage cyclique v ;
  • Un code orthogonal OCC (Orthogonal Cover Code) w.

Figure 4 : Illustration de la chaîne de transmission du canal PUCCH

  • PUCCH Format 0

Le PUCCH format 0 est configuré sur 1 ou deux symboles OFDM dans un slot et dans un seul PRB. L’information portée par le format 0 (PF0) est soit un acquittement HARQ-ACK soit un bit SR ou les deux. Ainsi, un ou deux bits d’informations sont à transmettre ce qui définit une variable mcs qui vaut, selon le codage de gray :

  • mcs =0 pour le bit 0 ou mcs =6 pour le bit 1
  • mcs =0 pour les bits (00), mcs =3 pour les bits (01), mcs =6 pour les bits (11) et mcs =9 pour les bits (10)

Le générateur de séquence émet une séquence de Zadoff-Chu de longueur 12, initialisée par la valeur NID de la cellule.

Afin de permettre un multiplexage entre plusieurs terminaux, la séquence de zadoff-chu est affectée d’un décalage cyclique m0 dont la valeur est configurée entre 0 et 11. Cette séquence est nommée low PAPR et le décalage cyclique m0 est défini par un message de configuration dédié RRC via le paramètre InitialCyclicShift dans la configuration PUCCH-Config IE> PUCCH-Resource > PUCCH-Format 0 (TS 38.311) par BWP :

Ainsi, la séquence émise est un décalage en fréquence de valeur (m0 + mcs).

L’information UCI pour les transmissions URLLC utilisent de préférence le PF0 (PUCCH Format 0).

  • Le canal PUCCH Format 1

Le canal PUCCH de format 1 transporte 1 à 2 bits UCI (HARQ-ACK et/ou SR) et est étalé sur 4 à 14 symboles permettant le multiplexage par code pour transmettre plusieurs acquittements de mobiles différents. Le signal UCI est codé par un code orthogonal OCC (Orthogonal Cover Code).

La modulation utilisée est soit la modulation BPSK (1 bit) ou QPSK (2 bits) et est multipliée par la même séquence de Zadoff-Chu de longueur 12. Un décalage cyclique m0 dont la valeur est configurée entre 0 et 11 est utilisé en plus du codage OCC (de longueur 2 ou 4) afin d’augmenter le nombre de terminaux qui émettent simultanément leur acquittement.

La détection cohérente apporte un gain au niveau de la réception du format long. La séquence DMRS est générée pour avoir un faible PAPR et un décalage en fréquence est appliqué.

Deux motifs de transmissions sont supportés :

  • Motif d’extension ou le signal de référence DMRS et l’information UCI sont entrelacés ;
  • Méthode de perforation (puncturing) ou le signal de référence DMRS est au milieu du slot.

Figure 6 : Les motifs pour le canal PUCCH format 1

  • Le canal PUCCH Format 2

Le canal PUCCH de format 2 est un format court qui est utilisé pour transporter une quantité d’informations plus importantes que le PUCCH de format 0 ou 1 (CSI, ou plus que deux acquittement HARQ-ACK, par exemple dans le cas d’agrégation de porteuses). Plusieurs blocs de ressources PRB peuvent être utilisés pour des charges de données importantes, toutefois si le mobile doit acquitter plusieurs HARQ et qu’il n’est pas possible d’allouer assez de ressource radioélectrique, alors la priorité est donnée pour l’acquittement au dépend du rapport CSI.

Le codage utilisé est le code linéaire Reed-Muller pour une charge utile de 11 bits ou le code polaire au-delà avec l’ajout d’une entête CRC. Le signal est ensuite embrouillé par l’identité du terminal C-RNTI puis modulé en QPSK.

Plusieurs motifs de multiplexages en forme de peigne du signal DMRS et UCI sont proposées avec un rendement de ½, 1/3 ou ¼ comme le montre la figure 7 (sur le dernier symbole comme c’est le cas pour les formats PUCCH court).

Figure 7 : Les motifs pour le canal PUCCH format 2

  • Le canal PUCCH Format 3

Le PUCCH format 3 est au PUCCH format 2 ce que le PUCCH format 1 est au PUCCH format 0. On a ainsi les mêmes caractéristiques que le PUCCH format 2 en transmettant sur 4 à 14 symboles (PUCCH format long).

La position du signal de référence peut exploiter le saut de fréquence (frequency hopping).

  • Le canal PUCCH Format 4

Le PUCCH de format 4 est similaire au PUCCH de format 3 en ajoutant les codes OCC pour augmenter le nombre de transmission simultanées.

 

 

[1] Source Matlab : https://www.youtube.com/watch?v=Tc_ECMWSH30

[2] https://rfmw.em.keysight.com/wireless/helpfiles/89600B/WebHelp/Subsystems/newradio/content/newradio_dlg_config_pucch.htm

[3] https://www.etsi.org/deliver/etsi_ts/138200_138299/138213/15.06.00_60/ts_138213v150600p.pdf

[4] https://www.etsi.org/deliver/etsi_ts/138300_138399/138331/15.03.00_60/ts_138331v150300p.pdf

 

 

 

Part 2 : Interface Radioélectrique 5G – Trames, numérologies et allocation de ressources

Posté le by - 2 569 vues
Répondre

Extrait du livre : NG-RAN et 5G-NR : L’accès radio 5G et l’interface radioélectrique – sortie prévue juillet 2021

Suite de l’article précédent

2) Les informations de contrôles DCI et les paramètres k0,k1 et k2

Nous allons nous intéresser dans cet article uniquement à l’allocation de ressource lorsque le mobile est à l’état connecté.

Dans cet état, la station de base alloue les ressources radioélectriques pour le lien descendant et le lien montant via les informations de contrôles DCI format 1_0 et DCI format 1_1 (Downlink Control Information).

Le message DCI pour le format 1_0 et 1_1 porte 4 bits d’allocation permettant d’informer le mobile de la réception de données dans le domaine temporel (‘time domain resource assignment’).

Les 4 bits font référence à une ligne d’un tableau de 16 valeurs. Chaque ligne donne 3 informations :

  • un décalage en slot K0  entre l’information DCI et la position du slot contenant le canal de trafic descendant PDSCH ;
  • la valeur SLIV indiquant le nombre de symboles S séparant le début du slot contenant le canal PDSCH et le premier symbole du canal PDCH et indiquant la longueur L du canal PDSCH ;
  • l’association du signal de référence DMRS avec le canal PDSCH (‘PDSCH mapping type’). Il existe deux types d’allocation nommée TypeA et Type B.

Figure 4 : L’allocation de ressource par rapport au signal de contrôle DCI [1]

Le paramètre K1 permet d’indiquer le décalage en nombre de slots entre le slot du canal PDSCH et le slot d’acquittement sur le lien montant.

 

Figure 5 : L’allocation des ressources pour l’acquittement de la part du mobile du message reçu en provenance de la station de base [2]

La valeur K1 est transmise dans le champ PDSCH-to-HARQ-timing-Indicator fourni par le message DCI sur 3 bits. Les 3 bits donnent la position de la valeur K1contenu dans le vecteur dl-DataToUL-ACK.

A titre d’exemple, si la valeur DCI=010, et le vecteur dl-DataToUL-ACK est le suivant

dl-DataToUL-ACK {  8,  6,  4,  12 }

Dans ce cas, la valeur K1= 4 (010 est la 3ème position). Se référer à la table 9.2.3-1 « Mapping of PDSCH-to-HARQ_feedback timing indicator field values to numbers of slots » [3]

Le vecteur dl-DataToUL-ACK est contenu dans l’élément d’information de configuration du PUCCH (PUCCH Config IE). Cette valeur est transmise lors du message SIB1 dans le champ tdd-UL-DL-ConfigurationCommon ou lors d’un message de configuration RRC dans le champ tdd-UL-DL-ConfigurationDedicated.

Enfin, la valeur K2 correspond au décalage en nombre de slots entre la réception de l’information DCI et l’allocation des ressources dans le domaine temporel pour le canal de trafic montant PUSCH.

Figure 6 : L’allocation des ressources pour le lien montant (PUSCH) [2]

[0] Extrait du livre : NG-RAN et 5G-NR : L’accès radio 5G et l’interface radioélectrique

[1] http://howltestuffworks.blogspot.com/2019/12/5g-nr-pdsch-resource-allocation-in-time.html

[2] https://www.linkedin.com/pulse/5g-nr-k0k1-k2-time-domain-dl-ul-resource-allocation-naveen-chelikani/