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 faite 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 pouvoir 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. Quel 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é, 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 (cf. )
    2. La mise en sécurité de l’interface NAS (cf.)
    3. La mise en sécurité de l’interface AS (cf.)
  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 (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 bearer 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)

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

5G – DSS – Partie 1

1. Introduction

Le déploiement de la 5G actuellement en cours par les opérateurs s’effectue soit sur la nouvelle bande de 3,5 GHz, soit sur une bande 4G à 700 MHz ou 2100 MHz. Seule l’exploitation de la nouvelle bande à 3,5 GHZ permet d’augmenter les débits de transmission. L’utilisation de la bande à 700 MHz ou 2100 MHz permet d’émettre un signal 5G en exploitant une partie de la bande 4G. Ainsi le débit obtenu en 5G s’obtient en réduisant en contrepartie le débit 4G (dans un ordre de grandeur assez proche).

Dans ce cas de déploiement de la 5G sur une bande actuellement utilisée par la 4G, il ne s’agit pas de refarming car on ne ré-affecte pas le spectre 4G pour la 5G mais la station de base procède à la gestion dynamique de spectre.

Figure 1 : La différence entre re-farming et DSS [1]

Le re-farming n’est pas possible car d’une part dans le fonctionnement de la 5G-NSA il est nécessaire de conserver la connexion radioélectrique 4G mais en plus, le nombre d’utilisateurs 4G est trop élevé pour basculer une partie du spectre 4G vers la 5G. Il faut ainsi attendre plusieurs années avant d’envisager du re-farming (cet argument est valable quelle que soit la technologie).

Figure 2 : Le déploiement de la 5G et les bandes allouées

Les opérateurs déploient donc une autre technologie, nommée DSS (Dynamic Spectrum Sharing) qui consiste à partager en temps réel les allocations de ressources radioélectriques entre une allocation 4G-LTE et une allocation 5G-NR sans impacter les utilisateurs 4G, c’est-à-dire en permettant aux terminaux 4G de pouvoir toujours exploiter la bande de fréquence LTE.

La technologie DSS est possible car la 5G se repose sur le LTE (beaucoup de similitudes : OFDM avec un espacement entre sous-porteuses identiques ou multiples de 2, précodage identique, modulation identique, …) toutefois cela impose le respect des contraintes suivantes :

  • pas d’interférence sur les signaux de références 4G : CRS et CSI-RS ;
  • pas d’interférence sur le canal de contrôle 4G-PDCCH ;
  • séparation des signaux de synchronisation PSS/SSS en 4G et du signal de synchronisation SSB en 5G. L’un et l’autre doivent être transmis sans interférence.

L’allocation des ressources 4G-LTE est gérée toute les 1 ms, les informations de contrôles 4G-PDCCH sont allouées sur toute la bande et l’allocation des signaux de références CRS et CSI-RS est assignée par un paramétrage statique qui dépend du nombre de port d’antennes supporté par la station de base 4G eNB.

Les signaux de références CRS sont transmis sur chaque bloc de ressources (12 sous porteuses) à raison de (figure 2) :

  • 4 éléments de ressources (RE) sur un slot (0,5 ms en 4G) pour une antenne ;
  • 8 RE sur un slot (0,5 ms en 4G) pour deux antennes ;
  • 12 RE sur un slot pour quatre antennes.

Pour plus d’information, se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2021/02/18/cours-2-niveau-master-chap-1-part-3/

Figure 3 : La position des éléments de ressources 4G-CRS

Les signaux de références 4G-CRS permettent au mobile de mesurer le niveau de puissance de chaque cellule (serveuse et voisines) et d’en déduire ainsi la qualité du lien radioélectrique (RSRP, RSRQ). Pour ne pas fausser les mesures, il est proscrit de transmettre des données sur le même élément de ressource (allocation dans le domaine fréquentiel – sous porteuse – et temporel –symbole-) qu’un signal de référence. La configuration des signaux de références CRS dépendent du numéro PCI (Physical Cell Identifier) de la cellule et du nombre de ports d’antennes (permettant de faire du MIMO). L’ingénierie radioélectrique va s’assurer que les stations de base voisine (PCI) respectent cette contrainte.

Les signaux de référence 4G-CRS utilise 4,76% des ressources 4G-LTE pour un seul port d’antenne et atteint 14,29% de ressources LTE pour 4 ports d’antennes. Au-delà de 4 antennes, le signal de référence émis est le CSI-RS qui nécessite moins de ressources.

Le canal de contrôle PDCCH est transmis sur toute la bande 4G-LTE dans le domaine fréquentiel et sur un, deux ou trois symboles dans le domaine temporel. Le nombre de symboles du canal PDCCH est défini par la station de base eNB en fonction du trafic. Le mobile prend connaissance du nombre de symboles de la zone du canal de contrôle PDCCH à partir de l’information portée par le canal PCFICH (figure 4).

L’allocation des ressources pour la 5G-NR est plus flexible, les informations de contrôle 5G-PDCCH sont transmises dans des bloc CORESET (COntrol REsource SET). Toutefois, les signaux de référence 5G-NR ne doivent pas non plus être interférés par la transmission 4G.

Figure 4 : L’allocation des canaux sur le réseau LTE

Enfin, les signaux de synchronisation 4G PSS/SSS sont transmis avec une périodicité de 5 ms en milieu de bande et le canal de diffusion 4G PBCH est transmis en milieu de bande toutes les 10 ms.

Pour qu’un terminal mobile 4G ne soit pas perturbé par la méthode DSS, il faut obligatoirement respecter les contraintes précédentes : le partage de la bande radioélectrique 4G/5G ne peut se faire simultanément et sur les mêmes fréquences que les signaux 4G : CRS, PSS, SSS, PBCH et PDCCH.

La méthode DSS permet donc d’utiliser des éléments de ressources 4G-LTE sans interférer avec les canaux de contrôles et les signaux de références 4G pour transmettre un signal 5G sur les ressources non-utilisées. Toutefois, les ressources 4G non-exploitées doivent permettre la transmission des canaux de contrôle, du bloc de synchronisation 5G-SSB et des signaux de référence 5G.

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

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

A l’instar de la 4G, l’interface radioélectrique 5G-NR utilise la modulation OFDM puisque celle-ci se révèle être la plus efficace dans le cas des transmissions multi-trajets (propagation en champs libre).

La modulation OFDM est une modulation multi-porteuses orthogonales, elle transmet un bloc de données binaires sur un grand nombre de porteuses en même temps. On définit ainsi le domaine fréquentiel de la transmission 5G par la largeur de sa bande de fréquence, c’est-à-dire par le nombre de sous-porteuses utilisées multiplié par l’espacement entre sous-porteuses.

L’orthogonalité se traduit par la durée de la transmission d’un symbole qui est inversement proportionnelle à l’espacement entre sous-porteuses. Ainsi, si les sous-porteuses sont espacées de 15 kHz, la durée de la transmission d’un symbole est de 66,67 µs (1/15 kHz).

Figure 1 : La transmission OFDM

Le bloc de données à transmettre est une suite binaire. La modulation OFDM permet de faire une modulation M-QAM sur chacune des porteuses.

