Etablissement de la connexion radio – Partie 3 : La procédure

Nous allons maintenant étudier la procédure d’accès aléatoire.

Lorsque le terminal UE est en veille, il récupère les paramètres d’accès radio transmis par la station de base à travers les différents SIB. Les informations SIB sont diffusées dans la cellule sur des canaux communs. Notamment, le terminal UE prend connaissance du SIB2 mais aucune ressource radio spécifique lui est dédiée.

Pour obtenir des ressources dédiées le terminal utilise dans un premier temps des ressources communes à l’ensemble des terminaux pour contacter l’entité radio (nous traitons le cas en 5G avec l’entité gNb mais la procédure est identique pour les autres accès radio mobiles) et l’informer de sa demande. Les ressources PRACH étant accessibles à l’ensemble des terminaux, la procédure d’accès aléatoire doit être en mesure de détecter un conflit en cas de collision.

Pour limiter les collisions, la station de base propose un ensemble de préambules (64 maximum). Le terminal tire au hasard un préambule parmi la liste proposée (on parle d’accès aléatoire). Le préambule est une séquence de Zadoff-Chu définit par son index RAPID (Random Access Preamble ID, l’index fait une correspondance avec la racine de la séquence, se référer au premier article décrivant l’accès aléatoire).

Cependant, rien n’exclut l’hypothèse que deux terminaux UE choisissent séparément le même préambule au même moment et transmettent chacun leur demande sur des ressources fréquentielles identiques. On parle alors de collision.

La procédure est décrite par les échanges suivants :

msg1 : Le terminal UE envoie sa demande d’accès aléatoire en transmettant un préambule. Une fois le préambule émis, le terminal UE écoute la réponse de la station de base entre l’instant t1 et t2= t1+ Fenêtre_reception (T300)

msg2 : La station de base répond au terminal mobile UE en indiquant l’avance de temps (TA) que le terminal UE doit appliquer, et lui alloue des ressources radios pour le prochain message montant. La réponse est diffusée sur le canal commun à l’ensemble des terminaux via le canal PDCCH. Le CRC du message DCI est embrouillé par l’identifiant RA-RNTI. Lorsque le terminal UE décode le PDCCH avec son identifiant RA-RNTI, il lit le contenu diffusé dans le canal PDSCH.

msg3 : Le terminal UE envoie une unité de donnée MAC ou un message RRC avec une identité UE. Cet identifiant va permettre de résoudre les conflits.

msg 4 : La station de base gNB diffuse sa réponse en indiquant l’identité reçu du terminal dans sa reponse. Ainsi, en cas de conflit, le terminal pour lequel la réponse du gNb correspond à son identifiant a réussi son accès aléatoire, pour les autres la réponse msg4 est attendu jusqu’à l’expiration du temporisateur. Une nouvelle demande d’accès sera alors renouvelée dans la limite des demandes autorisées dans le message SIB2.

Figure 1 : Procédure d’accès aléatoire

Le terminal UE émet ses messages et attend les réponses dans des fenêtres temporelles définies par l’accès radio.

Figure 2 : Les temporisateurs de la demande d’accès

L’objectif est maintenant de comprendre :

  • comment la station de base est en mesure de détecter plusieurs requêtes d’accès aléatoire ;
  • comment s’effectue la résolution de conflit.

Nous partons sur l’hypothèse de 3 terminaux UE A, UE B et UE C qui envoient leur demande d’accès aléatoire au même moment et sur les mêmes ressources tempo-fréquentielles. Dans ce cas l’identifiant RA-RNTI pour chaque terminal est identique. On suppose de plus que les terminaux UE A et UE B choisissent le même préambule. Dans ce cas , il y a collision.

Figure 3 : Demande d’accès UE vers gNB

Les préambules 1 et 3 sont différents, cela signifie que les séquences de Zadoff-Chu transmises par les terminaux A et C (ou B et C) ne sont pas identiques. Comme les séquences sont orthogonales, l’entité gNB est capable de les détecter. Par contre, les séquences émises par les terminaux UE A et UE B sont identiques, la station de base ne détecte donc qu’un seul message (pensant qu’il s’agit de multi-trajets).

La station de base répond aux 3 terminaux simultanément. Les terminaux sont informés d’une réponse en décodant l’information DCI dans le canal PDCCH. Les terminaux vont ensuite lire le message RAR (Random Access Response) présent dans le canal PDSCH. Le contenu du message contient les préambules décodés par la station de base gNB :

Figure 4 : La réponse du gNB vers les terminaux (message RAR)

Les terminaux A et B enregistrent l’identifiant radio temporaire TC-RNTI1 avec le Timing Advanced mesurée par la station de base. Ce TA correspond évidemment à l’un des deux terminaux. Le terminal C enregistre sont identifiant temporaire C-RNTI3.

Pour lever la collision entre les terminaux A et B, chaque terminal envoie son message 3 (RRC Connection Request) avec l’identifiant temporaire TC-RNTI1 et leur identifiant aléatoire comme identité de l’UE (UE-identity).

Figure 5 : Les terminaux acquittent le message reçu auprès de l’entité gNB

Dans l’exemple ci-dessus, la station de base gNB reçoit la réponse des terminaux A et B avec, pour chaque UE, une identité aléatoire UE-identity. Cette réponse permet à la station de base d’identifier le terminal A et le terminal B et de faire la correspondance avec l’identifiant radio temporaire TC-RNTI1. La station de base détecte ainsi la collision. Dans la procédure, la station de base répond au terminal qui envoie le msg 3 en premier et ignore les autres messages msg3 qui portent le même identifiant temporaire TC-RNTI1. Elle reçoit également le message du terminal C avec l’identifiant temporaire TC-RNTI3. Elle fait donc une correspondance entre l’identifiant radio temporaire TC-RNTI3 et le terminal C UE-identity. Il n’y a pas de conflit.

