PCell, SCell, PScell et SpCell

L’augmentation en débit entre le déploiement de la 4G et le déploiement de la 4G+/4G++ (UHD) a été rendue en partie possible par la technique d’agrégation de porteuses radioélectriques supplémentaires 4G. La technique d’agrégation de porteuses (ou CA : Carrier Agregation) à 2/3/4 ou 5 bandes 4G (LTE Advanced/LTE Advanced Pro) permet ainsi au mobile de disposer théoriquement jusqu’à 100 MHz de bande radioélectrique (ce qui correspond à 5 bandes de 20 MHz) [1].

La technique d’agrégation de porteuses est supportée par la couche MAC et la couche physique. On différencie la porteuse composante primaire (PCC : Primary Component Carrier) et la porteuse composante secondaire (SCC : Secondary Component Carrier). La PCC correspond à la porteuse principale LTE et les SCC correspondent aux porteuses agrégées.

On définit la cellule principale (PCell) la cellule sur la porteuse PCC. La PCell correspond à la cellule choisie par le mobile pour demander l’établissement ou le ré-établissement du lien radioélectrique. La Pcell est modifiée lors d’un handover ou libérée en fin de session. Les porteuses secondaires SCC permettent au mobile d’augmenter sa bande passante sur les cellules correspondantes aux fréquences secondaires. Les cellules secondaires (SCell) sont configurées lors d’un message RRC (RRC connection) et sont ensuite activées ou désactivées par la couche MAC via un message DCI.

Le message DCI est porté par le canal physique PDCCH. Le canal PDCCH ne porte l’allocation que d’une seule porteuse.

L’allocation de ressource via le canal PDCCH peut être transmise [2] :

  • soit sur la porteuse correspondante aux ressources désirées, on parle de self-scheduling car chaque porteuse agrégée alloue ses ressources sur le canal PDCCH de la porteuse agrégée ;
  • soit sur la porteuse principales et chaque canal PDCCH porte l’allocation de ressources de la porteuse principale ou d’une porteuse agrégée. On parle alors de cross-scheduling.

Lorsque le mobile est en mode connecté, la cellule serveuse (Serving Cell) correspond à une porteuse composante (CC : Component Carrier) c’est à dire la cellule primaire ou une cellule secondaire. La station de base gère la cellule principale ainsi que les cellules secondaires via les messages DCI de la couche MAC.

Le déploiement de la 5G-NSA met en œuvre un mécanisme de double connectivité multi-radio (MR-DC), mécanisme pour lequel on différencie le nœud maître (MN : Master Node) du nœud secondaire (SN : Secondary Node).

Le nœud maître établie la connexion de signalisation entre le mobile UE et le cœur de réseau. Dans le cas de la 5G NSA option 3, le nœud maitre est une station de base 4G. Le nœud maître correspond toujours au nœud sélectionné par l’UE en mode de veille et sur lequel l’UE fait sa demande initiale d’accès aléatoire.

Le nœud secondaire quant à lui a pour rôle de fournir des ressources radioélectriques supplémentaire et contrairement au nœud maître, il ne permet pas l’établissement d’un plan de contrôle avec le cœur de réseau. Dans le cas de la 5G-NSA, le nœud secondaire est une station de base 5G nommée en-gNB.

La technique d’agrégation de porteuses peut être mise en œuvre sur le nœud maître et/ou sur le nœud secondaire. On différencie l’agrégation de porteuses sur le nœud maître par un groupement de cellules MCG (Master Cell Group) et l’agrégation de porteuses sur le nœud secondaire par un groupement de cellules SCG (Secondary Cell Group).

Lorsque le nœud maître initie la demande d’établissement avec le nœud secondaire, le mobile recevra l’ordre via un message RRC (RRC reconfiguration) d’établir une demande d’accès aléatoire RACH avec la cellule secondaire SN et de faire des mesures radioélectriques sur le nœud secondaire et plus particulièrement sur la cellule sur laquelle le mobile aura établi sa demande d’accès aléatoire. Il s’agit donc de la cellule principale du groupe de cellules secondaires PSCell (Primary SCG Cell soit Primary Secondary Cell Group Cell).

Ainsi, lors de la double connectivité, l’UE réalise des mesures radioélectriques sur la cellule principale de la cellule serveuse maîtresse (PCell du MCG) et sur la cellule principale de la cellule serveuse secondaire PSCell ainsi que des mesures sur les cellules agrégées.

On appelle PCell la cellule principale de la station de base maîtresse et en cas d’agrégation de porteuse sur cette cellule, on appelle SCell, les cellules secondaires du MCG.

On appelle PSCell, la cellule principale de la station de base secondaire et on appelle également Scell les cellules secondaires du SCG.

La signalisation RRC n’étant émise que sur les cellules principales PCell et PSCell, le concept de Special Cell détermine la signalisation vers les cellules Maîtres et Secondaires : SpCELL = PCell + PSCELL

 

Reférences

[1] : ETSI TS 138 133 V15.2.0 (2018-07)

[2] https://www.3gpp.org/technologies/keywords-acronyms/101-carrier-aggregation-explained#:~:text=Carrier%20Aggregation%3B%20Primary%20and%20Secondary,coverage%2C%20i.e.%20different%20cell%20size.

SDT – Small Data Transmission (3ème)

Procédure d’accès aléatoire EDT/RA-SDT

La spécification R.15 propose une évolution de la procédure d’accès aléatoire nommée EDT Early Data Transmission. En cours de procédure d’accès aléatoire, le mobile UE peut transmettre des données dans le message 3 dont la taille est comprise entre 328 et 1000 bits et le message 4 est utilisé pour la transmission descendante [4]. La taille TBS (Transport Block Size) est toutefois imposée par l’accès radioélectrique RAN dans un message 2 RAR.

La transmission des données s’effectuant pendant la phase d’accès aléatoire, le mobile est soit à l’état RRC_IDLE soit à l’état RRC_INACTIVE, mais il n’est pas encore passé à l’état RRC_CONNECTED.

Deux optimisations pour la transmission EDT sont proposées :

  • CP-EDT : Control Plane EDT lorsque le mobile est à l’état RRC_IDLE
  • UP-EDT : User Plane EDT lorsque le mobile est à l’état RRC_CONNECTED

Cela signifie d’une part que les clés de sécurités sont différentes sur le chiffrement des messages (et sur l’authentification uniquement pour le mode CP) et que le tunnel est établi via un message NAS (eNB vers MME dans le cas CP-EDT) alors que les données sont transmises vers le SGW dans le cas de la transmission UP-EDT pour transmettre des données après la procédure d’accès aléatoire (mode connecté).

La procédure MO-EDT (Mobile Originating EDT) permet au mobile UE de transmettre des données lorsque la couche haute demande l’établissement d’une connexion RRC ou l’activation de la connexion RRC (resume) pour la transmission de données (MO Data). La cause de l’établissement n’est ni un SMS, ni de la signalisation mais la transmission de données.

Pour activer la transmission EDT, le mobile UE doit informer la station de base qu’il transmettra au cours du message 3 de la procédure RACH des paquets de données. Si la station de base supporte la transmission EDT, elle propose aux terminaux UE des séquences PRACH particulières (ou NPRACH pour le NB-IoT) en diffusant cette information dans le SIB2. Le terminal choisira une séquence PRACH pour constituer le message 1.

Dans le message 3 de la procédure RACH :

  • Si le terminal est à l’état RRC_IDLE, la transmission CP-EDT est mise en oeuvre et le terminal transmet la requête RRCEarlyData Request avec le message NAS encapsulé (S-TMSI, establishmentCause, dedicatedInfoNAS);
  • Si le terminal est à l’état RRC_INACTIVE, la transmission UP-EDT est mise en oeuvre et le terminal transmet la requête RRCResumeRequest

Le message EDT est transmis en clair sur l’interface radio si le mobile était à l’état RRC_IDLE ou chiffré en utilisant le contexte de sécurité AS si le mobile était à l’état RRC_INACTIVE. Le message NAS est quant à lui chiffré selon les clés de sécurités NAS connues au niveau du mobile UE et du cœur de réseau (MME/AMF).

Figure 8 : Protocole de transmission CP-EDT

Figure 9 : Protocole de transmission UP-EDT

Procédure de transmission pré-configurée PUR (Preconfigured Uplink resource)

La spécification 3GPP R.16 PUR [5,6] propose de réduire davantage la signalisation par rapport à la procédure EDT en supprimant les messages 1 et 2 de la procédure d’accès aléatoire.

Le mobile dispose ainsi d’une pré-configuration lorsqu’il est à l’état CONNECTE lui permettant de connaître :

  • Les spécifications de ressources (UL-Grant) ;
  • Le schéma de modulation et de codage MCS ;
  • Le nombre de répétition PUSCH ;
  • L’identifiant radio RNTI à utiliser : PUR C-RNTI

La configuration du mobile par un message RRC est déclenché soit par le mobile avec une requête PUR Configuration Request ou par l’eNB ou le réseau à travers un message RRC.

Dans le cas d’étude qui nous intéresse, le mobile étant statique la valeur du Timing Advanced (TA) ne change pas, dans le cas ou le mobile conserve la même cellule de service (Serving Cell). Comme évoqué dans l’introduction, le changement de cellule peut intervenir en cas de défaillance de la station de base lorsque le mobile est en écoute.

L’allocation de ressource de type 5, uniquement applicable pour les terminaux BL/CE est configurée à partir du paramètre PUR-Config [6].

La première transmission PUSCH PUR est séquencée par un message RRC, les messages subséquents sont ordonnancés par un message DCI.

Une étude plus importante doit être menée pour connaitre les conditions de validité de cette procédure.

 Etats RRC_INACTIVE (5G)/RRC_IDLE et RRC_CONNECTED