A titre d’exemple, pour une modulation 64-QAM, 6 bits sont modulés par sous-porteuse. Les 6 bits forment un symbole.

Une station de base 5G peut moduler au plus 3300 sous-porteuses. Si les sous-porteuses sont espacées de 30 kHz alors la largeur de bande 5G est de 99 MHz et la durée d’un symbole est de 33,33 µs.

Ainsi, si la station de base transmet le bloc de données sur 3300 sous-porteuses simultanément, alors dans le cas d’une modulation 64-QAM, la station de base gNB pourrait potentiellement transmettre 3300*6 = 19 800 bits pendant la durée d’un symbole de 33,33 µs.

Si le bloc de données à transmettre est supérieur à 19 800 bits, alors la station de base va émettre les bits restants sur le(s) symbole(s) suivant(s) (33,33 µs suivante).

La modulation OFDM est donc une modulation qui exploite le domaine fréquentiel (nombre de sous-porteuses) et le domaine temporelle (durée d’un symbole).

Pour la 5G, on définit :

  • dans le domaine fréquentiel, un bloc de ressource RB (Resource Bloc) qui correspond à 12 sous-porteuses contiguës ;
  • dans le domaine temporel, un slot correspond à 14 symboles consécutifs.

Afin d’organiser la transmission de données, et synchroniser les récepteurs, les transmissions en liaison descendante et montante sont organisées en trames d’une durée de 10 ms, chacune est découpée en dix sous-trames de 1 ms. Chaque trame est divisée en deux demi-trames de taille égale à cinq sous-trames :

  • la demi-trame 0 est composée des sous-trames 0 à 4 ;
  • la demi-trame 1 est composée des sous-trames 5 à 9.

Pour l’interface LTE, la sous-trame est composée de deux intervalles de temps (slot). Attention, la notion de slot en 4G est différente de la notion de slot en 5G : un slot LTE correspond à 7 symboles OFDM consécutifs (trame normale) de durée 0,5 ms. La valeur de l’intervalle de temps de transmission 4G-TTI (Transmission Time Interval) correspond à la durée de la sous-trame et a une valeur fixe égale à 1 ms car l’espacement entre sous-porteuse est de 15 kHz.

Pour l’interface NR, le slot est composé de 14 symboles OFDM consécutifs (trame normale).  La valeur de l’intervalle de temps de transmission 5G-TTI correspond à la durée d’un slot. La valeur 5G-TTI dépend de l’espacement entre les sous-porteuses (tableau 1).

Tableau 1 : La structure de la trame temporelle

L’espacement entre sous-porteuses SCS (SubCarrier Spacing) est défini par la formulation suivante :

SCS=2µ*15 kHz, avec µ la numérologie.

Si µ=0, l’espacement est de 15 kHz, si µ=1 l’espacement est de 30 kHz, … Dans la suite, on parlera de numérologie.

1) La grille de ressources

 

Figure 2 : La grille de ressources

Un élément de ressource RE (Resource Element) constitue la plus petite unité pouvant être attribuée à un signal de référence (figure 1). L’élément de ressource RE correspond à un symbole OFDM dans le domaine temporel, et à une sous-porteuse dans le domaine fréquentiel. Il est ainsi repéré par la paire (k,l), k représentant l’indice de la sous-porteuse et l, l’indice du symbole OFDM dans le domaine temporel par rapport à un point de référence relatif.

Le bloc de ressource RB (Resource Block) correspond à une allocation de N=12 sous-porteuses contiguës (figure 1). A la différence de la 4G, le bloc de ressource RB 5G correspond à une allocation fréquentielle.

La grille de ressources est une allocation de ressources tempo-fréquentielles correspondant aux ressources d’un port d’antenne. Elle est constituée d’un ensemble de symboles par sous-trame (cf. tableau 2) dans l’espace temporel et d’un ensemble de sous-porteuses contiguës dans le domaine fréquentiel. La grille de ressources est composée d’au plus 3300 sous-porteuses et elle est transmise sur chaque sens de transmission et sur chaque port d’antenne.

Table 2 : Numérologie et nombre de symboles par sous-trame

Pour mieux comprendre la table 2, nous allons présenter la numérologie dans le domaine temporel sur la figure 3.

Figure 3 : La trame temporelle 5G-NR

Une trame 5G est définie par une durée de 10 ms. La trame 5G est découpée en 10 sous-trames d’une ms. Chaque sous-trame est composé de slots. Le nombre de slot par sous-trame dépend de l’espacement entre sous-porteuses (table 2 : numérologie).

 

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

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

L’objectif de cet article est de comprendre l’évolution du cœur de réseau mobile entre l’architecture 4G monolithique et l’architecture 5G basée sur les services.

La nouvelle architecture 5G a été pensée pour pouvoir ajouter des briques logicielles innovantes et une mise sur marché rapide de ces nouvelles fonctionnalités. Ainsi, à l’instar des solutions proposées par Amazon ou Windows Azur, le réseau 5G s’appuie sur les solutions Cloud et la méthodologie DevOps.

Au cours de cet article, nous allons décrire le cœur de réseau 4G, puis les architectures SOA (Service Oriented Architecture) et microservice pour décrire et comprendre l’architecture SBA (Services Based Architecture) du réseau 5G.

Je remercie Mickael BARON [2] d’avoir pris le temps de relire l’article, le corriger et d’avoir contribué aux améliorations de cet article.

  1. L’architecture du réseau 4G

Le cœur de réseau de mobiles 4G (cf. figure 1) est construit à partir des entités fonctionnelles suivantes :

  • l’entité MME (Mobility Management Entity) a pour rôle de gérer :
    • l’attachement des mobile ;
    • le suivi de la mobilité ;
    • l’établissement de sessions IP prenant en compte la politique de taxation de l’usager ;
    • l’établissement d’un appel voix.
  • l’entité SGW (Serving Gateway) est le point d’ancrage des flux de sessions IP. Le SGW gère l’établissement d’un bearer (un bearer est un tunnel IP de bout en bout associée à une qualité de service QoS). Le bearer s’établit du mobile jusqu’à l’entité PGW. Le SGW mesure le trafic consommé par utilisateur et, en cas de demande judiciaire, dérive le trafic (cas d’interception légale).
  • l’entité PGW (PDN Gateway) est la passerelle de routage entre le réseau opérateur et un réseau IP (PDN : Packet Data Network). L’entité PGW réalise l’inspection de trafic, met en place les bearer avec le SGW, est en charge de fournir une adresse IP au mobile pour chaque bearer, mesure le trafic consommé et, en cas de demande, dérive le trafic dans le cas d’interception légale.
  • l’entité PCRF (Policy Charging Rule Function) gère la mise en œuvre de la QoS pour les bearer dédiés et la gestion dynamique de la facturation.

Figure 1 : Le réseau 4G, les bases de données et l’échange d’information

