La transmission PUR (IoT – EPC/5GS)

Cet article présente une évolution du standard R.15 pour une transmission de données montante (UPLINK) dans le cas d’une transmission de type machine MTC et pour un terminal IoT 4G.

La transmission PUR s’effectue sur une interface 4G entre deux entités qui supportent cette transmission, c’est-à-dire soit entre un UE et une eNB ou une ng-eNB.

Le cœur de réseau peut être un cœur de réseau 4 (EPC) ou un cœur de réseau 5G (5GS).

Sur un cœur de réseau 4G, l’état RRC du mobile est soit en veille (RRC_IDLE), soit en mode connecté (RRC_CONNECTED). Pour la procédure de transmission PUR, l’état du mobile est obligatoire en veille (RRC_IDLE).

En mode de veille, le terminal écoute les informations émises par la station de base. Pour transmettre des données sur des ressources tempo-fréquentielles dédiées, le smartphone doit passer en mode connecté.

La procédure d’accès aléatoire permet de passer de l’état de veille à l’état connecté, ce qui nécessite un échange de 4 messages (dont 2 messages RRC) entre le mobile et la station de base.

La transmission PUR permet de réaliser une transmission UPLINK lorsque le terminal est à l’état RRC_IDLE sans avoir besoin de réaliser de procédure d’accès aléatoire puisque le terminal est pré-configuré pour une transmission montante, c’est à dire que le terminal dispose déjà des informations sur les ressources tempo-fréquentielles UPLINK à utiliser pour transmettre ses données à la station de base.

La configuration PUR est transmise par la station de base au terminal UE lorsque celui-ci en fait la demande et à l’état RRC_CONNECTED. Cela ne peut s’appliquer que dans la cellule ou la demande a été faite. La configuration est transmise sous condition de disposer des droits (information d’inscription ou de politique local).

Figure 1 : Pré-configuration du terminal par la station de base

Le terminal UE indique à la station de base qu’il souhaite obtenir une préconfiguration PUR par la requête PURConfigurationRequest. Cette requête demande les informations suivantes :

  • Nombre d’occurrences
  • Périodicité (par fenêtre temporelle de 10,24 secondes)
  • La taille du bloc de données TBS
  • Time offset (TA)

La station de base transmet la configuration PUR au mobile lors de la libération de la connexion radioélectrique afin que le mobile soit à l’état RRC_IDLE.

Le terminal peut transmettre ses données lors d’une occurrence configurée, la station de base étant en écoute de l’éventuel message émis par le terminal. La pré-configuration revient donc à réserver une ressource tempo-fréquentielle pour permettre au terminal d’émettre ses données sur un canal radio dédiée.  Afin d’éviter de conserver cette ressource sur une durée trop longue, un nombre d’occurrence et de périodicité définie la durée de validité de la transmission PUR

La transmission PUR est déclenchée quand les couches supérieures demande l’établissement ou la reprise de la connexion RRC. Une fois le paquet émis, la configuration PUR est supprimée. Le terminal ne pourra donc pas re-transmettre tant qu’il n’aura pas une autre pré-configuration.

En mode de veille, le terminal UE peut transmettre les données selon :

  • L’optimisation du plan de contrôle CIoT EPS/5GS Optimization via la requête RRCEarlyDataRequest (Figure 2);
    • La station de base peut à son tour transmettre des données via la requête RRCEarlyDataComplete sur les ressources tempo-fréquentielles proposées dans la configuration PUR. Par contre, si la taille des données est supérieure à la taille du TBS, le mobile enverra la requête RRCConnectionRequest à la place (fall back to the legacy RRC Connection establishment procedure, a new C-RNTI can be assigned)
    • S’il n’y a pas de données, la station de base acquitte la requête PUR par une réponse HARQ et éventuellement des informations de commandes TA (message DCI).
  • L’optimisation du plan de trafic CIoT EPS/5GS Optimization via la requête RRCConnectionResumeRequest (Figure 3)

Figure 2 : La transmission PUR avec l’optimisation du plan de contrôle

Figure 2 : La transmission PUR avec l’optimisation du plan de contrôleFigure 3 : La transmission PUR avec l’optimisation du plan de trafic