L’état RRC INACTIVE a été introduit en 5G de manière à conserver au niveau de la station de base et du mobile UE le contexte AS (Access Stratum), dans le but de réduire la consommation énergétique et le nombre de messages échangés entre le mobile UE et la station de base.

La spécification R.13 (4G) introduit deux nouveaux messages : RRC SUSPEND et RRC RESUME pour modifier l’état du mobile UE au niveau du mobile et de la station de base.

ATTENTION, en 4G le mobile revient à l’état RRC_IDLE à la réception du message RRC SUSPEND.

L’état INACTIVE apparait avec la 5G. Le noeud radioélectrique 5G peut être une station de base 4G ou une station de base 5G. Ainsi, l’état RRC_INACTIVE apparait à partir de la R.15 sur l’accés radioélectrique E-UTRAN, à condition d’avoir un cœur de réseau 5G.

Dans l’état RRC INACTIVE, le mobile et la station de base suspendent leur connexion radioélectrique mais le contexte AS est conservé au niveau du mobile et de la station de base. Le cœur de réseau considère que le mobile est toujours à l’état RRC CONNECTED. La sélection de cellule est gérée par le mobile mais le paging est géré par la station de base.

Figure 10 : Les états du mobile UE 4G/5G

Figure 11 : Grafcet des états du mobile pour le 5GC

Lorsque le mobile UE est à l’état RRC INACTIVE, il dispose d’un identifiant I-RNTI permettant d’identifier le contexte AS et permettant à la station de base de s’adresser au mobile UE via les messages de signalisation RRC, mais l’identifiant I-RNTI n’est pas utilisé pour embrouiller les bits du CRC.

Dans le cas d’un coeur de réseau 4G, le mobile ayant reçu une demande de suspension passe à l’état inactif. L’identifiant I-RNTI n’existe pas en 4G mais uniquement en 5G. De ce fait, pour la 4G, c’est l’identifiant S-TMSI qui est utilisé, ce qui explique pourquoi le S-TMSI et l’I-RNTI ne servent pas à embrouiller les bits CRC mais uniquement comme un identifiant de terminal.

Il y a deux formats I-RNTI :

  • Un format court de 24 bits
  • Un format long de 40 bits

Le mobile UE utilise l’un des deux formats en fonction de l’information portée par le drapeau « useFullResumeId » porté par le message SIB1.

Figure 12 : Les informations concernant l’identifiant I-RNTI portées par le SIB1

Le format court est utilisé de préférence dans les macro-cellules, le format long pour les micro-cellules ou pico-cellule. En effet, dans le cas des macro-cellules, lorsque le terminal est situé à l’extrémité de la cellule, la connexion radio est mauvaise. La taille minimale du TBS est de 48 bits, si les conditions radios sont mauvaises alors les données pouvant être transmises sans segmentation doivent avoir une taille inférieure à 48 bits. Le Short-I-RNTI ne faisant que 20 bits est préféré au Full-I-RNTI.

L’identifiant I-RNTI est utilisé pour notifier le mobile UE d’une procédure de paging ou pour mettre à jour la localisation (RNA Update). L’identifiant I-RNTI n’est pas utilisé lors de la procédure PRACH pour embrouiller la séquence DCI, il est transmis dans un message RRC, remplaçant l’identifiant UE_Identity en 4G (S-TMSI).