Chaque entité fonctionnelle contient un ensemble de lignes de codes pour pouvoir apporter les fonctionnalités attendues. On parle de bloc monolithique : le langage de programmation choisi pour chaque entité fonctionnelle dépend de l’équipementier. La mise à jour d’une entité nécessite la recompilation de l’ensemble du programme (toutes les lignes de code), ce qui met à jour toutes les fonctions. L’équipementier doit s’assurer que la modification d’une fonction n’ait aucun impact sur le reste du programme.

Chaque entité fonctionnelle contient une base de données importante (une table avec des millions d’entrées). A titre d’exemple, la figure 1 représente en couleur bleue une partie du contexte sauvegardé dans la base de données des entités pour un mobile. Les entités fonctionnelles partagent leurs données aux autres entités dans des appels à fonction. La technologie utilisée pour la base de données est propre à l’équipementier (mariadb, PostgreSQL, …). Ainsi, deux entités MME provenant de deux équipementiers différents (Nokia/Ericsson par exemple) peuvent utiliser des bases de données différentes et un langage de programmation différent. Mais les échanges entre entités sont normalisés.

Enfin, une ou plusieurs entités fonctionnelles peuvent être intégrées dans une seule entité matérielle. A titre d’exemple, le SGW et le PGW peuvent former l’entité S/PGW. L’entité matérielle est dite monolithe.

Définition : en génie logiciel, un modèle monolithique fait référence à une seule unité indivisible.

Par dérivation, le concept de logiciel monolithique réside dans la combinaison de différents composants d’une application en un seul programme sur une seule plateforme. Habituellement, une application monolithique se compose d’une base de données, d’une interface utilisateur côté client et d’une application côté serveur. Toutes les parties du logiciel sont unifiées et toutes ses fonctions sont gérées en un seul endroit.

Comme le montre la figure 1, dans l’architecture 4G, les entités sont connectées les unes aux autres, par une connexion point à point. Cette connexion est nécessaire afin d’échanger des données.

L’architecture 4G est une architecture composée d’entité monolithe modulaire autonome : chaque entité est responsable d’un ensemble de fonctions et fournit aux autres entités les données nécessaires à l’exécution d’un service.

Par exemple :

  • l’identification, l’authentification et les droits d’accès du mobile sont gérées par l’entité HSS : l’entité MME interroge l’entité HSS pour pouvoir identifier le mobile en lui transmettant l’identité IMSI du mobile. Le HSS transmet à l’entité MME les données d’authentification. L’entité MME va ensuite réaliser la procédure d’authentification avec le mobile ;
  • lorsque le mobile est en mode connecté, l’entité MME connait l’identité de la station de base (eCGI) sur laquelle le mobile échange des données. L’entité MME peut donc demander à l’entité SGW de mettre en place, pour ce mobile, un nouveau bearer (dédié) vers la station de base.

Les spécifications 3GPP standardisent les interfaces entre chaque entité fonctionnelle en définissant :

  • les applications au niveau des interfaces (par exemple GTP-C, S1-AP, DIAMETER) ;
  • les messages échangés entre chaque interface (cf. figure 1).

Dans le cas de l’architecture 4G, une fonction (une portion du code) est sollicitée par une autre entité : à titre d’exemple la fonction PCEF intégrée au niveau de l’entité PGW applique les règles fixées par l’entité PCRF. L’entité PCRF transmet une requête DIAMETER à l’entité PGW sur l’interface Gx. Chaque entité gérant des millions d’utilisateurs, il est nécessaire d’identifier le mobile concerné. Ainsi, chaque entité source soumet à l’entité cible les informations nécessaires (l’identité GUTI ou IMSI, le numéro de tunnel TEID, …comme le montre la figure 1). Les informations à transmettre sont normalisées.

Cette architecture monolithe modulaire facilite l’ajout de nouvelles entités fonctionnelle. Toutefois, puisque les entités communiquent les unes avec les autres selon les spécifications 3GPP, il est nécessaire de respecter les spécifications sur les interfaces. Malgré les efforts de spécifications, l’interprétation de la norme peut être perçue différemment par chaque équipementier.

Ainsi, lorsque l’opérateur ajoute une nouvelle entité, cela nécessite du temps pour vérifier l’intégration de cette nouvelle entité avec les autres entités existantes provenant de constructeurs différents.

En général, une fois la normalisation d’un réseau mobile gelé, l’architecture du réseau de mobiles n’évolue pas.  C’est le cas pour la 2G, puis la 3G. Cela aurait dû être le cas pour la 4G, mais l’arrivée de l’IoT a nécessité une évolution de l’architecture du réseau 4G par l’ajout d’une nouvelle entité. Ainsi, initialement la 3GPP a proposé l’ajout d’une entité MTC-IWF pour les cas d’usage du MTC (Machine Type Communication) et a spécifié l’interface DIAMETER entre l’entité fonctionnelle MTC-IWF et les autres entités.

Toutefois, prenant compte qu’il est plus simple de faire évoluer l’architecture du réseau 4G par l’ajout d’une fonction qui expose des services [1], la spécification 3GPP a proposé l’ajout d’une nouvelle entité matérielle. Ainsi, l’entité fonctionnelle MTC-IWF a été abandonnée au profit de la fonction SCEF : Service Capacité Exposure Function.

Pour résumer, chaque entité fonctionnelle de l’architecture 4G est connectée point à point avec les autres entités par une interface normalisée.

A travers cet interface, les entités offrent des services à une autre entité : le service est une action exécutée par un « fournisseur » (ou « producteur ») à l’intention d’un « client » (ou « consommateur »).

A l’instar du rôle des entités de la 4G, l’architecture SOA (Service Oriented Architecture) s’appuie sur deux éléments principaux : un fournisseur de services et un consommateur de services. Ces deux rôles peuvent être joués par un agent logiciel.

La différence importante entre une architecture 4G et l’architecture SOA concerne la mise en relation des fonctions. Nous allons maintenant nous intéresser aux architectures SOA et microservices facilitant le développement logiciel de nouvelles fonctions.

2. Evolution du réseau de mobile vers l’architecture SOA et l’architecture microservices

II-a) L’architecture SOA

Définition : une architecture orientée services (SOA) est une architecture logicielle qui fait référence à une application composée d’agents logiciels discrets et faiblement couplés qui exécutent une fonction requise. Le concept de SOA est le suivant : une application peut être conçue et construite de manière à ce que ses modules soient intégrés de manière transparente et puissent être facilement réutilisés.

Dans une architecture SOA, les fonctions sont connectées les unes aux autres par un médiateur nommé bus d’intégration ESB.

Le bus d’intégration ESB est un logiciel (middleware) facilitant l’échange de données entre différentes fonctions logicielles (application).

Le logiciel ESB est le point de connectivité pour toutes les applications, et il garantit la sécurisation des échanges.

Le logiciel ESB enregistre les services que fournit chaque application (appelée capacité de service) dans un registre. Les applications publient une ou plusieurs de leurs capacités via le bus ESB et les consommateurs peuvent interagir avec ces applications sans même savoir ce qu’est une application

Le bus ESB centralise les informations et répartit le travail entre les applications. Le bus ESB agit comme un pont de données entre les applications. Le routage des données et la répartition de charge sont assurées par l’application BPM (Business Process Management).

