Archives pour la catégorie Technique

E2E Network Slicing : le découpage du réseau de bout en bout (Partie 2)

Posté le by - 4 259 vues
5

[bws_captcha]Cet article est la suite de :

« E2E Network Slicing : le découpage du réseau de bout en bout (Partie 1)

III) La virtualisation du cœur de réseau

Les entités du cœur de réseau AMF, SMF, NEF, PCF sont des fonctions qui peuvent être virtualisées. Ces fonctions gèrent le plan de contrôle du réseau de mobiles et les performances fonctionnelles sont analysées au niveau du support opérationnel OSS (FCAPS).

L’entité UPF peut également être virtualisée, cette fonction gère le plan utilisateur. La fonction UPF possède des capacités d’aiguillage de trafic à partir de la classification de flux UL-CL (Uplink Classifier). Ainsi, la fonction UPF peut avoir le rôle de point de branchement (multi-homing), point d’ancrage de session (PSA : PDU Session Anchor) ou classificateur de flux pour définir le prochain saut. La classification de flux est une fonctionnalité supportée par la fonction UPF afin de diriger le trafic localement en fonction des filtres appliqués au trafic UE.

Le contrôle des fonctions virtuelles dans le cœur de réseau 5G est réalisé par deux fonctions nommées NSSF (Network Slice Selection Function) et NRF (Network Repository Function).

  • Le rôle du NSSF est de sélectionner le jeu de tranches réseau que l’utilisateur va pouvoir utiliser en fonction de son contrat d’abonnement (SLA) pour lui apporter la QoE (Quality of Experience) souhaitée. Le choix du slice se faisant au moment de l’enregistrement du mobile, la fonction NSSF dialogue avec la fonction AMF ou la fonction NSSF d’un autre PLMN.
  • Le rôle du NRF est de fournir un contrôle des fonctions virtuelles (NF) et des services proposés par les fonctions virtuelles.
    • La fonction NRF est un catalogue qui est mis à jour au moment de l’activation de la fonction virtuelle (enregistrement) et mis à jour lorsque la fonction virtuelle est redimensionnée. Elle propose ainsi un service de découverte de fonctions virtuelles
    • Toute fonction virtuelle NF peut demander à la fonction NRF, par une procédure de souscription, d’être informée dès qu’une nouvelle instance est créée.

Figure 5 : Inscription d’une fonction virtuelle au niveau de la fonction NRF (TS 29.510)

Une sous-instance virtuelle est composée au minimum de fonctions AMF, SMF, PCF, NRF. L’opérateur (OSS) met en place un ou plusieurs sous réseaux virtuels SNI et peut à tout moment activer ou désactiver un sous-réseau (procédure NSI figure 3). Chaque fonction activée vient se déclarer auprès de la fonction NRF (figure 5).

Une instance de réseau permet de gérer un type de service. Le type de service est défini par la variable S-NSSAI. Le S-NSSAI contient 2 champs :

  • SST sur 8 bits défini le type de slice (Slice Service Type)
    • SST = 1 : eMBB (normalisée 3GPP) ;
    • SST = 2 : URLLC (normalisée 3GPP) ;
    • SST = 3 : mMTC (normalisée 3GPP) ;
    • SST = 4 : V2X (normalisée 3GPP) ;
    • SST= 5 : HMTC (High Performance MTC normalisée 3GPP – R.17 – mise à jour janvier 2022);
    • SST=6 : HDLLC (High Data Low Latency Communication 3GPP – R.18 mise à jour juin 2023)
    • SST de 128 à 255 sont définis par l’opérateur.
  • SD (Slice Differentiator) est une information optionnelle qui permet de décliner plusieurs types de sous-service dans une catégorie SST donnée afin de différencier les clients.

La fonction NSSF permet d’identifier les NSI. Cette fonction est configurable via une API REST.

Voici un exemple de configuration de la fonction NSSF :

https://host:port/v1/nssf/configurations/nsiprofiles
POST
Content-Type: application/json
BODY
{
    « name »: « NSI001 »,
    « nrfUri »: « https://nrf.bloglaunay.com »,
    « nsiId »: « 1 »,
    « targetAmfSets »:
    [
        {
            « regionId »: « 01 »,
            « setId »: « 001 »,
            « setFqdn »: « set001.region01.amfset.5gc.mnc111.mcc208.3gppnetwork.org »
        },
        {
            « regionId »: « 01 »,
            « setId »: « 002 »,
            « setFqdn »: « set002.region01.amfset.5gc.mnc111.mcc208.3gppnetwork.org »
        }
    ]
}

Pour être plus complet, la configuration de la fonction NSSF permet aussi de diriger le choix de la fonction NRF en fonction du NSSAI demandé.

D’un point de vue opérateur : Lorsqu’une tranche de réseau est mise en œuvre, la fonction AMF peut toujours mettre à jour la configuration S-NSSAI de la fonction NSSF afin d’informer celle-ci des types de service supportés par la fonction AMF sur une zone de localisation TA.

Une fonction AMF peut gérer plusieurs tranches de réseaux S-NSSAI (il n’y a pas de limite fixée au niveau du cœur de réseau).

Figure 6 : La mise à jour de la fonction NSSF

L’entité NSSF sélectionne le (ou les) instances de réseau NSI correspondant(s) à la demande du mobile à partir du (ou de la liste des) S-NSSAI et détermine ainsi les fonctions AMF candidates correspondant spécifiquement (ou au mieux) à la demande de l’UE. Eventuellement, l’entité NSSF interroge la base de données NRF (Network Repository Function).

Figure 7 : Procédure d’enregistrement et sélection du NSI

L’entité NSSF renvoie à la fonction AMF qui l’a interrogée, la valeur NSSAI autorisée sur la zone TA et la liste des fonctions AMF candidates (figure 7).

Lorsque la station de base s’active (mise en route ou suite à une procédure de ré-initialisation), elle interroge les fonctions AMF pour connaître les tranches de réseaux (slices) supportées par chaque fonction AMF accessible comme le montre la figure 8.

 

Figure 8 : La déclaration des slices supportées par les fonctions AMF auprès de l’entité gNB

Si la station de base gNB était déjà en fonctionnement, alors elle est informée des modifications NSSAI apportées au niveau de la fonction AMF via le message NG Setup request (figure 9).

Figure 9 : La mise à jour des slices supportées par les fonctions AMF auprès de l’entité gNB

Lorsque le mobile s’active, il réalise une procédure d’attachement auprès d’une fonction AMF. L’attachement se fait sur une fonction AMF parmi toutes les fonctions AMF qui ont été activées par le support opérationnel OSS et accessible par la station de base gNB.

La sélection de l’entité AMF est réalisée au moment de la procédure d’attachement. Le choix est effectué à partir de l’identifiant NSSAI émis dans la requête NAS REGISTER. La station de base gNB reçoit la requête RRC qui porte le message NAS et l’indicateur NSSAI à partir duquel il sélectionne une fonction AMF. Si plusieurs fonctions AMF candidates peuvent être choisies (cf figure 8), la station de base gNB fait son choix par équilibrage de charge.

La fonction AMF sélectionnée par l’entité gNB interroge la base de données UDM pour vérifier que l’indicateur NSSAI demandé par le terminal (requested NSSAI) est accepté. L’entité UDM transmet à la fonction AMF le NSSAI autorisé pour ce client (allowed NSSAI). A partir de ce moment, la fonction AMF consulte la fonction NSSF (Network Slicing Selection Function) à partir d’une requête GET en indiquant la liste des S-NSSAI autorisés.

Si après consultation de la fonction NSSF, la fonction AMF sélectionnée initialement (appelée AMF source) par la station de base n’est pas appropriée pour les services demandés (NSSAI), alors la fonction AMF source réalise la procédure de ré-allocation de la fonction AMF.

Concernant la ré-allocation (lors de la procédure d’attachement), deux options sont possibles :

Dans le cas de l’option A (figure 10), en fonction des informations de souscription et de politique locale, la fonction AMF source décide d’envoyer la requête initiale vers la fonction AMF cible via le message Namf_Communication_N1MessageNotify portant le message NG-RAN Reroute Message.

Cependant, comme il ne peut y avoir qu’un seul point de terminaison N2 entre l’entité gNB et la fonction AMF pour un UE donné, la fonction AMF cible met à jour le point de terminaison auprès du gNB via le message NG AMF Configuration Update.

 

Figure 10 : Procédure de ré-allocation de la fonction AMF pour la gestion des transches de réseau du mobile UE : Option A

