Etablissement de la connexion radio – Partie 2 : Les ressources et l’identifiant aléatoire

Avant d’émettre sa demande d’accès aléatoire, le terminal doit récupérer un ensemble d’informations transmises par la station de base via le message SIB2 :

  • la configuration du PRACH (prach-ConfigIndex) ;
  • le jeu des préambules d’accès aléatoires disponibles (la racine q et les décalages de la séquence, se référer à la partie 1) ;
  • la fenêtre temporelle pour la réponse (ra-ResponseWindowsSize) ;
  • la puissance d’émission du préambule initial (preambleInitialRecievedTargetPower) ;
  • le facteur de rampe de puissance (powerRampingStep) ;
  • en cas de non réponse, le nombre maximum de préambules pouvant être émis (preambleTransMax) ;
  • le temporisateur de résolution de contention (mac-ContentionResolutionTimer)

Figure 1 : Extrait des informations du SIB2

A partir de :

  • l’information msg1-FrequencyStart, le terminal UE calcule la position fréquentielle de la localisation du canal PRACH ;
  • l’information msg1-FDM, le terminal connait le nombre d’occasion PRACH dans le domaine fréquentiel

A titre d’exemple :

Dans la bande FR2 :

Figure 2 : La configuration de l’accès aléatoire selon la table 38.211 v15.5-Table 6.3.3.2-4

Les numéros de slot de référence sont le 19 et le 29, nous allons maintenant calculer la position du slot du RACH à partir de la référence du slot 19 :

N°slot_RACH=Starting_symbol + Numero_occassion_PRACH*Durée_PRACH+Nbre_symboles_par_slot*numero_du_slot

Avec :

  • Starting_symbol est une valeur indiquée dans le tableau, la valeur est à 7
  • Numero_occassion_PRACH correspond aux occasions du RA. L’indice démarre à 0 jusqu’à Number_of_time_domain_occasion – 1. La valeur vaut 0
  • Nbre_symboles_par_slot est de 14
  • Numero_du_slot se calcule par la formule suivante :
    • Si SCS = {1,25 kHz, 5 kHz, 15 kHz, 60 kHz} alors Numero_du_slot=1
    • Si SCS = {30 kHz, 60 kHz} et
      • si le nombre de slot RACH par sous-trame =1 alors Numero_du_slot=1
      • sinon Numero_du_slot={0,1}

Dans notre exemple, le symbole sur lequel démarre le canal PRACH est à la position : 7+0*6+14*1=21 par rapport au slot 19. Il se situe donc à la position du symbole 7 du slot 20

Figure 3 : Exemple de transmission du PRACH (FR2, format A3)

Une fois le préambule sélectionné, le terminal UE détermine la prochaine occasion pour envoyer sa demande. La puissance d’émission est estimée à partir des paramètres reçus par le SIB2 et en augmentant la puissance à chaque retransmission.

La demande d’accès est contrôlée par la station de base en indiquant par le message SIB2 les occasions du canal PRACH dans le domaine temporel et fréquentiel.

Ressources Temporelles (prach-ConfigurationIndex)

La référence temporelle est la durée d’une trame, soit 10 ms. La transmission du canal PRACH au cours de la trame est définie par les paramètres suivants :

  • PRACH configuration period : Le numéro de trame SFN utilisé pour transmettre le canal PRACH est défini par la condition suivante : x mod SFN = y.
    • A titre d’exemple x=16, alors les occasions du canal PRACH sont espacées de 160 ms
    • Si x=16, y=1, alors les numéros de trames portant le canal PRACH sont définis par le numéro de trame SFN 1,17,33,49,…
  • SubFrame Number : Indique le ou les sous-trames dans la trames qui transportent le canal PRACH
  • Slots with PRACH : La référence est un espacement entre sous-porteuses (SCS) de 60 kHz, pour laquelle on a 4 slots par sous trames soit 40 slots par trame. Le nombre d’occasion est donc de 40 lorsque l’espacement entre sous-porteuses est de 60 kHz ou 40*2 slots pour un espacement entre porteuses de 120 kHz.

Ressources Fréquentielles

  • msg1-FrequencyStart : Indique la première ressource PRACH
  • msg1-FDM : Indique le nombre de ressources fréquentielles pour le PRACH (1,2, 4 ou 8)

A partir de ces valeurs, le numéro de la sous-trame et l’index de fréquence utilisé par le terminal pour transmettre sa demande d’accès aléatoire permet de calculer l’identifiant radio RA-RNTI :

RA-RNTI= 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id

  • s_id : Index du premier symbole OFDM (entre 0 et 13)
  • t_id : Index du premier slot dans la trame (entre 0 et 79)
  • f_id : Index dans le domaine fréquentiel (entre 0 et 7)
  • ul_carrier_id est égal à 1 si la demande est faite dans la bande SUL, 0 sinon

Cette valeur sera utilisée par l’entité gNB pour répondre au terminal : le terminal écoute le canal PDCCH émis par l’entité gNb et recherche la réponse pour laquelle le code détecteur d’erreur CRC est mélangée par l’identifiant RA_RNTI (ou exclusif).

En fin de transmission, le terminal UE écoute (sur une durée définie) la réponse de l’entité gNB laquelle contient le numéro de référence RA-RNTI.

Références

3GPP 38.211

https://www.sharetechnote.com/html/5G/5G_RACH.html

Consultation 5G ARCEP- Bande de 3.4 GHz – 3.8 GHz

L’Arcep met en consultation publique les modalités d’attribution et les obligations pour les candidats à la 5G sur la bande de 3.4 GHz à 3.8 GHz. 300 MHz de bandes seront mis en enchère en automne 2019. La taille du bloc minimum est de 40 MHz et des blocs supplémentaires de 10 MHz de bande sont ensuite vendus aux opérateurs. Cependant, l’intérêt pour un opérateur est d’obtenir au minimum une bande de 80 MHz pour apporter une plus-value par rapport à la 4G et l’agrégation de porteuses. La taille maximum est de 100 MHz. Les fréquences seront attribuées pour 15 ans.

Cette bande de fréquence est uniformisé en Europe par le CEPT (bande n77 et n78)

Double Connectivité (DC – Dual Connectivity) 4G/5G – 3ème article

Pour continuer l’étude de la double connexion, je vous propose un call-flow. Ce call Flow termine l’étude de la Double connexion.

Le document est une lecture de la norme (Spécification 3GPP 38.912) dans un contexte ou les équipementiers testent leurs solutions. Mettez en doute chacune de mes affirmations, et n’hésitez pas à me corriger si vous détectez des erreurs.