Le bus d’intégration ESB permet de fusionner (interconnecter) diverses applications, anciennes comme récentes, pouvant fonctionner sur des systèmes d’exploitation différents et pouvant utiliser des protocoles différents [2]. Le bus d’intégration s’appuie sur des connecteurs sur lesquelles sont connectées les applications. Les connecteurs garantissent l’interopérabilité entre les applications.

Chaque application fournit et consomme des services : les applications exposent des services à travers des interfaces de programmation d’application API (Application Programming Interface). La gestion des API est fondamentale, elle permet aux développeurs d’utiliser des services back-end pour la supervision et permet de garantir l’agilité du réseau (Agilité [3] : Capacité de changer les choses rapidement).

L’architecture SOA permet donc de réduire le temps de déploiement de nouveaux services.

II-b) L’architecture microservices

L’architecture en microservices consiste à concevoir un ensemble de services autonomes qui communiquent entre eux via une API. Les microservices communiquent via des protocoles HTTP (REST), ou via AMQP (Advanced Message Queuing Protocol) en asynchrone chaque fois que cela est possible, surtout pendant la propagation de mises à jour avec des événements d’intégration. Cette communication se produit par le biais d’un bus d’événements pour propager les mises à jour sur les microservices ou pour s’intégrer à des applications externes.

Un microservice [2] doit réaliser une seule fonctionnalité de l’application globale. En général, chaque microservice est déployé en tant que conteneur indépendant, ou dans une machine virtuelle.

Le concept de conteneur est le plus généralement adopté car il consomme peu de ressource (l’application n’a pas besoin d’un système d’exploitation complet) et il améliore la sécurité, puisque la containerisation permet d’exécuter un programme de manière isolée du noyau d’un système d’exploitation (kernel).

Cette architecture apporte :

  • de la souplesse puisqu’il est possible de développer ou modifier un microservice sans affecter les autres sous-systèmes : chaque microservice étant déployé indépendamment grâce aux solutions de virtualisation et de conteneur, une nouvelle évolution d’un seul service peut rapidement être testée et re-déployée ;
  • de l’élasticité puisqu’il est possible de dimensionner dynamiquement le réseau en fonction du nombre de sollicitation (montée en charge = scalabilité). En cas de trafic croissant, il suffit de multiplier le nombre d’instances d’un microservice.

Chaque microservice dispose si possible de sa propre base de données, ce qui le découple entièrement des autres microservices. Quand elle est nécessaire, la cohérence entre les bases de données des différents microservices est obtenue à travers l’utilisation d’événements d’intégration au niveau de l’application (via un bus d’événements logiques)

A l’instar d’un bus d’intégration, l’architecture microservice utilise un bus d’évènement et un logiciel d’équilibrage de charge (load balancer) afin de mettre en relation des services.

Un bus d’événements est un logiciel (middleware) qui permet une communication de type publication/abonnement entre les microservices, sans nécessiter que les composants soient explicitement informés de la présence des uns des autres.

Figure 2 : Bus d’évènement

Lorsque le microservice publie un évènement, il ne sait pas que cet évènement sera diffusé vers les microservices B et C. Il ne connait pas les abonnés, ceux-ci se sont enregistrés auprès du bus d’évènement MOM (Message Oriented Middleware comme par exemple RabbitMQ).

Si le microservice est stateless, une même requête produit toujours la même réponse. Ainsi, le bus d’évènement met en relation les deux services qui doivent communiquer directement l’un à l’autre. Lorsque plusieurs instances sont activées, l’équilibrage de charge définit quelles instances doivent être sollicitées. L’architecture microservice est donc bien adapté pour dimensionner le système en fonction de la charge.

En contrepartie, cette architecture peut entraîner des soucis de performance puisque chaque microservice peut faire appel à plusieurs microservices. Ainsi, le temps de réponse du plan de contrôle (ce qui revient à la latence) est accru pour chaque dépendance supplémentaire entre microservices.

II-c) Microservices : les bonnes pratiques du SOA

L’architecture SOA est composée d’applications logicielles réutilisables. Les services sont exposés via des API. L’interface, c’est-à-dire le couplage entre applications est faible ce qui permet d’appeler ces services avec peu de connaissance sur la manière dont les services sont implémentés. Cela permet de réutiliser rapidement des services.

A l’instar du SOA, l’architecture microservice est conçu sur un ensemble de fonctions faiblement couplés.

3. Architecture des réseaux de mobile 5G

III-1) Architecture SBA

Les fonctions du cœur de réseau 5G sont très proches des fonctionnalités du cœur de réseau 4G. L’évolution Next-Gen (NG Core) consiste à séparer le plan de contrôle du plan de trafic. Concernant le trafic, pour le réseau 5G comme pour le réseau 4G, les données IP sont encapsulées par le protocole GTP-U à travers un tunnel. Le protocole GTP-U est utilisé entre la station de base gNB et les fonctions UPF (User Plane Function).

L’architecture du plan de contrôle du réseau de mobiles 5G est une architecture hybride entre des applications Cloud Native, et la virtualisation.

Sur la figure 3, on présente à gauche l’architecture monolithique traditionnelle, et deux solutions complémentaires : la virtualisation des fonctions réseaux (NFV : Network Function Virtualization) et la méthodologie Cloud Native.

Figure 3 : L’architecture monolithique, l’architecture de virtualisation VNF et l’architecture Cloud CNF

Une application Cloud Native (CNA) est développée sous forme de microservices faiblement couplés. Chaque microservice est conditionné dans un conteneur. Un orchestrateur central planifie les conteneurs pour gérer efficacement les ressources du serveur et réduire coûts opérationnels. Les CNA nécessitent également un environnement DevOps.

DevOps fait référence à une méthodologie qui prend en compte le développement logiciel avec les contraintes d’administration des infrastructures informatiques. La partie développement (Dev) intègre le développement logiciel, l’automatisation et le suivi du projet informatique et la partie opérationnelle (ops) intègre l’exploitation, la maintenance et la supervision de l’infrastructure informatique. L’équipe opérationnelle (ops) gère la stabilité du système et le contrôle de la qualité des services, et l’équipe développement (Dev) cherche à améliorer les services à moindre coût en ajoutant de nouvelles fonctionnalités. L’équipe ops doit donc constamment valider les évolutions proposées par l’équipe dev.

La méthodologie DevOps permet d’obtenir les avantages suivant pour les applications Cloud Native :

  • une évolutivité facilitée par une architecture modulaires (microservice) ;
  • la réduction du CAPEX et de l’OPEX par mutualisation des applications (hébergement sur des machines virtuelles ou conteneurs) ;
  • l’automatisation des fonctions applicatives.

La solution alternative NFV (Network Function Virtualization) a été initialement proposée et adaptée au cœur de réseau 5G par le groupe de travail de l’ETSI. L’architecture NFV décrit les interactions entre l’infrastructure matérielle (NFVI), la gestion des machine virtuelles (VNFM : Virtual Network Function Manager) et l’automatisation des VM sur les infrastructures matérielles.