Par contre, la séquence DCI est toujours embrouillée par un identifiant RA-RNTI puis TC-RNTI. A ce titre, le TC-RNTI doit remplacer l’ancien C-RNTI de la précédente transmission SDT (cf la demande de modification : https://portal.3gpp.org/ngppapp/DownloadTDoc.aspx?contributionUid=R2-2102084)

Procédure

Figure 13 : La procédure d’activation de lien RRC (Passage de l’état RRC IDLE à l’état RRC CONNECTED) pour un coeur de réseau 4G

RRCRESUMEREQUEST ou RRCRESUMEREQUEST1

Quand le mobile UE souhaite transmettre un message, il déclenche la procédure d’accès aléatoire puis demande le rétablissement de la connexion radioélectrique via le message RRCResumeRequest ou le message RRCResumeRequest1. Le mobile émet la requête RRCResumeRequest1 si le SIB1 contient l’information useFullResumeID pour transmettre l’identifiant I-RNTI sur 40 bits. Sinon, le mobile émet la requête RRCResumeRequest avec l’identifiant SHORT-IRNTI.

UE CONTEXT RESUME REQUEST

La procédure UE CONTEXT RESUME REQUEST permet à l’eNB d’indiquer au cœur de réseau (MME/AMF) que le mobile UE souhaite reprendre la connexion RRC suspendue ou pour permettre l’émission d’un message EDT.

5G-NR : RA-SDT et CG-SDT

La procédure SDT (Small Data Transmission) est définie lorsque le mobile est à l’état RRC_INACTIVE.

La procédure RA-SDT est similaire à la procédure EDT lorsque le mobile est soit à l’état de veille, soit à l’état inactif en proposant de transmettre le signal en 4 étapes ou en 2 étapes. Plus précisément, la R.16 propose une procédure d’accès aléatoire en 2 étapes nommées 2-Step RA.

La transmission EDT ou RA-SDT transmet les informations lorsque le mobiles est à l’état de veille (CP-EDT) ou à l’état RRC_INACTIVE (UP-EDT ou RA-SDT). La procédure d’accès aléatoire 2-Step RA permet donc de transmettre les données en 2 étapes seulement.

La procédure CG-SDT est similaire à la procédure PUR lorsque le mobile est à l’état inactive.

L’une et l’autre sont en cours de spécification dans la R.17 [7]. La mise en œuvre de la R.17 radio ne sera pas réalisée avant 2024/2025.

Je bloque actuellement sur le point suivant :

En reprenant la spécification TS 36.300 :

« Transmission using PUR allows one uplink transmission from RRC_IDLE using a preconfigured uplink resource without performing the random access procedure. »

Mais, la 3GPP définit la transmission PUR de la manière suivante :

« Transmission using PUR is triggered when the upper layers request the establishment or resumption of the RRC Connection »

Cela signifie donc que l’UE est à l’état RRC_INACTIVE et non à l’état de veille?

Conclusion

Pour passer du mode de veille au mode connecté, le terminal UE émet une séquence aléatoire dont les caractéristiques (racine de la séquence) et l’instant d’émission est transmise par la station de base au mobile UE.

Concernant l’émission de la séquence aléatoire, la sous-trame de transmission est définie par le message SIB2.

La transmission SDT est défini comme une transmission pour laquelle l’UE n’a pas besoin de passer à l’état RRC_CONNECTED.

La procédure de transmission de message SDT à 2 messages (EDT ou RA-SDT) consiste à transmettre les données lors de la procédure d’accès aléatoire à l’état RRC_IDLE ou RRC_INACTIVE.

La procédure de transmission PUR ou CG-SDT nécessite que le mobile soit à l’état RRC_INACTIVE suivant un état RRC_CONNECTED. Lorsque le mobile est à l’état RRC_CONNECTED, la station de base transmet la configuration des allocations de ressource à l’UE (MCS, UL Grant, TA). Cette configuration n’est valable que tant que le mobile reste sous la couverture de la même station de base (pas de modification du TA Timing Advanced).

 Pour plus d’information, n’hésitez pas à me contacter pour une formation sur les réseaux LPWAN.

Ressources Bibliographiques

[1] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.1-2: Frame structure type 1 random access configuration for preamble formats 0-3

[2] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-4: Root Zadoff-Chu sequence order for preamble formats 0 – 3

[3] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-2 NCS for preamble generation (preamble formats 0-3)

[4] 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

[5] Andreas Höglund, G. A. Medina-Acosta, Sandeep Narayanan Kadan Veedu, Olof Liberg, Tuomas Tirronen, Emre A. Yavuz, and Johan Bergman , 3GPP Release-16 Preconfigured Uplink Resources for LTE-M and NB-IoT

[6] 3GPP TS 36.213, R.16.8.0 : Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures

[7] 3GPP TS 38.321, R.17.0.0 (mars 2022), MAC protocol Specification.

 

SDT – Small Data Transmission

Introduction

L’Internet des Objets a poussé la 3GPP a imaginé des protocoles dédiés pour des transmissions à faible volumétrie de données SDT (Small Data Transmission).

Le réseau 4G propose deux solutions SDT nommées EDT (Early Data Transmission) et la PUR (Preconfigured Uplink Resource).

Le réseau 5G propose deux autres solutions SDT nommées RA-SDT et CG-SDT. La technologie RA-SDT est proche de la solution EDT et la technologie CG-SDT est proche de la solution PUR.

Cet article est la continuité de la présentation de l’IoT Cellulaire (https://blogs.univ-poitiers.fr/f-launay/2017/05/28/mtc-le-reseau-m2m-iot-sur-la-4g-1ere-partie/) et je vais reprendre l’article sur le canal PRACH  : https://blogs.univ-poitiers.fr/f-launay/2020/05/02/etablissement-de-la-connexion-radioelectrique-comparaison-4g-et-5g/

Etude du signal d’accès aléatoire

Le signal d’accès aléatoire sur l’interface radioélectrique LTE est généré par le mobile selon la formule suivante :

La séquence Xu,v est une séquence de Zadoff-Chu (ZC). La séquence de PRACH s’appuie sur une séquence de ZC dans le domaine fréquentiel et la formule précédente permet d’appliquer la transformation du signal vers le domaine temporel.

La liste des préambules est transmises à l’UE via le message d’information système SIB2. La station de base propose une liste voire deux listes par cellule, chaque liste contient 64 préambules.

Un préambule racine est une séquence pseudo-aléatoire de Zadoff-Chu (ZC) qui est définie par la valeur de la racine. Les préambules de la liste sont obtenus à partir d’un décalage cyclique Cv du préambule racine.

Un nombre fixe de 64 préambules est alloué pour chaque cellule et en fonction de la longueur de décalage cyclique NCS, une ou plusieurs séquences racine d’accès aléatoire sont nécessaires par cellule pour générer les 64 préambules.

PREAMBULE PRACH (Accès Aléatoire)

Le préambule PRACH est constitué d’un préfixe cyclique de longueur TCP et d’une séquence de longeur TSEQ.

Figure 1 : Le préambule PRACH

Les longueurs TCP et TSEQ  dépendent de la structure de la trame (type 1 : FDD ou type 2 : TDD) et de la configuration définie au niveau de la couche RRC de l’accès aléatoire selon l’un des quatre formats ci-dessous :

Table 1 : La configuration de la séquence PRACH

Il convient de noter que durée de la séquence d’apprentissage définit la couverture de la cellule pour estimer correctement l’avance de synchronisation. Si eNodeB reçoit des préambules au-delà de la plage de cellules définie, l’estimation de l’avance temporelle sera erronée et l’accès aléatoire, la procédure échouera, ce qui entraînera de nouvelles tentatives de la part de l’UE.

Table 2 : La couverture de la cellule

 Les préambules par cellule sont divisés en deux sous-ensembles

La transmission du préambule PRACH est déclenché soit par la couche MAC (demande d’accès avec contention), soit par la couche RRC de la station de base (demande d’accès sans contention). L’étude porte sur la demande d’accès avec contention.

Lorsque le préambule est déclenché par la couche MAC de l’UE, la transmission de la requête d’accès doit être transmises sur des ressources tempo/fréquentielle définies par l’eNB, c’est à dire sur des fenêtres temporelles spécifiques correspondant à un numéro de sous-trame dans une trame (trame paire, impaire ou toutes trames) et sur des emplacements fréquentiels correspondant à des blocs de ressource. Les ressources tempo-fréquentielles autorisées sont transmises de l’eNB à tous les terminaux par le message de diffusion d’information SIB2 :

  • L’instant de transmission est défini via l’index PRACH-Configuration. Le numéro d’index de configuration PRACH, sur 6 bits (valeurs 0 à 63), permet de savoir dans quelle(s) sous-trames le PRACH peut être transmis sur chaque sous trame ou uniquement sur les sous trames paires
  • Le décalage prach-FrequencyOffset détermine la position du bloc de ressource (PRB) contenant la séquence dans le domaine fréquentiel

Table 3 : Table de configuration de l’index de configuration PRACH  [1]

PREAMBULE NPRACH (Accès Aléatoire)

A l’instar du LTE, les informations sur la procédure d’accès aléatoires sont transmises via le SIB2. On trouve la périodicité des demandes d’accès aléatoires, l’instant de transmission, la première sous-porteuse et le nombre de sous-porteuses allouées à la demande NPRACH, le nombre de répétition de la transmission du préambule.

La figure suivante est extraite du site : https://www.sharetechnote.com/html/Handbook_LTE_NB_rach.html


Figure 2 : Les sous porteuses NPRACH (informations SIB2)

Le signal NPRACH est donc transmis dans les ressources tempo-fréquentielles spécifiées dans le message SIB2.

Figure 3 : La transmission du NPRACH (exemple)

Dans le cas du NB-IoT, il n’y a que deux formats de préambules. Les préambules sont toujours composées d’un préfixe cyclique CP et d’une séquence.

Figure 4 : Comparaison des préambules entre le l’interface LTE et l’interface NB-IoT [1]

 La séquence du préambule PRACH/NPRACH

La séquence du préambule PRACH/NPRACH est issue du générateur de Zadoff-Chu :

Avec u, la racine de Zadoff-Chu,  la longueur de la séquence (en général 839)

La station de base transmet au mobile un index de racine. La correspondance entre l’index et la racine de Zadoff-Chu est indiquée dans la table 4.

Les séquences cycliques sont calculées à partir de

Table 4 : La correspondance entre l’indice de la séquence RACH et la racine de Zadoff-Chu [2]

La valeur de Cv est calculée par l’équation suivante :

La valeur de NCS est définie par la table 4 à partir de la valeur ZeroCorrelationZoneConfig transmise dans le message SIB2

Figure 5 : Le message SIB2

Table 5 : Les valeurs de NCS [3]

Il y a une ou au plus deux listes de 64 séquences par cellule. Les 64 séquences d’une liste sont extraites à partir de tous les décalages cycliques possible de la séquence racine (root). La valeur racine est transmise par la station de base via le SIB2 dans le message RACH_ROOT_SEQUENCE (pour la 1ère liste de 64 séquence) et dans le message ROOT_SEQUENCE_INDEX_HI si une deuxième liste est gérée.

 

Ressources Bibliographiques

 

[1] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.1-2: Frame structure type 1 random access configuration for preamble formats 0-3

[2] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-4: Root Zadoff-Chu sequence order for preamble formats 0 – 3

[3] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-2 NCS for preamble generation (preamble formats 0-3)

[4] 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

[5] Andreas Höglund, G. A. Medina-Acosta, Sandeep Narayanan Kadan Veedu, Olof Liberg, Tuomas Tirronen, Emre A. Yavuz, and Johan Bergman , 3GPP Release-16 Preconfigured Uplink Resources for LTE-M and NB-IoT

[6] 3GPP TS 36.213, R.16.8.0 : Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures

[7] 3GPP TS 38.321, R.17.0.0 (mars 2022), MAC protocol Specification.

La spécification O-RAN : le decoupage 7.2

Dans cet article, nous allons nous intéresser à la spécification O-RAN et plus particulièrement à la partie de découpage de la couche basse LLS (Low Layer Split) c’est-à-dire à la séparation des fonctions entre l’unité radio RU et l’unité distribuée DU. Il existe plusieurs options numérotées de 1 à 8 décrivant un découpage entre les fonctionnalités intégrées à l’unité RU (Radio Unit), DU (Distributed Unit) et CU (Central Unit) faisant ainsi apparaitre de nouvelles interfaces (fronthaul/midhaul/backhaul).

Figure 1 : Le découpage radioélectrique et les interfaces

L’option 7.2 propose un découpage de la couche physique basse (LLS ) au niveau du RU et la couche physique haute au niveau du DU. Elle est souvent associée à l’option 2 pour le CU.

 

Figure 2 : L’architecture protocolaire de la station de base et l découpage des fonctions radio

Le découpage a un impact sur les performances de transmission :

Figure 3 : Le découpage et la qualité de service

L’interface entre l’unité RU et DU est nommée fronthaul et les données utilisateurs ainsi que la manière dont les données seront émises (mode de transmission) sont transportées par un bus série eCPRI. Pour pouvoir gérer les données, le fronthaul transporte également une couche de gestion et une synchronisation.

Figure 4 : L’interface Open-Fronthaul [1]

La transmission des données du plan de contrôle et le plan utilisateur entre l’unité O-RU et l’unité O-DU est gérée au niveau de la couche 2 avec un service l2VPN VPWS ou eVPN VPWS, les données du plan de gestion sont transportées par le protocole IPv4 ou IPv6.

Figure 5 : Le transport des plans de données et de gestion entre le DU et le RU

L’unité radio converti le signal numérique en signal radio et inversement. Les fonctionnalités dédiées à l’O-RU pour le découpage O-RAN version 7.2 :

  • Synchronisation (GPS/IEEE 1588) et transport Fronthaul (eCPRI)
  • Gestion de la couche physique basse (FPGA ou ASIC)
  • Front end (radio et numérique) : Convertisseur et pre-distorsion, amplificateurs

Figure 6 : l’architecture physique de l’O-RU [2]

Pour résumer, voici les principaux avantages et inconvénient du découpage des fonctions :

Figure 7 : Les avantages et inconvénients du découpage (source CISCO)

Le découpage 7.2 présente quatre avantages :

  1. Le transfert des données du plan utilisateur correspond à des éléments de ressources ce qui permet de gérer la correspondance des données (RE Mapping) au niveau du DU et limite le nombre de message de contrôle vers le RU ;
  2. L’adaptation de la bande de transport des données est basée sur le nombre de flux (stream) et non sur le nombre d’antennes :
  3. La gestion des faisceaux peut être numérique/analogique ou hybride.
  4. La simplification de la gestion de l’interférence intercellule ICIC et de la coordination multipoint (COMP) qui est gérée au niveau de l’unité DU

De plus, concernant le découpage 7.2, deux modes distincts de fonctionnement ont été définis selon que la précodage est situé au niveau de l’O-RU ou de l’O-DU

  • O-RU catégorie A

Le précodage est réalisé au niveau du DU. L’interface fronthaul transporte des flux séparés spatialement (stream). Cela peut nécessiter une charge plus élevée par rapport au transport d’une couche. Le Beamforming Numérique et analogique sont optionnels

  • O-RU catégorie B

Le précodage est réalisé au niveau du RU. L’interface fronthaul transport une couche réduisant ainsi la charge de la payload par rapport à la cat A mais le codeur est plus complexe. Le Beamforming Numérique et analogique sont optionnels

Pour comprendre la différence entre les deux catégories, il est intéressant de reprendre le schéma d’une chaîne de transmission MIMO :

Figure 7 : le synoptique d’une chaîne de transmission MIMO

Une couche est définie comme un chemin d’entrée de codage et de modulation vers le codeur MIMO. Un flux est défini comme la sortie de l’encodeur MIMO qui est ensuite traitée via la formation de faisceau ou le bloc de précodeur.

Figure 8 : Les deux catégories A/B du découpage radio fonctionnelle 7.2 [3]

La catégorie A permet de simplifier la conception de la partie radio (figure 8), laquelle n’a pas à gérer la matrice de précodage sur les flux.

L’exemple suivant (figure 4) présente la cas du MIMO. Figure 9: Découpage fonctionnel 7.2

A travers le plan de contrôle C-plane, l’unité O-DU informe l’unité O-RU du traitement à accomplir en transmettant le précodage a effectuer.

Figure 10 : La gestion du BeamForming selon la matrice de précodage calculée au niveau de l’unité O-DU[3]

 A partir de la solution XILINX [2], nous allons voir le découpage fonctionnel de l’unité O-RU cat B connectée à une antenne massive MIMO 64T64R.

L’unité O-RU est composée de 5 sous unités :

  • Une sous unité d’interface ISU (Interface SubUnit)
  • Quatre sous unité radio RSU (Radio SubUnit)

L’unité ISU reçoit des trames eCPRI via l’interface ethernet, et récupère la payload, c’est-à-dire les symboles I/Q. Les symboles sont multipliés par la matrice de précodage H18×64 permettant de générer 64 flux qui seront répartis sur les 4 sous unités radio RSU.

Chaque RSU traite en parallèle les 16 flux en réalisant l’IFFT sur le signal I/Q et en ajoutant le préfixe cyclique, puis une calibration, et un premier convertisseur en fréquence (DUC : Digital Up Converter) et une pré-distorsion (PDP) et/ou une réduction du facteur crête (CPR Crest Factor Reduction) est effectuée avant amplification.

Figure 11 : Le synoptique et l’implémentation Xilinx du O-RU

La partie antennaire est composée de brin rayonnants avec deux polarités, chaque RSU gère un panneau antennaire. L’antenne est constituée de 4 panneaux.

Sur la figure 12, il y a 128 éléments d’antennes pour 64 émetteurs/récepteurs (transceiver 64T64R) en connectant deux éléments d’antennes de même polarité au même port d’antenne.

Figure 12 : Antenne Massive MIMO avec 128 éléments rayonnants

 

[1] https://www.youtube.com/watch?v=KAW4LHK31Ek
[2] https://www.techplayon.com/o-ran-open-radio-unit-o-ru-reference-architecture/
[3] https://online-events.keysight.com/keysight-technologies7/Massive-MIMO-O-RAN-Radio-Units-O-RU-Design-and-Conformance-Test-Challenges?show_live_page=true&add_to_calendar=true&bmid=4f5ae43d7e8c

 

 

Du Maillage de service au Service Communication Proxy SCP

  1. Introduction : du SOA aux micro-services

L’évolution majeure entre le réseau 4G-CUPS et le réseau 5G repose sur le choix d’une architecture orientée service (demandeur de services/fournisseur de services). Les fonctions réseaux sont des composantes logicielles (NF : Network Function) ré-utilisables, qui échangent des informations les unes vers les autres à travers une interface de service SBI (Service Based Interface).

Les services sont exposés en utilisant des protocoles standards (SOAP, Thrift, JSON) permettant d’imposer le format des messages échangés. Dans le cas de la 5G, le format des données est le JSON et le protocole d’échange se fait en HTTP2. Chaque service récupère, crée ou modifie une ressource. L’écriture se fait en utilisant les commandes POST ou PUT et la lecture en utilisant la commande WGET.

 

Une composante réseau logicielle (NF) est une unité autonome qui réalise une ou plusieurs tâches.

 

Chaque fonction est conçue pour réaliser une tâche ou des tâches précises comme récupérer des informations (exemple : l’identité du mobile lors de son attachement) ou exécuter une opération (exemple : mettre en œuvre un tunnel). Une fonction contient le code logiciel et les données nécessaire pour réaliser la liste des tâches associées à cette fonction.

 

Dans une architecture orientée services, les services communiquent entre eux via un système de couplage faible. Le couplage faible permet de réduire la dépendance entre les éléments du réseau, ce qui permet d’accélérer les mises à jour de fonctionnalité du réseau pour répondre à de multiples cas d’usages (Segments verticaux du marché).

Ainsi, par rapport aux entités fonctionnelles monolithiques du cœur de réseau 4G (cf. https://blogs.univ-poitiers.fr/f-launay/2021/02/26/architecture-sba-du-reseau-5g-microservices-et-soa/), l’architecture basée sur les services permet :

  • Une plus grande flexibilité et une innovation plus rapide : la ré-utilisation des fonctions accélère la mise en production d’une application car les développeurs utilisent des lignes de codes déjà exploitables
  • Une ouverture vers des nouveaux segments (agriculture, entreprise, …) par le biais d’exposition de service (API ouvertes)
  • Une maintenance et une évolution facile : les services étant autonomes (couplage lâche), il est plus facile de les modifier sans impacter le réseau, ou de créer des fonctions évoluées pour des solutions innovantes tout en maintenant les précédentes versions.

Le concept SOA est un des pilier du Cloud Computing. Le Cloud Computing porte l’architecture SOA à une échelle plus importante (en comparaison, le Cloud Computing est au WAN ce que le SOA est au LAN).

Plus précisément, le Cloud Computing exploite des composantes logicielles pouvant communiquer entre eux sans états (stateless) nommées micro-services. Le langage de programmation d’un micro-service est indépendant des autres micro-services.

L’usage des micro-services est grandement facilité par les techniques de conteneurisation. Les micro-services faiblement couplés sont déployés dans des conteneurs et connectés via des API ou via un réseau de services maillé (MESH Service) pour le routage des messages.

Lorsque le nombre de micro-service augmente, la gestion des communications entre chaque micro-service se complexifie. Le premier rôle du maillage de service (MESH Service) est de gérer l’échange très important des données entre les micro-services.

L’architecte 5G est une architecture basée sur le service (SBA : Service Base Architecture). L’architecture SBA fournit une architecture orientée services (SOA) pour héberger des composants de plan de contrôle distincts de différents fournisseurs avec des cycles de développement disparates qui pourraient facilement inter fonctionner et interagir pour fournir un sous-système 5G complet ou une offre de services.

Avec l’architecture SOA et SBA, de nombreuses fonctions réseaux sont lancées, avec un nombre d’instances permettant de prendre en charge le trafic de signalisation. A la différence du SOA, l’architecture SBA introduit la fonction NRF qui est un annuaire listant les instances déployées : chaque instance d’une fonction de réseau annonce sa disponibilité à la fonction NRF avant d’initier une connexion est-ouest et participer à la livraison d’une application ou d’un service plus important.

Figure 1 : L’architecture SBA et la fonction de découverte NRF

Toutefois, à l’instar du SOA, la difficulté est la répartition de charge de trafic de signalisation entre les fonctions.

 

2. Le maillage de service – Service MESH

Un service MESH a pour objectif de contrôler l’échange des données de services partagées entre les instances logicielles (micro-service ou fonctions NF).

Un micro-service est conçu pour échanger des données au niveau applicatif. Le service MESH introduit une couche d’infrastructure dédiée en intégrant dans l’application des PROXYS nommés SIDECAR (imaginez le sidecar d’une moto pour prendre en charge non pas une personne mais un service) afin d’optimiser l’échange de données.

Avec le maillage de service, les requêtes s’effectuent à travers des PROXYS implémentés en sortie des micro-services.

Figure 2 : Modèle SideCar [1]

Sans Sidecar, la composante logicielle devait compiler une bibliothèque de communication spécifique au langage pour gérer la découverte de services, les routages et les exigences de communication non fonctionnelles au niveau applicatif (couche 7).

Figure 3 : De kubernetes au Maillage de services [2]

Le maillage de service permet de plus de réaliser de la surveillance réseau en fournissant des statistiques sur les performances des communications entre les services. Ces performances permettent ainsi de mettre en œuvre des fonctionnalités d’équilibrage de charge, de modification de route (exemple : la réponse d’une instance à un service met trop de temps par rapport à une autre instance pour le même service, le proxy va donc choisir cette dernière instance).

La solution de maillage de service OpenSource ISTIO [3,4] permet ainsi :

  • La gestion de trafic par une configuration des règles de services entre les micro-services
  • La sécurité en introduisant des fonctions d’authentification, d’autorisation (OAuth2) et de chiffrement des communications
  • Observabilité

Figure 4 : La journalisation des messages

3. SCP : Service Communication Proxy

Le service side-car ne fait pas nécessairement partie de l’application, mais il est connecté à celle-ci. Il est présent partout où l’application parente est présente.

Figure 5 : Le principe du maillage de service [5]

Le service n’a pas connaissance du réseau, mais ne connait que le proxy sur lequel il est connecté.

Le proxy réalisant les fonctions suivantes :

  • La découverte de services
  • Le routage
  • L’équilibrage de charges
  • L’authentification et l’autorisation
  • L’observabilité (statistique, log, traces)
  • Le bon fonctionnement (et éventuellement le transfert via une réponse 3XX ou une erreur de service 5XX)

Le standard 3GPP a introduit le proxy SCP dans la R16 [6]. De ce fait, l’architecture SBA n’a pas besoin du proxy SCP dans son principe de fonctionnement. Mais dans le cas de fonction NF multi-distribués, le SCP va résoudre les problématiques de trafic de signalisation en fournissant un point d’entrée unique pour un groupe de fonctions réseau (qui sont enregistrées dans la fonction NRF). Cela permet au SCP de devenir le point de découverte délégué dans un centre de données, déchargeant le NRF des nombreux maillages de services distribués. Les règles de routage du SCP peuvent s’appuyer sur une ressource, un numéro de téléphone ou un identifiant IMSI. Dans le monde des Télécom, par comparaison (et abus de langage), le SCP joue un rôle similaire au proxy et routeur DIAMETER. Il s’agit d’une simple comparaison, le SCP permet l’échange de signalisation dans le réseau d’un opérateur, les agents DIAMETER DRA permettaient de mettre en relation tous les HSS/MME inter-opérateurs (et auparavant, le routage de la signalisation était géré par le réseau SS7 et les points sémaphores STP).

Figure 6 : SS7 -> DIAMETER -> HTTP2 – SCP

Le SCP est un sidecar centralisé, il a pour rôle de gérer la communication de services à services s’il est impliqué. En ce sens le SCP est attaché à chaque NF. Le rôle du SCP inclut l’interfonctionnement entre NF, la segmentation des services, le contrôle d’accès centré sur les services et l’équilibrage de charge. Le SCP apporte donc une abstraction réseau ce qui permet aux développeurs d’applications d’être indépendants de l’infrastructure.

Le SCP n’est pas une fonction réseau, il n’expose pas de service contrairement aux NF. Deux fonctions NF peuvent s’échanger des services directement ou indirectement en passant par le proxy SCP.

Figure 7 : Communication directe/indirecte de deux NF [6 – Fig 7.1.1.1]

Les rôles du SCP sont :

  • D’apporter une fiabilité des services NF.

[6] 5.21.3.4 Reliability of NF Services Si une défaillance de l’instance de service NF est détectée ou notifiée par la NRF (exemple plus disponible), le consommateur de service NF ou SCP sélectionne un autre NF Service Instance de service du même ensemble de services NF dans l’instance NF.

  • De sélectionner la fonction NF adéquate : une fonction NF (consommateur de service) interroge le SCP en transmettant les attributs souhaités de la fonction NF (producteur de service). A partir de ces informations suivantes permettent au SCP de trouver la fonction SMF (DNN, capacité UE, localisation)
  • Le transfert et le routage de message de signalisation
  • Les services de sécurités (ex : autorisation qu’un consommateur de service puisse accéder à l’API d’un producteur de service)
  • L’équilibrage de charge et contrôle de surcharge de trafic
  • Surveillance du réseau
  • Optionnellement interagit avec la base de donnée unifiée UDR pour la résolution de nom (IMSI, IMPI/IMPU, Identité UDM/HSS

 

Figure 8 : Implémentation du maillage de service via le SCP

Le maillage de service et le proxy SCP ajoute de la latence. Dans le cas du service MESH, au moins deux sauts de réseau supplémentaires sont ajoutés lorsqu’un service communique avec un autre service (le premier provient du proxy qui gère la connexion sortante de la source et le second provient du proxy qui gère la connexion entrante de la destination).

Pour l’architecture SBA, la communication entre service peut être directe ou indirecte, c’est-à-dire en passant par le SCP. Quoiqu’il en soit, la latence est sur le plan de contrôle et non le plan de transport.

 

Pour en savoir plus :

  • Linkerd, Istio, Consul, Kuma et Maesh.
  • https://www.infoq.com/fr/articles/service-mesh-ultimate-guide/
  • https://carrier.huawei.com/~/media/cnbgv2/download/products/core/strategy-analytics-5g-signaling-en.pdf

Références :

[1] https://docs.microsoft.com/fr-FR/azure/architecture/patterns/sidecarTS23.501 – System architecture

[2] https://jimmysong.io/en/blog/service-mesh-the-microservices-in-post-kubernetes-era/

[3] https://istio.io/

[4]  https://www.redhat.com/fr/topics/microservices/what-is-istio

[5] https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc

[6]  TS 23.501(3GPP  version 16.6.0)  System Architecture for the 5G System.

[7] https://www.metaswitch.com/blog/the-service-communication-proxy-5g-caught-up-in-a-service-mesh

 

 

 

Déploiement 5G-NSA : A quel moment le logo 5G apparait sur mon téléphone

  1. Introduction et problématique

Le déploiement de la 5G-NSA option 3X sur la bande 3,5 GHz consiste à mettre en œuvre une double connectivité (DC – Dual Connectivity) entre la station de base 4G (eNB), appelée station de base maîtresse MNB, et la station de base 5G (en-gNb) appelée station de base secondaire SNB.

Un téléphone UE, compatible 5G, en mode de veille, s’accroche sur une cellule 4G. Pour passer en mode connecté, le mobile fait une demande d’accès aléatoire avec la station de base eNB (cf. méhode d’accès aléatoire).

Dans cet article, nous supposons que la station de base 4G dispose des capacités à mettre en œuvre la double connectivité EN-DC pour une session DATA IP (hors appel VoIP).

Lorsque le mobile fait une requête de service (message NAS Service Request), la station de base 4G transfère la requête de service du mobile à l’entité MME en vue du ré-établissement d’un bearer IP. Ensuite (cf. Double Connectivité), la station de base 4G déclenche la double connectivité entre la station de base 5G et le mobile. A partir de ce moment, le mobile fait une demande d’accès aléatoire avec la station de base 5G (en-gNB) afin de pouvoir échanger des données sur la cellule 5G (cf. Acces aléatoire)

La question est donc de savoir à quel moment le logo 5G s’affiche sur mon téléphone, et est-il possible d’avoir le logo 5G sans pour autant recevoir la 5G ?

  1. Le logo 5G

II-1) Comment le mobile sait que la station de base 4G peut mettre en œuvre la Double Connectivité ?

L’échange de données 5G s’établit à partir du moment où la double connexion est mise en œuvre, donc lorsque le mobile est en mode connecté.

Toutefois, on peut observer le logo 5G sur son téléphone lorsque celui-ci est en mode de veille (aucune session IP). Par conséquent, le mobile est accroché à une station de base 4G maîtresse sur laquelle la double connectivité EN-DC peut être mise en œuvre. La station de base 4G transmet cette information par un message RRC à travers le système d’information SIB2 et plus particulièrement par le paramètre ULI – Upper Layer Indication positionné à la valeur vrai ‘true’.

Figure 1 : Information ULI portée par le SIB2 [1]

II-2) Est-il possible d’avoir le logo 5G sans pouvoir recevoir la 5G

Initialement, la bande de fréquence d’ancrage de la station de base maîtresse eNB pour la 5G-NSA était la fréquence de 700 MHz. Actuellement les autres bandes 4G (800 MHz, 1800 MHz, 2100 MHz ou 2600 MHz) peuvent également être des bandes d’ancrages pour le déclenchement de la double connectivité EN-DC. Quelle que soit la fréquence de la bande d’ancrage, on constate que la fréquence 4G est toujours plus basse que la fréquence 5G, laquelle est située à 3,5 GHz. L’atténuation de l’onde étant fonction de la fréquence, la couverture 5G est plus faible que la couverture 4G dans les mêmes conditions radio.

Figure 2 : Couverture 4G et 5G dans les mêmes conditions radios

Un mobile hors bande 5G reçoit toujours les informations diffusées par la station de base 4G et par conséquent peut afficher le logo 5G sans être sous la couverture de la station de base en-gNB. On parle de configuration D du mobile, lorsque le mobile affiche le logo 5G sous la couverture de la station de base maitresse 4G sans détecter le bloc de signal SSB (synchronisation/diffusion) de la station de base 5G.

Dans les fait, pour des sites co-localisés, la couverture 5G est identique à la couverture 4G : les ingénieurs radio des opérateurs mobiles tiltent les antennes 4G de manière à avoir la même couverture. Dans ce cas, nous ne sommes plus dans les mêmes conditions radio.

Par conséquent, le mobile peut donc afficher le logo 5G même s’il est en veille sur la cellule 4G. Evidemment, un terminal mobile non compatible 5G n’affichera pas le logo 5G puisqu’il ignore l’information ULI porté par le SIB2.

Dans le cadre classique d’attachement, voici le call flow correspondant pour un abonné qui a souscrit à l’offre 5G :

Figure 3 : Procédure d’attachement 5G-NSA Call flow avec un abonnement 5G [3]

  1. Le terminal fait une demande d’attachement (ou de mise à jour de sa localisation) avec le bit DCNR à 1 indiquant au cœur de réseau qu’il est compatible 5G-NSA
  2. L’entité MME met en œuvre :
    1. La procédure d’authentification du mobile avec le serveur HSS
    2. La mise en sécurité de l’interface NAS
    3. La mise en sécurité de l’interface AS
  3. L’entité MME informe le serveur HSS qu’il est le serveur d’enregistrement de l’abonné.
  4. Le serveur HSS met à jour sa table de correspondance IMSI/MME et transmet au MME le type d’abonnement de l’abonné avec des valeurs AMBR maximales pour la 5G via l’AVP extended (AVPs « Extended-Max-Requested-BW-UL » and « Extended-Max-Requested-BW-DL »: 4 294 967 295 bps)
  5. L’entité MME procède à l’établissement des bearers par défaut
  6. L’entité PGW reçoit une demande d’établissement de tunnel avec une demande de débit AMBR élevé. Le PGW interroge l’entité PCRF (message DIAMETER Credit Control CCR-I) avec les valeurs AMBR reçues par le MME.
  7. L’entité PCRF transmet au PGW les caractéristiques de QoS du bearer afin d’établir que l’entité PGW puisse établir sa table d’acheminement.
  8. Le PGW transmet les caractéristiques du bearer et l’@IP du mobile au SGW lequel transfère l’information au MME (Le document [3], le SGW et le PGW sont sur la même entité S/PGW et le SGW n’apparait pas. De plus, la flèche est dans le moment sens sur ce document).
  9. L’entité MME transmet la valeur maximale autorisée UE-AMBR au mobile (10 Gbps) si l’abonne à les droits d’accès 5G. Dans le cas contraire, l’entité MME informe la station de base de la restriction d’accès NR (« RestrictDCNR » bit to « Use of dual connectivity with NR is restricted »)
  10. La station de base eNB transmet la réponse Initial Context Setup à destination du MME permettant de définir les caractéristiques du bearer radio RAB.
  11. La station de base eNB transmet au MME la réponse de l’UE validant l’attachement et l’établissement du bearer par défaut.

Lors de la procédure d’attachement (figure 3), l’entité MME supporte les fonctionnalités suivantes pour la 5G-NSA :

  • Procédure de modification E-RAB

Dans le cas de la 5G-NSA option 3X, l’option SCG (Secondary Cell Group) est activée pour supporter la double connectivité DCNR sur la gNB. La procédure de modification E-RAB permt à l’eNB peut commuter le bearer radio vers la station de base 5G sans modification du tunnel de signalisation S1-MME.

  • Sélection du SGW/PGW

Lorsque le serveur HSS accepte l’option 5G-NSA, le serveur DNS fourni au MME les informations de sélection des entités SGW/PGW pour la mise en œuvre de la double connectivité :

  1. x-3gpp-sgw:x-s5-gtp+nc-nr
  2. x-3gpp-pgw:x-s5-gtp+nc-nr

Mais qu’en est-il si le terminal est compatible 5G, alors que le client n’a pas souscrit à l’offre 5G ?

II-3) Le client n’a pas souscrit à l’offre 5G

Lorsque le mobile s’attache, il émet la requête NAS ATTACH REQUEST à la station de base 4G eNB. Cette requête est relayée par l’eNB vers le MME. Au cours de cette demande d’attachement, le terminal informe le MME qu’il est compatible 5G-NSA à travers le bit d’information nommé DCNR (dual connectivity with NR supported). Le MME interroge le serveur HSS pour l’authentification de l’abonné (cf Attachement et sécurité ).

Une fois l’abonné authentifié, le HSS conserve l’identité du MME sur lequel le mobile est attaché. L’entité MME envoie la requête DIAMETER ULA Update Location Answer en indiquant que le mobile est compatible 5G-NSA et le HSS répond au MME par la requête Update Location Request ULR que la 5G-NSA ne fait pas partie du forfait de l’utilisateur (« Access-Restriction » avec comme précision « NR as Secondary RAT Not Allowed »). Ainsi, le MME va informer la station de base de la restriction de la double connectivité par le message RestrictDCNR=1 (Use of dual connectivity with NR is restricted » in the EPS network feature support IE), ce qui va de plus interdire le mobile de faire des mesures 5G (évènements B1 et B2).

Lorsque le mobile fait un changement de MME (par la requête TAU – Tracking Area Update par exemple), les messages ULR/ULA seront échangés entre le serveur HSS et la nouvelle entité MME. Si le client change de forfait et que le mobile est attaché, alors le serveur HSS met à jour les informations auprès du MME par le message DIAMETER IDR/IDA (Insert-Subscription-Data-Request/Answer).

Pour plus de détail, reprenons la spécification 3GPP:

« If the RestrictDCNR bit is set to “Use of dual connectivity with NR is restricted” in the EPS network feature support IE of the Attach Accept/Tracking Area Update Accept message, the UE provides the indication that dual connectivity with NR is restricted to the upper layers.”

Figure 4 : Procédure d’attachement 5G-NSA Call flow sans abonnement 5G[4]

Si le terminal est compatible 5G mais l’abonne n’a pas souscrit à l’offre 5G alors le terminal n’est pas supposé fonctionner en 5G. Toutefois, je n’ai pas personnellement fait le test, on peut lire dans des forums une procédure pour contourner l’attachement en forçant dans un premier temps l’attachement sur le réseau 3G et ainsi ne pas transmettre la restriction DC puis de lever ce forçage pour que le mobile sélectionne une station de base 5G.

  1. 4G attach in any MME
  2. put the phone in 3G: Preferred Network Type : Prefer 3G
  3. change Preferred Network Type : Prefer 5G. (Most likely the MME takes the profile from 3G SGSN and it doesn’t get any 5G restriction from there since the SGSN doesn’t know what 5G is. The 5G restriction is set in HSS.)
  4. Enjoy 5G.

Cette procédure semble fonctionner sur un cœur de réseau Huawei (l’auteur du blog étant situé en roumanie : https://volteromania.blogspot.com/p/5gproblem.html)

III) Conclusion

Pour pouvoir afficher le logo 5G, il est déjà nécessaire d’avoir un smartphone compatible 5G et un abonnement 5G.

L’alliance GSMA proposé 4 configurations :

  • Configuration D : le mobile est en mode de veille sous la couverture d’une station de base 4G eNB qui diffuse l’information UpperLayerIndication=true dans le SIB2.
  • Configuration C : Le mobile est en mode connecté avec une station de base 4G et la station de base 4G configure l’interface radio du mobile pour faire des mesures 5G (SS-RSRP).
  • Configuration B : Le mobile est attaché sur une station de base 4G qui diffuse l’information UpperLayerIndication=true dans le SIB2 et le mobile mesure en plus la présence d’une station de base 5G (SS-RSRP)
  • Configuration A : Le mobile est connecté en double connectivité sur la station de base 4G et 5G.

 

Biblio

[1] TS 36.311 Radio Resource Control (RRC); Protocol specification (3GPP TS 36.331 version 15.3.0 Release 15) – ASN1 SystemInformationBlockType2 information element

[2] TS 29.272 V15.5.0 (2018-09) – Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol

[3] https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-16_6-10/5G-NSA/21-16-5G-NSA-Solution-Guide/21-16-5G-NSA-Solution-Guide_chapter_010.html

[4] https://www.telecomhall.net/t/ue-restrictdcnr-use-of-dual-connectivity-with-nr-is-restricted/10352/20

Les informations UCI portées par le canal PUCCH

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

 

 

 

La sécurité des réseaux mobiles – Part 6

Cet article est le dernier de la série – Sécurité des réseaux mobiles.

Se référer à :

La sécurité sur les réseaux de mobiles – Part 1

La sécurité sur les réseaux de mobiles – Part 2

La sécurité sur les réseaux de mobiles – Part 3

La sécurité des réseaux mobiles – Part 4

La sécurité des réseaux mobiles – Part 5

II-3-2) La sécurité sur l’architecture SBA