Je me suis aussi inspiré du blog de Martin SAUTER : https://blog.wirelessmoves.com/2018/08/5g-en-dc-lets-talk-about-signaling-srb1-2-srb-3-split-srb.html

2-3) Call Flow – EN-DC NSA : Split-Bearer option 3X (Création d’un support entre le cœur réseau 4G (EPC) et une station de base en-SgNB)

Le call flow présente le ré-établissement d’un support (bearer) entre l’entité SGW et la station de base secondaire en 6 étapes pour le sens descendant uniquement (se référer au premier article). 

On considère ici le cas de l’option 3X :

  • le bearer montant est maintenu au niveau de l’entité eNB
  • le bearer descendant est configuré vers l’entité S-en-gNB (SCG Configuration) et partagé entre les deux stations de base (Split-bearer)

On part évidemment dans l’hypothèse que le terminal est déjà attaché au réseau, et que le support PDN par défaut existe. Cette hypothèse permet d’avoir l’identifiant TEID UL du SGW stocké au niveau de l’entité MME, ce qui est nécessaire lors du ré-établissement de support (entre le SGW et l’eNB). Le TEID S1-UL est l’identifiant de tunnel qui sera inscrit dans le contexte de l’entité eNB (donc le Master) permettant d’étiqueter le flux montant (association avec l’identité temporaire du terminal et la QoS correspondante). Ainsi, les données émises par le terminal UE vers l’entité eNB (lien montant) et identifiées par l’identifiant radio C-RNTI seront transférées par l’entité eNB vers l’entité SGW avec l’identifiant d’acheminement TEID S1-UL (et l’adresse IP du SGW). Pour l’entité SGW, le tunnel TEID a été construit et correspond à l’identifiant du tunnel par défaut monté lors de la procédure d’attachement (PDN Connectivity).

Dans cet exemple, on suppose la création d’un support entre l’entité SGW et l’entité en-gNB. Ce support peut (mais pas obligatoire) remplacer le support existant entre l’entité SGW et l’entité eNB. On se positionne donc sur l’option 3x.

On suppose également que la station de base eNB a activé la cellule secondaire en-gNB (procédure X2AP Secondary Cell activation). Ainsi, la station de base eNB émet la liste des cellules 5G présentes dans le message de SIB2 permettant au terminal UE d’être informé de la présence du réseau 5G (et d’afficher le logo 5G).

Etape 1 : Connexion radio et cœur réseau en 4G

Le terminal UE fait une demande de connexion radio vers l’entité eNB, à laquelle la station de base répond en indiquant l’identifiant radio C-RNTI pour la connexion LTE.

A partir de l’identifiant C-RNTI, le mobile transmet une requête RRC d’établissement de support (RRC Connexion Request) en indiquant la raison de sa demande (Establishment cause).

La station de base eNB répond au terminal UE par le message RRC Connection SETUP (Support de signalisation SRB0).

Le terminal UE encapsule le message NAS (Service Request) dans le message RRC Connection Setup Complete (support de signalisation SRB1) à destination de la station de base eNB. Il indique au réseau qu’il supporte la fonction DC 4G/5G en positionnant le bit DCNR du message UE Capability Network à 1. Le message est chiffré avec la clé NAS (MME).

La station de base eNB transmet le message NAS à l’entité MME. Si l’entité MME ne parvient pas à déchiffrer le message, il procède à l’authentification et à la mise en sécurité NAS. L’authentification nécessite l’apport de l’entité HSS.

Cette procédure est optionnelle car si le message NAS est déchiffré par l’entité MME, l’authentification est alors validée.

Etape 2 :  Mise en place du support pour le lien montant UL entre l’entité eNB et l’entité SGW et du support radio bi-directionnel entre le terminal UE et la station de base (récupération des capacités du terminal et mise en sécurité AS sur l’accès LTE)

A partir de cette étape, tous les messages NAS échangés entre le terminal UE et l’entité MME sont chiffrés.

L’entité MME transmet à la station de base eNB via le message Initial Context Setup Request :

  • les capacités QoS maximales (extended UE AMBR);
  • l’identité QoS de la requête de service ;
  • l’identité du support radio (RAB Id) ;
  • le numéro de tunnel SGW TEID UL permettant d’identifier le lien UL au niveau du SGW ;
  • la clé de sécurité (KeNB) permettant de dériver les clés de chiffrement et d’intégrité sur le lien radio

A partir du message Initial Context Setup Request, l’entité eNB doit :

  • mettre en œuvre l’établissement du support E-RAB configuré par l’entité MME ;
  • sauvegarder le profil de QoS de l’utilisateur (UE-AMBR) ;
  • sauvegarder la liste de restriction de handover (handover restriction list IE);
  • transmettre les valeurs contenues dans chaque élément d’information E-RAB ID IE et NAS-PDU IE pour chaque support d’accès radio (RAB) ;
  • sauvegarder la capacité du terminal UE (exemple : IoT et le mode CE)et ses capacités de sécurités (UE security capacities et NR UE security capacities ) .

La capacité du mobile à supporter la double connexion 4G/5G est signalée à l’entité MME dans le message d’information : Extended UE-AMBR Downlink and Uplink Information Elements. Ces informations sont connues par le MME et récupérées à partir de l’entité HSS lors de la demande d’attachement de l’utilisateur.

Si la liste de restriction de handover est transmise, l’entité eNB pourra sélectionner la cellule secondaire SCG pendant l’opération de Double Connexion.

En absence d’information sur le terminal de la part de l’entité MME, la station de base demande des informations sur les capacités radios supportées par le terminal UE (UE-CapabilityRequest = eutra, eutra-nr, nr).

Le terminal UE informe la station de base MeNB (on parle maintenant de MeNB car on se prépare à la double connexion) qu’il supporte le mécanisme DC NR et indique les bandes supportées dans le message UE-CapabilityRAT-ContainerList {rat-Type EUTRA-NR, ue-CapabilityRAT-Container = UE-MRDC-Capability}, SupportedBandListNR-r15.

Les informations récupérées par l’entité MeNB sont transmises à l’entité MME par le message UE Capability Information Indication portée par l’application S1 AP

A l’issu du message Initial Context Setup Request, l’entité eNB :

  • sécurise le lien radio ;
  • établi le lien radio avec le terminal UE via le message RRC Connection Reconfiguration (SRB2)

L’entité MeNB configure le terminal UE des mesures à réaliser (Objects Measurements) sur les liens radios 4G/5G et active le lien radio (support Data) via le message RRC Connexion Reconfiguration en fournissant au terminal UE le numéro de séquence PDN et l’identifiant du support radio (EPS Radio Bearer Identity).