La spécification NFV a permis de définir un environnement stable pour la mise en place automatisée de machines virtuelles et de conteneurs, chaque VM ou conteneur exécutant une fonction du réseau 5G (NFV : Network Function Virtualized).

L’architecture SBA du cœur du réseau de contrôle 5G est une solution hybride SOA/microservices.

Figure 4: L’architecture SBA du réseau 5G [9]

La mise en place des fonctions réseaux, la supervision (monitoring) nécessite un orchestrateur afin d’automatiser le déploiement des services (établissement ou relâchement d’un service ou d’un microservice). Une plateforme de service permet de fournir un environnement temps-réel qui utilise une pile de protocoles open-source pour le déploiement de fonction réseaux NF.

La plateforme de service permet l’intégration et le déploiement de nouvelles fonctions sur un réseau en production :

  • CI : l’intégration continue de nouvelles fonctionnalités (CI – Continuous Integration) ;
  • CD : le déploiement continue ou la distribution continue permettant d’automatiser l’ajout d’un nouveau code dans une bibliothèque de code partagé et dans un environnement de production (CD – Continuous delivery/continuous deployment), et résoudre ainsi la difficulté connue sous le nom « integration hell», ou l’enfer de l’intégration.

L’approche CI/CD permet de créer de créer plusieurs versions d’une application, chaque version étant gérées par un serveur de distribution (un serveur référentiel comme github) et de développer l’environnement client afin de tester rapidement la nouvelle version.

Une fois testée en laboratoire, il est assez rapide de rajouter une nouvelle fonction réseau NF (avec la nouvelle version) tout en conservant en parallèle l’ancienne version de la fonction. Le client peut ainsi tester sur son environnement réel la nouvelle version et la conserver en production.

Figure 5 : L’approche CI/CD [9]

L’environnement complet est représenté sur la figure 6 suivante

Figure 6 : L’environnement de production du cœur de réseau 5G [8]

L’approche CI/CD est parfaitement adaptée pour la mise en place du découpage de réseau (Network Slicing) puisqu’elle permet de déployer des nouvelles fonctionnalités rapidement en fonction des spécificités de chaque service.

Figure 7 : L’architecture SBA [10]

MOLI : Management and Orchestration Layer Interface

SOBI : Southbound Interface (SoBI)

III-2) Les fonctions réseau NF (Network Function)

Les fonctions réseau NF se compose d’opérations basées sur un modèle de demande-réponse ou sur un modèle de souscription/notification.

Le protocole HTTP2 est un protocole commun à l’ensemble des fonctions du réseau (NF) remplaçant ainsi les protocoles DIAMETER, GTP-C du réseau de mobiles 4G. Les fonctions réseaux NF communiquent à travers l’interface SBI grâce à un système d’API, principalement le JSON.

Figure 8 : L’interface SBI entre deux fonctions NF

Dans l’architecture SOA, un bus d’intégration permet la communication entre chaque fonction NF. Lorsqu’une fonction NF démarre, elle interroge dans un premier temps un catalogue de fonction pour découvrir les fonctions existantes et communiquer avec elles. Nous avons vu précédemment que le bus ESB enregistre les services que fournit chaque application (appelée capacité de service) dans un registre.

Dans l’architecture réseau 5G, le catalogue de fonction se nomme NRF (Network Repository function). Il offre un service de découverte des fonctions du réseau de mobile et un service d’enregistrement (service registration management et service discovery mechanisms).

La fonction NRF:

  • implémente une fonction d’authentification via une règle de sécurité d’accès sur chaque requête de services reçue
  • délivre un certificat à la fonction NF qui l’interroge. La fonction NF initiatrice d’une requête pourra ainsi prouver son authenticité à la fonction NF cible (qui rend le service).

Figure 9 : L’interface SBI et la communication JSON

Dans le cas de l’architecture SOA, les événements d’intégration sont utilisés pour synchroniser l’état du domaine sur plusieurs fonctions (microservices ou systèmes externes). Cette fonctionnalité est effectuée en publiant des événements d’intégration.

La fonction NF peut se décomposer en plusieurs microservices, notamment un agent_NRF permettant à la fonction NF de se déclarer auprès du NRF. Ainsi, en cas d’évolution de la fonction du NF, l’agent_NRF peut mettre à jour les fonctionnalités au niveau du NRF.

Lorsqu’un événement est publié sur plusieurs microservices récepteurs (sur tous les microservices abonnés à l’événement d’intégration), le gestionnaire d’événements de chaque microservice récepteur gère l’événement.

Figure 10 : Le NF découpé en microservice (Source China Telecom [11])

Dans l’architecture microservices, chaque microservice dispose de sa propre base de données. Pour l’architecture SBA du réseau 5G, la fonction réseau NF (microservice) dispose soit de sa propre base de données UDSF (Unstructured Data Storage Function) soit partage la base de données UDSF avec plusieurs NF.

Comme en 4G, la base de données UDSF contient le contexte de chaque mobile UE (User Equipment).

Figure 11 : La base de données

   4. Conclusion

Si le cœur de réseau 5G présente beaucoup d’analogie fonctionnelle avec le cœur de réseau 4G, l’évolution majeure consiste en un découpage de fonction réseau NF dans un environnement agile permettant de déployer et adapter dynamiquement le cœur de réseau en fonction de la charge et d’apporter rapidement de nouvelles fonctionnalités.

La méthodologie DevOps et l’approche CD/CI permet la mise à jour de certains microservices tout en conservant des microservices de versions plus anciennes pour assurer la stabilité avec des terminaux non compatibles avec cette mise à jour.

Ainsi en maintenant des microservices en fonction (version 1.0) tout en proposant des microservices dans une nouvelle version (version 1.1) cela permet à certains téléphones de profiter des dernières évolutions sans impacter certains terminaux mobiles qui peuvent continuer à fonctionner sur les anciennes versions.

Figure 12 : Le cœur de réseau 5G [7]

L’architecture SBA permet donc une meilleure adaptation aux évolutions de service (Network Slicing).

Figure 13 : Comparaison de l’architecture monolithique et SBA (HPE [12])

La figure 14 fait une synthèse des améliorations ainsi apportées par l’architecture SBA

Figure 14 : Comparaison des architectures [4]

 

Références :

[1] Andrea Zerial

https://www.organisation-performante.com/le-monolithe-dans-l-it-pour-en-comprendre-l-origine/

https://www.organisation-performante.com/les-evolutions-du-si-2-soa-et-le-monolithe-seffrita/

[2] Mickael BARON :  https://mickael-baron.fr/soa/introduction-microservices

[3] Thimothée Barray : https://slides.com/tyx/sflive2020-bb8c28

[4] Michael Sukachev : https://fr.slideshare.net/MichaelSukachev/soa-vs-microservices-vs-sba

[5] Jonathan Huteau, Jérôme Cognet,

https://blog.link-value.fr/architectures-de-projet-b42dc5213857

[6] https://www.ibm.com/cloud/blog/soa-vs-microservices

[7] https://docs.microsoft.com/fr-fr/dotnet/architecture/microservices/multi-container-microservice-net-applications/integration-event-based-microservice-communications