Le réseau 5G – 5GS

Le réseau 5G (5G System) se compose d’un accès Radio (NG-RAN : Next Generation RAN) et d’un cœur réseau (5G Core).

I. L’accès radio 5G

L’accès radio 5G est constitué de stations de base de nouvelle génération qui forment le nœud de connexion des mobiles avec le cœur réseau 5G (5GC)

Les mobiles UE communiquent avec les stations de base soient par un lien radio 5G, soit par un lien radio 4G. Si la communication est en 5G, la station de base se nomme gNB (next Generation Node Base Station), si la communication est en 4G, la station de base est une station de base 4G eNB évoluée pour s’interconnecter avec le cœur réseau 5G. La station de base se nomme ng-eNb (Next Generation eNb).

Les fonctions de la station de base gNb sont  assez similaires avec l’entité eNB. Cependant, les différences concernent la gestion de la qualité de service par flux et non par support (bearer) et la gestion des tranches de réseau (Slices) sur l’interface radio.

Pour rappel, un slice est composé d’instances logiques du réseau mobile permettant d’apporter un service réseau de manière efficace en vue de répondre à une qualité de service QoS spécifique à ce service (se référer à l’article Network Slicing).

II. Le cœur réseau 5G (5GC)

Le cœur réseau 5G est adapté pour la virtualisation du réseau et s’appuie sur le découpage du plan de contrôle (Control Plane) et du plan utilisateur (User Plane) définit dans l’architecture CUPS.

Par comparaison avec la 4G CUPS, on pourrait dire que  :

  • L’entité AMF (Access and Mobility Managmenent Function) reprend le rôle de l’entité MME. L’entité AMF établit une connexion NAS avec le mobile UE et a pour rôle d’enregistrer (attachement) les mobiles UE et de gérer la localisation des mobiles sur le réseau 3GPP et/ou non 3GPP.
  • L’entité SMF (Session Management Funtion) reprend le rôle de l’entité SGW-C et PGW-C. L’entité SMF permet de contrôler les sessions PDN. L’entité SMF est choisie par l’entité AMF puisque l’entité AMF  gère la signalisation NAS avec le mobile. L’entité SMF est responsable de la gestion du plan de contrôle. L’entité SMF a une interface avec l’entité qui gère la politique des flux (PCF : Policy Charging Function).

Le plan de transport est composé de passerelles de données qui réalise des mesures sur les données transportées et réalise l’interconnexion avec les réseaux Data (PDN). Dans l’architecture CUPS, les fonctions du plan de transport sont gérées par les entités SGW-U et PGW-U. Pour le cœur réseau 5G, les fonctions du plan de transport sont à la charge de l’entité UPF (User Plane Function). L’entité UPF communique avec l’entité SMF par l’interfae Sx et selon le protocole PFCP. Se référer à l’article présentant l’architecture CUPS.

L’entité PCRF de l’architecture 4G permet de définir les règles de contrôle et les politiques de flux avec l’entité SGW/PGW. En 5G, l’entité PCRF se renomme PCF et permet de contrôler les flux à la fois au niveau de l’entité SMF mais également au niveau de l’entité AMF afin de pouvoir apporter une meilleure granularité sur les flux autorisés en prenant en compte la localisation du mobile UE.

Le profil utilisateur (son abonnement, ses droits, …) sont sauvegardées dans une base de données UDR accessible via l’entité UDM (Unified Data Management). L’entité UDM conserve les profils de sessions de données (sessions PDU) et de l’entité AMF sur laquelle est attachée le mobile UE (éventuellement les entités AMF pour un accès 3GPP et non 3GPP sur un autre opérateur).

L’enregistrement du mobile nécessite une double authentification réalisée au niveau de l’entité AMF et du mobile UE à partir de vecteurs d’authentifications fournies par l’entité AUSF (AUthentication Server Function).

Enfin, l’entité NSSF (Network Slice Selection Function) est une entité permettant d’assister l’entité AMF de la sélection des instances logiques du réseau pour une tranche de réseau (slice) défini.

La figure 1 présente l’architecture 5G et les interfaces entre chaque entité.

Figure 1 : L’architecture du réseau 5G point à point (R.15)