Le terminal UE confirme l’activation du support par défaut (RRC Connection Reconfiguration Complete).

A partir de ces messages RRC Connection Reconfiguration, le support radio data (RAB) est établi dans les deux sens entre le terminal UE et la station de base. Le terminal peut donc recevoir ou transmettre des données avec la station de base.

Une fois la connexion établie (et sécurisée), l’entité eNB acquitte la demande d’établissement de support du MME par le message Initial Context Setup Response. Ce message contient la liste des supports RAB (E-RAB list) qui sont établis par l’entité MeNB.

Etape 3 : Configuration du support S1-U pour le lien descendant DL

L’entité MeNB transmet à l’entité MME le message Initial Context Setup response en réponse au message Initial Context Setup request transmis précédemment par le MME pour la demande d’établissement du support. C’est à ce moment que l’entité MeNB transmet à l’entité MME l’identifiant TEID DL qui sera utilisé par le SGW pour l’acheminement du trafic descendant vers la station de base MeNB (et à destination du terminal UE).

L’entité MME créée une entrée dans la table d’acheminement de l’entité SGW avec l’identité TEID DL et l’adresse IP de l’entité eNB pour le contexte de transfert en DL. A partir de ce moment, le trafic descendant est possible au niveau du cœur réseau et donc de bout en bout.

A ce stade, le support EPS par défaut est établi permettant une connexion bi-directionnelle entre le terminal UE, la station de base maîtresse MeNB, et les entités du plan de transport SGW/PGW.

Etape 4 : Préparation à la Double Connexion 4G/5G (option 3)

La procédure d’ajout d’un nœud secondaire est controlée par l’entité MeNB et la requête est soumise à la station de base secondaire via le message SgNB Addition Request. Cette procédure permet à la station de base maitresse de définir le type l’option DC (3/3a/3x) en transmettant les identifiants de tunnel TEID pour le support MCG/SCG ou en demandant à l’entité SgNB de fournir les identifiants de tunnel pour le support SCG.

Si on revient sur la figure 8, il y a beaucoup d’options possibles :

  • MCG bearer ;
  • SCG bearer ;
  • Split-bearer.

Chaque support est transmis du cœur de réseau vers l’entité MeNB ou vers l’entité SgNB ou vers les deux. On va nommer la station de base en-gNB sous le terme SgNB.

A titre d’exemple, le support MCG peut être reçu par l’entité SgNB et les paquets DL sont transmis de l’entité SgNB vers l’entité MeNB. La norme précise que si la requête SgNB Addition Request demande la configuration entre le coeur de réseau 4G et l’entité S-gNB alors l’entité S-gNB transmet l’identifiant de tunnel S1 SGW TEID DL à l’entité MeNB pour modifier le tunnel descendant avec l’entité SGW. Pour terminer le tunnel descendant vers l’entité eNb, ce dernier transmet l’identifiant de tunnel MeNB DL GTP TEID at MCG IE pour le tunnel entre l’entité SgNB et MeNB. Dans ce cas, l’entité SgNB doit utiliser ce numéro de tunnel en tant qu’acheminement en DL (DL X2-U) pour délivrer les paquets DL PDCP.

Pour résumer :

  1. avant l’ajout d’un noeud secondaire, le tunnel data s’effectue entre le CN et l’entité MeNB.
  2. Après l’ajout du noeud secondaire, l’entité SGW aura modifié sa table de commutation vers l’entité SgNB (identifiant S1 SGW DL) et l’entité SgNB aura crée une table dans sa table de commutation vers l’entité MeNB (MeNB DL GTP TEID).

Mais pendant la phase de changement de commutation de tunnel entre l’étape 1 et l’étape 2, les paquets transmis du SGW vers l’entité MeNB seraient perdus? Il faut donc assurer un tunnel temporaire entre l’entité MeNB vers l’entité SgNB des données arrivant du SGW. Ce numéro de tunnel est transmis dans le message SgNB Addition Request, par le paramètre MeNB UL GTP TEID at PDCP IE. Pour que le tunnel soit complet, l’entité SgNB va répondre dans le message SGNB ADDITION REQUEST ACKNOWLEDGE le numéro de tunnel du SgNB (Secondary SgNB DL GTP TEID at SCG IE) en indiquant le mode de transmission (duplication ou non).

Nous allons maintenant étudier les requêtes, cependant, avant d’établir une double connexion, l’entité MeNB analyse les mesures effectuées par le terminal UE.

Dans le précédent message de signalisation RRC Connexion Reconfiguration SRB2, l’entité MeNB avait transmis au terminal UE les éléments de mesure (measurement objects) à réaliser. Dans le cas d’un terminal compatible DC LTE/NR, la station de base maîtresse MeNB demande au terminal UE d’écouter les signaux de références NR.

Le terminal UE se synchronise sur les signaux de références PSS/SSS 5G et mesure le niveau de puissance reçu à partir des canaux de références DM-RS (transmis avec le bloc SSB : bloc de synchronisation et BCCH) et le signal de référence CSI-RS. A cette étape, le terminal ne cherche pas à établir un support de signalisation SRB avec la station de base secondaire SgNB, mais uniquement à remonter la qualité du lien radio NR.

Si la mesure du lien radio réalisée par le terminal UE et transmise à la station de base MeNB permet d’établir une double connexion, la station de base maitresse MeNB demande l’ajout d’un second nœud radio avec la station de base secondaire 5G SgNB.

Nous allons étudier la procédure d’ajout du nœud secondaire (procédure SgNB Addition). Nous verrons ensuite la procédure de modification du nœud secondaire. La procédure d’ajout d’un nœud secondaire s’effectue par un échange d’information sur le routage et la QoS des supports, et la procédure de modification permet de changer la configuration.

La requête SgNB Addition Request transporte les informations de configuration du support (TEID, E-RAB Parameters), les capacités du terminal et les informations de sécurité de la couche radio : Pour le chiffrement, la station de base MeNB indique au terminal si le chiffrement sera réalisé par l’entité PDCP 4G ou par l’entité PDCP 5G.

En fonction de l’option DC choisi (ou imposée) par l’entité MeNB, les paramètres échangés entre la station de base maitresse MeNb et secondaire définissent :

  • le routage du support (bearer) soit au niveau du cœur réseau (MCG/SCG), soit au niveau de l’accès radio (MeNB ou SgNB pour le split-bearer) ;
  • l’allocation de ressource et la QoS attendue sur le support MCG ou le support SGC (Request MCG E-RAB Level QoS Parameter IE ou Request SCG E-RAB Level QoS Parameter IE).