L’architecture 5G SBA est définie à l’article suivant :

Architecture SBA du réseau 5G : Microservices et SOA

Figure 20 : l’architecture SBA du réseau 5G

Les fonctions réseaux NF (Network Function) doivent supporter le protocole TLS pour l’échange d’information coté serveur et client.

Le proxy SEPP implémente un niveau de sécurité sur la couche application sur l’échange d’information de signalisation échangées entre deux fonctions réseaux NF entre deux opérateurs (nominal et visité). La transaction entre les deux opérateurs est sécurisée par un certificat d’autorité.

Le rôle du SEPP est d’apporter une sécurité de bout en bout (E2E core network interconnection security) en chiffrement et en sécurité lorsque la signalisation est prise en charge par un fournisseur de transport IPX.

La confidentialité et l’intégrité sont assurées par les fonctions SEPP de bout en bout (réseau visité, réseau nominal) à travers l’interface N32.*

Figure 21 : L’architecture SBA dans le cas du Home Routing (HR)

3. Le mécanisme EAP

Pour gérer différentes méthodes d’authentification, les réseaux de mobiles utilise le protocole EAP (extensible Authentication Protocol). Ce protocole est dit extensible car il supporte différentes méthodes d’authentification.  Pour que l’authentification réussisse, il faut supporter le même type d’authentification EAP sur le client et sur le serveur d’authentification.