Dans le cas de l’option B (figure 11), en fonction des informations de souscriptions et de politique locale, la fonction AMF source décide d’envoyer le message NGAP Reroute NAS Message à l’entité gNB afin que celle-ci formule une nouvelle requête d’attachement vers la fonction AMF cible.

Figure 11 : Procédure de ré-allocation de la fonction AMF pour la gestion des tranches de réseau du mobile UE : Option B

Au niveau du cœur de réseau, le mobile s’enregistre sur une seule fonction AMF.

Le mobile peut demander à profiter de plusieurs tranches de réseaux (figure 12), les fonctions AMF, NSSF font parties des fonctions communes à toutes les tranches. Les fonctions PCF et NRF peuvent être communes ou spécifiques à une tranche de réseau.

Pour que le mobile puisse recevoir ou émettre des données, il faut mettre en place une session PDU. La session PDU est contrôlée par la fonction SMF, avec des règles PCF spécifiques.

Figure 12 : Les tranches de réseaux : Fonctions communes et spécifiques.

Il est aussi possible d’ajouter des fonctionnalités supplémentaires comme imposer la direction de trafic (trafic steering) en sortie du réseau de mobiles Gi-LAN afin d’apporter des services comme de l’optimisation vidéo, optimisation http, un cache CDN, un cache de réalité virtuelle, un détecteur de malware, une fonction parentale, un parefeu, …

Au niveau du mobile, le mobile fait une demande d’enregistrement auprès du cœur de réseau. Le mobile indique dans sa requête NAS les tranches de réseaux souhaitées (Requested NSSAI). Le requested NSSAI correspond soit au NSSAI configuré pour le PLMN (configured NSSAI), soit au NSSAI autorisé pour le PLMN (allowed NSSAI). Ce dernier (allowed NSSAI) a été récupéré lors d’un précédent enregistrement. Si le mobile n’a aucun NSSAI configuré pour le PLMN sur lequel il s’enregistre, alors il transmet l’information NSSAI configurée par défaut (Default configured NSSAI).

L’information NSSAI est configurée sur la mémoire non volatile du mobile. Il ne revient pas au standard 3GPP d’indiquer où est stockée cette information mais aux fabricants de terminaux. Le mobile peut contenir plusieurs informations NSSAI, chaque NSSAI est couplée à l’identifiant SUPI et est identifiée par le PLMN ID (cf. TS 24.501). Si on change l’identifiant SUPI, les informations NSSAI sont supprimées de la mémoire du terminal.

Dans le cas des smartphones, l’information NSSAI est configurée par défaut (Default configured NSSAI).

Dans le cas des terminaux IoT et URLCC, l’information NSSAI devrait être provisionnée afin de limiter l’impact de charge au niveau de la fonction AMF grand public lorsque les terminaux IoT s’allumeront.

Le mobile doit stocker les informations S-NSSAI du HPLMN. Si le mobile est enregistré sur un réseau visité VPLMN, le mobile doit aussi sauvegarder le NSSAI configuré pour ce VPLMN et doit faire la correspondance avec les S-NSSAI qu’il peut exploiter sur le réseau HPLMN. Le mapped NSSAI est utilisé en roaming pour faire la correspondance entre un S-NSSAI spécifique (128 à 255) du réseau H-PLMN et le S-NSSAI correspondant dans le VPLMN.

Lorsque le mobile demande l’établissement d’une session PDU, il transmet dans le message NAS l’information S-NSSAI souhaitée et des règles URSP (UE Route Selection Policy).

 

Le dernier paragraphe sera traité dans un autre article.

Etablissement de la connexion radioélectrique : Comparaison 4G et 5G

Posté le by - 2 609 vues
Répondre

En reprenant la procédure de demande de connexion d’accès 5G SA, j’ai constaté qu’il y avait deux types de requêtes RRC différentes pour la même procédure.

Le premier échange pour l’établissement de la connexion radioélectrique est identique aux échanges entre le terminal et la station de base 4G, le deuxième échange diffère dans le type de message transmis.

La question qui se pose est donc la suivante : Pourquoi trouve t’on deux types de messages différents pour la même procédure et laquelle est correcte?

Afin de comprendre laquelle était juste, j’ai comparé plusieurs articles pour m’apercevoir qu’au final, la spécification TS 3GPP a évolué entre mars 2018 et novembre 2018. Ce qui explique les deux formalismes différents rencontrés.

Ainsi, je propose dans cet article de comparer la demande d’accès radioélectrique entre un mobile et une station de base 4G et entre un mobile et une station de base 5G en se basant sur la spécification R15 (qui est à l’état gelé).

  1. Introduction

Lorsque le mobile souhaite établir ou ré-établir la connexion radioélectrique avec la station de base, il doit dans un premier temps informer la station de base de sa présence par la procédure d’accès aléatoire avec collision. Il s’agit de la connexion initiale destinée à gérer les conflits éventuels si plusieurs mobiles font simultanément une demande d’accès.

Ensuite, la station de base sécurise le lien radioélectrique (la strate d’accès AS) par chiffrement et intégrité de la strate radioélectrique AS (Access Stratum).

Nous allons présenter dans cet article la connexion radioélectrique sur l’interface 4G et sur l’interface 5G, mettant ainsi en avant les différences et les similitudes.

2) La procédure d’accès aléatoire avec collision 4G

La procédure d’accès aléatoire avec collision, lors de l’établissement ou du rétablissement de la connexion avec un nœud radioélectrique est décrite à la figure 1.

Le mobile choisi un préambule aléatoirement parmi la liste des préambules proposées par la station de base 4G (message SIB2) et transmet sa demande via le canal physique PRACH avec une puissance initiale P.

Le signal PRACH est transmis sur une fréquence porteuse et pendant une sous-trame qui permet de calculer la valeur RA-RNTI d’émission :

En cas de non-réponse de la station de base eNB, le mobile retransmet le même canal PRACH en augmentant la puissance d’émission. Le nombre maximal de retransmission est indiqué par l’information système porté par le SIB2.

Le risque de collision est lié au fait que plusieurs mobiles peuvent transmettre le message PRACH au même instant (donc avec le même identifiant RA-RNTI). La collision ne se produit que si deux mobiles émettent simultanément avec le même préambule.

Lorsque la station de base eNB reçoit le canal physique PRACH, elle calcule l’avance de temps TA et répond au mobile. Le mobile écoute le canal physique PDCCH (Physical Downlink Control Channel) à la recherche de l’information de contrôle DCI format 1A ou 1C dont le RRC est mélangé avec l’identifiant RA-RNTI. Lorsque le mobile récupère l’information DCI correspondant à la réponse d’une demande d’accès aléatoire avec l’identifiant RA-RNTI, le mobile récupère les données correspondantes qui sont transmises par la station de base dans le canal physique PDSCH (i s’agit de la trame MAC RAR).

La trame MAC RAR (Random Access Response) contient l’indice du préambule, l’avance de temps TA, la ressource à utiliser (UL Grant) pour la transmission dans le canal montant et l’identité temporaire TC-RNTI (Tempory Cell RNTI). C’est par l’indice de préambule que le mobile est capable de savoir si la réponse lui est destinée (sauf en cas de conflit). Ainsi, si deux mobiles ont fait simultanément la demande d’accès aléatoire avec deux préambules différents, chaque mobile trouvera son identifiant dans la trame MAC RAR.

Le mobile initialise son avance de temps TA et répond avec le message RRC ConnectionRequest contenant :

  • l’identité temporaire S-TMSI (Shortened Temporary Subscriber Identity), si le mobile est déjà attaché;
  • un nombre aléatoire dans le cas contraire (40 bits).

Si deux mobiles avaient fait une demande d’accès aléatoire simultanément avec le même préambule, alors l’entité eNB reçoit les deux message RRC ConnectionRequest sur les mêmes ressources radioélectrique, elle répond au mobile pour lequel elle a pu décoder la requête par le message RRC ConnectionSetupComplete comprenant :

  • l’information DCI dans le canal physique PDCCH ;
  • l’en-tête MAC RAR contenant l’élément de contrôle UE CRI (Contention Resolution Identity). Cet élément de contrôle reproduit l’identité du message RRC ConnectionRequest, permettant ainsi de résoudre la collision.

Le mobile récupère l’information DCI à partir de l’identité TC-RNTI et récupère, à partir de l’information DCI, la description de ses données dans le canal physique PDSCH.

Si deux mobiles avaient simultanément fait une demande d’accès aléatoire avec le même préambule, seul un mobile reçoit la réponse avec l’identifiant S-TMSI ou le numéro aléatoire choisi, le conflit est ainsi résolu.