Ainsi, les paramètres transmis lors de la procédure d’ajout d’un nœud secondaire concernent :

  • les caractéristiques du support radio E-RAB (E-RAB Parameters, TNL address information) ;
  • les dernières mesures radios correspondant à l’entité SgNB
  • les informations de sécurité pour l’établissement du lien de signalisation SRB3 (option si la configuration SRB-splitUL est activée)
  • les informations
    • de configuration SCG avec les capacités du terminal UE (UE capabilities and UE capability coordination result) : les identifiants de tunnel SgNB DL TEID
    • de configuration Split-bearer avec les capacités du terminal UE : les identifiants de tunnel dans le cas de l’établissement d’un support nécessitant un transfert via l’interface X2-U entre les nœud maître et secondaire (MN et SN) pour le split bearer : X2-U TNS address information (MeNB UL TEID)
  • les caractéristiques de la QoS dans le cas de l’option de split-bearer.
    • maximum supportable QoS level

Si la station de base secondaire accepte la demande d’ajout de nœud, celle-ci répond par un message SgNB Addition Request acknowledge et transmet :

  • l’allocation des ressources radios nécessaires pour le transport des flux ;
  • décide de la mise en place de l’agrégation de porteuse en attribuant des ressources sur la cellule principale PScell (cellule de service ou Serving Cell) et éventuellement les cellules secondaires pour l’agrégation de porteuses sur l’entité gNB (SGS Scells) ;
  • selon l’option choisi (option 3a ou option 3x) :
    • fournit les identifiants d’adressage sur le lien X2-U dans le cas ou du trafic doit être transmis entre l’entité MeNB et l’entité SgNB.
  • Selon le mise en place de ressources radio SCG, l’entité SgNB fournit la configuration des ressources

Dans le cas de l’option de configuration du support SCG ou de l’option 3x (split-bearer) sur l’entité SgNB, le support radio est géré par l’entité PDCP de la station de base secondaire SgNB. Dans ce cas, l’entité maîtresse MeNB propose la modification d’acheminement d’un certain nombre de supports sur la liaison descendante. Les différents supports à modifier sont indiqués dans les éléments d’informations DL forwarding IE du champ E-RAB to Be Added Item (tableau 1).

Tableau 1 : Les champs d’information de la requête en-SgNB addition Request

La liste des supports radios E-RAB pris en charge par l’entité secondaire SgNB est transmise à la station de base maitresse MeNB via le message SgNB Addition Request Acknowldge.

L’entité SgNB valide en totalité ou partiellement la demande de l’entité MeNB. Les supports pris en charge par l’entité SgNB sont indiqués à l’entité SgNB dans l’élément DL Forwarding GTP Tunnel Endpoint du champ E-RAB to Be Added Item (tableau 2).

L’allocation de ressource au niveau de la station de base secondaire SgNB permet :

  • d’établir la cellule primaire Pscell et éventuellement d’autres SCG Scells
  • Dans le cas de l’option 3 ou 3x nécessitant un support sur l’interface X2-U
    • l’entité SgNB fournit les informations d’adressages X2-U TNS pour l’acheminement des données
  • Dans le cas d’une requête de support radio SCG radio
    • l’entité MeNB fournit la configuration des ressources radio SCG

Tableau 2 : Les champs d’information de la requête SgNB addition Request Acknowledge

Pour résumer, la configuration (pour chaque support radio) de la table d’acheminement correspondant à l’option 3/3a/3x de la double connexion est transmis par l’entité secondaire SgNB vers l’entité MeNB dans le message SgNB Addition Request Acknowldge :

  • SCG Bearer
    • une identité de tunnel S1 DL GTP TEID ;
    • une identité de tunnel DL Forwarding pour le transfert du bearer dédié à l’eNB (et non partagé, le tunnel arrive à l’entité S-gNB et est entièrement transmis à l’entité MeNB);
    • une identité de tunnel UL Forwarding pour transmettre les données reçues par l’entité MeNB vers le CN (point d’ancrage SgNB)
  • Split-bearer
    • une identité de tunnel S1 DL Forwarding GTP TEID
    • une identité de tunnel X2 DL GTP TEID pour les données partagées au niveau de l’entité SgNB et destiné à l’entité MeNB.

Dans le cas de l’option 3a (avec le SCG bearer défini au niveau de l’entité en-gNB) et dans le cas de l’option 3x (le split bearer est ancré au niveau du en-gNB), l’entité MeNB devra communiquer au MME l’identifiant de tunnel S1 DL TEID pour l’établissement du bearer S1-U entre l’entité en-gNB et l’entité SGW.

Dans le cas du SCG bearer défini au niveau de l’entité MeNB ou dans le cas du split bearer au niveau de l’entité eNB (option 3), la modification d’acheminement porte sur le routage de tunnel TEID entre l’entité en-gNB et l’entité MeNB : la station de base maîtresse MeNB va transmettre à l’entité en-gNB l’identifiant de tunnel X2 UL TEID pour l’établissement du bearer X2-U entre l’entité S-gNB et l’entité SGW et l’entité SgNb envoie l’identifiant de tunnel X2 DL TEID à l’entité MeNB.

Si la station de base maitresse MeNB a demandé à l’entité SgNB la configuration d’un support MCG en transmettant dans le message SgNB Addition Request la ressource MeNB DL GTP TEID at MCG, alors l’entité SgNB doit utiliser l’adresse X2-U pour les paquets PDU PDCP dans le sens descendant.

A partir du moment où les règles d’acheminement ont été négociées entre l’entité maitresse MeNB et l’entité SgNB, la station de base MeNB transmet au terminal UE la nouvelle configuration radio. Le contenu de la configuration du lien radio est transmis par l’entité MeNB au terminal UE via le message RRC Connection Reconfiguration (SRB2). Ce message transporte la requête NR RRC Connection Reconfiguration

A partir de ce message, le terminal UE récupère la configuration du lien RACH avec l’entité SgNB et l’identité C-RNTI pour l’accès 5G.

Le terminal UE transmet le message RRC Connection Reconfiguration Complete à l’entité MeNB. Ce message transporte la requête NR RRC Reconfiguration Complete destiné à l’entité SgNB. La station de base maîtresse transfert ce message à l’entité SgNB via l’interface X2 à travers le message SgNB Reconfiguration Complete. La station de base maitresse transmet ensuite le numéro de séquence SFN des supports SCG qui seront transférés vers l’entité SgNB.