[8] https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/cloud-native-5g-core/Cloud-Native-5G-Core-Samsung-5G-Core-Volume-2.pdf

[9] https://www.redhat.com/fr/topics/devops/what-is-ci-cd

[10] https://5g-monarch.eu/wp-content/uploads/2019/05/5G-MoNArch_761445_D2.3_Final_overall_architecture_v1.0.pdf

[11] https://www.3g4g.co.uk/5G/5Gtech_6004_2017_11_Service-Based-Architecture-for-5G-Core-Networks_HR_Huawei.pdf

[12] http://www.hpe.com/info/5g

 

 

Cours 3 – Niveau Master – Chap 2 (Part 1)

L’agrégation de porteuses sur les bandes licenciées et non licenciées

3.1. Principe d’agrégation de porteuses pour le LTE-Advanced

En théorie de l’information, le débit maximum de transmission à travers un canal de communication dépend de la bande de fréquence B utilisée et du rapport signal sur bruit (SNR : Signal Noise Ratio). Le théorème de Shannon-Hartley donne une limite maximale C pour bruit gaussien :

C=B.log2(1+SNR)

(la démonstration mathématique à partir de la théorie du signal se trouve facilement sur Internet)

La bande de fréquence B utilisée par le LTE est au plus égale à 20 MHz. L’agrégation de porteuses (Carrier Aggregation ou CA) permet d’atteindre des débits de transmission beaucoup plus rapides en augmentant la bande de fréquence.

L’agrégation de porteuse est une fonctionnalité qui est apparue avec le LTE-Advanced (LTE-A R.10), pour le mode duplex FDD ou TDD (Frequency Division Duplex, Time Division Duplex).

Avant la R.10, les terminaux de catégorie 1 à 5 étaient mono-porteuse sur une bande comprise entre 1.4 MHz et 20 MHz. Les premiers tests d’agrégation de porteuses ont été réalisés sur des terminaux de catégorie 4 et sur deux bandes de 10 MHz. Les terminaux de catégorie 6 sont disponibles depuis 2014, et permettent d’atteindre des débits de 300 Mbps (en DownLink DL) en supportant deux bandes de 20 MHz. Les terminaux de catégories 9 disponibles à la vente depuis 2015 supportent 3 bandes de 20 MHz, ce qui permet d’atteindre un débit de 450 Mbps. Les terminaux de catégories 4, 6 et 9 possèdent 2 antennes et supportent la modulation 64 QAM sur le lien descendant. Pour ces terminaux, une bande de 20 MHz correspond à un débit de 150 Mbps. En pratique, pour un opérateur qui disposerait un total de 45 MHz sur 3 bandes différentes pourrait proposer un débit maximal descendant de 337.5 Mbps avec ces catégories de terminaux.

On peut ainsi définir une première classification des catégories de terminaux en vente en 2017 en fonction du nombre de canaux de fréquences supportés :

Tableau 2.1. Catégories de terminaux définies dans la R.10 et R.11

Le LTE-Advanced étend l’agrégation de porteuses à 5 canaux, portant à 100 MHz la bande maximum. L’UE de catégorie 8 (également défini dans la R.10) supportera cette fonctionnalité.

Dans les R.10 et R.11, le nombre de porteuses pour le lien montant est inférieur ou égal au nombre de porteuses pour le lien descendant.

Dans la R.12, les UE peuvent réaliser de l’agrégation de porteuses en mode TDD et conjointement en mode FDD. La R.12 propose 80 combinaisons de deux porteuses et quelques combinaisons de trois porteuses.

La R.13 ajoute de nouvelles combinaisons de porteuses pour 2, 3, 4 et 5 porteuses et étend la combinaison avec les bandes WiFi. La R.13 a normalisé 492 combinaisons de porteuses pour l’agrégation de deux bandes, 248 combinaisons sur 3 bandes, 56 combinaisons pour 4 bandes et 2 combinaisons pour 5 bandes.

3.2. Mécanisme d’agrégation de porteuses

Le principe consiste à augmenter la bande utilisée par le mobile pour accroitre son débit, on nomme Component Carrier (CC) chaque bande agrégée. L’UE est connecté avec un seul eNb, l’eNb dispose de plusieurs bandes de fréquences contiguës ou disjointes.

Après avoir décrit les fonctionnalités de l’Agrégation de porteuses, nous allons maintenant étudier son mécanisme.

En mode de veille, l’UE écoute les informations émises par l’eNb (canal balise, paging) sur la bande de fréquence spécifique à la cellule. Si l’UE doit émettre ou recevoir des données, il doit passer en mode connecté (RRC Connected). L’UE pouvant exploiter plusieurs bandes de fréquences, on différencie la PCC (Primary Component Carrier) correspondant à la bande sur laquelle l’UE échange la signalisation NAS et les données avec l’eNb (PCell : Primary Cell) et le(s) SCC (Secondary Component Carrier) les bandes sur lesquelles l’UE échangent les données avec les autres cellules (SCell : Secondary Cell). Les paramètres de la cellule primaire et des cellules secondaires sont configurés au niveau RRC. Ainsi, la PCC est modifiée uniquement par une procédure de Handover et les SCC peuvent être dynamiquement activées et désactivées par des nouvelles requêtes RRC. Dans le cadre du CA, l’UE ne dispose que d’une seule connexion RRC avec l’eNb.

Figure 3.1. Impact de l’agrégation de porteuses sur l’interface radio

Toutes les SCC sont considérées comme des ressources de transmission additionnelles. Les couches Physique et la couche MAC sont les deux couches impactées par la CA (Figure 2.1), avec de nouvelles requêtes RRC :

  • La couche Physique réalise la transmission d’un bloc de transport (TB), la retransmission rapide des paquets erronés via le mécanisme HARQ est réalisée sur chaque CC.
  • L’allocation de ressources est réalisée sur le canal PDCCH. Dans le cas de l’agrégation de porteuses, soit le PDCCH de chaque cellule assigne les ressources pour sa cellule (self scheduling), soit un seul PDCCH assigne les ressources pour toutes les cellules (PCell et SCell). Ce scénario se nomme Cross Carrier Scheduling.

Figure 3.2. Séquencement avec et sans cross scheduling

La couche MAC multiplexe les données issues de la couche PDCP et RLC sur les différentes porteuses.

La signalisation relative à l’agrégation de porteuses est donc transparente pour le protocole de convergence des paquets de données (PDCP) et pour la couche de contrôle des liaisons radio (RLC).

L’UE doit en retour émettre un acquittement pour chaque HARQ. Dans la R.10, le lien étant asymétrique, l’UE doit pouvoir, sur le canal montant, transmettre les acquittements (ACK/NACK) de chaque HARQ ainsi que des mesures du lien radio (CQI, PMI, RI). Le PUCCH de format 3 permet de compiler les informations.

Concernant le lien montant, l’UE doit émettre ses données avec un temps d’avance (TA Timing Advanced) afin de compenser la durée du trajet de l’onde Radio et assurer ainsi une synchronisation avec la trame en réception de l’eNb. Lorsque l’UE réalise de l’agrégation de porteuse, les antennes de réception (RRH) peuvent être déportées (se référer au chapitre 1), et le temps de trajet n’est donc pas identique sur chacune des porteuses. Si la R.10 ne gère le TA que pour la Pcell, la R.11 permet d’appliquer des TA différents selon la bande de fréquence.