Après résolution de collision, l’identité temporaire TC-RNTI devient l’identité définitive C-RNTI attribuée au mobile.

Le mobile confirme la connexion radioélectrique en indiquant son C-RNTI dans l’élément de contrôle de la trame MAC du message RRC ConnectionSetupComplete.

Figure 1 : La demande d’accès aléatoire en 4G

 

3) La procédure de connexion radioélectrique 4G

Dans le message RRC ConnectionSetupComplete, le mobile transfère le message NAS dédié au cœur de réseau. Il peut s’agir d’une demande d’attachement et d’établissement de support, ou d’une demande de service (ServiceRequest) pour le ré-établissement d’un support.

Figure 2 : La demande de ré-établissement de support en 4G

Les 4 premiers messages  concernent la procédure d’accès aléatoire. Dans le 5ème message RRC ConnectionSetupComplete, le mobile confirme la connexion du support radioélectrique et transmet la raison de sa demande (message NAS : Non Access Stratum);

L’entité eNB transfère la requête auprès du MME via le message X2 Initial UE Message (non présenté ici). Si l’entité MME acquitte la demande, alors la station de base eNB va procéder à la sécurisation du lien radioélectrique par la requête RRC Security Mode.

Une fois la capacité de chiffrement des messages validés par le mobile (RRC Security Mode Complete), la station de base configure un nouveau support radioélectrique pour l’échange de trafic (RRC Connection Reconfiguration).

 

4) La procédure d’accès aléatoire avec collision 5G

Dans le cas de la procédure d’accès aléatoire 5G, la bande passante est découpée en partition de bande BWP. Dans chaque sous bande BWP, la station de base diffuse le bloc SSB (signal de synchronisation et le canal BCCH) permettant au mobile de se synchroniser en temps et en fréquence et de lire les informations portées par le message MIB.

Pour faire sa demande d’accès aléatoire, le mobile recherche la partition BWP d’accès initiale. La partition de bande initiale correspond à une sous-bande de fréquence dans laquelle la station de base émet le bloc SSB avec en plus un espace de recherche sur lequel le mobile pourra scruter le message d’information DCI transmise par la station de base en réponse à la requête PRACH du mobile.

Si la station de base gNB peut émettre des slots SSB dans des faisceaux différents (beam sweeping), le mobile sélectionne le faisceau de meilleure qualité.

A l’instar de la 4G, le mobile transmet la demande d’accès par le canal PRACH avec une puissance P. Néanmoins, la valeur d’identifiant RA-RNTI se calcule de la manière suivante :

Si le nœud radioélectrique reçoit le canal physique PRACH, il calcule l’avance de temps TA et il transmet la trame MAC RAR (Random Access Response) au mobile (message 2) en lui attribuant les ressources radioélectriques pour le prochain message montant (UL Grant) et l’identité temporaire TC-RNTI (Tempory Cell RNTI).

Figure 3 : La demande d’accès aléatoire en 5G

 

Pour plus d’information sur la procédure RACH, se référer à l’article suivant : http://blogs.univ-poitiers.fr/f-launay/2019/10/14/etablissement-de-la-connexion-radio-partie-3-la-procedure/

5) La procédure de connexion radioélectrique 5G

Sur le web, on trouve deux procédures de connexion radioélectrique :

  • l’une antérieure à la Release V15.4.0 (par exemple : 3GPP TS 38.401 V15.3.0 (2018-09)) où l’on retrouve les mêmes messages que la procédure de connexion radioélectrique 4G
  • la version officielle pour laquelle les messages sont dorénavant les suivants (message RRC similaire en supprimant le mot Connection)

Figure 4 : Les messages RRC pour la demande d’accès aléatoire en 5G

Ainsi, en s’appuyant sur la Figure 8.1-1: UE Initial Access procedure du document 3GPP TS 38.401 V.15.4 ou supérieure (jusqu’à V16.2), on observe le call-flow suivant.

Figure 5 : La procédure d’accès initiale en 5G

 

6) Conclusion

La procédure d’accès initiale en 4G et 5G reste assez similaire, l’approche simplifiée de cet article ne permet pas d’entrer dans les détails de la sélection de faisceau pour l’accès initial 5G. Je prendrai le temps dans un prochain article pour le détailler.

Massive MIMO : Fonctionnement (Troisième Article)

Posté le by - 4 687 vues
Répondre

Voici le troisième article sur le déploiement du Massive MIMO.

Se référer aux articles précédents :

Massive MIMO : Définition (Première Partie)

Massive MIMO : Description de l’antenne (Deuxième partie)

La spécification pour le LTE définit 8 modes de transmission, le LTE-Advanced en défini 10 et un onzième mode est rajouté dans la release R.11. A part le mode TM1 qui ne nécessite qu’une seule antenne en émission et en réception, les autres modes permettent :

  • d’apporter une meilleure robustesse du canal par de la diversité en émission ou par la gestion de faisceau ;
  • d’améliorer la capacité par une transmission MIMO. Dans le cas du MIMO, le nombre de couches MIMO dépend du nombre de transmission décorrélées entre l’émetteur et le récepteur. Soit H la matrice du canal de propagation, le rang du canal correspond au nombre de couches MIMO possible.

Il est donc nécessaire d’avoir une antenne avec une colonne d’éléments rayonnants, la polarisation cross-polaire permet de doubler la diversité.

Une antenne est alors configurée par :

  • un seul élément rayonnant ;
  • deux éléments rayonnant en cross-polaire ;
  • une colonne d’élément rayonnant (avec une seule ou deux polarisation) ;
  • de plusieurs colonnes, chaque colonne contient plusieurs éléments rayonnants (en nombre égal).

Dans le cas des antennes actives, plusieurs AE sont regroupés dans un TRX, et

On définit les caractéristiques de l’antenne par une lettre A à I :

Figure 14 : La configuration des antennes (extrait livre : « LTE-Advanced Pro, Une étape vers le réseau de mobiles 5G », LAUNAY, PEREZ)

Les modes de transmissions nécessitent une configuration d’antenne :

  • TM1 : SISO n’utilise qu’une seule colonne et une seule polarité
  • TM2 : Diversité en transmission nécessite 2 ou 4 colonnes d’éléments rayonnants. Elle peut donc utiliser la configuration d’antenne D (une colonne de polarisation +/- 45°), E, F, H ou I. Avec deux colonnes, le codage utilisé est le code d’Alamouti SFBC (Space Frequency Block Codes), avec 4 colonnes on rajoute de la diversité temporelle FSTD (Frequency Shift Time Diversity).
  • TM3 : SU-MIMO en boucle ouverte avec diversité CDD (Cyclic Delay Diversity) nécessite 2 ou 4 colonnes d’éléments rayonnants. Elle peut donc utiliser la configuration d’antenne B, D (une colonne de polarisation +/- 45°), E, F, H ou I.
  • TM4 : SU-MIMO en boucle fermée avec la configuration d’antennes B,D,E,F,H ou I
  • TM5 : MU-MIMO avec la configuration d’antennes B,C,E,F,H.
  • TM6 : Multiplexage spatiale pour la formation de faisceau avec la configuration d’antennes B,C,E,G (plusieurs colonnes) par précodage numérique (PMI)
  • TM7 : Multiplexage spatial pour la formation de faisceau et MIMO dans une direction donnée en exploitant l’angle d’arrivée (AoA) ou direction à l’arrivé (DoA). Le mobile ne distingue plus une antenne physique comme dans les modes précédents mais une antenne virtuelle (cf. figure 4) en s’appuyant sur des éléments rayonnants à égales distances (ULA : Uniform Linear Array) dont la distance est inférieure à lambda/2 (lambda est la longueur d’onde). Ce mode nécessite la configuration d’antennes B,C,E,G.
  • TM8 : Introduit dans la R.9, le mode TM8 est similaire au TM7 avec deux couches.
  • TM9 : SU-MIMO et MU-MIMO à 8 couches.

Pour le mode TM7, la spécification 3GPP introduit la notion d’antenne virtuelle AP5 : le terminal ne voit qu’une seule antenne virtuelle mais l’orientation numérique du faisceau est obtenue en apportant un déphasage et un gain constant sur chacune des antennes physiques. Une antenne physique est nommée dans cet article par antenne individuelle : le même signal est transmis sur 4 TRX avec une pondération différente, chaque TRX est connecté à une antenne individuelle.

Figure 15 : La connexion de l’antenne virtuelle et physique

Le standard 3GPP introduit la notion de port d’antenne, qui une nouvelle fois peut apporter de la confusion. Un port d’antenne est un port logique.