A ce stade, le support radio NR n’est pas encore finalisé, mais les données du support reçue au niveau de l’entité MeNB et provenant de l’entité SGW sont routées et bufférisées au niveau de l’entité SgNB.

Etape 5 : Création d’un support SCG entre le cœur de réseau 4G et la station de base SgNB

Dans le cas de la création du support SCG, la station de base maîtresse demande à l’entité MME de modifier la table d’acheminement au niveau de l’entité SGW afin d’acheminer les supports vers la station de base SgNB et non plus vers la station de base maîtresse MeNB.

L’entité MME modifie la table d’acheminement au niveau du SGW par une requête de modification de support (Modify Bearer). Une fois la modification portée, l’entité SGW confirme à l’entité eNB la suppression du bearer, ce dernier transfère alors les données subséquentes vers l’entité SgNG en attendant l’établissement du lien radio NR.

Dans le cas de l’option du split bearer option 3, l’entité MME n’est pas informé de la modification de la demande de bearer S1-U.

Dans le cas de l’option du split-bearer option 3x, l’entité MME est informé de la modification du point de terminaison du bearer S1-U.

Etape 6 : Etablissement de l’accès radio 5G

Le terminal UE se synchronise sur l’accès radio NR avec l’entité SgNB à partir des signaux de synchronisation PSS et SSS. A partir du PSS et SSS, le terminal UE récupère le numéro de la cellule NR PCI.

La lecture du MIB permet au mobile de se synchroniser avec le début de la trame.
Le terminal UE fait une demande d’accès radio via la procédure d’accès aléatoire RACH. Le préambule aléatoire est déterminé par la lecture du MIB (accès avec contention) ou à partir des informations transmises au mobile lors de l’étape 4 pour un accès sans-contention (message RRC Connection Reconfiguration).

La station de base secondaire fournit l’identifiant temporaire RA-RNTI puis alloue des ressources radio NR au terminal (DCI 1.0). Le terminal acquitte par une réponse en UL (PUSCH) et des données sur le lien montant.

La connexion bidirectionnelle est établie entre le terminal UE et le cœur de réseau SGW via l’entité SgNB.

Régulièrement, le terminal UE transmet à la station de base maîtresse MeNB l’information PHR (Power HeadRoom) concernant à la fois le lien sur la station maitresse et secondaire.

Le terminal transmet également les rapports de puissance régulièrement vers l’entité maitresse MeNB. L’entité MeNB transfert les informations de mesure vers l’entité secondaire SgNB.

 

Double Connectivité (DC – Dual Connectivity) 4G/5G

La 5G arrivera en 2020, le déploiement sera un déploiement au niveau de la couche radio. Comment la 5G sera déployée? Quels services va t’elle apporter? Quelles performances? Comment la station de base 5G (gNB) sera controlée? Peut on parler de 5G si le coeur réseau est 4G?

Ces réponses seront apportées dans une série d’articles, et voici le premier article d’une longue série sur la double connectivité.

Introduction

La double connectivité implique la présence de deux stations de base pour apporter des ressources radio-électrique vers un terminal mais un seul point de terminaison de signalisation vers le coeur réseau. Dans une première phase, le coeur de réseau est le coeur de réseau 4G (EPC), le point de terminaison est donc l’interface S1-MME.

La double connexion implique soit deux stations de bases LTE (se référer à l’article suivant) soit une station de base NR et une station de base LTE (Multi-Radio DC – MR-DC aussi nommé NR-DC).

Chaque nœud radio contient plusieurs cellules (une cellule pour une antenne omni-directionnelle, trois cellules, 6 cellules pour des antennes multi-sectorielles, …), et chaque nœud gère plusieurs porteuses LTE ou NR (agrégation de porteuses).

La double connexion implique donc la gestion de groupe de cellules (GC : Group Cell) pour chaque nœud radio. L’objectif d’un groupe de cellules est de gérer les données sur une ou plusieurs porteuses pour augmenter le débit. Dans un groupe de cellules (GC), on identifie la cellule principale (SpCell) qui est en charge de contrôler toutes les cellules du groupe et optionnellement une ou plusieurs cellules secondaires (SCell).

La double connectivité définie la notion de support MCG (Master Cell Group) et SCG (Secondary Cell Group bearer). Le support MCG est géré par la station de base maitresse, le support SCG correspond aux supports de la station de base secondaire. La double connexion permet de modifier la terminaison du plan de transport (U-plane termination) vers le support MCG ou SCG via la signalisation S1-MME sans modifier le point de terminaison du nœud de contrôle S1-MME (la signalisation est toujours définie entre le cœur de réseau et la station de base maîtresse).

Ainsi, si on appelle MCG le groupe de cellule maître et SCG le groupe de cellules secondaires, le MSG et le SCG peuvent avoit un SpCELL et des SCELL.

La fonctionnalité Double Connectivité (Dual Connectivity DC) a initialement été spécifiée sur le réseau de mobiles 4G entre deux stations de bases eNB différentes (sur des porteuses différentes) avec l’objectif d’augmenter le débit ressenti par l’utilisateur en agrégeant des flux des deux eNB en dépit de la latence provoquée par le lien X2 (backhaul). Cela constitue une différence avec l’agrégation de porteuses ou l’agrégation des flux est réalisée sur la même station de base dans deux bandes radios différentes. Dans le cas de la double connexion, les stations de base n’ont pas besoin d’être synchronisées (et peuvent donc être non co-localisées).

Figure 1 : Agrégation de porteuses et Double Connexion

L’interface X2 est une interface physique, généralement en Fibre Optique. L’interface X2 peut être séparée en deux interfaces, l’interface X2-U pour l’échange de données du plan utilisateur entre la station de base maîtresse et secondaire (handover, double connexion), et l’interface X2-C permettant l’échange des informations de contrôle entre les deux stations de base.

La pile protocolaire pour le plan de transport sur l’interface X2-U utilise les couches protocolaires GTP-U, UDP, IP et la couche de niveau 2

  1. La double connectivité DC 4G-4G (se référer à l’article DC 4G/4G)

L’option DC 4G-4G a déjà été présentée dans un article précédent, on différencie le plan de contrôle et le plan de trafic. L’une des deux stations de base est responsable de la signalisation avec le cœur réseau et le terminal. Les supports (nommés bearer) de signalisation correspondent aux bearer SRB1 et SRB2 entre le terminal Ue et la station de base maîtresse (MeNB). La station de base secondaire est responsable de la connexion de données additionnelles sur le lien radio (DRB) et vers le cœur réseau.