Dans le chronogramme, on suppose que le terminal A est plus proche de la station de base gNb que le terminal B. Ainsi, la station de base reçoit d’abord le message 3 du terminal A et diffuse vers tous les terminaux un message de contrôle PDCCH DCI. Le contenu du message msg4 est transmis dans le canal PDSCH RRC_Connection_Setup avec la correspondance entre l’identifiant temporaire TC-RNTI1 et l’identité aléatoire UE-identity_A. La station de base diffuse le message qui est donc reçue par le terminal A et le terminal B. Le terminal A retrouve ainsi son identité temporaire UE-identity A dans le message de la station de base, les terminaux B et C reçoivent une réponse avec l’identité temporaire d’un autre terminal UE-identity A. Le terminal B attend la réponse du gNb (qui n’arrivera pas) jusqu’à la fin du temporisateur T300, le terminal C attend la réponse du gNB qui est transmise avant la fin du temporisateur T300.

Le message RRC_Connection_Setup permet également au terminal concerné de récupérer les informations de séquencement (attribution des ressources radio) pour la voie montante.

Les terminaux A et C vont donc pouvoir transmettre à la station de base la raison de leur demande d’accès (message NAS à destination de l’entité AMF), en encapsulant le message NAS dans la requête RRC Connection Setup Complete.

Le terminal B va refaire une procédure d’accès aléatoire.

Figure 6 : Signalisation montante pour les terminaux A et C, procédure aléatoire pour l’UE B

Figure7 : La procédure d’accès aléatoire complète

 

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

Etablissement de la connexion radio – Partie 1 : Les séquences aléatoires

La connexion radio s’effectue par un échange de signalisation entre le terminal UE et la station de base gNB.

La première étape, nommée Accès Initial (Initial Access) permet au terminal de se manifester auprès de la station de base en transmettant un préambule (procédure d’accès aléatoire ou RACH). En retour, le terminal se synchronise en Uplink avec la station de base et récupère un identifiant radio.

  • La séquence aléatoire RA

La procédure d’accès aléatoire est destinée à résoudre les possibles collisions si deux ou plusieurs terminaux souhaitent établir simultanément une connexion radio. Les étapes de la connexion radio sont :

1 – Le terminal UE émet un préambule dans le canal d’accès aléatoire PRACH

A l’instar de la 4G, le préambule est une séquence de Zadoff-Chu. La séquence est définie de la manière suivante :

N est la longueur de la séquence, N est un nombre premier. La séquence est nommée séquence d’accès aléatoire ou RA (Random Access),  z indice n exposant u représente la n-ième bit de la séquence de Zadoff-chu de racine u.

La u-ième racine est obtenue à partir de l’index de la séquence i transmis par la variable rootsequenceIndex.

Table 1 : Le numéro de séquence en fonction de i

Le numéro de séquence logique est porté par le SIB 2 rootsequenceIndex. A titre d’exemple, si l’on se réfère au tableau, ‘rootsequenceIndex = 22’ correspond à u=1 :

Table 2 : Correspondance entre i et u

Le signal émis est la transformée de Fourier sur N sous-porteuses dont l’amplitude de la n-ième sous porteuse est définie par la séquence de Zadoff-Chu (se référer à l’équation ci-dessus).

Pour la 5G, N prend pour valeur 139 ou 839. Si l’espacement entre sous-porteuses est de 1,25 kHz, le signal est émis respectivement sur une largeur de bande de 173,5 kHz ou 1048,8 kHz.

Figure 1 : Synoptique de transmission

La séquence de Zadoff-Chu possède des propriétés suivantes :

  • signal d’amplitude constante ;
  • bonne propriété d’autocorrélation permettant à la station de base de détecter une séquence par un pic sur la séquence d’’autocorrélation ;

la puissance d’intercorrélation entre deux séquence de Zadoff (q1 et q2 différents) est égale à 1/N.

La figure 1 représente l’autocorrélation de la séquence de Zadoff-Chu de 139 bits (25ème racine)

A partir de la connaissance de q et de N, les préambules émis est une séquence aléatoire avec un décalage cyclique  C possible est :

Figure 2 : Autocorrélation d’une séquence de Zadoff-Chu de longueur 139

Le canal physique PRACH transporte la séquence aléatoire RA précédée d’un préfixe cyclique et suivi d’un temps de garde.

Figure 3 : Le canal PRACH

On nomme TSEQ la durée de la séquence avec le préfixe cyclique, et TTG la durée du temps de garde. Soit τd l’étalement temporel du canal (le délai de propagation du canal dû aux multitrajets, s’exprime ne µS) et R le rayon de la cellule couverte par la station de base, alors :

A partir de ncs, on peut déterminer le nombre de séquences aléatoires possible à partir d’une séquence de Zadoff-Chu et vaut M/ncs.

A titre d’exemple, si M=839 et ncs=11 alors une séquence génère 76 RA différents.

En général, une cellule dispose de 64 codes RA, toutefois, 14 codes sont réservés pour la demande d’établissement radio lors d’un handover, c’est-à-dire sans contention, contention free et 50 pour la demande d’accès aléatoire avec contention.

La taille de la cellule permettant un accès initial se calcule à partir de la durée du temps de garde. La durée d’un slot est de 1 ms. La durée du préfixe cyclique permet de compenser l’étalement temporel du canal.  Par exemple, je fixe TCP=103.13 µs. Supposons une séquence aléatoire TSEQ=800µs. La durée  de la séquence dépend à la fois de la taille du message aléatoire (139 ou 839 bits) et de l’espacement entre porteuse. La durée du temps de garde TGP=1000-103.13-800=96.87 µs.