Différents type d’authentification supportés par le protocole EAP sont :

  • EAP-MD5 : Authentification avec un mot de passe ;
  • EAP-TLS (Transport Layer Security) : Authentification mutuelle basée sur les certificats du client et du réseau. Le client et le serveur doivent posséder un certificat numérique issue d’une autorité de certification (CA – Certificate Authority) ;
  • EAP-TTLS : Le client authentifie le serveur grâce à une infrastructure à clés publique (PKI : Public Key Infrastructure) au niveau du serveur. L’authentification mutuelle est optionnelle (l’utilisation de la clé publique au niveau client est optionnelle). Lorsque le client a authentifié le serveur, le serveur met en place un tunnel chiffré avec le client. Ce tunnel permet au serveur d’authentifier le client par un login/mot de passe au niveau du client. Le mot de passe peut en plus être chiffré par la méthode CHAP;
  • EAP-PEAP : La méthode PEAP est similaire à la méthode TTLS. Pour la méthode TTLS le mot de passe est transmis dans la payload TLS, alors que dans la méthode PEAP, le mot de passe du client est encapsulé dans l’en-tête TLS.
  • EAP-FAST : Authentification mutuelle, basée sur un certificat. L’obtention du certificat est négociée par le client lors du premier échange. Si le client n’a pas de clé PAC (Crédit d’Accès Protégé – Protected Access Credential) secrète communiquée à l’avance, il peut envoyer une requête d’échange EAP-FAST afin d’en obtenir une dynamiquement du serveur du client et du réseau par l’intermédiaire d’un canal chiffré (ou tunnel) ;
  • EAP-SIM : Authentification via l’application SIM d’un téléphone 2G;
  • EAP-AKA : Authentification mutuelle sur le réseau 3G/4G/5G ;
  • EAP-AKA’ : Authentification mutuelle sur le réseau 5G.