Plan de contrôle :  La station de base maîtresse (MeNB) établie la connexion RRC avec le terminal UE et la connexion radio avec l’entité SeNB (Secondary eNB) est contrôlée par la station de base maîtresse.

Plan utilisateur : Deux options sont supportées pour la DC 4G-4G :

  • Option 1A : Le cœur de réseau établit deux supports (bearer) avec chacun des entités eNB ;
  • Option 3C : Le support est séparé par l’entité MeNB : Split Bearer

Figure 2 : Pile protocolaire DC 4G-4G

Le terminal UE ne dispose que d’une seule entité RRC.

Dans le cas de la double connexion 4G-4G, les deux options retenues parmi toutes les options possibles sont l’architecture 1A et 3C.

Pour l’option 1A, la séparation des flux est gérée au niveau du cœur réseau (SGW).

Pour l’option 3C, la séparation des données est basée sur le routage de support de données PDCP.

Figure 3 : Double Connexion 4G-4G

  1. DC 4G-5G : Déploiement NSA

Le mode de déploiement de la 5G s’appuiera en 2020 sur une double connectivité 4G-5G (mode NSA – Non Standalone Architecture). L’opérateur conserve le cœur de réseau 4G (EPC), la signalisation entre l’accès radio et le cœur de réseau est réalisée par l’entité eNB. On parle d’option 3

Remarque : si le cœur de réseau était 5G on parlerait alors d’option 7, tout chose égale par ailleurs.

Pour l’option 3, le terminal UE est sous le contrôle de la station de base 4G et lors de la demande de connexion radio avec la station de base eNB (LTE PCell), le terminal va être configuré pour monter un support radio NR avec la station de base gNB (dénommée en-gNb : E-UTRAN – NR gNB pour rappeler le mode DC).

Plan de contrôle : Sur l’interface radio, le terminal UE est contrôlé par l’entité eNB et en-gNB (par des messages RRC). La signalisation (CP : Control Plane) est échangée entre les deux stations de base via le lien backhaul X2.

L’application X2AP réalise plusieurs fonctions comme le rappelle la figure 4 :

Figure 4 : les fonctions supportées par l’application X2AP

Plan Utilisateur : Le terminal UE peut être connecté simultanément sur l’entité eNB et en-gNB pour le plan utilisateur ou uniquement avec l’entité en-gNB.

La fonction DC 4G-5G option 3 se décline en trois sous options (figure 4) en séparant le support au niveau de l’accès radio (split bearer) ou en créant un support au niveau du cœur de réseau (MCG ou SCG) :

  • option 3 : La séparation du support (split bearer) est réalisée par l’entité MeNB. Le trafic (UP : User Plane) est transmis à travers le lien X2 vers l’entité SgNB (Slave en-gNB) ;
  • option 3a : La création d’un bearer secondaire (SGC) s’effectue au niveau du cœur réseau (SGW) et le flux de données est transmis sur deux supports (bearer) complémentaires, l’un vers l’entité MeNB, l’autre vers l’entité SgNB ;
  • option 3x : La création d’un bearer est réalisée au niveau du cœur radio (SCG) et la séparation du bearer est réalisée par la station de base secondaire (SCG split bearer).

Figure 5 : Les options 3/7 vert à gauche, 3a/7a (en bleu), 3x/7x vert à droite du mode NSA

L’option 3x consiste à séparer le support DC au niveau de la station de base gNB. L’entité eNB peut conserver un ou plusieurs bearer avec le cœur de réseau (MCG bearer) ou ne gérer que la signalisation entre l’accès radio (eNB/en-gNb) et le cœur de réseau.

Dans le cas du split-bearer, les données sont distribuées ou dupliquées entre les deux nœuds radios. L’équilibrage de charge est réalisé de manière dynamique par le nœud d’ancrage (MeNB ou SgNB) en fonction du trafic, c’est-à-dire par l’entité PDCP du nœud d’ancrage (MeNB pour l’option 3 et SgNB pour l’option 3x).

Dans la suite, on appellera indifférent SgNb ou en-gNB.

IoT, Blockchain, IA, machine learning : Des technologies disruptives?

Les évolutions technologiques récentes vont apporter des changements profonds dans les domaines de la santé, de la logistique, le transport, l’énergie, l’agriculture, …

Si le déploiement de l’IoT (Internet of Things) destiné à collecter un ensemble d’informations constitue la première brique de cette évolution, la plus-value de cette transversalité numérique ne peut être obtenue qu’en garantissant la sécurisation des données collectées et le traitement efficace de ces données.

En cela, la technologie Blockchain s’insère dans l’écosystème de l’IoT en apportant un stockage des données, en assurant le transport sécurisé des données échangées et en permettant la traçabilité des données.

Quant aux traitements des données, l’intelligence artificielle (IA) permet de les valoriser et de les traduire en informations exploitables facilitant ainsi l’analyse décisionnelle des systèmes complexes. De surcroît, les méthodes d’apprentissages autonomes (Machine Learning) permettent également de classifier les données et d’apporter des outils de prédictions des pannes.

Les applications IA pourraient être mise en œuvre sur des lames de serveurs au plus proches des données collectées (MEC : Mobile Edge Computing).

Ainsi, les secteurs de la santé (capteurs et IA pour détecter l’évolution des maladies), du transport (véhicules autonomes), des chaînes d’approvisionnement (réparation des chaînes de production avant la cassure des pièces usées, l’approvisionnement en flux tendus), de l’énergie (délestages des sites industriels en assurant un transport de l’énergie au plus proche) seront impactés par la complémentarité de ces technologies disruptives.

Dans ces écosystèmes de plus en plus complexes, la donnée reste l’élément fondamental et le premier maillon d’une nouvelle ère économique. Les cabinets d’analystes estiment une évolution constante du marché des capteurs de l’IoT pour atteindre une centaine de milliards de dollars d’ici 2023 et une croissance du taux actuariel (CAGR – Compound annual growth rate) de 13%.

SigFox est le premier opérateur à s’être positionné sur le marché de la transmission sans fil des données issues des capteurs en déployant le réseau de transmission longue portée à basse consommation (LPWAN : LoW Power WAN).  Ce réseau LPWAN répond à la demande des compteurs intelligents (smart-meters, compteur d’eau, compteur de gaz), à la gestion des villes (smart-city) pour lesquels la communication est à latence élevée.

Aujourd’hui, l’opérateur Télécom SigFox est concurrencé par l’opérateur QoWiSio, l’opérateur Américain Ingénu, et l’alliance LoRaWAN avec le déploiement de LoRa par les opérateurs télécoms historiques.