Figure 4 : Le format 0 du canal PRACH

Le temps de garde correspond au temps autorisé pour faire une transmission aller-retour : le mobile est synchronisé sur le lien descendant par la séquence de synchronisation de la station de base. Il reçoit le signal avec un retard qui dépend de la distance. La distance parcourue entre la station de base et le terminal est : d = c. t avec t le temps que met l’onde pour se propager de la station de base vers le terminal.

Si la séquence est de 800 µs, la célérité de la lumière est de 3.108 m/s soit 0.3 km/µs alors : d=0.3*96.87/2=14.5 km

  • Le format PRACH

La 5G supporte 13 formats différents, définit en fonction

  • de la longueur de la séquence RA ;
  • de l’espacement entre sous-porteuse : SCS=1.25 kHz ou SCS=15 kHz ;
  • de la longueur de la durée du préfixe cyclique ;
  • de la longueur de la séquence ;
  • du nombre de répétition.
  1. a) Les formats long : Formats 0, 1, 2 et 3

les formats longs ne sont utilisés que dans la bande FR1. Les formats 0 et 1 sont similaires aux formats 4G (préambule long format 0 et format 2). Les caractéristiques sont :

  • la longueur de la séance est de 839 bits ;
  • l’espacement de la sous-porteuse est de 1.25 kHz pour les formats 0,1,2 et 15 kHz pour le format 3. Dans ce cas, 6 RB sont utilisés dans le premier cas et 24 RB dans le second cas ;
  • Le facteur 1, 2 et 4 pour Nu correspond au nombre de répétitions.

Table 3 : Les formats PRACH 0 à 3 pour la 5G*

K est le facteur d’échantillonnage k=Ts/Tc avec la fréquence d’échantillonnage Fs=30.72 MHz et Tc=1/(SCS_max.Nfft). Pour l’interface radio 5G-NR l’espacement SCS maximal est de 480 kHz et le nombre d’entrée FFT est de 4096.

Fc=1.966080 GHz (1966080 kHz)

Format 0 :

CP length(Tcp) = 3168*k échantillons = 3168*64 *Tc sec = 3168*Ts ms = 3168/30720 = .1031 ms
sequence length (Tseq) = 24576*k échantillons = 24576*64*Tc= 24576/30720 =.800 ms

Format 1 :

CP length(Tcp) = 21024/30720 = .6844 ms
sequence length (Tseq) = 2*24576*k échantillons =1.6 ms

Format 2 :

CP length(Tcp) = 21024/30720 = .6844 ms
sequence length (Tseq) = 2*24576*k échantillons =1.6 ms

Format 3 :

CP length(Tcp) = = 3168/30720 = .1031

sequence length (Tseq) = 4*6144*k échantillons =0.8 ms

a) Les formats courts : Formats A1, A2, A3, A4, B1, B2, B3, B4, C0, C2

Les formats cours sont constitués de 139 bits, et l’espacement entre porteuses dépend de la numérologie (15 kHz ou 30 kHz pour la bande FR1 et 60 kHz ou 120 kHz dans la bande FR2).

Table 4 : Les formats PRACH court pour la 5G

Exemple du format A1 :

CP length(Tcp) = 288*k *(2^-μ) samples = 288*64 *1 samples =288/30720 = .009381 ms

sequence length (Tseq) = 2*2048*k*(2^-μ) samples = 2*2048*64 samples =(2*2048*/30720) ms = .1334 ms

Figure 5 : Le format A1 du canal PRACH

Figure 6 : Les formats du canal PRACH

Référence :

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 – 2ème article

2-1) Architecture du plan de contrôle

Dans l’architecture DC, chaque station de base gère son propre ordonnanceur : Chaque ordonnanceur est responsable de l’allocation des ressources radio-électriques dans la cellule. Il est cependant nécessaire de partager des informations de contrôle entre la cellule secondaire (en-gNB) et la cellule maîtresse (MeNB) comme le contrôle de la mobilité et la mesure du lien radio entre la station de base secondaire et le terminal UE.

Chaque nœud radio (eNB et en-gNB) dispose de sa propre entité RRC.

La connexion initiale s’effectue entre le terminal UE et la station de base 4G. La station de base 4G initie l’établissement du support radio avec la station de base en-gNB ce qui nécessite l’échange de signalisation RRC entre le terminal UE et la station de base en-gNB.

Le canaux radio de signalisation SRB sont transmis sur le groupe de cellules maîtresses MCG mais optionnellement, le terminal UE peut également échanger de la signalisation directement avec la station de base secondaire.

Pour transporter les messages RRC entre le terminal et les nœuds d’accès radio, les signalisations SRB (Signaling Radio Bearer) sont utilisés :

  • SRB0 concerne les messages RRC portant les informations du canal logique de contrôle commun CCCH (Common Control Channel)
  • SRB1 transporte les messages NAS précédent l’établissement du support SRB2 concernant les canaux logiques de contrôle dédié DCCH
  • SRB2 à l’instar du support SRB1 transporte les canaux logiques de contrôle dédié DCCH avec une priorité plus petite que le support SRB1. Le support SRB2 est toujour configuré après la mise en place de la sécuri :té du lien radio.
  • SRB3 transporte des messages RRC spécifiques au mécanisme DC et directement échangés entre l’entité SgNB et le terminal UE (optionnel).