Cours 2 – Niveau Master (Chap 1 – Part 3)

Les Modes de transmission

2.3 LTE et MIMO

2.3.1 Chaîne de transmission dans le sens descendant.

La couche physique du LTE se décompose en sous-bloc afin de répartir les flux d’informations issues de la couche MAC en bloc de transport jusqu’au mappage OFDM transmis sur chaque antenne.

Le synoptique de la chaine de transmission est décrite à la figure 2.10.

Figure 2.10. Chaîne de transmission MIMO

Afin de détailler le rôle de la chaîne, nous allons séparer l’étude en trois sous-parties :

  • Description de la chaîne entre les mots de code (codeword) aux couches spatiales
  • Description de la matrice de Précodage et association avec les modes de transmissions
  • Affectation aux ressources spectrales : Association du signal de référence au port d’antenne.

2.3.1.1 Chaîne de transmission du mot de code aux couches spatiales

A chaque TTI, la couche MAC délivre un ou deux bloc de transport (de taille TBS)

Un code CRC (cyclic redundancy check) de 24 bits est rajouté au transport bloc. L’objectif est de détecter une erreur de transmission. Le code CRC est le reste de la division euclidienne du transport block par le générateur  G exprimé par l’équation suivante.

La séquence binaire est ensuite segmentée en bloc de codage. Un CRC de 8, 16 ou 24 bits est rajouté à chaque bloc de codage avant d’être codé par un turbo-code ou un code convolutif. Le Turbo code utilise deux entrelaceurs dont la taille minimum est de 40 bits et la taille maximum est de 6144 bits (la norme propose 188 tailles différentes). Les codes bloc ont donc une taille comprise entre 40 bits et 6144 bits.

Le turbo code a un rendement de 1/3, le signal est ensuite poinçonné ou répété afin d’adapter la taille du flux de bits de sortie au débit désiré.

Le flux de bits ainsi obtenu se nomme codeword ou mot de code.

Figure 2.11. Couche Physique LTE

Le mot de code est ensuite embrouillé par une séquence pseudo-aléatoire de Gold (scrambling) et modulé suivant la modulation QAM définie par la couche MAC. La séquence de Gold est calculée en fonction de l’identité de la cellule, et avec l’identifiant RNTI de l’UE pour les canaux PDSCH, PUSCH et PUCCH. Ainsi, le récepteur peut séparer les mots de code provenant de cellules différentes dans le sens descendant et les mots de code provenant d’UE différent dans le sens montant et d’un même UE dans le cadre du MIMO.

Les mots de blocs embrouillés et modulé sont issus de la segmentation du bloc de transport ou des blocs de transport et constituent les sources d’entrées du bloc MIMO. On numérote par 0 et 1 les mots de code issus des blocs de transport.

En R.8, dans le sens descendant, les mots de code peuvent être transmis sur 1, 2 ou 4 antennes physiques. Dans le cas d’un retour d’information, l’eNb utilise l’information du rang de la matrice de propagation (RI) pour définir le nombre de couches spatiales utilisable par l’UE. Le nombre de couches spatiales est inférieur ou égale au RI. Le bloc Layer Mapper a pour objectif d’associer le ou les mots de codes au nombre de couches spatiales. Le nombre de couche spatiale est donc de 1, 2 ou 4 pour la R.8 et jusqu’à 8 antennes à partir de la R.10.

Figure 2.11. Layer Mapper

La figure 2.7 est un exemple de mise en correspondance de deux codewords vers 4 couches spatiales. Cependant, les différentes combinaisons résumées dans la table 2.7 existent.

Table 2.7. Associations entre mots de code et couches spatiales pour le sens descendant

SM : Spatial Multiplexing et DT : Diversity Transmission

2.3.1.2 Les matrices de précodage et les modes de transmission en DL

Après avoir disposé les mots de codes sur les différentes couches spatiales, chaque couche spatiale est précodée par des coefficients complexes en fonction du mode de transmission (TM) et transmis vers des ports d’antennes. Nous reviendrons sur la notion de port d’antenne ultérieurement et sur l’association entre les ports d’antennes et les antennes physiques.

Le traitement du signal consiste à convertir L couches spatiales vers N ports d’antennes en multipliant les symboles d’entrées par des coefficients complexes (matrice de précodage de taille N x L).

Le précodage s’appuie sur une matrice extraite d’un livre de code (codebook). Le livre de code est connu par l’UE et l’eNb et dans le cas de l’estimation du CSI avec retour vers l’émetteur, l’UE informe l’eNb de la matrice de codage la plus adaptée parmi la liste définie dans le livre de code. L’UE renvoie le numéro de la ligne correspondant à la matrice et cette information est portée par le PMI.

Dans le sens descendant, 10 modes de transmission ont été définis :

  • TM1 à TM7 ont été définis dans la R.8.
  • TM8 a été défini dans la R.9
  • TM9 a été défini dans la R.10
  • TM10 a été défini dans la R.11
  • TM9 a évolué dans la R.13 pour gérer les UE dédiés aux objets connectés.

TM1 : Single Transmission antenna.

Dans le cas de la transmission SISO, une seule antenne est utilisée à l’émission et une seule en réception.

TM2 : Transmit Diversity

La diversité de transmission utilise :

  • pour deux antennes d’émission : le codage SFBC (Space Frequency Block Coding). Il s’agit du codage Alamouti exploité en fréquence et non en temps (ce qui le différencie du STBC). La figure 2.4 illustre le code Alamouti en temps, on retranscrit le code dans le domaine fréquentiel :

En écrivant :

Alors, on obtient :

La matrice de précodage est donc (cf. section 6.3.4.3 3GPP TS 36.211) :

  • Pour 4 antennes  d’émission : le codage FSTD (Frequency Switched Transmit Diversity) : 4 symboles sont découpés en 2 paires, chaque paire est transmise sur deux antennes comme le SFBC sur des RB différents (frequency switched). Chaque ligne de la matrice correspond un port d’antenne :

est le code en temporel. Lorsqu’on retranscrit en fréquentielle, on obtient :

Se référer à la section 6.3.4.3 3GPP TS 36.211

Les canaux PDSCH, PDCCH et PBCH utilisent la diversité de transmission.

TM 3 – Open loop spatial multiplexing with CDD (Cyclic Delay Diversity)

Le multiplexage spatial en boucle ouverte se base sur le choix d’une matrice de précodage au niveau de l’émetteur sans connaissance de l’estimation du canal. En général, ce mode est choisi lorsque l’UE se déplace rapidement (scénario de haute mobilité) et le temps de calcul de l’estimation du canal (PMI) est supérieur au temps de cohérence du canal. Le RI est néanmoins transmis à l’eNb mais pas le PMI.

Ce mode supporte le multiplexage spatial de 2 ou 4 couches transmises simultanément sur 2 ou 4 antennes. La matrice de précodage utilisée en émission est connue par le récepteur et se calcule par le produit de trois matrices : Une matrice  de taille N x L et deux matrices carrées D et U de taille L x L : D.U