Le réseau cellulaire 4G se positionne également sur ce secteur en étendant ses fonctionnalités pour répondre à l’émergence du marché de l’Internet des Objets. Ce réseau dédié aux communications Machine à Machine (MTC – Machine Type Communication) est destiné à devenir le premier réseau cellulaire LPWAN (Low Power WAN). Le premier avantage est de pouvoir rapidement apporter une couverture mondiale avec optionnellement une qualité de service.

L’IoT cellulaire (par son réseau d’accès NB-IoT, LTE-M et prochainement 5G NR) devrait connaître la plus forte croissance avec en point de mire, entre 10 000 et 100 000 objets connectés sous la couverture d’une seule station de base. Orange a ouvert son réseau LTE-M en novembre 2018, comme annoncé dans un précédent article traitant du cellular IoT.

Le réseau 5G quant à lui va permettre d’apporter de nouvelles solutions pour les communications M2M à temps réel (missions critiques URLLC : Ultra Reliable Low Latency Communication) pour répondre au besoin du secteur de l’automobile et de l’industrie (IIoT – Industrial IoT).

Le laboratoire LIAS s’intéresse à ces différentes technologies notamment comme application visée (de manière non exhaustive) le smart-grid, le secteur du transport,…

Dans les prochains articles je reviendrai plus particulièrement sur le MTC (réseau 4G).

Il est à rappeler que ces métiers s’adressent aux femmes et aux hommes, je vous invite à consulter le site femmes-numérique.fr

Blockchain, intelligence artificielle, big data, cyber sécurité, objets connectés, cloud…

 

L’initiative

 

Le réseau 5G – 5GS

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

I. L’accès radio 5G

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

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

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

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

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

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

Ainsi, l’entité MME qui gère à la fois l’attachement des mobiles, la localisation et la création des supports (bearers) se décompose en deux entités fonctionnelles en 5G :

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

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

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

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

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

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

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

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

Virtualisation du réseau EPC : Concept NFV/SDN

La virtualisation du réseau permet  la montée rapide en charge de travail en mettant en route plusieurs machines virtuelles (VM) et les services réseaux associés (commutation logique, routage logique, pare-feu logique, équilibrage de charge logique, VPN logique, accélération WAN, compression d’entête, …) pour chaque charge de travail.

Les avantages de la virtualisation sont les suivants :

  • amélioration de l’efficacité des serveurs ;
  • gestion des charges de travail grâce au déploiement de VM et des services réseaux;
  • gain des performances du réseau et flexibilité;
    • déplacement de VM
    • équilibrage de charge
    • agilité de l’infrastructure réseau
    • Réduction du temps de déploiement : Time To Market
    • Chaînage de service en déployant les VMs  par application

I – La virtualisation du réseau

La virtualisation consiste à déployer plusieurs machines virtuelles sur un serveur physique. Afin de pouvoir partager les ressources matérielles (CPU, cartes réseaux, ….), il est nécessaire d’installer un logiciel de virtualisation appelé hyperviseur. Chaque machine virtuelle dispose de son propre système d’exploitation. Les pilotes et les périphériques sont stockés dans un domaine de l’hyperviseur accessible à chaque VM, les VMs utilisent des périphériques virtuels.

Un hyperviseur de type paravirtualisation nommé bare-metal ou type 1 s’exécute directement sur le serveur physique.

La gestion des VM et la sécurité est un point critique : les règles de pare-feu doivent être modifiées (rajoutées ou supprimées) à chaque fois qu’une nouvelle VM est rajoutée ou supprimée. Les premières solutions déployées pour les Datacenters permettent l’automatisation du provisionnement (provisionning) en fonction de l’ajout, la suppression ou la modification de VM.

Ainsi, lorsque le client exprime un besoin, par exemple mettre à jour des données sur son site web hébergé au niveau d’un Datacenter, cette charge de travail peut nécessiter la collecte et la fusion de données, des calculs, un stockage et une mise en forme spécifique des résultats à travers un tableur. L’hébergeur peut ainsi activer plusieurs VM (ou container) sur un seul serveur ou sur plusieurs serveurs. Dans ce cas il est nécessaire que les serveurs communiquent les uns avec les autres, on parle de communication est/ouest afin de répondre à la requête du client (communication nord/sud).

Au niveau du serveur physique, les VM sont isolées les unes des autres. L’isolation de VM non chaînées garantie qu’aucun échange ne peut s’effectuer entre les deux VM.  Cependant, l’échange de données entre les VMs est possible via un routage mais cela nécessite l’établissement de règles de sécurité : les règles du pare-feu entre chaque VM doivent être définies par rapport aux applications hébergées sur la VM. La micro-segmentation qui consiste à mettre en réseau plusieurs VM pour une charge de travail donnée peut être sécurisée par des pare-feux virtuels.

Dans le cas d’architecture réseau traditionnel, le trafic des charges de travail doit passer par un point de contrôle unique comme par exemple un pare-feu physique avec des règles établies pour tous les types d’application. Cette architecture, nommée hairpinning, créée un goulot d’étranglement ce qui rend donc cette architecture inefficace lorsque les charges de travail ne nécessitent pas les mêmes traitements. Son avantage est la stabilité du réseau et son prix.

Grace au déploiement du réseau virtuel :

  • la charge de travail est indépendante du réseau physique, c’est-à-dire de la configuration de VLAN, de la liste de contrôle d’accès, des règles de pare-feu. La micro-segmentation permet le transfert de données entre VMs isolées via un routage logiciel et un pare-feu logiciel ;
  • plusieurs charges de travail peuvent co-exister sur le même réseau physique et sur les mêmes entités, permet ainsi de partitionner virtuellement plusieurs services (slicing network).

L’automatisation permet de mettre en route ou d’éteindre l’ensemble des VM concernés et de provisionner les politiques adéquates des pare-feux pour chaque charge de travail.

L’orchestration permet de configurer toutes les charges de travail sur les serveurs physiques (planification des VMs en fonction des serveurs physiques existants et gestion des réseaux virtuels en fonction des capacités physiques réelles de la couche de transport).

II – Network Functions Virtualization

Jusqu’à présent, nous avons vu que la virtualisation permettaient de déplacer vers des serveurs banalisés :

  • les équipements de traitement de réseau (pare-feu, dpi, accélérateur WAN, équilibrage de charge, …)
  • les équipements de fonction réseau (commutateur, routeur)
  • les serveurs de stockage et serveur cache