Chaque entité MeNB et SgNB est configuré au niveau du lien radio pour communiquer des flux de données avec le terminal UE en fonction du mécanisme DC, on note :

  • MCG (Master Cell Group) : Des messages SRB1/SRB2 sont transmis directement entre le terminal et la station de base MeNB
  • Split SRB (SRB1+SRB1S, SRB2, SRB2S) : la signalisation SRB est séparée au niveau de la couche PDCP entre l’entité MeNB et SgNB. La signalisation SRB du nœud maître est donc transmise soit au niveau du nœud maître, soit au niveau du nœud secondaire et réciproquement, la signalisation SRB du nœud secondaire est donc transmise soit au niveau du nœud maître, soit au niveau du nœud secondaire. Les messages RRC du nœud secondaire peuvent être encapsulés dans les messages RRC de la station de base maîtresse.
  • SCG (Secondary Cell Group) : les messages de signalisation SRB3 sont transmis directement entre la station de base secondaire (SgNB) et le terminal.

Ainsi, dans le cas où le lien SRB3 est configuré entre le terminal UE et la station de base secondaire, les rapports de mesure du lien radio (CSI) et la mobilité peuvent être transmises directement vers l’entité en-gNB (figure 6). Sinon, ceux-ci sont transmis dans un containeur SRB2 entre les deux stations de bases par le message RRC Transfer.

Figure 6 : Architecture du plan de contrôle

Avant de procéder à la reconfiguration du lien radio pour la double connexion, la station de base doit vérifier la compatibilité du terminal UE (capability information).

2-2) Etablissement de la connexion radio

L’entité MeNB et en-gNB disposent de leur propre ordonnanceur : chacun gère la quantité de données à transmettre et l’allocation radio via des messages RRC. La signalisation RRC permet d’établir ou libérer le support data, de réaliser de l’agrégation de porteuses, de réaliser le handover vers une autre station de base, d’allouer un canal dédié.

Il est néanmoins nécessaire de configurer le support de signalisation (SRB : Signaling Radio Bearer) pour pouvoir transmettre les requêtes RRC. Il existe trois façon pour configurer le SRB au niveau de la station en-gNB :

1ère possibilité : La station de base maîtresse MeNB configure le SRB1 et SRB2 avec le terminal UE pour ses messages RRC. L’entité en-gNB transmet ses messages RRC à l’entité MeNB sur l’interface X2 et l’entité MeNB encapsule ses messages RRC en provenance (ou respectivement pour) l’entité en-gNB dans les supports de signalisation SRB2 vers (ou respectivement) depuis le terminal UE.

2ème possibilité : La station de base maîtresse MeNB utilise le support radio de signalisation SRB1/SRB2 pour ses propres messages RRC. La station de base secondaire en-gNB établit son propre support de signalisation SRB3 pour communiquer directement avec le terminal UE.

3ème possibilité : La station de base maîtresse MeNB établit une séparation de support (split bearer ou plus précisément split Radio Bearer) pour la signalisation : Les messages RRC de la station de base maitresse MeNB et les messages RRC de la station de base secondaire en-gNB encapsulés dans le support radio de signalisation SRB1/SRB2 peuvent être émis par l’entité MeNB ou l’entité en-gNB ou par les deux.

Une fois le support de signalisation radio configuré, chaque station de base MeNB et en-gNB peut transmettre ses données vers le terminal UE à travers les sous-couches PDCP, RLC et MAC (figure 7) :

Figure 7 : Architecture protocolaire pour la transmission de la signalisation (SRB)

Le trafic est partagé soit au niveau du cœur réseau (option 3a) soit au niveau de l’entité MeNb (option 3) ou au niveau de l’entité en-gNB (option 3X).

Le support MCG (Master Cell Group) est le support radio (radio bearer) fournit par la station de base maitresse MeNB (lequel peut aussi procéder à de l’agrégation de porteuses).

Le support SCG (Secondary Cell Group) est le support radio (radio bearer) fournit par la station de base en-gNB (lequel peut aussi procéder à de l’agrégation de porteuses).

D’un point de vue cœur réseau, on distingue deux supports différents. Pour bien comprendre la figure 6 et la notion de split-bearer, il faut revenir sur la définition du support.

Un bearer EPS porte des flux de trafic ayant les mêmes caractéristiques QoS (QCI, ARP, GBR, MBR) entre l’entité PGW et le terminal UE. Ce bearer est caractérisé par :

  • des paramètres de QoS (latence, débit, taux d’erreur) ;
  • des identifiants d’acheminement permettant le routage de bout en bout.

Le bearer S1-U et le bearer radio forment une connexion logique entre l’entité SGW et le terminal UE.

La notion de split bearer concerne le partage du support radio au niveau de l’entité PDCP de la station de base eNB ou de la station de base secondaire en-gNB. Ce partage aurait pu être réalisé par l’entité RLC ou MAC. Dans le cas du DC 4G-5G, c’est l’entité PDCP qui partage le support. Dans l’option 3, le split bearer concerne le support MCG, dans l’option 3x, le split bearer concerne le support SCG.

Figure 8 : Architecture protocolaire DC option 3, 3a et 3X

Le rappel de la définition du bearer est importante pour expliquer cette figure : Le bearer MCG correspond à un support transmis sur l’interface radio LTE, le bearer SCG est transmis sur l’interface radio NR.

Le bearer MCG et le bearer SCG sont définis par des caractéristiques de QoS et de routage. Du point de vue du cœur réseau, le routage est établi de bout en bout par l’entité MME entre l’entité SGW et le nœud radio, celui-ci peut être le nœud radio eNB ou le nœud radio gNB.

Donc, d’un point de vue cœur réseau il y a deux supports : le bearer MCG et le bearer SCG.