Tableau 1 : Les ports d’antenne pour la 4G

Comme l’indique la table 1, les signaux de références correspondent à un numéro de port d’antenne. Les ports d’antennes correspondants au UE Specific RS sont utilisés pour la formation du faisceau (obligatoirement supporté en mode TDD et optionnel en mode FDD).

Les signaux de références sont référencés à un numéro de port d’antenne, mais plusieurs ports d’antennes différents transmettent le signal vers la même antenne individuelle (antenne physique) ou transmis vers plusieurs antennes individuelles. La station de base gère la correspondance entre un port d’antenne et l’antenne individuelle.

Dans le cas de la formation d’un faisceau numérique (beamforming), le calcul des pondérations à effectuer sur chaque antennes individuelle (nommé aussi poids) est réalisé par la station de base en s’appuyant sur le rapport de retour d’état du canal 4G (CSI à partir des signaux de références) ou à partir des signaux de références sur le lien montant.

II-2) Les signaux de références

Un signal de référence (CRS ou CSI-RS) est une séquence pseudo-aléatoire transmise sur chaque antenne individuelle. La séquence pseudo-aléatoire permet au récepteur de séparer les différentes séquences CSI-RS et d’estimer la qualité du signal reçu au niveau de chaque séquence de référence.

Le récepteur n’a pas besoin de connaître le nombre d’antennes individuelles de l’antenne MIMO (ou Massive MIMO, il doit savoir combien de signaux de référence il doit mesurer. Il retourne ainsi l’état du canal de propagation ayant affecté chaque signal de référence. Pour que cette information soit utile, il est nécessaire que les signaux de références soient décorrelées. Ainsi, chaque signal de référence doit être transmis sur une et une seule antenne individuelle.

Dans le cas du LTE (R8, R9), le MIMO était limité à 4 antennes. L’exploitation de 4 signaux de références CRS suffit.

Si la release 10 augmente à 8 signaux de références CSI-RS, il est nécessaire de monter à 16 (R.13) puis 32 (R.14) signaux de références CSI-RS pour augmenter le nombre de chaîne de transmission TRX. Mais cela reste insuffisant pour fonctionner avec une antenne massive-MIMO 64T64R sauf si l’on transmet deux séquences CSI-RS sur deux antennes individuelles dont la polarisation est croisée (il s’agit ici d’une hypothèse, je n’ai aucune certitude sur ce point.)

Pour lever cette limitation, dans le cas LTE-FDD la station de base utilise la combinaison des signaux SRS et CSI-RS. Le signal SRS est le signal de référence émis par le terminal mobile vers la station de base. Ainsi dans le cas de la 4G TDD, il est plus efficace d’exploiter l’estimation du canal sur le lien montant.

Pour les modes TM7 et TM8 en 4G, la station de base utilise les signaux de références UE-RS. Pour la station de base 5G, la station de base s’appuie sur le signal de référence SRS du lien montant.

Dans le cas de la 5G à 3,5 GHz, les signaux de références du lien montant SRS suffisent à la station de base pour estimer la formation du faisceau.

Toutefois, le nombre de signaux de références CSI-RS étant limité, la 5G NR en mode FDD s’appuie sur deux méthodes :

  • Reciprocity based CSI : Il s’agit d’estimer le signal de référence CSI-RS à partir des signaux SRS
  • Closed Loop : Le terminal UE envoie à la station de base les informations du canal CSI

II-3) Le mode de transmission Massive MIMO en 5G

Pour améliorer les performances de la méthode Closed Loop, l’accès initial propose une commutation des faisceaux (beam switch transmission procedure) en utilisant différent blocs SSB. Au niveau de l’antenne, un réseau de calibration est nécessaire pour pointer dans la bonne direction. Ainsi, le terminal UE détermine le bloc SSB et renvoie les informations du canal pour chaque faisceau reçu à la station de base gNB. Ensuite, des informations complémentaires peuvent être transmis selon le type de configuration choisi :

  • CSI TYPE 1 : Normal (PMI) feedback dans le cas du SU-MIMO donnant la direction du faisceau le plus important
  • CSI TYPE 2 : Enhanced (explicit or codebook based) dans le cas du MU-MIMO en apportant plus d’information de retour par le terminal à la station de base.

ANNEXE

Reference 1 :

https://www.5gamericas.org/wp-content/uploads/2019/07/MIMO_and_Smart_Antennas_July_2013_FINAL.pdf)

Référence 2 : Livre « LTE-Advanced Pro, Une étape vers le réseau de mobiles 5G », Launay F, Perez A

(https://www.amazon.fr/LTE-Advanced-Pro-Fr%C3%A9d%C3%A9ric-Launay/dp/1784055778)

Massive MIMO : Description de l’antenne (Deuxième partie)

Posté le by - 4 815 vues
1

Suite de l’article : Massive MIMO : Définition (Première Partie)

I-4) La structure d’une antenne

Sur l’exemple ci-dessous extrait du site 5GAmericas (Reference 1), l’antenne est simplement constituée d’une colonne d’éléments rayonnants. L’antenne est équipée de 4 connecteurs coaxiaux, chaque connecteur est relié à une chaîne radio RF. Parmi ces 4 connecteurs, deux connecteurs permettent de fonctionner sur deux bandes différentes, et deux connecteurs sont utilisés pour l’exploitation de la polarisation cross-polaire (+/- 45°).

Figure 8 : Antenne 4G

Sur le schéma on observe 18 éléments rayonnants (Antenna Element), 10 éléments rayonnant sont conçus pour fonctionner dans une bande de fréquence avec une polarisation +/-45°, les 8 autres pour une autre bande de fréquence avec une polarisation de +/- 45°.

Il s’agit néanmoins que d’une seule antenne composée d’une colonne d’éléments rayonnants cross-polaire (single cross polarized column). Un panneau d’antennes (pannel antenna) représente un ensemble d’éléments rayonnants (AE) régulièrement espacés (Linear arrays).

Un circuit de connexion (feed network) réparti les signaux des connecteurs de la chaîne RF vers les éléments rayonnants correspondants (figure 8).

Figure 9 : Le circuit de connexion de l’antenne (feed circuit)

Pour reprendre les définitions précédentes : L’antenne dispose de 4 connecteurs TRX, deux connecteurs TRX fonctionnant sur une bande de fréquence, deux autres sur une autre bande.

Chaque antenne individuelle TRX se compose de 4 ou 5 éléments rayonnants. Chaque élément rayonnant fonctionnant sur une bande de fréquence et de même polarisation transmet donc le même signal RF. Si le déphasage apporté par le circuit de connexion est figé (feed circuit), on apporte un gain RF non contrôlé en temps réel (pas de possibilité d’orienter le faisceau RF de manière analogique, on peut toujours réaliser du beamforming numérique dans une bande donnée à partir des 2 antennes individuelles cross-polaires). Il s’agit d’antenne passive.

Le tiltage électronique peut être réalisé de manière mécanique soit par le contrôle d’un moteur DC soit par le déphasage apporté au niveau du circuit de connexion (signal RET e-tilt sur la figure 8).

Le faisceau commuté (switch beam) est une avancée vers l’antenne intelligente. L’objectif est de sélectionner le meilleur faisceau en fonction des conditions radios. Dans le cas de la matrice de Butler 4T4R, les 4 antennes individuelles sont toutes connectées à 4 éléments rayonnants avec une combinaison sur le déphasage de manière à transmettre 4 faisceaux différents.

Figure 10 : La commutation de faisceau

Chaque signal en entrée (4 signaux RF) peut donc être transmis dans une direction donnée.

Couplage du MIMO et du BeamForming : Pour transmettre le signal radio dans une direction donnée (Beamforming), il faut transmettre le même flux sur plusieurs antennes individuelles. Dans le cas suivant, l’antenne MIMO est une antenne 8T8R car elle est connectée à 8 chaînes radio RF. Chaque antenne individuelle est connectée à une colonne d’éléments rayonnant dans une polarisation donnée. La figure 11 montre 4 colonnes cross-polaires.

La directivité de l’onde nécessitant l’utilisation de plusieurs antennes individuelles de même polarisation, il est donc possible de générer deux ondes directives (nommés BeamForming BF1, BF2) à partir d’un poids de pondération à appliquer sur chaque antenne individuelle.

Il est donc possible :

  • de transmettre 8 flux identiques pour un seul utilisateur en exploitant les 8 antennes individuelles, dans ce cas on a un faisceau étroit et directif ;
  • ou de réaliser 4 flux MIMO pour augmenter la capacité et le ressenti utilisateur.