Figure 1 : Virtualisation de fonctions réseaux

D’autres fonctions réseaux sont également virtualisables :

  • les entités du réseau mobiles : HSS, HLR, MME, SGW, PGW, SGSN, GGSN
  • les réseaux d’accès : BTS, BSC, NB, RNC, eNB

L’approche NFV a été initiée par l’organisme ETSI dans l’objectif de virtualiser les services et fonctions du réseau et de gérer les VMs en fonction des demandes des utilisateurs. Nous définirons l’architecture NFV dans un prochain article.

III – NFV/SDN

On distingue :

  • la virtualisation du réseau consistant à virtualiser sur des pools de ressources des applications (calcul, stockage et service réseau –DHCP – DNS – Parefeu logiciel – équilibrage de charge) et à gérer au niveau de l’hyperviseur les fonctions réseaux logiciel et la sécurité logicielle;
  • le NFV qui exploite les fonctions de la virtualisation en gérant et orchestrant les fonctions de virtualisation par un contrôleur. Le NFV est une architecture de virtualisation s’appuyant sur l’infrastructure physique (NFVI) sur laquelle tourne plusieurs VM. La gestion des ressources physiques du serveur (CPU, RAM, accès réseau, disques virtuels, switchs/routeurs virtuels, …), et la durée de vie des VMs sont contrôlés par une couche de gestion et d’orchestration NFV nommé MANO (Management and Orchestration) et qui est piloté par le système BSS/OSS de l’opérateur
  • le SDN consistant à séparer le plan de contrôle et le plan de données en centralisant au niveau d’un contrôleur l’intelligence de l’infrastructure matérielle. L’objectif est de provisionner automatiquement les fonctions du réseau de transport

 

Le concept de SDN (Software Defined Networking) repose sur un découplage entre le plan de commutation local aux équipements réseaux et le plan de contrôle. Le NFV peut s’appuyer sur le SDN en autorisant une gestion centralisée du réseau. La conséquence majeure est que le réseau devient programmable et peut être couplé aux applications métiers des usagers.

L’approche NFV propose d’extraire les fonctions réseaux des équipements dédiés et de les faire fonctionner dans un environnement virtualisé. Pour les opérateurs réseau, l’approche NFV constitue une opportunité de proposer des services de manière plus agile, capable de fonctionner à des échelles extrêmement importantes, mais surtout de manière plus rapide en exploitant les propriétés intrinsèques à la virtualisation. Ainsi, la virtualisation du réseau et de la sécurité permet de gérer des commutateurs virtuels et routeurs virtuels à la charge de l’hyperviseur, ainsi que la sécurité (pare-feu logique, VPN logique et équilibrage de charge logique).  On parle de réseau Overlay car les VMs et les services exploitent le réseau physique sous-jacent (cf.http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-architecture-reseau-classique/ ).

Ainsi, le contrôleur SDN est utilisé

  • pour programmer l’infrastructure réseau virtuel afin de définir les règles de routages et de sous-réseaux pouvant être utilisées pour interconnecter des fonctions réseaux virtualisés (VNF) : SDN Overlay ;
  • par une fonction réseau virtualisée afin de traduire la fonctionnalité réseau virtualisée attendue à la configuration physique du réseau. Le contrôleur SDN est donc une fonction VNF dans l’infrastructure NFV.

A titre d’exemple, l’un des avantages du SDN/NFV est le chaînage de service dynamique virtuel (traffic steering and chaining service) défini par une politique de flux. Lorsque l’utilisateur souhaite accéder à un service, le contrôleur SDN défini un ensemble de fonction réseaux à déployer. Le rôle du NFV est alors de gérer les VMs à mettre en œuvre et le contrôleur SDN gère le routage des flux.

Nous étudierons le SFC – Service Function Chaining dans le prochain article

Les deux technologies SDN/NFV réduisent ainsi l’OPEX (un seul environnement, automatisation des taches, …) et le CAPEX (remplacement du matériel devient une mise à jour logicielle).

S4-LTE Advanced en préparation

LTE-Advanced

Dans un précédent article, je présentais les différentes évolutions attendues ces prochaines années pour accroitre le débit. Le LTE-Advanced, en exploitant une bande de 100 MHz (agrégation de canaux) permettra d’atteindre un débit de 1 Gbps, s’approchant ainsi des performances de la Fibre Optique.

On apprend depuis peu que Samsung s’est lancé dans la fabrication du premier terminal S4-LTE-A. On peut supposer la sortie de l’appareil pour février 2014 à Barcelone (les plus optimistes espèrent la sortie en fin 2013).

Les principales évolutions concernent encore le débit, mais l’évolution de la norme propose aussi des fonctionnements optimum dans un environnement multi-radios (WiFI, SuperWiFi, 2G, 3G), et des améliorations sur la couverture par l’ajout de relais;

Au niveau du réseau de l’opérateur, les évolutions concernentle Gigabit Ethernet synchrone dans le backhaul de l’opérateur.Je rappelle que l’architecture dorsale du réseau IP s’appuye sur un réseau SDH, né de la commutation de circuit. SDH étant un système de transport Synchrone (Synchronous Digital Hierarchy), mais la comutation de circuit n’est pas optimal pour la DATA, raison pour laquelle le réseau éthernet replacer le transport SDH.

Revenons sur le smartphone 4G LTE-A, l’annonce montre que Samsung est à la pointe en terme de smartphone, mais le marché est il prêt?

En France, on peut espérer le LTE-A en 2015, mais au Japon (NTT DoCoMo) , les premières antennes devraient être installées en 2014.

Etonnament, en décembre 2012 et Mai 2013, c’est aussi NTT DoCoMo et Samsung qui ont fait le buzz en annoncant la 5G sur la fréquence de 11 GHz ou 28 GHz.

Je n’ai pas relayé l’information, car la première difficulté à résoudre est la portée des ondes à cette fréquence, et que le choix de la fréquence ne fait pas une norme;

Par contre, pour ceux qui aimeraient savoir quelles évolutions peuvent être annoncees pour la norme 5G, je vous propose de vous intéresser à la modulation multi-porteuses FBMC, au réseau Ad’Hoc (le mobile permettant de relayer le signal et dans ce cas l’idée d’un fonctionnement à 11 GHz ou 28 Ghz est plus réaliste), au codage conjoint (et s’intéresser aussi à la norme HEVC pour la vidéo permettant de réduire le débit de la transmission vidéo en conservant une bonne qualité QoE), à la radio-cognitive, et au relais.

Ce sont des pistes, à suivre …