Le point de terminaison du bearer MCG est soit la station de base eNB soit la station de base en-gNB. Le point de terminaison du bearer correspond au tunnel TEID. Par contre, le bearer MCG est transmis sur l’interface radio LTE, donc si le point de terminaison est l’entité eNB, le flux est pris en charge par l’entité eNB, si le point de terminaison est l’entité gNB, le flux est acheminé vers l’entité eNB.

La figure 8 montre que le traitement est effectué au niveau de l’entité PDCP, le chiffrement est donc défini par un chiffrement NR ou LTE.

Ainsi, le standard défini :

  • un bearer MCG ou SCG entre le cœur réseau et l’entité eNB ;
  • un bearer MCG ou SCG entre le cœur réseau et l’entité gNB.

Les flux du bearer MCG qui sont acheminés sur l’entité eNB sont transmis intégralement sur les entités protocolaires PDCP 4G, RLC 4G et MAC 4G de l’entité eNB, alors que les flux du bearer SCG acheminés sur l’entité eNB sont pris en charge par l’entité protocolaire PDCP 5G de l’entité eNB et transmis intégralement à l’entité RLC 5G et MAC 5G de l’entité gNB.

Le même raisonnement peut être appliqué au niveau des flux du bearer MCG ou SCG acheminés sur l’entité gNB.

C’est ce que montre la figure 8 (spécification TS 37.340 figure 4.2.2.3) et le terminal dispose de deux entités PDCP : l’entité 4G PDCP configurée lors de la demande de session de la part du terminal, et l’entité 5G PDCP est configurée lors de la double connexion. L’entité 5G PDCP est gérée par la station de base MeNB (Option 3) ou par la station de base SgNB  (option 3a ou 3x).

Le split-bearer introduit la notion d’un seul bearer vu du coté cœur réseau qui est partagé entre l’entité eNb et en-gNb par l’un des deux nœuds (option 3 par l’entité eNb et option 3x par l’entité en-gNB).

Remarque : Il est à noter que le split bearer peut être configuré uniquement en DL. Ainsi dans le cas de l’architecture DC option 3x plus particulièrement, les équipementiers ont choisi de séparer le flux descendant entre l’entité en-gNB vers l’entité MeNB pour pouvoir augmenter le débit descendant mais le flux montant est ancré au niveau de l’entité MeNB.

Ainsi, pour l’option 3x, lorsque l’entité en-gNB réalise la séparation du support au niveau de la couche NR-PDCP, le mobile traite les données dans les couches NR RLC et LTE RLC.

Figure 9 : Option 3x – Split bearer pour le lien descendant

Figure 10 : Option 3a : MCG/SCG bearer

Figure 11 : Option 3x : MCG et split-bearer

Dans un prochain article nous traiterons le call-flow

IoT, BigData, IA : Un monde 100% connecté pour les systèmes cyber-physique (CPS)

Dans le précédent article, j’ai évoqué différentes technologies complémentaires, sans illustrer par des exemples concrets les applications attendues. Je vais présenter dans cet article la notion de système cyber-physique (CPS : Cyber Physical System).

Un système cyber-physique est un système bouclé qui intégre la remonté d’informations issues de capteurs physiques via des réseaux de connectivités vers un serveur de décision lequel par une boucle de rétroaction contrôle les processus physique.

(image issue du site suivant : https://smart-industries.fr/fr/challenges-et-opportunites-des-systemes-cyber-physiques)

Le serveur décisionnel permet de superviser les processus physiques, les commander et de faire de la détection de fautes afin de planifier une réparation avant l’apparition de défaut. On parle alors de reconfiguration ou de ré-organisation dynamique.

Un système de production CPPS (Cyber Physical Production System) concernent la coopération entre sous-systèmes autonomes afin de reconfigurer dynamiquement une chaîne de production. A titre d’exemple, une chaîne de fabrication est caractérisée par un ensemble de flux comme :

  • une prévision à la demande (flux poussée : on planifie les ressources dont on aura besoin lors de la conception d’un produit) ;
  • une prévision en temps réel (flux tirés : on commande à la demande pour satisfaire le besoin);
  • une prévision au plus juste de la demande (flux tendus)

L’objectif est donc de mesurer en temps réel le stock existant, de prévoir la commande en prenant en compte les délais d’approvisionnement et en fonction de la demande du produit, de reconfigurer la chaîne de production à la volée en cas de défaut d’un élément afin de maintenir l’activité de la chaîne de production. A cela, le système CPSS vise à prendre en compte d’autres paramètres comme :

  • le coût fluctuant de la matière première
  • le coût de l’énergie ou l’équilibrage de la consommation/production d’électricité

afin de réduire le coût énergétique (énergie verte).

C’est dans cette vision d’optimisation de la logistique, de la consommation énergétique que s’inscrit l’industrie 4.0 (e-usine ou smart-factory : les usines intelligentes).

Un autre exemple est le chargement/déchargement de cargo. Aujourd’hui, les opérateurs déploient des solutions de tracker sur les conteneurs. Ces solutions doivent fonctionner tout autour de la terre, ainsi on peut citer comme technologies qui nous intéressent ici le réseau d’accès LTE-M et NB-IoT. Ce dernier est plus adapté pour de faible quantité d’information. En dehors du blog, on peut aussi citer l’exemple MONARCH de Sigfox qui permet de réaliser le roaming vers les pays qui sont couverts par cet opérateur.

Rajoutons maintenant une connectivité sur les grues et les véhicules guidés (AGV : Automatic Guided Vehicule) et revenons à notre exemple : les ports de futur.

On peut ainsi imaginer une communication entre les grues, les véhicules, les conteneurs, et un serveur centralisé (fog) qui orchestre toute la logistique permet ainsi de réduire la durée d’attente de chargement ou déchargement.

Le déploiement d’antennes 4G et 5G à l’intérieur des entreprises (exemple de DAS : Distributed Antenna System) permettront de commander automatiquement les chariots élévateurs en fonction de toutes les informations recueillies et traitées (Big Data) comme les produits finis, les stocks en cours, …

A moins que … ce soient les machines qui commandent les hommes?

https://www.francetvinfo.fr/economie/emploi/video-cash-investigation-travail-vis-ma-vie-de-manutentionnaire-chez-lidl_2381539.html

Il faudra que je pense à écrire un article sur : Faut il avoir peur des nouvelles technologies?

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)