Dans le cas des réseaux mobiles, la méthode d’authentification s’appuie sur une clé secrète connue uniquement par le client et par le serveur d’authentification. Aucun mot de passe n’est transmis. Ainsi, seules les méthodes EAP-SIM, EAP-AKA et EAP-AKA’ sont utilisées.

La méthode EAP-SIM est définie pour le réseau 2G et dans ce cas, seul le serveur authentifie le client. Pour les méthodes EAP-AKA et EAP-AKA’, l’authentification est mutuelle (Authentication and Key Agreement), le réseau authentifie le mobile et le mobile authentifie le réseau.

Le réseau 4G supporte la méthode EAP-AKA, les réseaux 5G supportent en plus les méthodes EAP-AKA’ et EAP-TLS. Le protocole EAP-TLS est utilisé pour les réseaux privés.

Le format des messages EAP est le suivant :

Figure 22 : Le format EAP

Le champ des données utiles (payload) est constitué d’un champ type et du vecteur d’authentification.

Le champ type défini la méthode d’authentification :

Tableau 2 : Différentes valeurs des types EAP

L’implémentation du protocole EAP nécessite trois composantes :

  • Une couche basse (lower layer) est responsable de la transmission/réception des trames EAP. La couche basse peut être une connexion PPP, un modem RTC, une connexion Ethernet, une connexion WiFi, une connexion cellulaire ;
  • Une couche EAP qui transmet les paquets EAP à la couche basse ou reçoit les paquets EAP en provenance de la couche basse. La couche EAP implémente une fonction de détection des doublons et une fonction de retransmission.
  • La méthode EAP implémente l’algorithme d’authentification