Figure 11 : L’antenne MIMO 8T8R

I-4) L’évolution vers le FD-MIMO.

Jusqu’à présent, la directivité de l’onde en élévation (vertical) était réalisée par un tiltage électronique (RET) lors du placement de l’antenne et cette configuration figeait la directivité dans la cellule.

Avec la technique FD-MIMO, il est possible de diriger le faisceau en élévation et en azimuth par l’exploitation d’un réseau d’antennes rectangulaires (ULA 2D) en temps réel.

Figure 12 : L’antenne ULA 2D

A partir de l’angle des signaux d’arrivé et d’un DSP intégré, l’antenne devient intelligente et peut contrôler la phase pour orienter le faisceau RF, on parle d’antenne active :

Figure 13 : Contrôle de la phase appliquée sur chaque AE de l’antenne individuelle

Les antennes Massive MIMO sont des antennes actives. La puissance de transmission  de l’antenne peut monter jusqu’à 120 W pour 128 AE et 180 W pour 192 AE lorsque tous les éléments rayonnants émettent à puissance maximales. La consommation électrique est bien supérieure, je n’ai pas les chiffres à ce jour.

 

Massive MIMO : Définition (Première Partie)

Posté le by - 8 391 vues
3

Je vous propose une série de 3 articles pour comprendre le massive MIMO. Je me suis appuyé sur les documents :

  • 3GPP;
  • 5G América;
  • et les informations des équipementiers comme Nokia, Ericsson et Huawei.

Cependant,malgré quelques réponses de Emil Björson (https://ma-mimo.ellintech.se/author/eb/) , et de Jakob Hoydis (Nokia), il y a une grande part d’interprétation. Je les remercie d’avoir pris le temps de me répondre.

N’hésitez donc pas à commenter ces articles pour améliorer le contenu, merci.

  1. Description générale du MIMO au Massive MIMO

I-1) Définition

La technologie MIMO (Multiple Input Multiple Output) consiste à transmettre simultanément N flux d’informations sur N antennes d’émission (un flux d’information par antenne d’émission) et chaque flux est reçu par M antennes en réception.

Le flux transmis par antenne peut être :

  • un même flux avec un précodage pour :
    • améliorer la diversité en émission (se référer aux codes Alamouti SBFC) ;
    • diriger le flux dans une direction donnée (avec un précodage pour orienter le flux – beam RF) ;
  • des flux différents (K flux, K est inférieur ou égal à N) pour augmenter la capacité de la station de base et améliorer le ressenti utilisateur.

Figure 1 : Le principe du MIMO

La notion de faisceau porte à confusion. On fera donc la différence entre :

  • un faisceau RF (beam RF) transmis dans une direction donnée en utilisant plusieurs antennes qui transmettent toutes le même flux;
  • un faisceau MIMO (beam) qui utilise plusieurs antennes pour transmettre différents flux ;
  • un faisceau MIMO dans une direction donnée (un faisceau RF) : le faisceau MIMO est constitué de plusieurs faisceaux RF (plusieurs beam RF) pour transmettre les flux différents dans une direction donnée. A titre d’exemple, on peut utiliser 16 antennes pour faire du 4×4 MIMO dans une direction donnée.

La notion d’antenne porte aussi à confusion, on parle en effet d’une antenne MIMO pour évoquer en réalité un réseau d’antennes (antenna array) ou un système multi-antennes. Pour clarifier les éléments, dans cet article, on nomme antenne MIMO, un réseau d’antennes constitué de plusieurs antennes individuelles et chaque antenne individuelle peut être constituée d’un réseau d’éléments rayonnants.

On va donc poser les définitions suivantes :

  • un réseau d’antennes est un ensemble de plusieurs antennes individuelles pouvant fonctionner ensemble comme une seule antenne nommée antenne MIMO;
  • les antennes individuelles sont connectées à un seul récepteur ou émetteur nommé TRX ;
  • l’évolution des techniques d’intégration permettent d’intégrer plusieurs éléments d’antennes (nommé Antenna Element) par antenne individuelle.

Une antenne du radio cellulaire (2G/3G/4G) est composée d’un ensemble d’éléments rayonnants protégé par un radôme :

Figure 2 : Le Radôme

Un élément rayonnant est appelé élément d’antenne (AE : Antenna Element). L’élément rayonnant présente un diagramme de rayonnement de 180° :

Figure 3 : Le Diagramme de rayonnement d’un élément d’antenne

Le module TRX est le module permettant de passer du signal en bande de base vers le signal RF. Il est composé d’un émetteur et d’un récepteur. En émission, le signal RF est transmis du module TRX à l’antenne individuelle, en réception l’antenne individuelle transmet le signal au module TRX.

L’antenne individuelle est constituée d’un réseau d’éléments rayonnants AE.

L’antenne MIMO est composée d’un ou de plusieurs panneaux d’antennes individuelles.

Les éléments rayonnant peuvent être co-localisés ou distribués.

Il existe deux modèle de connexion :

  • une antenne individuelle est connectée à un seul TRX, on parle de modèle de partitionnement ;
  • une antenne individuelle est connectée à plusieurs TRX, on parle de modèle complet.

En général, les antennes individuelles sont connectées à un ensemble d’éléments d’antennes colocalisées ou distribuées (sous-panneau – subarray), on est donc sur un modèle de partitionnement.

Figure 4 : Le modèle de connexion des TRX aux éléments d’antennes

I-2) La formation du faisceau RF

Un émetteur MIMO est composé de plusieurs modules d’émissions (N TX) chaque chaîne de transmission radio TX est connectée à une antenne individuelle.

Un récepteur MIMO est composé de plusieurs modules de réception (M RX) chaque chaîne de réception radio RX est connectée à une antenne individuelle.

Dans le cas de l’antenne MIMO, la formation d’un faisceau RF (beam RF) est un ensemble de gain et de déphasage appliqué sur les TRX de l’antenne par un précodage numérique.  La formation du faisceau est donc réalisée à partir d’un sous-réseau d’antennes individuelles passives.

Dans le cas de l’antenne Massive MIMO, chaque TRX est constitué d’un ou plusieurs éléments rayonnants (AE). Le contrôle des éléments rayonnant apporte un gain supplémentaire dans une direction donnée grâce à un contrôle en amplitude et en phase du signal issu du TRX (beam analog steering). Il s’agit donc d’un sous-réseau actif d’antennes et on parle de système d’antennes actives (AAS : Active Antenna System).

Figure 5 : Le contrôle de la direction du faisceau dans le domaine analogique

Si les éléments d’antennes sont régulièrement espacés (ULA : Uniform linear Array), la direction d’arrivée de l’onde est estimée à partir de la différence de marche :

Figure 6 : Calcul de la différence de marche

Pour un signal de bande étroite, en appliquant le retard (la différence de marche) sur chaque élément d’antenne, le signal reçu est le suivant :

(Equation 1)

 

On peut également écrire sous forme vectorielle :


(Equation 2)

 

 

 

Avec a la direction du faisceau.

A l’inverse, en appliquant un déphasage sur chaque élément d’antenne rayonnant, il est possible d’orienter le faisceau (faible bande car la formule dépend de la longueur d’onde) dans une direction donnée (AoD : Angle of Departure).

La simulation sous Matlab se programme ainsi :

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% SIMPLE UNIFORM LINEAR ARRRAY
% WITH VARIABLE NUMBER OF ELEMENTS
% MATRIX IMPLEMENTATION
% COPYRIGHT RAYMAPS (C) 2018

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clear all
close all

f=1e9;
c=3e8;
l=c/f;
d=l/2;

no_elements=4;
theta=0:pi/180:2*pi;

n=1:no_elements;
n=transpose(n);

A=(n-1)*(i*2*pi*d*cos(theta)/l);
X=exp(-A);
w=ones(1,no_elements);
r=w*X;

polar(theta,abs(r),'r')
title ('Gain of a Uniform Linear Array')