Présentation de l’architecture CUPS : Control and Use Plane separation

I) L’architecture du réseau mobile 4G

Le réseau de mobiles 2G/3G/4G est rappelé sur la figure 1 :

Figure 1 : Architecture des réseaux de  mobiles

Le réseau est composé de trois accès radios complémentaires (2G/3G/4G) et de deux trois cœurs réseaux, l’un dédié à la gestion des appels téléphoniques (exploitant la technique de commutation de circuit – MSC), le second dédié à la gestion des sessions Data (exploitant la technique de commutation de paquets) en 2.5G/3G (SGSN, GGSN), le troisième est le cœur réseau tout IP pour la 4G. Ce cœur réseau est représenté sur la figure 2.

Sur la figure 2 apparaît une nouvelle entité nommée TDF (Traffic Detection Function). Son rôle est d’analyser le trafic (DPI – Detection Packet Inspector) pour détecter des flux sous surveillance de l’opérateur afin de proposer des fonctions réseaux spécifiques aux flux détectés.

Figure 2 : Evolution de l’architecture réseau 4G (R11)

Lorsque l’utilisateur souhaite établir une session Data, l’entité MME transmet à l’entité SGW et à l’entité PGW (via le protocole GTP-C) la requête de création de support avec les caractéristiques associées au support (priorité, débit, temps réel, …)

Ainsi, les entités SGW et PGW gèrent à la fois le plan de contrôle et le plan de données utilisateurs.

II) L’approche SDN : CUPS (Control User Plane Separation)

Le CUPS propose de séparer en deux parties les entités SGW et PGW. Le contrôleur se nomme SGW-C et PGW-C et le plan de données deviennent les entités SGW-U et PGW-U.

Les règles de traitement de flux sont transmises du contrôleur aux entités du plan utilisateur par une session de règle SX. Cette session permet d’injecter les règles de traitement via le protocole PFCP

Figure 3 : La séparation du plan de contrôle et du plan utilisateur (CUPS)

L’entité fonctionnelle CP s’interface avec plusieurs entités fonctionnelles UP et une entité fonctionnelle UP peut être partagée par plusieurs entités fonctionnelles CP. Le contrôle des flux reste ancré sur un unique SGW-C mais différents SGW-U peuvent être choisis pour différentes connexion PDN. L’entité fonctionnelle CP (SGW-C et PGW-C) fait une sélection (via une recherche DNS évoluée) de l’entité UP en prenant en compte :

  • la localisation de l’entité UE afin de réduire la latence si besoin
  • la capacité de l’entité fonctionnelle UP de prendre en compte les caractéristiques de l’entité UE
  • La charge (overload) de l’entité SGW-U

Pour le dernier point, l’entité SGW-C doit supporter les caractéristiques Load Control transmises sur l’interface Sx.

Localisation de l’UE

Selon la définition, l’aire de service de l’entité SGW est un ensemble de zone de suivis (Tracking Area  TAI) entiers. A chaque mise à jour de localisation, l’entité UE reçoit de la part du MME une liste de zone de suivi (TA) correspondant à la position du mobile UE couvert par le SGW. Deux mobiles UE dans la même cellule peuvent avoir des listes de TA différentes pour ne pas solliciter des ressources réseaux sur les mêmes eNB.

Dans le cas de la séparation en plan de contrôle et plan utilisateur, le SGW-C n’a pas de lien physique avec les stations de base eNB mais communiquent avec les entités fonctionnels comme le MME, le SGSN, le PGW et le SeGW (Security Gateway pour la demande de création de connexions PDN. Le lien avec les eNB est maintenu via l’interface S1-U avec l’entité SGW-U. Dans le cas du CUPS, l’aire de service du SGW-U correspond à l’aire de service du SGW.

Ainsi, en cas de relocalisation sur une entité fonctionnelle SGW-U, il est préférable de trouver l’entité  SGW-U qui couvre la liste de TA (TA1, TA2, TA3) fournit par l’entité MME au mobile UE.

Capacité de l’entité fonctionnelle UP

Les entités fonctionnelles du plan utilisateur peuvent implémenter des fonctionnalités spécifiques qui ne seront utilisées que par des nombre limités d’entités UE comme par exemple, un type de service supportant les communications à haute latence (High Latency Communication HLcom). Pour ce type de service, le SGW-U implémente des fonctionnalités spécifiques de buffer.

Ainsi, en cas de relocalisation sur une entité SGW-U, il est préférable de trouver l’entité  SGW-U qui supporte les fonctionnalités attendues, comme par exemple un buffer étendu pour les communications à latences élévées.

Les conséquences du CUPS

L’avantage de contrôler plusieurs entités SGW-U par un seul SGW-C est de simplifier la gestion de la mobilité et mieux gérer l’équilibrage de charge. De plus, avec la virtualisation du SGW-U, il est possible d’allouer plus ou moins de ressources au SGW-U.

La zone de service du SGW-C peut être plus grande que la zone de service du SGW-U. Dans ce cas, le SGW-C est partitionné et chaque SGW-C gère un SGW-U. Pour assurer la compatibilité entre les différentes évolutions du standard, le MME considère le SGW-C comme un SGW classique. L’alignement de la zone de service du SGW-C partitionné avec le SGW-U assure que la liste de TAI fournie par le MME au SGW-C partitionné permet de sélectionner les SGW-U couvrant ces zones de suivis (la liste de TAI).

Si, pour un UE donné, le SGW-C a sélectionné plusieurs entités SGW-U dans ce cas, la zone de service des SGW-Us réunis couvrent au moins la zone de service du SGW-C.

III) SDN et PFCP : les protocoles d’injections de règles