Dans le cadre des réseaux de mobiles, le client EAP est situé dans la carte UICC.

Figure 23 : Le protocole EAP (cas PPP)

Les trois méthodes qui sont présentées permettent l’authentification du mobile à partir d’un point d’accès WiFi.

III-1) La méthode EAP-SIM

La méthode EAP-SIM permet au téléphone de basculer sur la connexion 2G ou 3G sur le réseau WiFi. La figure 3 présente les messages échangés entre le terminal et un point d’accès WiFi.

Figure 24 : La méthode EAP SIM

La méthode EAP SIM permet d’authentifier le mobile à partir de la clé privée symétrique située dans l’application SIM de la carte UICC et dans la base de donnée HLR.

L’objectif de la méthode EAP SIM est de permettre au mobile de se connecter automatiquement et de manière sécurisée sur un réseau WiFi communautaire. La méthode EAP SIM ne nécessité pas de login/mot de passe ni de portail captif.

Le centre d’authentification est l’entité HLR/Auc et l’authentificateur est le serveur d’authentification RADIUS AAA (Authentication Autorisation Accounting).

Figure 25 : Le protocole d’authentification par la méthode EAP-SIM (Source CISCO [4])

III-2) La méthode EAP-AKA

La méthode EAP-AKA est un mécanisme de défi-réponse basé sur une clé symétrique dans le module USIM et dans l’environnement nominal (HLR).

Le mécanisme est similaire à l’authentification 4G-AKA, le serveur EAP (authentificateur) est un serveur AAA (Authentication, Authorization and Accounting) et le centre d’authentification est l’entité HLR/AuC. Le lien radioélectrique WiFi n’étant pas protégé, le support de données (bearer) sera transmis dans un tunnel VPN sécurisé par le protocole IPSEC (Internet Protocol Security). Ce tunnel s’établit entre le mobile et l’entité ePDG (evolved Packet Data Gateway).

Figure 26 : L’architecture du réseau 4G avec le point d’accès WiFi

Le mécanisme IPsec est mis en œuvre pour l’établissement d’un tunnel à l’issue de la phase d’authentification utilisant le mécanisme 802.1x.

Le plan de contrôle (signalisation) est mis en œuvre par le protocole de chiffrement IKEv2 qui gère l’association de sécurité SA (Security Association) pour les sessions IPsec. Le protocole IKEv2 permet d’authentifier les deux extrémités du tunnel (ePDG et le mobile). Le mobile est l’initiateur et l’entité ePDG est le répondeur. Le protocole IKEv2 négocie les algorithmes de l’association de sécurité et permet l’échange des valeurs publiques D-H (algorithme Diffie Hellman) et les nombres aléatoires Nonce.

La clé de chiffrement Ck et la clé d’intégrité Ik générées par le centre d’authentification sont transmises à la passerelle ePDG. Les clés Ck et Ik étant connues par le mobile, ces deux clés sont utilisées pour générer la clé maîtresse MSK (Master Session Key).

Une fois l’authentification réussie, le tunnel IPsec assure la protection des données. Le protocole IPsec se situe sur la couche IP et permet :

  • le chiffrement des données (payload) par le protocole ESP (Encapsuling Security Payload). C’est la totalité du paquet IP qui est chiffrée ;
  • l’intégrité et l’authentification par encapsulation de l’entête AH (Authentication Header). Le paquet chiffré est encapsulé dans un nouveau paquet IP avec un nouvel en-tête IP.

Pour plus d’information, se référer à l’article : http://blogs.univ-poitiers.fr/f-launay/2018/01/01/interfonctionnement-du-lte-et-du-wifi/

En 4G, l’accès WiFi vers le cœur de réseau est utilisé principalement pour le WiFiCalling.

Figure 27 : La mise en place d’un tunnel pour le protocole SIP

III-3) La méthode EAP-AKA’

La méthode EAP-AKA’ est proche de la méthode d’authentification 5G-AKA. La demande d’authentification est transmise selon le protocole EAP. Les messages EAP sont encapsulés dans les messages NAS entre le mobile et la fonction SEAF de l’AMF, et dans les API (JSON) entre la fonction SEAF et la fonction AUSF.

Le rôle de la fonction SEAF est néanmoins différent dans le cas de la méthode EAP-AKA’ puisque la fonction SEAF transfère de manière transparente les messages EAP sans être impliquée dans la décision comme c’est le cas pour la méthode 5G-AKA.

L’autre différence porte sur la dérivation des clés. Dans le cas de la méthode 5G-AKA, le clé KAUSF est calculée par la fonction ARPF de l’entité UDM. Dans la méthode EAP-AKA’, la clé EMSK (Extended Master Session Key) est calculée au niveau de la fonction AUSF et les 256 premiers bits de la clé EMSK forment la clé KAUSF.

 

Références :

[1] http://www-igm.univ-mlv.fr/~jyt/Crypto/3/GSM/S5.Brumley-comp128.pdf

[2] 3GPP TS 35.205 : System Aspects; 3G Security, Specification of the MILENAGE algorithm set, An example algorithm set for the 3GPP, authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*. V9.0.0

[3] 3GPP TS 35.206 – LTE; 3G Security; Specification of the MILENAGE algorithm set: An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; Document 2: Algorithm specification. V9.0.0

[4] Source CISCO : Cisco SP Wi-Fi solution: use cases and call flows (Djordje Vulovic) https://www.cisco.com/c/dam/global/hr_hr/assets/ciscoconnect/2014/docs/cisco_connect_see_2014_sp_wi-fi_dvulovic.pdf

[5] 3GPP TS 33.102 3G security; Security architecture, version 11.5.1 Release 11

[6] Snow3G : https://www.gsma.com/aboutus/wp-content/uploads/2014/12/snow3gspec.pdf

[7] ZUC Specification : https://www.gsma.com/aboutus/wp-content/uploads/2014/12/eea3eia3zucv16.pdf

[8] https://www.netmanias.com/en/?m=view&id=techdocs&no=10425

[9] 3GPP TS 35.206, 3G Security, specification of the MILENAGE, Release 7 version 7.0.0

https://www.etsi.org/deliver/etsi_ts/135200_135299/135206/07.00.00_60/ts_135206v070000p.pdf

[10] https://labs.p1sec.com/2020/06/26/5g-supi-suci-and-ecies/

[11] Des failles de sécurité dans la future norme de communication mobile 5G ; https://factuel.univ-lorraine.fr/node/9972

[12] 3GPP TS 33.501 Security Architecture and Procedure – version 15.1.0 (figure 6.1.3.1.1) : https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/15.01.00_60/ts_133501v150100p.pdf

 

Autres lectures : 

https://www.open.com.au/radiator/eap-sim-whitepaper.pdf

https://www.cablelabs.com/insights/a-comparative-introduction-to-4g-and-5g-authentication

ETSI TS 102 310 V6.0.0 (2004-12) : Extensible Authentication Protocol support in the UICC, Release 6

https://github.com/mitshell/CryptoMobile

https://github.com/CellularPrivacy/Android-IMSI-Catcher-Detector/issues/926

RFC3748 : Extensible Authentication Protocol (EAP) : https://tools.ietf.org/html/rfc3748

RFC 5998 : An Extension for EAP-Only Authentication in IKEv2 : https://tools.ietf.org/html/rfc5998

La sécurité sur les réseaux de mobiles – Part 3

Précédents articles : 

La sécurité sur les réseaux de mobiles – Part 1

La sécurité sur les réseaux de mobiles – Part 2

2. La protocole AKA

II-1) La sécurité sur le réseau 3G :

Le protocole d’authentification GSM n’est pas fiable. D’une part, l’authentification étant unilatérale, le mobile peut s’attacher à un réseau pirate et d’autre part, l’algorithme COMP128 a été cassé en 1997 (figure 3 : attaque Narrow Pipe en 1998) :

Figure 5 : L’algorithme COMP128 [1]

De plus, le réseau pouvant négocier l’algorithme de chiffrement en 2G, il est possible de récupérer en clair les données échangées.

Afin de sécuriser l’attachement du mobile et interdire l’attachement sur un réseau pirate, le protocole AKA (Authentication and Key Agreement) exige une authentification bilatérale.

Le cœur de réseau 3G est identique au cœur de réseau 2G, l’amélioration de la sécurité est apportée au niveau du mobile par l’application USIM sur la carte UICC et d’une mise à jour de la fonction AuC du serveur d’authentification HLR. Pour réaliser l’authentification du réseau, une nouvelle clé AMF (Authentication Management Field) est inscrite dans la carte UICC et dans le HLR.