(source : http://www.raymaps.com/index.php/fundamentals-of-a-uniform-linear-array-ula/)

Figure 7 : Diagramme de rayonnement (angle et gain) en fonction du nombre d’éléments d’antenne

Le gain apporté par l’antenne individuelle (sur laquelle est connectée le TRX) est égal au nombre d’élément rayonnants, cela revient à concentrer la puissance du signal dans un faisceau étroit. Quel que soit le diagramme de rayonnement, la puissance transmise dans le faisceau est identique, par contre plus le faisceau est fin plus la couverture est importante. Si N est le nombre d’éléments rayonnants, le gain en dB s’exprime par 10*log10(N).

En réception, la station de base est en mesure de déterminer la position du mobile selon une des deux méthodes :

  • en analysant le signal de réception sur les différentes antennes (cf. equation 2). Le calcul de l’angle d’arrivée (AoA : Angle of Arrival ou DoA : Direction of Arrival) utilise un algorithme de traitement du signal comme MUSIC ou ESPRIT ;
  • à partir du rapport de mesure transmis par le terminal mobile (CSI : Channel State Information).

En émission, la station de base peut diriger le faisceau dans une direction donnée en appliquant un déphasage et un gain sur chacun des éléments rayonnants : pour diriger un faisceau (beam) dans une direction donnée, il est nécessaire d’apporter un poids sur chaque élément rayonnant :

La valeur du vecteur de poids w est estimée à partir d’une des deux méthodes décrites ci-dessus (estimation AoA ou CSI).

I-3) La formation du faisceau

L’une des complexités du Massive MIMO réside dans le contrôle du gain et de la phase de chaque élément d’antenne. Pour réduire cette complexité, la formation du faisceau est réalisée par un précodage numérique (digital beamforming) à partir d’un sous-résau d’antennes passif suivi d’un gain apporté par le tableau d’élément rayonnant (plusieurs AE) par un sous-réseau d’antennes actives. On parle alors de technique hybride (hybrid : digital and analog) formant un système d’antennes actives.

Nous avons vu précédemment qu’une antenne individuelle était connectée à une ou plusieurs chaîne radio TRX. Donc, une chaine radio (TRX) est connectée à une antenne individuelle, laquelle pour rappel est composée d’un ensemble d’éléments rayonnants.

Le précodage en bande de base consiste à contrôler les flux au niveau de chaque chaîne radio TRX. Ainsi dans le cas d’une antenne 64T64R, le précodage numérique contrôle 64 flux.

Le précodage analogique permet d’apporter un gain RF supplémentaire.

Pour résumer :

  • le précodage numérique (en bande de base) permet de contrôler un ensemble d’antenne individuelle par TRX. Le précodage s’appuie sur les retours CSI ;
    • du MIMO en transmettant des flux différents sur différentes antennes individuelles ;
    • de la formation d’un faisceau en transmettant le même flux vers différentes antennes individuelles (plusieurs TRX transmettent le même flux).
  • le précodage analogique (sur le signal RF) permet de contrôler les éléments d’antennes constituant un TRX. Le précodage s’appuie sur l’estimation de l’angle à l’arrivée.
    • Le précodage analogique en RF permet d’orienter le faisceau dans une direction donnée.

Il est ainsi possible

  • d’affiner le faisceau (beam) dans une direction donnée en couplant le précodage numérique et analogique ;
  • ou de faire du MIMO directif en couplant le MIMO du précodage numérique en dirigeant les faisceaux (le faisceau MIMO est formé à partir de plusieurs faisceaux RF).

Il existe deux types de connexion entre l’antenne individuelle de la chaîne radio TRX et les éléments d’antennes :

  • une connexion par partitionnement : une antenne individuelle est connectée à un ensemble d’éléments d’antennes disjoints (se référer à la figure 4) ;
  • une connexion complète : les antennes individuelles sont toutes connectées aux mêmes éléments d’antennes.

A titre d’exemple, pour une station de base 64T64R, si chaque antenne individuelle de la chaîne radio TRX est connectée à 4 AE, alors l’antenne massive MIMO est composée de 64*4 = 256 AE.

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

Posté le by - 3 131 vues
Répondre

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 par la station de base secondaire (SN Terminated 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 (option 3a);
  • SCG bearer (option 3a);
  • MN Terminated Split-bearer (option 3);
  • SN Terminated Split Bearer (option 3x).

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 (bearer) 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

Posté le by - 4 713 vues
Répondre

La 5G arrivera en Juillet 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.

L’interface radio-électrique LTE-M : 2ème article

Posté le by - 2 749 vues
Répondre

Afin de réduire la signalisation, la procédure de mise à jour périodique de la localisation a été étendue et une nouvelle procédure de connexion radio a été proposée.

La procédure PTAU (Periodic Tracking Area Update) est périodiquement exécutée par un dispositif pour notifier auprès de l’entité MME de sa joignabilité sur le réseau d’accès radio 3GPP. Cette procédure est réalisée à l’expiration du Timer T.3412 lequel est ré-initialisé à chaque message NAS. Sa valeur par défaut est de 54 mn : la valeur du Timer T.3412 est transmise par le cœur réseau vers le mobile UE au cours de la procédure d’attachement ou lors de la mise à jour de la localisation en cas de changement d’indicateur de zone de tracking TAI.

Pour réduire ce message de signalisation, l’organisme de normalisation 3GPP propose d’étendre la temporisation périodique de localisation en augmentant la valeur du timer T.3412 (timer étendu).

Lorsque le terminal demande une connexion radio, la station de base eNB réalise une mise en sécurité des commandes NAS et une mise en sécurité de la transmission de données en échangeant. Ce contexte de mise en sécurité AS (Access Stratum) est sauvegardé au niveau du terminal UE et de la station de base eNB. L’établissement de ce lien permet au terminal de passer de l’état de veille à l’état connecté.

Pour éviter l’échange d’information AS chaque fois que le mobile souhaite passer du mode de veille au mode connecté, deux nouvelles requêtes RRC ont été introduites. Ces requêtes permettent de suspendre le lien radio et de passer en mode de veille tout en conservant le contexte AS au niveau du terminal et de la station de base. On dit alors que le terminal est à l’état Inactif (Inactive State) : Après une période d’inactivité, le terminal suspend sa transmission par le message RRC Suspend. La station de base eNB suspend alors la communication en relâchant le lien radio avec le terminal mais en conservant le contexte du terminal.

Le lien radio sera rétabli à l’initiative de la station de base (par une notification de paging) ou à l’initiative du terminal via la requête RRC Resume.

IV-1-c) La durée de vie de la batterie

Les terminaux IoT doivent pouvoir être connectés au cœur réseau sans la moindre recharge pendant plusieurs années. Cette autonomie s’obtient en apportant plusieurs mécanismes complémentaires au terminal comme le mode PSM (Power Saving Mode) défini dans la Release R.12 et l’évolution du DRX définie dans la Release R.13 (eDRX). Ces deux modes définissent une durée pendant laquelle le terminal éteint son interface radio dans le but de prolonger la durée de vie de sa batterie.

IV-2) L’interface radio LTE-M

Le réseau d’accès LTE-M hérite des canaux physiques du LTE-M. La bande totale du réseau LTE est divisée en bande étroite occupant chacune 6 PRB (soit 1.4 MHz) comme le montre la figure 3.

Figure 3 : La division de la bande LTE de 10 MHz en sous bandes étroites LTE-M de 1.4 MHz

Le nombre de sous bandes étroites dépendent de la bande LTE sur laquelle le réseau LTE-M s ‘adosse :

Table 1: La configuration des bandes étroites LTE-M

A l’instar de tous terminaux LTE, le terminal IoT écoute le centre de la bande du réseau d’accès LTE afin de récupérer les signaux de synchronisations et le message MIB transmis dans le canal de diffusion (PBCH)

Pour les terminaux IoT, les informations MIB sont transportées sur le canal physique MPBCH avec une périodicité de 10 ms. Un nouveau MIB est transmis toutes les 40 ms et par conséquent chaque MIB est répété 4 fois. Le nombre de répétitions peut être augmenté afin d’améliorer la couverture du canal MPBCH. Le nombre de répétitions est connu par le terminal via le paramètre CATMPR:mibRepEnabledCatM.

Figure 5 : La répétition du MPBCH

La station de base LTE-M transmet en plus des informations de signalisation SIB, lesquelles sont indiquées par le canal de diffusion MPBCH. Les informations SIB1-BR permet d’informer le terminal IoT du numéro de bande étroite exploité sur la bande LTE pour des communications sur le réseau d’accès LTE-M. Ainsi, en reprenant comme exemple le tableau 11.2, les communications sur l’accès radio LTE-M peuvent utiliser les 3 premières sous-bandes (NB1 à NB3) ou les trois dernières sous-bandes NB6 à NB8 : SIB1-BR indique les sous-bandes valides du lien descendant, et exclue automatiquement les 72 sous-porteuses centrales.