L’entité de contrôle SGW-C et PGW-C injecte les règles de traitement de flux aux SGW-U et PGW-U afin de connaître les règles d’acheminements des paquets. L’injection de règles s’effectue via l’interface Sxa ou Sxb. Le contrôleur crée une session Sx avec la fonction du plan utilisateur via le protocole d’injection PFCP (Packet Forwarding Control Plane).

Les protocoles OpenFlow, Forces n’ont pas été retenu car ils ne répondaient pas aux critères recherchés :

  • facilité d’implémentation aux fonctions du plan de contrôle (SGW-U, PGW-U) ;
  • latence faible ;
  • gestion de toutes les caractéristiques existantes 3GPP
  • facilité d’étendre ou maintenir le protocole pour supporter les fonctions 3GPP
  • Compatibilités avec les standards 3GPP précédents

Ainsi, le protocole PFCP a été retenu et propose les propriétés suivantes :

  • Une association Sx doit être établie entre la fonction CP et la fonction UP avant d’établir une session Sx (injection de règles). La fonction CP et UP sont appelés Nœuds Sx.
  • Les procédures entre les nœuds Sx sont :
    • Procédure d’établissement, de mise à jour ou de libération de l’association Sx
    • Procédure vérifiant que la session Sx est active (alive)
    • Procédure de contrôle de charge et de congestion afin d’équilibrer la charge sur d’autres fonctions du plan utilisateur (SGW-U, PGW-U) et réduire la signalisation vers l’UP en cas de congestion.
  • La session Sx provisionne les règles d’acheminements de flux du contrôleur vers l’entité du plan utilisateur. La session Sx peut correspondre aux règles d’une connexion PDN pour un UE ou pour une session TDF
  • Procédure de gestion Sx PFD pour injecter les PFD (Packet Flow Descriptions) pour chaque application.

 

Notions sur le SD-WAN et positionnement par rapport aux réseaux de mobiles

Dans l’article précédent, nous avons présenté le principe du Network Slicing, consistant à définir des règles d’acheminement pour un réseau particulier. Le Network Slicing s’appuie sur le principe de découpage de la fonction de contrôle et du plan utilisateur (SDN), la virtualisation des services réseaux (NFV) et du chaînage des services réseaux (SFC).

L’objectif du SD-WAN est aussi d’assurer une bonne connectivité aux outils cloud à travers internet (google suite pour le travail collaboratif, Microsoft 360, Amazon, azur …).  Le SD-WAN utilise donc les mêmes technologies vu précédemment (SDN, NFV, SFC) pour programmer rapidement l’accès d’un nouveau site  (en général il s’agit de connecter une entreprise) sur le réseau opérateur et offrir à ce dernier les différents services (cloud, FTP, tunnels entre site, …) demandés. On  parle  de  « zero touch  deployment », l’objectif  est  de  pouvoir provisionner (pousser automatiquement)  un  logiciel  et  une  configuration  sur  un  nouvel  équipement  SD-WAN  installé avec l’agilité réseau possible par ce type d’équipement (cf. la solution easy go network).

Le SD-WAN est une solution permettant à l’opérateur de déployer une solution de connectivité réseau pour tout nouveau site via des outils de provisionning réseau de haut niveau et d’assurer une interconnexion des différents sites de l’entreprise entre eux.

Ainsi, le SD-WAN permet à l’opérateur de fournir les règles d’acheminements au niveau de ces équipements pour gérer les applications critiques vers un réseau implémentant du MPLS et les applications non critiques vers des solutions de best-effort. L’opérateur peut ainsi, via une plateforme, provisionner et orchestrer ses équipements réseaux pour garantir à  l’entreprise l’accès à  Internet, l’accès à la téléphonie, l’accès à des services FTP sécurisés entre les différents sites de l’entreprise ou vers un Cloud et ceci quel que soit l’emplacement géographique du nouveau site par rapport aux autres sites de l’entreprises ou des solutions hébergées.

La notion de WAN dans l’approche SD-WAN indique que le pilotage du réseau est autorisé entre plusieurs opérateurs, afin qu’un entreprise dans un pays puisse installer une entité dans un autre pays et profiter des mêmes accès et services réseaux avec la même qualité. Ainsi, le SD-WAN supporte différents types de connectivités (MPLS, xDSL, FTTx, LTE, …).

Le SD-WAN est donc une solution de connectivité sur les différents types de réseau (fixe et mobile) ) travers le monde. Son application est ciblée sur les entreprises et sur les applicatifs utilisés par les entreprises à travers leur réseau de connectivité.

Les tranches de réseau : Network Slicing

Cet article propose de faire une première synthèse des technologies abordées dans les articles précédents comme la virtualisation matérielle, la virtualisation des fonctions réseaux NFV, le chaînage des fonctions service (SFC) et l’approche de découpage du plan de données et du plan de contrôle (SDN).