La matrice W distribue le signal provenant de chaque couche vers les P ports d’antennes, la matrice D permet d’avoir un décalage alors que la matrice U distribue l’énergie sur chacun des ports d’antennes.

Avec :

Table 2.8. Bibliothèque de matrices de précodage pour deux ports d’antennes

Afin de connaitre la position des colonnes constituant la matrice de précodage W, on se réfère à la spécification TS 36.211 Table 6.3.4.2.3-2 (cf. table 2.9).

Table 2. 9. Bibliothèque Tableau de codes pour la transmission sur 4 antennes en DL

Pour l’index 0 et pour deux couches spatiales, la matrice de précodage est constituée de la colonne 1 et de la colonne 4 de la matrice w0, laquelle se calcule à partir du vecteur u0.

Pour le mode de transmission TM3, 4 antennes, l’index est 12, 13, 14 et 15.

Les matrices D et U sont définies dans la spécification 3GPP TS 36.211 (Table 6.3.4.2.2-1) :

Table 2.10. Matrice de précodage : Matrices U et D

CDD représente la diversité temporelle : Un bloc est retransmis avec un retard spécifique constant représenté par U

TM3 : Transmit Diversity

Le TM3 nécessite uniquement l’information RI. Le PMI n’est pas transmis. Dans le cas où le rang de la matrice est unitaire, le mode TM3 est utilisé pour la diversité d’émission

Dans ce cas, la matrice de précodage est identique à la matrice de précodage du mode TM2

TM 4 – Multiplexage spatiale en boucle fermée (CSI transmis à l’émetteur)

Ce mode supporte le multiplexage spatiale SU-MIMO jusqu’à 4 couches spatiales multiplexées jusqu’à 4 antennes. L’estimation du CSI est réalisée à partir du CRS ce qui signifie que le retour de l’UE n’exploite pas de pilote dédié à l’UE.

La matrice de précodage s’appuie

  • Sur la table xx.8 pour un utilisateur transmettant un ou deux couches spatiales sur 2 ports d’antennes.
  • Sur la table xx.9 pour un utilisateur transmettant une à 4 couches spatiales sur 4 ports d’antennes.

Dans le TM4, les mêmes ressources temps fréquentielles sur les différentes antennes sont transmises vers un seul UE

TM 5 – MU-MIMO

Ce mode est similaire au TM4, il supporte la fonction de multiplexage spatial en boucle fermée de deux utilisateurs (MIMO 2×2) ou de 4 utilisateurs (MIMO 4×4). La matrice de précodage est extraite à partir des mêmes tables.

Dans le TM5, les ressources temps fréquentielles sur les différentes antennes sont transmises vers plusieurs UE

TM6 : Multiplexage spatial en boule fermé en utilisant qu’une seule couche de transmission.

Ce mode est un cas particulier du TM4 pour lequel le rang de la matrice (RI) est 1. L’UE estime le canal et retourne l’index PMI de la matrice de précodage la plus adaptée.

Dans le cas de deux antennes, la matrice de précodage est définie par la table xx.8 (1ère colonne) et par la table xx.9 (1ère colonne) dans le cas de 4 antennes.

TM7 : Faisceau de voie (Beamforming)

Le mode TM7 peut être vu comme le mode TM6 en boucle ouverte. Le faisceau de voie est dédié vers un UE, l’estimation du canal s’appuie de la part de l’UE sur le signal de reference UE-specific RS. Ainsi, les données et l’UE-RS sont précodés par la même matrice.

TM8 : Faisceau de voie sur deux couches

La R.8 a spécifié le beamforming sur une seule couche (TM7). La R.9 a specifié le beam-forming sur 2 couches. Ainsi, le TM8 permet de combiné le beamforming avec un multiplexage spatial pour un ou plusieurs utilisateurs. L’utilisation de deux couches permet également de faire du SU-MIMO ou du MU-MIMO.

TM9 : Faisceau de voie sur deux couches

La R.10 a spécifié le TM.9 pour étendre les configurations du MIMO sur 8 antennes. Ainsi, le SU-MIMO et le MU-MIMO sont définies dans le TM9 (comme une extension du TM4 et du TM8)

Pour pouvoir exploiter 4 antennes supplémentaires, la R.10 propose 8 signaux de références nommés CSI-RS et de nouvelles matrices de précodage calculées à partir des mots de codes existants : W=W1W2  ou :

  • W1 est une matrice de précodage diagonale large bande permettant de définir la sélection de voies
  • W2 change la phase du signal sur chaque polarisation de l’antenne

TM 10

Le TM10 est similaire au TM9 mais les antennes utilisées peuvent être sur des eNb différents. Le TM10 supporte la technologie COMP

xx.3.1.3 Les matrices de précodage et les modes de transmission en UL

La R.8 et la R.9 ne spécifient pas la possibilité de faire du MIMO sur le sens montant.

A partir de la R.10, les UE supportent le MIMO jusqu’à 4 couches, il n’existe donc que deux modes de transmission en Uplink :

TM1 : SISO

TM2 : Closed loop spatial Multiplexing

2.3.2 Les mappage sur les éléments de ressources

Le dernier bloc de la chaîne de transmission correspond à l’association entre les ports d’antennes et les antennes physiques.

Les ports d’antennes sont des entités logiques qui se définissent par les signaux de références qu’ils transportent. La table xx.11 fait l’association du port d’antenne et du signal de référence.

Table 2. 11. Association Signaux de références et port d’antenne pour le DL

Signaux de références CRS

Dans le chapitre sur la structure de la trame radio LTE, nous avons vu que les signaux de références CRS sont insérés dans chaque bloc de ressource (RB) émis par la station de base. L’UE doit estimer toute la bande du canal à partir de la connaissance du CRS et même en cas de forte mobilité (120 km/h à 250 km/h).

Les signaux de références CRS sont insérés dans tous les RB de la bande avec un motif répétitif.

Pour un préfixe cyclique normal, le mappage est effectué sur le premier et cinquième symbole OFDM de chaque slot pour les ports d’antennes 0 et 1 et sur le deuxième symbole OFDM pour les ports d’antennes 2 et 3.

Au niveau fréquentiel, les CRS sont espacés de 6 sous porteuses sur chaque port d’antenne et peut prendre une  position parmi les 6 positions possibles. La position en fréquence du CRS dépend de l’identité physique PCI de la cellule.

De plus, les éléments de ressource utilisés pour le port d’antenne p0 ne doivent pas être utilisés pour le port d’antenne p1, et vice versa pour éviter les interférences entre antenne.

Ainsi, la figure 2.13 présente le mapping dans le cas du préfixe normal (7 symboles par slot) pour une, deux et 4 antennes

Figure 2. 13. Mappage des CRS dans les ports d’antennes

L’allocation de ressources des données transmises est signalée dans le canal physique PDCCH par l’information         .

La table 2.12 propose une synthèse entre le TM et les ports d’antennes.

Table 2. 12. Correspondance entre le TM et les ports d’antennes