L’information DCI portée par le canal MPDCCH permet de transmettre :

  • les informations de séquencement DL (DCI Format 6-1A/6-1B dans le mode CE A/B ;
  • les commandes de contrôle de puissance du lien montant (DCI Format 3/3A) ;
  • les informations d’allocation de ressource pour le lien montant (DCI Format 6-0A/6-0B pour les modes CE A/B) ;
  • un indicateur de paging ou une mise à jour des informations de SI (DCI Format 6-2).

Les terminaux de catégorie CAT-M1 répondent aux spécifications proposées par le réseau d’accès LTE-M et les évolutions du cœur réseau.

  • Conclusion

Le marché du Wireless IoT est très concurrentiel : les opérateurs Orange et Bouygues ont déployé la solution LoRa pour ne pas laisser aux opérateurs Sigfox ou QoWiSio le marché du M2M en France. Orange a récemment ouvert un deuxième réseau d’objet connecté via l’accès radio 4G/LTE-M. Cela permet de répondre à des cas d’usage différents puisque le réseau d’accès LTE-M permet :

  • des débits de transmission plus important ;
  • des appels téléphonique via le mécanisme VoLTE ;
  • des accords de roaming avec les opérateurs pour le trafic
  • des accords de roaming avec les opérateurs ayant déployé l’entité d’interfonctionnement IWK-SCEF pour les notifications

Les solutions LoRa propose des accords de roaming entre opérateurs (LoRAWAN 1.1) cependant, le dispositif doit pouvoir se caler sur le plan de fréquence du pays visité. Cette solution a été mise en œuvre par Sigfox par le mécanisme MONARCH.

L’opérateur SFR est aussi présent sur le marché via un accord commercial avec SIGFOX mais SFR ouvre le réseau d’accès NB-IoT.

Ces informations ont été recueillies à partir de la formation SE26 de la société NEXCOM Systems (https://www.nexcom.fr/formation/comprendre-le-deploiement-de-la-4g-m2m-lte-m-mtc-pour-liot/). Cette formation présente les évolutions de l’interface radio et les canaux logiques/physiques, notamment les impacts sur les canaux physiques (MPBCH, MPRACH, MPDCCH/MPUCCH, MPDSCH/MPUSCH) et de synchronisation (PSS, SSS). Vous pouvez contacter formation@nexcom.fr pour obtenir des informations sur le contenu des formations qu’ils proposent, en indiquant que vous avez découvert leur formation à travers ce blog.

L’interface radio LTE-M – 1er article

Posté le by - 2 640 vues
2

L’accès radio LTE a initialement été conçu pour optimiser les communications à haut débit (MBB : Mobile BroadBand, mobiles larges bandes) en prenant en compte une mobilité élevée et une latence faible pour le transport des données (10 ms). Les exigences en termes de performances 4G sont encore mesurées à ce jour par le débit maximum et la réduction de la latence sur le plan de transport (UP : User Plane).

Le marché de l’Internet des Objets a longtemps été supporté par le réseau GPRS. Cela s’explique par le faible coût des modems GPRS comparé aux modems 4G. Toutefois, les performances de l’accès radio LTE sont attractives :

  • meilleure efficacité spectrale ;
  • disponibilité de l’interface radio pour du long terme ;
  • couverture globale.

De par ses atouts, une optimisation du lien radio LTE et du cœur réseau (MTC : Machine Type Communication) sont mises en œuvre pour répondre aux spécificités du marché de l’IoT.

Les optimisations portent sur :

  • le contrôle de la congestion et la maximisation de la capacité de la cellule ;
  • la réduction de la signalisation 4G ;
  • l’augmentation de la durée de vie de la batterie ;
  • l’augmentation de la Couverture.

De surcroît, pour devenir compétitif sur le marché de l’IoT, une réduction importante du prix des modems LTE est nécessaire. Dans la Release R.13, l’organisme 3GPP propose une simplification des terminaux en définissant deux nouvelles catégories de terminaux sous l’appellation cat-M1 et cat-NB1.

IV-1) Les améliorations sur l’interface radio

Le réseau d’accès doit pouvoir supporter un très grand nombre de terminaux (mMTC massive MTC) tout en conservant une QoS (Quality Of Service) pour les communications humaines. Pour répondre à cet impératif :

  • des procédures de contrôle de congestion et le paramétrage d’objets tolérants au délai permet d’optimiser le fonctionnement du réseau tout en différenciant la requête de service émise par le terminal UE ;
  • des procédures de réduction de la signalisation permet d’optimiser le plan de signalisation.

De plus, les terminaux IoT doivent obligatoirement avoir une autonomie de plusieurs années, ce qui nécessite de mettre en œuvre des mécanismes de gestion d’énergie (DRX – Discontinuous Reception et PSM – Power Saving Mode) en contrepartie d’une latence élevée (HL Com High Latency Communication).

IV-1-a) Le contrôle de la congestion

La saturation du réseau peut se produire :

  • Au niveau de l’interface radio lorsque de nombreux terminaux se connectent ou tentent de se connecter simultanément vers la même station de base eNB ;
  • Au niveau du cœur réseau EPC (Evolved Packet Network) : la congestion peut se produire au niveau de l’entité MME pour la signalisation ou au niveau des entités SGW/PGW pour le trafic. L’entité MME peut être fortement sollicitée lorsque le nombre de terminaux établissant une communication NAS est élevé. Pour réduire sa charge, l’entité MME contrôle principalement la congestion avec les entités eNB.

Pour gérer de manière sélective la congestion sur l’interface radio, la Release R.10 introduit un indicateur de faible priorité (LAPI : Low Access Priority Indicator) destiné aux terminaux IoT. Cet indicateur est implémenté dans les dispositifs soit au cours de leur fabrication, soit lors du provisionnement via l’interface radio par le mécanisme OTA (Over The Air). Lorsque le terminal fait sa demande de connexion radio, il transmet au cours de la requête RRC_Connection_Request la cause de sa demande (delay tolerant). En cas de saturation de la station de base eNB, celle-ci rejette la demande de connexion en demandant au terminal, dans le message RRC_Connexion_Reject, d’attendre jusqu’à 30 mn avant de refaire une nouvelle demande de connexion radio (Extended Wait Time).

Dans la Release 11 l’entité eNB contrôle la congestion via l’interface LTE-Uu en diffusant un message d’information SIB 14.

Le message diffusé par le SIB14 transporte une information de restriction de cellule (EAB : Extended Access Barring). Ce message est destiné à interdire aux terminaux de faible latence (LAPI) toute demande de requête de service. Afin de prendre connaissance de la modification du SIB14, les terminaux configurés avec l’identifiant LAPI reçoivent une notification par la procédure de paging les informant d’écouter le message d’information SIB14 diffusé par la station de base eNB. La procédure EAB ne concerne donc qu’une partie des terminaux.

Ce nouveau mécanisme offre deux avantages : Le premier avantage est la réduction de la signalisation au niveau de la station de base eNB, le deuxième avantage est une réduction de la puissance consommée par le mobile UE.

Evolution de l’architecture du réseau 4G pour le M2M : AESE – Part 2

Posté le by - 2 021 vues
Répondre

(Suite de l’article précédent)

2) La procédure de déclenchement

La procédure de déclenchement a été proposée dans la recommandation technique de la release R.10 afin de permettre à un dispositif IoT de répondre à une sollicitation du portail client (SCS). La procédure de déclenchement de dispositif est normalisée dans la release R.11 et nécessite une première phase d’enregistrement de la part du serveur SCS auprès de l’entité SCEF ou MTC-IWF avec comme droit d’émettre des requêtes de réveil (Trigger Request). La phase d’enregistrement a pour but de créer un identifiant de transaction et les droits de requêtes formant ainsi une entrée dans la table de contexte de l’entité MTC-IWF/SCEF à laquelle se rajoute l’identifiant du ou des dispositifs à réveiller. Le dispositif peut s’identifier à partir de son numéro MSISDN, d’un identifiant externe sauvegardé sur le serveur MTC AAA de l’opérateur ou d’un identifiant de groupe.

Dans les spécifications 3GPP de la Release 11, l’entité SCS contacte l’entité MTC-IWF via une requête DIAMETER afin que ce dernier puisse réveiller le dispositif. Lorsque l’entité MTC-IWF reçoit une demande de réveil, il contacte d’abord la base de données HSS (ou le HLR) afin de convertir l’identité publique en une identité interne au réseau opérateur (identifiant IMSI). L’entité HSS/HLR peut éventuellement contacter un serveur d’authentification MTC-AAA pour convertir une identité externe en un numéro IMSI. Si l’identité de l’UE MTC est reconnue, l’entité MTC-IWF récupère les informations de souscription du afin de mettre en relation le portail client SCS avec le dispositif.