La programmation des réseaux est une tendance émergente qui permet de transformer l’usage du réseau en s’appuyant sur des solutions logicielles. Si la virtualisation (cf  article : http://blogs.univ-poitiers.fr/f-launay/2018/01/23/virtualisation-du-reseau-epc-concept-nfvsdn/ )a permis de déployer des services réseaux facilement sous le contrôle d’un orchestrateur (cf article : http://blogs.univ-poitiers.fr/f-launay/2018/02/04/network-functions-virtualisation-nfv-pour-le-reseau-4g5g/), l’enchainement des fonctions de services (NVFFG ou SFC : article http://blogs.univ-poitiers.fr/f-launay/2018/01/28/le-sfc-service-function-chaining-mise-en-oeuvre-du-sdnnfv-sur-le-reseau-de-mobile-4g/) permet la flexibilité et l’adaptabilité du réseau en fonction de la demande.

Le chainage de fonction service s’appuie sur une approche SDN (cf article http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-architecture-reseau-classique/) pour programmer les besoins de services d’acheminements de flux et de contrôle de flux en proposant une abstraction de la couche réseau aux services applicatifs.

Grâce à ces différentes technologies (SDN, NFV, SFC), la programmation du réseau apporte une flexibilité et une modularité permettant de créer simultanément plusieurs réseaux logiques (virtual network) pilotés par la couche application via des API. Les descripteurs (NVFD) permettant de définir chaque besoin permettent ainsi de tailler un réseau à la demande et adapté au besoin (NFV MANO)

Ces différents réseaux logiques sont appelés des tranches de réseaux ou network slices et correspond à la mise en réseau de bout en bout entre un client UE et un service réseau (IoT, IP, IMS, …) en s’appuyant sur une infrastructure réseau virtuelle (SDN Overlay) ou physique (SDN). Chaque tranche de réseau est isolée des autres et gérée/contrôlée de manière indépendante (bac à sable grâce à la virtualisation et à la gestion NFV MANO) et s’adapte à la demande (easy go network).

Une tranche de réseau (network slice) est une collection de ressources, qui combinées ensemble de manière appropriées, permettent de créer un support réseau répondant aux exigences demandées. Les types de ressources pour le network slicing sont :

  • Fonction réseaux (NF : Network Function) : Bloc fonctionnel qui fournit une capacité réseau spécifique et réalise une fonction demandée. La fonction réseau est généralement une instance logicielle tournant sur une infrastructure physique mais, il peut aussi s’agir d’un équipement matériel dédie ou une combinaison des deux.
  • Infrastructure matérielle  dédiée ou partagée pouvant héberger les fonctions réseaux.

La figure 1 représente ainsi un exemple d’architecture du network slicing.

Figure 1 : L’architecture réseau en tranche

En proposant un réseau pour les différents besoins, le réseau opérateur supporte des besoins en terme de qualité de service (temps réel ou non, débit garanti ou non, bande passante, latence) très différent en fonction des besoins, comme le montre la figure 2.

Figure 2 : Approche horizontale des sous réseaux logiques de l’opérateur

I) Approche NFV

Orchestration

L’orchestration est un processus clé pour le network slicing qui s’appuie sur des descripteurs définies par exemple sur des accords de niveau de service SLA. L’orchestration est définie comme un processus de sélection optimale de ressources pour répondre entièrement aux demandes de service de chaque client. Le terme optimal réfère à l’optimisation de la politique de flux en fonction de l’abonnement du client (SLA) qui gouverne les choix du processus d’orchestration sur la sélection de ressources au niveau de l’infrastructure physique sur les POP.

Isolation

L’isolation est une exigence primordiale afin de pouvoir faire fonctionner en parallèle plusieurs tranches de réseau qui se partagent les mêmes ressources physique et les mêmes infrastructures.

L’isolation fait référence à :

  • Performance : Chaque tranche est définie par rapport à une exigence de service particulière et exprimées sous forme de KPI. L’isolation assure le respect du KPI si le service est accepté quel que soit la congestion ou les niveaux de performances des autres tranches
  • Sécurité et confidentialité : les fautes ou les attaques sur une tranche n’aura aucune incidence sur les autres tranches. De plus, chaque tranche met en œuvre ses propres fonctions de sécurités qui interdit entre autre à ce que des entités non autorisés aient un droit de lecture ou d’écriture sur la configuration d’une tranche de réseau.
  • Gestion : Chaque tranche est gérée de manière indépendante comme un réseau séparé.

II) Approche SDN

L’architecture SDN découple le plan de contrôle du plan de données permettant de configurer dynamiquement le plan d’acheminements des données comme un service à la demande du client. Cela répond aux attentes du network slicing qui a besoin de satisfaire à la demande à un large éventail de services de manière agile et à un coût optimal.

Concernant le réseau SDN, une ressource est une instance ou une entité qui peut être utilisé pour fournir un service en réponse aux demandes d’un client.  Le contrôleur est une entité centralisée qui planifie les ressources en fonction du contexte du client :

  • Contexte du client représente toutes les informations qui le contrôleur a besoin pour un client donné. Il contient :
    • un groupe de ressource : Le groupe de ressource est une vue de toutes les ressources que le contrôleur peut offrir pour répondre sur mesure à la demande du client. Le groupe de ressources est proposée par des API sur l’interface nord et correspond donc à une couche d’abstraction du réseau pour répondre au besoin du client ;
    • le support client contient les opérations et les règles de politique autorisées pour le client, ainsi que des informations relatives aux services demandés pour ajuster les actions entre la demande du client et le contrôleur.
  • Contexte serveur représente toutes les informations nécessaires au contrôleur pour interagir avec les ressources physiques accessibles via son interface sud.

Figure 3 : L’architecture SDN du network slicing