Le vecteur d’authentification généré par l’AuC contient :

  • l’aléa RAND sur 128 bits ;
  • le résultat d’authentification attendu SRES (32 bits à 128 bits);
  • le sceau d’authentification du réseau opérateur AUTN (128 bits);
  • une clé de chiffrement Ck(128 bits) ;
  • une clé d’intégrité Ik (128 bits).

Le résultat SRES, le sceau AUTN, les clés de chiffrements Ck et Ik sont calculés à partir de l’aléa RAND, de la clé privé symétrique Ki et d’une séquence SQN (figure 6).

Figure 6 : Calcul du vecteur d’authentification 3G

Le vecteur d’authentification est transmis à l’authentificateur VLR ou SGSN. Ce dernier envoie l’aléa RAND et la sceau d’authentification AUTN au mobile, lequel le transfert à la carte UICC.

Le sceau d’authentification est composé de 3 champs qui sont embrouillés par une séquence de 128 bits :

  • une clé d’anonymat Ak (Anonimity Key) sur 48 bits ;
  • la valeur AMF (Authentication Management Field) sur 16 bits ;
  • d’un message de signature d’authentification MAC.

f1 et f2 sont deux fonctions d’authentification. f3, f4 et f5 sont des fonctions de génération de clés (KDF : Key Derivation Function).

Le choix des algorithmes f1, f2, f3, f4 et f5 est spécifique à l’opérateur. Cependant un choix d’algorithmes appelé MILENAGE est proposé par la spécification 3GPP [2] [3].

A partir de sa clé Ki, et de l’aléa, l’application USIM calcule d’abord la clé d’anonymat et récupère ainsi la valeur SQN (par un OU exclusif avec AK et le premier champs AUTN).

Ensuite, le mobile calcule :

  • le message d’authentification XMAC=f1(Ki, AMF, SQN) ;
  • le résultat RES attendu par le cœur de réseau f2(Ki,RAND).

Le résultat RES calculé au niveau de la carte UICC est transmis au mobile qui l’envoie à l’authentificateur. L’authentificateur compare le résultat RES du mobile avec la valeur attendue SRES.

Enfin, la carte UICC vérifie la correspondance entre la signature XMAC calculée avec le champ MAC contenu dans le sceau d’authentification AUTN. Cela permet d’éviter les attaques de type Man In The Middle. Si les valeurs sont identiques, l’application USIM calcule le résultat d’authentification (figure 7).

Figure 7 : Les étapes d’authentification pour la 3G et détection d’une station de base pirate

Ensuite, le mobile dérive les clés de chiffrement Ck et d’intégrité Ik à partir des fonctions f3 et f4.

Alors qu’en 2G le chiffrement et le déchiffrement sont réalisés au niveau de la BTS pour les sessions téléphoniques et au niveau du SGSN pour le trafic IP, en 3G le chiffrement et le déchiffrement s’effectuent au niveau du RNC (Radio Network Controller).

Ainsi, la clé CK doit être transférée du VLR au RNC via la commande security mode command gérée par le protocole RANAP (Radio Access Network Application Part). Ensuite, le RNC active le chiffrement au niveau du mobile via le message RRC security mode command.

Figure 8 : La procédure d’authentification et de chiffrement [5]

La clé Ck est calculée à chaque processus d’authentification. Le chiffrement est réalisé par un ou exclusif entre un bloc de données et un flux de chiffrement. Le flux de chiffrement est calculé à partir de l’algorithme f8 avec comme paramètres :

  • la clé Ck;
  • un compteur COUNT-C sur 32 bits ;
  • l’identité du support radio (BEARER) sur 5 bits ;
  • la direction de transmission (UpLink =0/DownLink =1) ;
  • la longueur du flux de chiffrement (le bloc de donnée à chiffrer).

Figure 9: Le chiffrement des données

L’algorithme f9 est utilisé pour le calcul d’intégrité :

Figure 10 : La signature d’intégrité des données

La valeur FRESH est une variable aléatoire généré par le RNC. La clé IK étant générée lors de l’enregistrement, celle-ci n’est pas modifiée tant que le mobile ne se détache pas. La valeur FRESH permet de modifier régulièrement la signature. Cette valeur est transmise au mobile au cours de la demande de connexion RRC.

D’un point de vue implémentation algorithmique, la valeur FRESH n’est pas réellement aléatoire, elle est souvent prise égale à la valeur du BEARER.

Le compteur COUNT-I protège le récepteur d’une attaque Man In The Middle : le prochain message, le compteur est incrémenté et la signature MAC pour le même message sera différente.

Les algorithmes d’authentification sont connus sous le nom de MILENAGE.

Les algorithmes de chiffrement f8 et f9 sont des algorithmes de KASUMI (déjà utilisé en 2G pour l’algorithme A5/3). Plus récemment, l’algorithme Snow 3G est un algorithme de chiffrement à flot pouvant remplacer l’algorithme KASUMI. L’algorithme SNOW3G est aussi utilisé pour fournir un message d’intégrité MAC (aussi nommé algorithme UIA2).

Figure 11 : Le calcul des clés en 3G

L’intégrité est calculé au niveau de la couche RRC, le chiffrement est réalisé au niveau de la couche RLC (sauf pour le mode transparent ou le chiffrement est réalisé par la couche MAC)

La sécurité sur les réseaux de mobiles – Part 1

Merci à Tony Boucheau pour la relecture de l’article

 Introduction

A l’exception des appels d’urgence, le client mobile n’a accès à aucun des services offerts par le cœur de réseau mobile tant que celui-ci n’est pas authentifié.

Les échanges liés au processus d’authentification sont relayés par le point d’accès vers le serveur d’authentification. Le point d’accès est en général une station de base 2G/3G/4G/5G. Toutefois, le point d’accès WiFi est également vu comme une passerelle radioélectrique permettant de connecter l’utilisateur mobile au cœur de réseau 5G.

Une fois le client authentifié, le point d’accès laisse passer le trafic. Afin de garantir le secret des informations échangées, les données sont chiffrées et un contrôle d’intégrité par une signature MAC (Message Authentication Code) permet de vérifier l’authenticité de l’émetteur.

Le chiffrement est mis en place entre les acteurs de la transaction ce qui garantit que la session devient inintelligible aux autres personnes. Enfin, pour se prémunir des attaques de type Man in the Middle (IMSI Catcher), l’intégrité des données permet de vérifier que les données de signalisation échangées n’ont pas été altérées (de manière fortuite ou intentionnelle). Le chiffrement et l’intégrité sont réalisés au niveau du terminal et :

  • si le point d’accès est une station de base 4G ou 5G, celle-ci apporte un chiffrement sur le trafic de données et sur le trafic de signalisation ainsi qu’un contrôle d’intégrité sur la signalisation. Optionnellement, pour le réseau 5G, le contrôle d’intégrité peut aussi s’appliquer sur le trafic des données. Les clés de chiffrement et d’intégrité sont dérivées à partir d’une clé secrète et à partir des paramètres échangés lors du processus d’authentification ;
  • si le point d’accès est une station de base 2G, le chiffrement est réalisé au niveau de la station de base pour les communications téléphoniques et au niveau du SGSN pour les sessions IP ;
  • si le point d’accès est une station de base 3G, le chiffrement est réalisé au niveau du contrôleur RNC ;
  • si le point d’accès est un point WiFi, un tunnel est mis en œuvre entre le mobile et une entité de passerelle WAG (Wireless Access Gateway). Cette entité se nomme ePDG (evolved Packet Data Gateway) pour le réseau 4G et N3IWF pour le réseau 5G.

 

Le processus d’authentification a pour objectif de vérifier l’identité d’un client (aussi nommé pair ou supplicant). Le protocole d’authentification spécifie le format des messages échangés (requêtes/réponses) entre le client et l’authentificateur. En se basant sur l’identité présumée du client, l’authentificateur transmet au client un défi (un challenge). A partir du défi, le client calcule sa réponse qu’il transmet à l’authentificateur. Cette réponse permettra à l’authentificateur soit d’authentifier le client soit de démasquer un usurpateur d’identité.

L’architecture d’authentification est composée d’un point d’accès, d’un authentificateur et d’un serveur d’authentification. Dans le cas des réseaux de mobiles, l’authentificateur et le serveur d’authentification sont deux entités distinctes : le serveur d’authentification correspond à l’entité HSS pour les réseaux de mobiles 4G ou à l’entité UDM pour les réseaux de mobiles 5G. Le serveur d’authentification (HSS/UDM) est situé en back-end de l’authentificateur. La fonction d’authentificateur est gérée par l’entité MME en 4G ou par la fonction AMF en 5G.

Les étapes d’authentification sont les suivantes :

  • L’authentificateur reçoit une demande d’identification de la part d’un client comprenant l’identité du client. Cette requête peut être initiée par le client ou par l’authentificateur. A partir de cette demande d’identification, l’authentificateur transmet un défi au client ;
  • Le client calcule la réponse au défi et transmet la réponse à l’authentificateur ;
  • L’authentificateur contrôle la réponse en comparant la réponse du client à la réponse attendue.

L’authentificateur interroge le serveur d’authentification en lui fournissant l’identité du client. Le serveur d’authentification vérifie l’existence de l’identité du client, et le cas échéant génère un défi. Le client peut supporter plusieurs méthodes d’authentification. Le défi est choisi selon la méthode d’authentification supportée par le client. Le défi et la réponse sont transmises à l’authentificateur.

Pour les réseaux de mobiles, le client est la carte UICC et les méthodes d’authentifications sont définies dans l’application USIM (et dans l’application ISIM pour l’authentification avec le réseau IMS).

La carte UICC contient une identité IMSI unique et une clé d’authentification Ki. Ces deux informations sont stockées au niveau du serveur d’authentification.