L’entité MTC-IWF définit la méthode de réveil la plus adéquate sur le plan de contrôle pour déclencher une mesure au niveau du dispositif à partir des informations suivantes :

  • Les informations actuelles d’accessibilités de l’UE (sur quel réseau l’UE est situé, et sur quel zone) ;
  • Les méthodes de déclenchement de service supporté par le réseau HPLMN ou VPLMN ;
  • Les méthodes de déclenchement supportées par l’UE ;
  • Les politiques de déclenchement de réveil de l’opérateur ;
  • Autres informations reçues de la part du serveur SCS dont potentiellement la localisation du dispositif si celle-ci est connue. La localisation permet d’optimiser le paging à la cellule et non à la zone de localisation TAI (Tracking Area Identifier).

Les méthodes de réveil possible sont :

  • MT SMS. L’UE doit pouvoir reconnaître dans le message un MT SMS provenant du SCS ;
  • Cell Broadcast : La procédure Cell Broadcast permet de réveiller un dispositif UE en émettant des informations sur les SIB portés par le canal balise ;
  • Signalisation NAS ;
  • Messages IMS.

De manière plus explicite, la figure 3 présente le call flow de la procédure de déclenchement. On suppose que le serveur SCS s’est préalablement enregistrée auprès de l’entité MTC-IWF et au cours de la procédure d’enregistrement, le portail client SCS a associé le dispositif UE à réveiller. L’entité SCS connait l’adresse IP de l’entité MTC-IWF, dans le cas contraire, le portail client SCS fait une requête DNS.

La demande de réveil est initialement déclenchée par une API provenant du serveur d’application Client vers l’entité SCS (non présente sur le call-flow). L’entité SCS transmet le message Request Device trigger à l’entité MTC-IWF (éventuellement après une requête DNS) dans la commande DIAMETER DAR (Device Action Request) à travers l’interface Tsp.

Le message DAR contient les informations suivantes (AVP) :

  • Le type de message : Device Trigger Request
  • Le MSISDN ou une identité externe correspondant à l’UE MTC à réveiller
  • L’identité du SCS qui émet la requête.
  • Un numéro de référence de la demande de requête de réveil
  • Les données de Trigger contenant données à transmettre à l’UE MTC lors de la demande de réveil comme :
  • Priorité du trigger
  • L’identification du port de l’application à exécuter au niveau du dispositif
  • Une durée de validité du message de réveil. Un temporisateur est déclenché au niveau du MTC-IWF qui reçoit le message DAR.

Figure 2. Call Flow d’un réveil de dispositif par SMS

L’entité MTC-IWF peut interdire ou autoriser la requête de réveil à partir de l’identité du serveur SCS si le serveur SCS n’est pas reconnu ou si le serveur SCS a dépassé le nombre de requêtes autorisées.

La durée de validité permettra à l’entité MTC-IWF de savoir si le dispositif sera joignable avant la fin du temporisateur. L’entité MTC-IWF aura besoin de connaitre la durée pendant laquelle le dispositif est soit à l’état dormant, soit en mode de veille avant la prochaine écoute de paging (Paging Occasion). Si le dispositif ne peut pas être réveillé pendant la durée de validité du message de réveil, alors l’entité MTC-IWF retourne un rapport d’erreur dans le message DAA.

L’entité MTC-IWF contacte l’entité HSS (éventuellement après une résolution HSS via la fonction de localisation SLF). A la réception de la requête DIAMETER SIR, l’entité HSS réalise les opérations suivantes :

  • Correspondance entre le numéro publique (MSISDN ou identité MTC externe) avec l’identité privée IMSI du dispositif ;
  • Récupère -si le dispositif est enregistré- le nœud de service actuel du dispositif (soit l’entité MME, l’entité SGSN, ou l’entité MSC) ;
  • Vérifie les droits de souscriptions du dispositif en correspondance avec l’identification du serveur SCS pour valider ou non la requête de réveil.

L’entité HSS répond à l’entité MTC-IWF par la requête SIA avec les éléments suivants :

  • Le nœud de service (MSC, SGSN, SGW) actuel du dispositif ;
  • Renvoie le statut du dispositif (UE State Information) permettant de savoir si le dispositif est à l’état connecté, de veille, ou non enregistré (absent). Cette information est apportée par le HSS ;
  • Le ou les mécanismes supportés par le dispositif (information apportée par le HSS) ;
  • Les capacités de services offertes par le réseau de l’opérateur Home (framework implémenté dans le MTC-IWF) et éventuellement par l’opérateur visité en cas de roaming ;
  • Autres informations transmises par le SCS (localisation du dispositif, demande de réveil groupé, …).

A partir des informations reçues, l’entité MTC-IWF sélectionne le mécanisme pour transmettre la requête de réveil au dispositif le plus efficace (SMS, Cell Broadcast, …) et génère un ticket de taxation.

L’entité MTC-IWF sélectionne la méthode SMS pour réveiller le dispositif. Il émet au serveur SMC-SC (SMS Service Center) la requête DTR.

Le message DTR contient :

  • le numéro IMSI du dispositif et éventuellement le MSISDN si le MTC-IWF le connait (si le SCS a donné l’identité MSISDN au MTC-IWF et non un identifiant MTC externe) ;
  • l’identité de l’entité SCS ;
  • l’identité du nœud de service (SGSN, MSC ou MME) si connu ;
  • le statut du dispositif ;
  • le numéro de référence de la demande de requête de réveil ;
  • la durée de validité du message de réveil ;
  • la Priorité du trigger ;
  • l’identification du port d’application du SMS.

Une fois le message DTR reçu, si le dispositif est joignable le centre de service SMS (SMS-SC) n’a pas besoin de contacter l’entité HSS. Il doit néanmoins :

  • vérifier l’identité du dispositif (IMSI ou MSISDN). Si l’UE n’est pas reconnu (DIAMETER_ERROR_USER_UNKNOWN) ;
  • vérifier l’identité du SCS. Si l’identité du SCS n’est pas reconnu (DIAMETER_ERROR_INVALID_SME_ADDRESS) ;
  • Router l’information vers le nœud de service (SGSN, MSC ou MME). Il renvoie alors l’information DIAMETER_SUCCESS à l’entité MTC-IWF.

Si le dispositif est non enregistré (absent), le centre SMS-SC va stocker le message et envoyer une notification à l’entité HSS (SM Message Delivery Status Report) afin que l’entité HSS rajoute l’adresse du centre SMS-SC dans la liste des messages d’attentes. Ainsi, lorsque le terminal MTC UE fera une demande d’attachement, il prendra connaissance du trigger.

Le centre SMS-SC renvoi le résultat de la demande DTR dans le message DTA. Le code de résultat AVP indique si la requête est acceptée (SUCCESS) ou refusée (FAILURE) avec le code d’erreur correspondant :

  • congestion du SMS-SC ;
  • adresse SME non valide ;
  • erreur de protocole SM.

A ce stade, l’entité MCT-IWF acquitte le message DAR par la réponse DAA, ce qui confirme que la demande de réveil a bien été transmise au SMS-SC.

Le message DAA contient :

  • le numéro de référence de la demande de requête de réveil ;
  • l’état du statut de la requête de réveil.

Si la requête est acceptée, le centre SMS-SC envoie le SMS vers le MTC UE et attend la notification de SMS. Cette notification est transférée du SMS-SC vers l’entité MTC-IWF dans le message DIAMETER DRR (Delivery Report Request) et l’entité MTC-IWF répondra au SMS-SC par la réponse DRA (Delivery Report Answer).

Le message DRR transmet le rapport de succès ou d’échec de transfert su Trigger par SMS, il contient les informations suivantes :

  • l’identité IMSI de l’UE et éventuellement le MSISDN ;
  • l’identité du SCS ;
  • le résultat de la requête :
  • Client Absent
  • Mémoire de l’UE remplie
  • Transfert réussi.

L’entité MTC IWF informe l’entité SCS de la réception du SMS de la part de l’UE. L’entité MTC-IWF envoie le message DIAMETER DNR (Device Notification Request) au serveur SCS et attend la réponse DNA (Device Notification Accept)

Le DNR contient les informations suivantes :

  • le MSISDN ou l’identité externe du dispositif ;
  • l’identité du SCS qui a fait la demande de réveil ;
  • le numéro de référence de la demande de requête de réveil ;
  • la réponse à la demande de réveil.

L’entité SCS acquitte la réception de cette requête en répondant par le message DIAMETER DNA.

Enfin, l’entité MTC-IWF répond à la requête DRR émis par le SMS-SC par la réponse DRA, informant ainsi le SMS-SC d’un succès ou d’une erreur sur l’interface T4.