Archives pour la catégorie Non classé

Sélection de cellules – Principes Généraux (Partie II)

Posté le by - 469 vues
Répondre

Cet article est la suite de l’article précédent

2. Sélection du PLMN en mode automatique

L’information PLMN est transmise par la station de base aux UE via un message RRC (SIB1). La sélection du PLMN est réalisée au niveau de la couche 3 de l’UE en mode automatique à partir des données fournies par l’UICC à l’UE ou par l’utilisateur en mode manuelle (cf. mobile => Paramétrage => Réseaux Mobiles => Sélection réseaux)

La sélection d’un réseau de mobile PLMN (Public Land Mobile Network) est initiée par l’UE lorsque l’UE s’allume et la sélection se fait en deux étapes :

  • Classification des cellules les plus fortes reçue à partir du signal de synchronisation PSS/SSS par la couche physique dite procédure AS (Access Stratum). Cette classification de meilleure cellule est imposée par la norme 3GPP. D’autres études (non standardisées actuellement) explorent des sélections différentes basées par exemple sur la charge de la cellule [lien Thèse R.Pujol 9].
  • Lecture du PLMN au niveau de la couche 3 (information NAS) et sélection automatique de la cellule. La partie NAS de l’UE sélectionne la cellule et peut donc aussi refuser un type d’accès radioélectrique (RAT : Radio Access Type) si la cellule est considérée comme interdite (barrée ou barred).

Pour résumer, la sélection du PLMN est réalisée par la couche NAS de l’UE, et fournit une liste de PLMN à la couche AS sur lesquelles la couche AS pourra faire une sélection/re-sélection de cellules et le mobile campe sur cette cellule.

Une fois la cellule sélectionnée, l’UE conserve le PLMN et la fréquence de la cellule afin de sélectionner la même cellule lors de la prochaine mise sous tension du mobile ou après la perte de la couverture radioélectrique.

(En mode de veille), si le réseau PLMN correspondant n’est pas le réseau prioritaire indiqué par l’USIM, alors l’UE va régulièrement rechercher un PLMN prioritaire. La périodicité de la recherche est définie par l’opérateur dans la configuration de l’USIM. La valeur maximale est de 300 secondes.

Si l’UE perd la connexion radioélectrique, il peut sélectionner un PLMN équivalent ou choisir un RAT moins prioritaire.

La sélection de la cellule au niveau physique s’appuie sur la mesure en dBm de la puissance du signal RSRP (Reference Signal Received Power) de la cellule candidate. La cellule est éligible si le niveau de puissance est supérieur à un seuil de sélection compensé. Les informations sont transmises dans les messages RRC portant les informations systèmes SIB.

Dans le cas d’un accès radio NG-RAN, la station de base 4G (ng-eNB) est associée à un cœur de réseau 5GC. Ainsi la sélection d’une cellule eNB permet au mobile d’être potentiellement enregistré sur un cœur de réseau 4G ou 5G. C’est au niveau de la couche NAS que s’effectue le choix du cœur de réseau associée à la cellule sur laquelle l’UE campe.

Si l’UE ne trouve pas de cellule appropriée (ou si la carte SIM n’est pas insérée) alors le mobile entre dans l’état « service limité ».

La commande AT +CSRM permet récupérer le nom du réseau préféré, les réseaux interdits et de récupérer la valeur de temporisateur (périodicité de recherche d’un réseau plus prioritaire, …)

 

  1. Description des processus en mode de veille

Lorsque le mobile est en mode de veille, le standard 3GPP présente la liste de 4 processus suivants [TS36.304]

  • Sélection de PLMN
  • Sélection et re-sélection de cellule
  • Mise à jour de sa localisation TAI
  • Support pour une sélection manuelle d’un groupe d’abonnés pouvant s’attacher sur une femto CSG (Closed Subscriber Group).

La sélection du PLMN se fait en mode manuelle ou automatique à partir des mesures radioélectriques PSS/SSS effectuées par le mobile et après lecture du SIB1 pour chaque réseau détecté (PLMN disponible).

A partir des informations NAS, l’UE sélectionne une cellule (ou re-sélectionne une cellule) en fonction de la puissance de la plus forte cellule (mesures) appartenant à l’opérateur préféré (information NAS). La sélection de la cellule fournie au mobile l’identité de la zone de tracking TAI (Tracking Area Identity).

Si l’utilisateur dispose d’une femto-cell, il déclare la liste des UE pouvant se connecter à la femto. L’identité de la celllule CSG-ID est diffusé dans le SIB2 et seuls les UE qui appartiennent au groupe CSG peuvent sélectionner la cellule.

Figure 2 : Les processus dans le mode de veille

Le document [2] fournit la liste des fonctions supportées par la couche AS ou la couche NAS.

 

Références

[1] TS 23.122 V17.7.1 (2022-06) Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode

[2] TS 36.304 v17.1.0 (Juin 2022), Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode

[3] TS 31.121 version 16.0.0 Release 16, UICC-terminal interface; Universal Subscriber Identity Module (USIM) https://www.etsi.org/deliver/etsi_ts/131100_131199/131121/16.00.00_60/ts_131121v160000p.pdf

[4] 3GPP TS 31.111, Universal Subscriber Identity Module (USIM) Application Toolkit (USAT)

[5] https://www.sharetechnote.com/html/Handbook_LTE_USIM_Parameters.html

[6] ETSI TS 102 221 : Smart cards; UICC-Terminal interface; Physical and logical characteristics

[7] https://www.gsma.com/newsroom/wp-content/uploads/SGP.02-v4.0.pdf

[8] https://www.gsma.com/newsroom/wp-content/uploads//IR.73-v5.0.pdf

[9] Romain Pujol, Association des utilisateurs dans les réseaux mobiles flexibles et agiles https://theses.hal.science/tel-03859479/file/these.pdf

 

La Mutualisation de l’accès radio : RAN SHARING

Posté le by - 1 120 vues
4

Je remercie Rafika Rezgui (responsable New Deal Bouygues Télécom ) et Hugues-Antoine ROUSSILLO (Chef de projet Programme Réglementaire Bouyues Télécom) pour la relecture et les explications fournies qui ont contribuées à l’amélioration de l’article.

I) La mutualisation du RAN – RAN SHARING

L’architecture des réseaux de mobiles fait une séparation entre le réseau d’accès radio (RAN Radio Access Network) et le cœur de réseau (CN : Core Network).

Le partage du réseau (Network Sharing) a pour objectif de réduire les coûts de déploiement en partageant une partie du réseau entre opérateurs.

Selon la définition de l’ARCEP [1]: le partage de réseaux mobiles correspond à la mise en commun entre plusieurs opérateurs de tout ou partie des équipements constituant leurs réseaux mobiles.

 On distingue ainsi plusieurs solutions sur le partage de l’accès radio :

  • Location de site (Tower Companies)  nommée partage d’infrastructure passive : chaque opérateur installe ses équipements actifs (antennes mobiles) sur une infrastructure passive partagée (pylône) ;
  • La mutualisation active des réseaux (RAN Sharing)
    • Avec partage de fréquences MOCN (Multi-Operator Core Network) : la station de base (ou le cœur d’accès radio) est connectée au cœur de réseau de plusieurs opérateurs et les porteuses de fréquence de chaque opérateur sont combinées. Les clients d’un opérateur peut donc accéder à l’ensemble des fréquences de l’ensemble des opérateurs [2]
    • MORAN (Multi-Operator RAN) : La station de base est partagée entre plusieurs opérateurs mais chaque opérateur dispose de sa propre bande de fréquence. Les équipements mis en place par un des opérateurs émettent les fréquences des autres opérateurs mais chaque client n’a accès qu’aux fréquences de son opérateur. (exemple : Accord Crozon entre SFR et Bouygues)
  • Full MVNO ou itinérance : un opérateur loue et utilise les fréquences d’un autre opérateur hôte qui accueille sur son réseau ses clients
  • L’architecture GWCN (Gateway core network) pour laquelle plusieurs opérateurs partagent l’accès RAN et l’entité MME. L’entité MME doit évidemment supporter l’option RAN Sharing et doit pouvoir délivrer une liste de restriction d’eNB pour la continuité d’appels HO (Handover).

Figure 1 : La mutualisation du réseau de mobiles [1]

II) Exemple du New Deal

L’accord New Deal est un engagement imposé par le gouvernement aux opérateurs Français pour avoir une bonne couverture du réseau mobile. Cet engagement est encadré par l’ARCEP qui définit La notion de « bonne couverture ».

Une bonne couverture permet de téléphoner et d’échanger des SMS à l’extérieur des bâtiments dans la plupart des cas, et, dans certains cas, à l’intérieur des bâtiments (cf. https://www.arcep.fr/cartes-et-donnees/nos-cartes/la-couverture-4g-en-france-par-departement.html)

Le New Deal s’appuie sur la mutualisation radio (RAN SHARING). Le « New Deal » a pris la forme d’un « gentlemen’s agreement » matérialisé dans un échange de lettres, suivies d’annonces.

Le new deal utilise la mutualisation de l’accès radio (RAN Sharing) avec partage de fréquence (MOCN) ou sans partage de fréquence (MORAN).

La mutualisation MOCN est favorisée dans les zones blanches et la mutualisation MORAN dans les zones moins denses. Toutefois, Hugues-Antoine ROUSSILLO précise : « en cas de charge, la bande passante est limitée à ¼ des ressources par opérateur en MOCN ».

III) Les évolutions du spectre radiomobile

A partir de 2024, les plans de fréquences à 900 MHz, 1800 MHz et 2100 MHz seront équilibrés entre les opérateurs (suivant [3]) :

Tableau 1 : Bande de 900 MHz

Tableau 2 : Bande de 1800 MHz

Tableau 3 : Bande de 2100 MHz

Notes 

Le NB-IoT ne supporte pas le RAN SHARING (jusqu’à la R.17)

 

Références

[1] https://www.arcep.fr/la-regulation/grands-dossiers-reseaux-mobiles/le-partage-de-reseaux-mobiles.html

[2] Rapport de la cours de comptes : Réduire la fracture numérique mobile (Juin 2021) : https://www.ccomptes.fr/sites/default/files/2021-09/20210928-58-2-reduire-fracture-numerique-mobile-4G.pdf

[3] Décision n° 2018-1306 du 23 octobre 2018 : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038057322

Déploiement de la 5GC

Posté le by - 922 vues
Répondre
  1. Architecture du cœur de réseau 5GC

Le cœur de réseau 5GC est déployé selon l’architecture a 3 niveaux :

  • les instances des fonctions réseaux sont exécutées au sein de DataCenter central
  • un Datacenter régional avec le plan de trafic
  • un Datacenter de proximité (Edge Datacenter) avec le MEC et le CDN

Figure 1 : Architecture 3 niveaux [1]

      2. Fiabilité du réseau : Redondance

Afin de fiabiliser le cœur de réseau, le déploiement des fonctions 5G s’appuient sur la redondance de fonctions dans des Datacenter séparés (DC1/DC2) selon une approche active/active, active/passive ou sur une redondance dans un pool.

La redondance active ou passive sont mises en œuvre pour les fonctions NRF, NSSF, SMSF, UDM, et UPCF alors que la redondance par pool est utilisée pour les fonctions AMF, SMF et UPF.

II-a) La redondance active/passive

La redondance active/passive représente une paire de fonction NF et seule la fonction active apporte le service demandé, la fonction passive est vue comme un backup. Les deux NF échangent un message Heartbeat (battement de cœur) c’est-à-dire un ping envoyé à un intervalle de pulsation régulier configuré.

Figure 2 : La redondance active/passive

Le HeartBeat est un système de haute disponibilité sous Linux (LinuxHA High Availability), mettant en cluster, c’est-à-dire en groupe, plusieurs fonctions. Le processus Heartbeat se chargera de passer les communications aux serveur actif si celui-ci est vivant et au serveur passif le cas échéant.

Sous linux, installez le paquet Heartbeat (apt-get install heartbeat)
et configurez le fichier /etc/heartbeat/ha.cf de la même manière
sur les deux serveurs.

II-B) La redondance active/active

La redondance active/active chaque NF déployée sur 2 DC différents répondent aux services demandés. Les données de backup peuvent être transmises d’une NF active à une autre, mais n’est pas obligatoire.

II-C) La redondance par pool

Les fonctions NFs sont regroupées dans un pool et chaque NF répond aux services demandés. Quand une fonction NF tombe en panne, les autres prennent le relai.

Les fonctions AMF sont regroupées selon l’architecture mesh, c’est-à-dire décentralisée et par type de service à supporter.

Un pool de SMF permet de connecter plusieurs SMF pour contrôler plusieurs UPF sur une zone radio donnée

Figure 3 : Le regroupement des NF

II-D) La surveillance des états

Les fonctions NF du cœur de réseau vérifient l’état des autres fonctions NF couplées via des messages ping à travers l’interface SBI ou des notifications de souscriptions pour la fonction NRF.

Sur l’interface point à point, les fonctions NF vérifient le lien à travers des messages Heartbeat via l’association SCTP ou le lien PFCP.

Figure 4 : La surveillance des états [1]

La fonction NRF est la première instance qui est exécutée lorsqu’on souhaite démarrer un nouveau cœur de réseau. Le NRF répertorie toutes les fonctions réseaux NF. Lors de la procédure de démarrage, une fonction NF vient s’enregistrer au niveau du NRF via une requête http.

Figure 5 : L’enregistrement de la fonction SMSF [2]

Pour la fiabilité du réseau, la fonction NRF fonctionne par paire : les opérateurs copient de manière active le NRF du DC1 vers le DC2.

La fonction NSSF assure la mise en œuvre du network slicing. Pour la fiabilité du réseau, les opérateurs déploient une paire de NSSF.

 

[1] Huawei : Deploy and apply 5G Core

[2] https://nickvsnetworking.com/if-you-like-pina-coladas-and-service-the-control-plane-intro-to-nrf-in-5gc/

 

Le déploiement d’un réseau 5G SA (cloud privée ou publique)

Posté le by - 1 102 vues
Répondre

I) Introduction

L’évolution de la 4G vers la 5G n’est pas uniquement une virtualisation des entités 4G (ex: DECOR ou eDECOR – Dedicated Core) mais un déploiement automatisé des fonctions réseaux sur une architecture basée sur les services (SOA).

Une application est dite « native pour le cloud », lorsqu’elle est conçue autour d’instances gérées de façon automatisée dans les clouds privés, publics et hybrides. Aujourd’hui, les entreprises adoptent le Cloud Computing  [1] pour améliorer l’évolutivité et la disponibilité de leurs applications.

Le principal avantage d’une stratégie cloud-native est qu’elle permet d’accélérer le développement des applications dont les ressources de calcul sont réparties dans différents environnements [2].

Selon [1], « le cloud computing consiste à exécuter des charges de travail dans des clouds, des environnements qui dissocient, regroupent et partagent des ressources évolutives sur un réseau. »

Les concepteurs DevOps réalisent une architecture composée de ressources en libre-service et à la demande ainsi qu’à l’automatisation du cycle de vie des applications (de la phase de développement jusqu’à la production).

La 5G est dite cloud Native, la 3GPP propose une architecture composée de fonctions réseaux (NF) faiblement couplées. Une fonction réseau peut être découpée en microservices qui communiquent entre elles via des interfaces de programmation d’application (API).

Dans une architecture de microservices, les applications sont décomposées en éléments les plus simples et indépendants.

Les interfaces de programmation d’application (API) sont des ensembles d’outils, de définitions et de protocoles qui facilitent la création de fonctions d’applications (réseau). Elles connectent les producteurs de services et les consommateurs de services sans connaître les détails de leur mise en œuvre [1].

Le modèle DevOps est une approche d’automatisation et de conception de plateformes pour une solution logicielle complexe [3].

II) Cloud Public, privé, hybride, multicloud

Selon [1] :

Cloud Public : Environnements cloud créés à partir de ressources qui n’appartiennent pas à l’utilisateur final et qui peuvent être redistribuées à d’autres clients.

Cloud Privé : Généralement décrits comme des environnements cloud réservés à l’utilisateur final, la plupart du temps à l’intérieur du pare-feu et parfois sur site.

Cloud hybride : Plusieurs environnements cloud qui offrent différents degrés de portabilité, d’orchestration et de gestion de la charge de travail.

Multicloud : Systèmes informatiques qui comprennent au moins deux clouds (privés ou publics) qui peuvent être mis en réseau ou non.

Un cloud public est un pool de ressources virtuelles, créées à partir de matériel détenu et géré par une entreprise tierce, qui sont automatiquement provisionnées et allouées à différents clients via une interface en libre-service. Il s’agit d’une méthode simple qui permet de faire évoluer les charges de travail soumises à des fluctuations imprévues de la demande.

Déploiement de la 5G SA sur un Cloud Public

Les entités du coeur de réseau 2G/3G/4G stockent des informations, nommées contextes, relatives aux utilisateurs ou à l’association de couche transport (Tunnels). Ces contextes doivent être résilientes à toutes pannes.

La 3GPP propose une architecture sans état (Stateless) pour optimiser le déploiement des fonctions réseaux, en découplant le stockage des contextes et les couches applicatives. Les données sont sauvegardées dans des fonctions UDSF (Unstructured Data Storage Function [5]).

A titre d’exemple, le Cloud Public Amazon propose Elasticache et Google propose Google Cloud Memorystore, l’un et l’autre surtout connus pour leur capacité à sauvegarder des données en mémoire rapide de type NoSQL (REDIS : Remote Dictionary Server – Serveur de dictionnaire à distance).

Le découpage du réseau en tranche (Network Slicing) s’appuie sur l’architecture Cloud Native et les technologies SDN/NFV pour apporter des services à faible latence, haut débit, …

Les microservices n’ont pas nécessité de s’appuyer sur des conteneurs, néanmoins les solutions K3s ou K8s apportent plus de la flexibilité et de la scalabilité des fonctions réseaux par rapport aux VM.

Dans le cas de l’architecture NFV [6], une solution basée sur les VM nécessite des gestionnaires spécifiques S-VNFM (vendor-specific VNF manager) ou générique (generic VNF manager) pour la gestion des durées de vie des VMs.

Une application basée sur Kubernetes permet de gérer la durée de vie des conteneurs et des fonctions réseaux NF.

Les conteneurs permettent de gérer efficacement les fonctions du cœur de réseau (AMF/SMF/…).

Par contre les fonctions UPF sont plutôt distribués sur les MEC et la localisation étant imposée, la gestion par VM est plus efficace.

L’approche Cloud Native impose également un seul protocole http2 entre les fonctions réseaux, à l’exception du protocole PFCP sur l’interface N4.

Au niveau du plan de transport, l’établissement d’une session PDU signifie que le réseau 5G transporte du trafic Ethernet, IP ou non structuré. L’utilisation de PoD multi-homed permet d’avoir plusieurs interfaces et permet aussi de gérer différents protocoles (SCTP par exemple)

[1] https://www.redhat.com/fr/topics/cloud

[2] https://www.redhat.com/fr/topics/cloud-native-apps

[3] https://www.redhat.com/fr/topics/cloud-native-apps

[4] https://d1.awsstatic.com/whitepapers/5g-network-evolution-with-aws.pdf

[5] TS 21.195

[6] https://www.etsi.org/technologies/nfv

Evolution de la pile protocolaire LTE vers NR (3/5)

Posté le by - 609 vues
Répondre

La couche RLC

La couche RLC (Radio Link Control) a pour rôle de contrôler le lien de données c’est-à-dire :

  • Le Transfert de PDU vers la couche PDCP selon l’un des trois modes suivants
    • Acquitté AM (Acknowledged Mode)
    • Non Acquitté UM (Unacknowlege Mode)
    • Transparent TM (Transparent Mode)

L’optimisation de la transmission des données est réalisée par l’utilisation d’une fenêtre d’émission et de réception.

  • La correction d’erreur en mode AM par la retransmission d’un RLC PDU perdu
  • La segmentation et le réassemblage des RLC SDU (Mode AM et UM)
  • La re-segmentation de données RLC PDU car le RLC PDU en entier ne peut pas être transmis

 

Afin d’optimiser le contrôle des flux, les fonctions suivantes, réalisées au niveau du RLC-LTE, sont implémentées sur la sous-couche MAC ou PDCP:

  • la concaténation, réalisée au niveau de la couche LTE RLC est mise en œuvre sur la couche NR MAC.
  • La mise en ordre des données, réalisé au niveau de la couche LTE RLC est maintenant réalisée au niveau de la couche NR PDCP.

 

Une entité RLC est établie par la couche RRC afin de monter un bearer radio DRB. L’unité de service de données RLC SDU est issue de la couche PDCP (cf. figure 2) et un numéro de séquence SN (Sequence Number) est assigné à la transmission du RLC PDU et incrémenté à chaque transmission.

L’entité TM RLC transporte (cf. figure 2) les canaux logiques de diffusions BCCH et de notification (Paging : PCCH) et les supports de signalisation SRB0 [FL4].

Les supports de signalisation, autre que le SRB0, sont transmis sur l’entité AM RLC et les supports DRB peuvent être transmis sur une entité AM RLC et une ou deux entités UM RLC.

L’entité UM RLC est mise en oeuvre pour des services en temps réel dont la perte de paquets est acceptable, comme les services multimédias (VoLTE), streaming. L’entité UM RLC est configurée en émission ou réception (uni-directionnel UL ou DL) et supporte la fonction de segmentation.

L’entité AM RLC est mise en œuvre pour des services sensibles à la perte de données et la transmission de rapport de statut. Le protocole ARQ est gérée pour la retransmission des paquets perdus. L’entité AM RLC est bi-directionnelle.

Le RLC PDU est transmis à la couche MAC selon les exigences attendues par la couche MAC (ordonnancement). Ainsi, la couche RLC met en œuvre la segmentation pour adapter la taille du paquet à la MAC SDU et réduire le padding.

La gestion des erreurs pour le mode de transmission AM est mise en œuvre par le protocole ARQ (Automatic ReQuest) au niveau de la couche RLC.

La fonction de segmentation

La fonction de segmentation permet à la couche RLC à l’émission de découper les paquets PDCP PDU qui seront multiplexés par la couche MAC vers un MAC PDU. La couche RLC en réception réalise l’opération inverse, en assemblant les RLC SDU et fournir un PDCP PDU à partir des séquences reçues et numérotées SN.

Figure 7 : Segmentation RLC SDU

La fonction de concaténation n’étant plus assurée au niveau de la couche RLC, les en-têtes RLC augmentent lorsque plusieurs RLC SDU sont multiplexées dans une MAC PDU.

Le nombre de RLC SDU dépend de la taille du bloc de transport TB MAC. Si la taille du bloc de transport n’est pas suffisante alors le paquet de données RLC PDU est segmenté.

Au niveau de l’en-tête RLC PDU, les champs :

  • SI Segment Information indique sur le RLC PDU contient
    • SI =00 un RLC SDU en entier (provenant de la couche PDCP)
    • un segment du RLC SDU (SI=01 début du segment, SI=10 le milieu ou SI=11 la fin du segment)
  • SO Segment Offset indique le décalage en octet du segment du segment par rapport au RLC SDU initial.

Par exemple, le 3ème RLC SDU est segmenté en deux partie : 1000 octets sont transmis dans le 1er segment et 231 octets dans le deuxième segment.

Figure 8 : La segmentation d’un RLC PDU

Figure 9 : La transmission de segments RLC PDU [2]

Pour réduire la taille des en-têtes, il existe deux structures de la MAC PDU pour le mode UM. La figure 10 présente une première structure sans segmentation. On ne transmet pas le numéro de séquence SN car celui-ci ne sert qu’à différencier les différents segments de service RLC SDU dans le RLC PDU.

Figure 10 : Structure RLC PDU en mode UM

Figure 11 : Structure RLC PDU en mode UM

Le protocole ARQ

Dans le cas de transmission en mode acquittée, le protocole ARQ s’appuie sur le numéro de séquence SN pour vérifier qu’aucun segment SDU n’a été perdu lors de la transmission.

Trois fonctions sont implémentées :

  • Interrogation (polling) demandée par l’entité RLC émettrice permet de déclencher un rapport d’état au niveau de la couche RLC réceptrice. Le déclenchement est émis au bout d’un certain nombre de SDU reçus (numéro SN) ou à l’expiration d’un temporisateur. En absence de réception du rapport, l’entité RLC émettrice n’émet pas de nouveaux RLC PDU.
  • Emission d’un rapport d’états, émis par la couche RLC réceptrice permet d’indiquer à la couche RLC émettrice la réception de tous les RLC SDU ou les RLC SDU/segments RLC SDU manquants. Les RLC SDU manquants sont explicitement indiqués par le numéro de séquence SN et en cas de segment, le décalage SO correspondant. Si tous les SDU RLC sont reçus, alors la couche RLC émettrice transmet dans son rapport la valeur de séquence SN la plus haute.
  • Retransmission est effectuée par la couche RLC émettrice en se basant sur le rapport d’état. Le nombre maximum de retransmission est configuré par la couche RRC à l’entité RLC émettrice. Lorsque ce nombre est atteint, la couche RLC émet une notification d’échec du lien radioélectrique RLF (Radio Link Failure). Le ré-établissement d’une entité RLC est contrôlé par le message RRC re-establishment [FL4]

 

 

[1] 3GPP TS 38.322

[2] [https://www.techplayon.com/5g-nr-rlc-um-mode-data-transmission/

[FL4] : https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/

 

Evolution de la pile protocolaire LTE vers NR

Posté le by - 789 vues
Répondre

Introduction

Dans ces 4 articles, nous allons expliquer l’évolution des protocoles radioélectriques LTE/NR permettant :

  • de transmettre différents formats de paquets IP sur la couche physique (LTE/NR), mais également la transmission de trames Ethernet (supportée par la NR uniquement). Les paquets de données, Ethernet ou IP, sont transmis dans des supports radio nommés DRB (Data Radio Bearer) ;
  • de transmettre de manière fiable des messages du protocole RRC à travers des supports de signalisation SRB (Signaling Bearer Data) [FL1]

La transmission est assurée par différentes sous-couches protocolaires héritées des réseaux antérieurs (3G/4G).

Toutefois :

  • pour améliorer la transmission de données, certaines fonctionnalités sont gérées de manière différentes en 4G et 5G comme par exemple :
    • la concaténation est effectuée au niveau de la couche MAC NR et au niveau de la couche RLC LTE
    • la structure MAC PDU NR contient une suite de sous-en-tête MAC immédiatement suivi du SDU ou d’un élément de contrôle (différemment de la structure de la couche MAC LTE) ;
    • la couche MAC NR gère la gestion des faisceaux (Beam Management)
    • la couche MAC de l’UE implémente la fonction LCP (Logical Channel Priority)
  • pour gérer les solutions de double connectivité MR-DC (Multi-Rat Dual Connectivity), la fonction PDCP supporte la séparation des paquets. Ainsi la re numérotation des paquets est également réalisée au niveau de la couche PDCP NR et RLC LTE.
  • pour améliorer la fiabilité des données par duplication des paquets. La couche PDCP est à nouveau utilisée pour dupliquer le paquet en mode DC ou en mode CA.

De plus, la NR est conçue pour un déploiement Cloud (C-RAN/O-RAN). Le protocole est donc pensé pour être implémenté sur des serveurs physiques (datacenter) différents.

Rappels généraux sur les concepts réseaux

Les données sont transmises de sous-couches en sous-couches par des primitives. On appelle SDU (Service Data Unit) les données échangées dans les primitives de services. Il s’agit donc des données utiles qu’une sous-couche N+1 (respectivement N) transmet à une autre sous-couche N (respectivement N+1).

Un protocole défini des règles d’échange de service entre entité de même couche.  Les données échangées par un protocole d’une sous couche N à son homologue de couche N sont nommées PDU (Protocol Data Unit). Un PDU est constitué d’un en-tête (information de contrôle PCI Protocol Control Information) et de données de service SDU : plusieurs SDU de la couche N+1 (respectivement N-1) peuvent être transportés par encapsulation/dés-encapsulation dans un même PDU de la couche N à son homologue de couche N.

Figure 1 : La pile protocolaire NR pour le plan de trafic

Les 4 articles suivants seront consacrés respectivement à la couche MAC, RLC, PDCP et SDAP.

Référence : 

[FL1] : https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/

 

L’accès aléatoire pour les terminaux LTE UE et LTE-BL/CE UE et NB-IoT 4step RA et 2 Step RA

Posté le by - 665 vues
Répondre

La procédure d’accès aléatoire pour les terminaux LTE UE et la procédure d’accès aléatoire pour les terminaux LTE-BL/CE UE dans le cas de la transmission EDT sont presque identiques.

Les objectifs de l’accès aléatoire sont :

  • La connexion radioélectrique d’un terminal UE avec une station de base spécifique, c’est-à-dire l’établissement d’un support radio de signalisation SRB1 (Signaling Radio Bearer 1) sur un canal de contrôle radioélectrique dédié DCCH (Dedicated Channel Control).
  • La gestion de conflit lorsque plusieurs terminaux font une demande simultanée.
  • La synchronisation de la transmission sur le lien montant Uplink pour que le signal réceptionné au niveau de la station de base soit aligné temporellement avec la sous-trame (Timing Advanced). Le Timing Advanced TA correspond à la durée de propagation du signal de l’UE à la station de base.

A travers le signal d’information SIB2 en 4G ou SIB1 en 5G, chaque station de base transmet, par cellule, sa propre configuration de l’accès aléatoire. Ainsi, un UE souhaitant réaliser une connexion radioélectrique est ainsi paramétré par la cellule serveuse, ce qui permet à la station de base de reconnaitre si c’est à elle qu’est adressée la procédure d’accès aléatoire avec contention (CBRA : Contention Based RACH).

En cas de mobilité, lorsque l’UE passe d’une cellule à une autre cellule, il est nécessaire de synchroniser l’UE avec la station de base cible. Dans le cas du HandOver, la procédure d’accès aléatoire sans contention est préférée (CFRA : Contention Free RACH) même si la procédure d’accès aléatoire avec contention reste possible.

Dans le cas de la double connexion MR-DC, le mobile fait une demande de connexion radioélectrique avec le nœud maître MN (Master Node) selon la procédure d’accès aléatoire avec contention CBRA et une fois l’UE connecté, la demande de connexion radioélectrique avec le nœud secondaire est effectuée selon la procédure d’accès aléatoire sans contention.

La liste des paramètres transmis aux terminaux LTE UE et LTE-BL/CE UE sont [4] :

  • Prach-configIndex: indique le format de la demande d’accès aléatoire, et la localisation dans le domaine temporel de la transmission du préambule : la sous-trame dans laquelle doit être transmise la demande d’accès (numéro de la sous-trame et sur toutes les trames ou uniquement les trames paires)
  • Prach-FreqOffset: la localisation dans le domaine fréquentiel de la transmission du préambule
  • rootSequenceIndex: la liste de séquences de Zadoff-Chu parmi les 838 racines de ZC

La procédure d’accès aléatoire 4-Step RA

La procédure d’accès aléatoire traditionnelle s’effectue en 4 étapes sur le canal de contrôle commun (CCCH)

  • Msg1 : Transmission du préambule dans les occasions RACH RO (RACH Occasion) configurées par la station de base afin de séparer les ressources tempo-fréquentielles utilisées pour les terminaux UE et les terminaux MTC (NB-IoT, BL UE et non BL UE). Une liste de préambule est identifiée par station de base et par type de terminaux (UE, NB-IoT, BL UE et non BL UE). L’instant de transmission défini par le numéro de symbole et le slot utilisé, et la fréquence utilisée pour émettre la demande d’accès aléatoire permettent de calculer l’identifiant RA-RNTI.
  • Msg2 : RAR – Response Access Random. La station de base répond au mobile dans un message DCI embrouillé avec l’identifiant RA-RNTI. Le terminal UE est à l’écoute du canal PDCCH. Le message RAR contient l’allocation de ressource en UL permettant au mobile de savoir sur quelles ressources tempo/fréquentielle l’UE transmettra le Msg3 et contient un identifiant radio temporaire T-RNTI. Dans le cas de la transmission EDT, le Msg2 RAR contient de plus un champ indiquant que l’allocation de ressource (UL Grant) correspond à une transmission EDT
  • Msg3 : L’UE envoie une requête RRC avec l’identifiant radio temporaire T-RNTI et un identifiant supplémentaire pour identifier l’UE qui réponse.
    • Si le mobile est à l’état RRC_IDLE,
      • le message émis est la requête RRC Connection Request en 4G ou RRC Setup Request en 5G pour la demande d’établissement d’un bearer radio et bassculer à l’état RRC_CONNECTED
      • le message émis est la requête RRCEarlyDataTransmission Request pour la transmission d’un message EDT en restant à l’état de veille RRC_IDLE.
      • le message émis est la requête RRC ConnexionResume Request pour ré-établir le contexte AS.
    • Si le mobile est à l’état RRC_CONNECTED
      • l’UE a détecté un échec du lien radio (RLF : Radio Link Failure) ou un échec de HandOver, ou un échec sur le calcul d’intégrité MAC_I, le message émis est la requête RRC Connection Re-establishment Request en 4G ou RRC Re-establishment Request en 5G.
      • dans le cas de la 5G (SA ou NSA), si la station de base gNB a envoyé à l’UE le message RRCReconfiguration avec l’information reconfigurationWithSyncIE, alors l’UE réinitialise la couche MAC, relâchant ainsi la configuration UL et le mobile démarre la connexion d’accès aléatoire sur la cellule SpCELL.
    • Si le mobile est à l’état RRC_INACTIVE, le message émis est la requête RRC Resume Request ou requête RRC Resume Request1

Dans le cas des terminaux NB-IoT, LTE-BL/CE UE, les messages 1 et 2 peuvent être répétés plusieurs fois, le nombre de répétition dépend du niveau du puissance de réception de la couverture CE (Coverage Enhanced : CE0, CE1 ou CE2).  La durée de la fenêtre pour la réception du message 2 est également spécifique pour ces terminaux. Ces informations sont transmises dans le SIB2 (SIB2-NB) via l’information RACH-CE-LevelInfoList-r13.

L’UE mesure le niveau de configuration du CE en fonction de la puissance mesurée RSRP. Afin que la station de base prenne connaissance du niveau de CE, la liste des préambules est différente par niveau de CE.

Figure 1 : Niveau de puissance et sélection du CE [1]

La procédure d’accès aléatoire traditionnelle est présentée sur la figure 3 pour le réseau d’accès radioélectrique E-UTRAN et sur la figure 2 pour l’accès radio NG-RAN.

Figure 2 : Procédure d’accès aléatoire sur l’interface LTE

Figure 3 : Procédure d’accès aléatoire sur l’interface 5G-NR [2]

La procédure d’accès aléatoire 2-Step RA – Release R.16

La procédure d’accès aléatoire 2 step RA proposée dans la R.16 permet de réduire la latence et la signalisation en réduisant la procédure d’accès aléatoire à deux échanges. Il s’agit de combiner le message 1 et 3 dans un même message, nommé msgA et les messages 2 et 4 dans un même message nommé msgB.

Figure 5 : Procédure d’accès aléatoire 2 Step RA[2,3]

La procédure d’accès aléatoire à deux étapes 2S-RA s’applique pour les deux procédures avec et sans contention CBRA/CFRA.

Les informations concernant le paramétrage de la procédure d’accès aléatoire est transmise dans le message RRC du SIB1 en 5G. La configuration du réseau défini un seuil msgA-RSRP-Threshold permettant à l’UE de choisir entre l’accès aléatoire à 2 étapes ou 4 étapes.

Si le mobile est à l’état connecté RRC_CONNECTED, le réseau peut configurer le msgA-PUSCH-Config dans la configuration du BWP montant (UL BWP).

La procédure d’accès aléatoire à 2 étapes est plus sensible aux problèmes de ;

  • Réceptions simultanées de plusieurs utilisateurs (payload msgA)
  • Démodulation du message msgA (PUSCH) en étant non synchronisé

Pour savoir quel type de procédure est choisi par l’UE (2 step RA ou 4 Step RA), la liste de préambules pour la demande d’accès à 2 états est différente de la liste des préambules pour la demande d’accès à 4 états.

Les occasions de transmissions des préambules (RO : RACH Occasion) peuvent être spécifiques. La durée de la fenêtre d’écoute du mobile après l’émission de son premier message msgA est définie par le paramètre msgB-ResponseWindow-r16

Les paramètres pour la demande d’accès aléatoires sont définis dans l’élément d’information RACH-ConfigCommonTwoStepRA et msgA-PUSCH-Config-r16 contenu dans la structure du message MsgA-ConfigCommon-r16 (se référer à l’annexe).

Etape 1 : Transmission du message A

Le message A contient un préambule choisi parmi la liste des préambules pour la demande d’accès à 2 états et des données PUSCH (msgA-PUSCH) dans lequel le mobile transmet un message RRC

  • Si le mobile était à l’état connecté RRC_CONNECTED, l’UE transmet son identifiant C-RNTI pour la valeur de ue_identity.
  • Si le mobile était à l’état de veille RRC_IDLE ou à l’état Inactive RRC_INACTIVE, alors l’UE transmet la requête RRC correspondante aux requêtes RRC sur le bearer SRB0 :
    • RRC Setup Request
    • RRCResumeRequest
    • RRCResumeRequest1
    • RRCReestablishmentRequest

Etape 2 : Transmission du message B : msgB

L’UE attend la réponse de la station de base sur une durée définie par la valeur du champ msgB-ResponseWindow (1, 2, 4, 8, 10, 20, 40, 80, 160 ou 320 slots) à partir du symbole suivant le dernier symbole de la séquence d’occasion du PRACH.

L’UE écoute la zone de recherche CORESET et décode le message DCI format 1_0. La réponse destinée au mobile est embrouillée avec l’identifiant C-RNTI si l’UE était en mode connecté ou msgB-RNTI sinon.

L’identifiant msgB_RNTI est calculé de manière assez similaire au RA_RNTI :

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

Lorsque l’UE reçoit le msgB avec l’identifiant C_RNTI, la procédure RA est réussie et la station de base transmet dans le msgB une allocation de ressource pour la voie montante Uplink Grant ou des consignes pour le lien descendant downlink assignment.

Lorsque l’UE reçoit le msgB avec l’identifiant msgB_RNTI, plusieurs réponses sont possibles :

  • La station de base détecte un préambule et arrive à décoder la demande d’accès aléatoire. La station de base retourne à l’UE le message successRAR contenant un identifiant radioélectrique C-RNTI et la valeur du TA.
  • La station de base détecte un seul préambule mais ne parvient pas à décoder le message. A partir de l’instant de réception du préambule, la station de base envoie le message fallback RAR vers l’UE en indiquant la valeur du TA. L’UE poursuit la procédure d’accès aléatoire en 4 étapes et en reprenant au msg3.
  • Plusieurs UE ont lancé la procédure simultanément avec le même préambule, le msgA n’est pas correctement décodé au niveau de la station de base. La station de base ne trasmets pas de fallback RAR car elle ne peut pas indiquer la valeur du TA pour chaque UE. La station de base envoie un message de backoff pour que les terminaux retente la procédure d’accès aléatoire.
  • Le mobile ne reçoit pas le msgB, soit l’UE retente une demande d’accès aléatoire à 2 états ou à 4 états.

 

Références :

[1] https://www.eventhelix.com/5g/standalone-access-registration/5g-standalone-access-registration.pdf

[2] http://howltestuffworks.blogspot.com/2020/04/5g-nr-2-step-random-access-procedure.html

[3] https://www.linkedin.com/pulse/2-step-rach-5g-nr-syed-mohiuddin/

[4] https://blogs.univ-poitiers.fr/f-launay/2022/08/01/bl-ue-non-bl-ue-et-nb-iot-quelles-sont-les-differences/

 

Les supports de signalisation SRB (Signaling Radio Bearer)

Posté le by - 1 421 vues
Répondre

Introduction

L’établissement de bearer radioélectrique de signalisation SRB [1,2] (Signaling Radio Bearer) permettent l’échanges de messages RRC et de messages NAS (couches supérieures) entre l’UE (User Equipment) et la station de base.

Figure 1 : Les supports de signalisation SRB

Jusqu’à la spécification R.14, le réseau d’accès radioélectrique 4G E-UTRAN supporte 3 types de SRB numérotés de 0 à 2. La spécification 3GPP propose le bearer SRB4 à partir de la R.15 [3].

La 5G-NSA introduit un SRB supplémentaire (SRB3) pour l’échange de message RRC entre l’UE et le nœud radioélectrique secondaire SN (Secondary Node) et une séparation des SRB1 et SRB2 nommés respectivement Split SRB1 et Split SRB2.

L’inteface NB-IoT présente le bearer SRB1bis.

L’interface 5G reprend les notions de bearer SRB0 à SRB2.

Les messages échangés entre un UE et une station de base doivent être protégés (chiffrement), authentifiés (intégrité) et sur des allocations de ressources spécifiques (des blocs de ressources physiques PRB alloués à l’UE, éventuellement PRB alloués à plusieurs UE dans le cas d’un multiplexage d’accès non orthogonal NOMA).
Toutefois, lorsque le mobile est à l’état de veille RRC_IDLE, son interface radioélectrique est déconnectée de la station de base. L’UE écoute les informations émises par la station de base (MIB/SIB, Synchronisation, Paging) mais ne transmet aucun message dans le canal dédié PUCCH/PUSCH vers la station de base. Le mobile peut uniquement émettre un message de demande d’accès aléatoire sur le canal commun PRACH et recevoir la réponse sur le canal commun logique CCCH. Des requêtes de signalisation peuvent être émises au cours de cette procédure.

Ainsi, lorsque l’UE souhaite passer de l’état RRC_IDLE à l’état RRC_CONNECTED (cf. article précédent), il doit dans un premier temps signifier sa présence à la station de base en transmettant sa demande sur le canal de contrôle commun. Il s’agit de la procédure d’accès aléatoire RACH (Random Access Channel).

On définit ainsi l’établissement des bearers radioélectrique de signalisation SRB de la
manière suivante :

  • SRB0 correspond à l’échange de signalisation entre l’UE et la station de base lors de la procédure d’accès aléatoire. L’échange entre l’UE et la station de base se fait sur le canal de contrôle commun CCCH, en mode transparent TM-RLC. Les échanges RRC ne sont pas sécurisés (pas de chiffrement, ni d’intégrité). Le bearer SRB0 permet d’allouer des ressources radioélectriques dédiées au mobile pour basculer sur la canal dédié DCCH (Dedicated Control Channel)
  • SRB1 permet l’échange de messages RRC et de messages NAS encapsulés dans le message RRC sur le canal DCCH. Le bearer SRB1 permet l’activation du mode de sécurité entre l’UE et la station de base. Pour activer le mode de sécurité, les premiers messages RRC transmis sur le bearer SRB1 sont non chiffrés mais authentifiés par un sceau MAC. Le dernier message est quant à lui chiffré et authentifié. La transmission se fait en mode acquitté RLC-AM.
    • Pour les terminaux NB-IoT, le bearer de signalisation se nomme SRB1bis
  • SRB2 permet l’échange de message RRC sécurisés. La transmission se fait en mode acquitté RLC-AM.
    • Pour les terminaux NB-IoT, le bearer de signalisation SRB2 n’est pas
      applicable.
  • SRB4 (R.15) est configuré sur le réseau d’accès E-UTRAN pour transmettre des
    mesures au niveau de la couche applicative. Ces mesures sont portées par le canal DCCH

    • Pour les terminaux NB-IoT, le bearer de signalisation SRB4 n’est pas
      applicable

Le bearer SRB0 étant utilisé pour la procédure d’accès aléatoire, ses objectifs sont :

  • D’établir une connexion radioélectrique via le message RRC Connection Setup en 4G ou RRC Setup en 5G
  • De ré-établir la connexion radioélectrique en cas d’échec via le message RRC Connection Re-establishment Request en 4G ou RRC Re-establishment Request en 5G
  • De permettre l’échange de données pour les terminaux LTE BL/CE UE selon
    l’optimisation du plan de contrôle C-IoT EPS optimization ou l’optimisation du plan
    de données U-IoT EPS Optimization.
  • De ré-activer la connexion radioélectrique lorsque le mobile est :
    • à l’état RRC_IDLE via le message RRC Connexion Resume Request à partir de la R.13 [4] sur un cœur de réseau 4G EPC
    • à l’état RRC_INACTIVE via le message RRC Resume Request à partir de la
      R.15 sur un ceour de réseau 5GC

Le bearer SRB1 a pour objectif d’activer la sécurité AS (Access Stratum) entre l’UE et la
station de base et prépare ainsi l’établissement du bearer SRB2. Les messages émis sur le bearer SRB1 sont prioritaires par rapport aux messages émis sur le bearer SRB2.

Le bearer SRB2 est utilisé pour transporter des messages NAS encapsulés dans les requêtes RRC.

Le bearer SRB4 porte les informations sur les mesures relatives à la couche applicative QoE Measurement Collection [5].

Pour l’interface LTE, les messages RRC transmis sont présentés dans le tableau ci-dessous :

Tableau 1 : Les bearers SRB et les messages associés sur l’interface LTE [6]

Pour l’interface 5G NR, les messages RRC transmis sont présentés dans le tableau ci-dessous :

Tableau 2 : Les bearers SRB et les messages associés sur l’interface 5G NR [2]

5G NSA
Le bearer de signalisation SRB3 (R.15) est spécifique au mode MR-DC (EN-DC pour le cas de la 5G-NSA) sur le canal DCCH. La transmission se fait en mode acquitté RLC-AM.

Le support SRB3 permet un échange direct entre l’UE et la nœud radioélectrique secondaire SN (Secondary Node). Le bearer SRB3 est optionnel. L’établissement du SRB3 est décidé par le nœud secondaire.

Tableau 3 : Le bearer SRB3

Références :
[1] TS 36.331 v17
[2] TS 38.331
[3] TS 36.331v15.3.0
[4] TS 36.331, Release 13, version 13.2.0
[5] TS 26.247
[6] https://www.rfwireless-world.com/Tutorials/LTE-signalling-radio-bearers.html

Les états du terminal en 5G

Posté le by - 1 093 vues
Répondre

Introduction

Lorsque le réseau 4G a été standardisé, le terminal UE ne pouvait être que dans deux états RRC :

  • RRC_IDLE dit en mode de veille. Ce mode est optimisé de par sa faible
    consommation de puissance
  • RRC_CONNECTED dit en mode connecté. A l’état RRC_CONNECTED, l’UE
    échange des données avec la station de base.

Ces deux états RRC_IDLE et RRC_CONNECTED sont optimisés pour le cas d’usage eMBB (Mobile BroadBand), mais ne sont pas efficace pour des transmissions fréquentes de paquets de petites tailles.

La spécification R.15 relative à la 5G apporte un état supplémentaire RRC_INACTIVE. Le passage de l’état RRC_INACTIVE à l’état RRC_CONNECTED est établi lors de la procédure d’accès aléatoire via le message RRC Connection Resume Request.

A l’instar de la 4G, le passage de l’état RRC_IDLE à l’état RRC_CONNECTED est réalisé lors de la procédure d’accès aléatoire. Dans le cas de l’interface 5G NR, voici les 3 requêtes RRC échangées pour l’établissement de la connexion (les deux premières requêtes sont transmises lors de la procédure d’accès aléatoire RACH) :

  • RRCSetupRequest initié par le terminal UE pour l’établissement d’une connexion RRC (msg 3 de la procédure RACH)
  • RRCSetup (msg4 de la procédure RACH)
  • RRCSetupComplete.

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

Sur un cœur de réseau 4G : le passage de l’état RRC_CONNECTED à l’état RRC_IDLE est provoqué :

  • Soit par le relâchement de la connexion RRC en fin d’un temporisateur ou par ordre du MME dans le cas où il est congestionné.
  • Soit par la suspension de la connexion RRC

Le relâchement est normalement initié par le réseau d’accès radioélectrique RAN via la requête RRCConnectionRelease. Dans certains cas, le mobile peut néanmoins relâcher sa connexion RRC et passer à l’état RRC_IDLE sans en informer le réseau d’accès radioélectrique.

La requête RRC Connection Release émise sur le bearer de signalisation SRB1 supprime le contexte AS au niveau du réseau d’accès radioélectrique et du mobile.

Figure 2 : Relâchement de la connexion RRC

Dans le cas d’usage pour l’IoT (CAT-M, NB-IoT), la spécification 3GPP propose dans la R.13 la suspension de la connexion RRC. Celle-ci est à l’initiative du réseau d’accès radioélectrique en émettant la requête RRCConnectionRelease, et le terminal revient à l’état RRC_IDLE. Cette requête contient :

  • L’identifiant resumeIdentity pour retrouver le contexte de l’UE
  • La cause de relâchement : rrc-Suspend

Lorsque le terminal est à l’état RRC_IDLE, la requête RRC ConnectionResumeRequest, est exécutée par le terminal UE pour restaurer le contexte AS. Le mobile passe ainsi à l’état RRC_CONNECTED.

Lorsque le mobile émet sa requête RRCConnectionResumeRequest alors l’UE restaure :

  • la configuration RRC
  • le contexte de sécurité à partir du contexte AS conservé au niveau de l’UE
  • l’état PDCP et le ré-établissement de l’entité PDCP pour le bearer SRB1

A la réception du message RRCConnectionResume au niveau de l’UE, celui-ci restore le SRB2 et le DRB et met à jour la clé Kenb à partir de la clé Kasme et de la valeur
nextHopChainingCount contenu dans le message RRCConnectionResume puis dérive les clés de chiffrement du lien radio.

Pour résumer, cette procédure RRCConnectionResume permet de ré-activer les bearers SRB et DRB ainsi que le contexte de sécurité AS.

Figure 3: Accès aléatoire : Mode connecté en 4G

Sur un cœur de réseau 5GC

Pour prendre en compte les cas d’usage de l’IoT et URLLC, le standard 3GPP a défini un nouvel état nommé RRC_INACTIVE dans le cas de la 5G. Un terminal UE est soit à l’état RRC_CONNECTED, soit à l’état RRC_INACTIVE à partir du moment ou une connexion RRC a été établie [1].

L’état RRC_INACTIVE a été introduit pour les terminaux IoT (R.15) dans le but de réduire le nombre de requêtes de signalisation et par conséquent la consommation énergétique.

Comme nous l’avons vu précédemment, la spécification R.13 introduisait déjà deux nouveaux messages : RRCConnectionRelease avec la cause rrc_suspend pour conserver des informations de contexte du terminal UE au niveau du mobile et de la station de base et RRCConnectionresume pour restaurer le contexte et les bearers.

La figure 4 présente les états et les passage d’un état à un autre état dans le cas d’un réseau 5G.

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

Figure 4 : Les états du mobile UE sur un cœur 5GC

Lorsque le mobile est à l’état RRC_INACTIVE, cela permet :

  • De transmettre rapidement des petits paquets de données sans délai ;
  • De réduire les requêtes de signalisation et la latence associée
  • Réduire la consommation énergétique du mobile par rapport à l’état RRC_CONNECTED

La suspension de la connexion RRC est initiée par le réseau d’accès radioélectrique RAN via :

  • LTE : la requête RRCConnectionRelease avec pour cause rrc_suspend (pour l’UE ou pour un NB-IoT ReleaseCause-NB-r13)
  • 5G-NR : la requête RRCRelease with Suspend Config.

Le relâchement est normalement initié par le réseau d’accès radioélectrique RAN via la requête RRCRelease en 5G. Dans certains cas, le mobile peut néanmoins relâcher sa connexion RRC et passer à l’état RRC_IDLE sans en informer le réseau d’accès radioélectrique.

La requête RRCRelease supprime le contexte AS au niveau du réseau d’accès radioélectrique et du mobile.

La requête de suspension de la connexion RRC est chiffrée et protégée en intégrité. Lorsque le mobile doit suspendre sa connexion RRC, il conserve son contexte AS et l’identité associé au contexte resumeIdentity. La suspension ne peut se faire que si au moins un DRB a été établi.

A la différence du cœur de réseau 4G EPC [2]:

Sur le cœur de réseau 5GC : le passage de l’état RRC_CONNECTED à l’état RRC_IDLE est provoqué par le relâchement de la connexion RRC.

Sur le cœur de réseau 5GC : le passage de l’état RRC_CONNECTED à l’état RRC_INACTIVE est provoqué par la suspension de la connexion RRC

Sur l’interface radio 5G NR ou E-UTRA (connecté au cœur de réseau 5GC), pour passer de l’état RRC_CONNECTED à l’état RRC_INACTIVE, le réseau d’accès radioélectrique suspend la connexion radioélectrique avec l’UE. Le basculement est déclenché par la requête RRC_RELEASE_WITH_SUSPEND émise par la station de base vers le terminal sur l’interface NR et par la requpete RRC_RELEASE avec la cause rrc_suspend sur l’interface E-UTRA.

Pour passer de l’état RRC_INACTIVE à l’état RRC_CONNECTED, le terminal émet la requête RRCConnectionResumeRequest ou la requête RRCResumeRequest à la station de base.

L’état RRC_INACTIVE est proche de l’état RRC_IDLE au niveau de l’accès radioélectrique avec conservation de son contexte AS et de l’état CONNECTED pour le cœur de réseau :

  • Le contexte AS est maintenu au niveau de la station de base et de l’UE
  • Le réseau d’accès radioélectrique connait la zone de tracking radioélectrique RNA (RAN based Notification Area), zone dans laquelle l’UE peut se déplacer sans aucun échange de signalisation vers le réseau d’accès radioélectrique. Il s’agit de la zone de paging radioélectrique
  • Le cœur de réseau considère que le mobile est toujours à l’état RRC_CONNECTED. La fonction AMF conserve son contexte, lui permettant de savoir quelle fonction SMF gère le bearer entre l’UPF et le gNB.

La figure ci-dessous présente les différents états du terminal UE et le passage d’un état à un autre état pour un cœur de réseau 5GC

L’état E-UTRA RRC_INACTIVE n’est pas défini pour un cœur de réseau 4G EPC

Figure 5 : Les procédures de mobilité entre l’E-UTRA/5GC et le NG-RAN/5GC

La figure ci-dessous présente les différents états du terminal UE et le passage d’un état à un autre état pour un cœur de réseau EPC à droite.

Figure 6 : Les procédures de mobilité entre l’E-UTRA/5GC et l’E-UTRA 4G

Dans l’état NR RRC_IDLE :

  • le mode DRX peut être activé avec un temporisateur spécifique pour l’UE
  • Le terminal UE contrôle sa mobilité (re-sélection de cellule) à partir de la
    configuration réseau
  •  Le terminal UE
    • Scrute les messages de notification (paging) sur le canal de contrôle PDCCH à partir de l’identifiant radio P-RNTI embrouillant le message DCI.
    • Scrute le canal de paging avec l’identité 5G-S-TMSI
    • Réalise des mesures radioélectriques pour la (re)sélection de cellules avec les  stations de base voisines
    • Lit les informations de diffusion (SI) et peut éventuellement envoyer une requête SI (si configuré)

Dans l’état NR RRC_INACTIVE :

  •  le mode DRX peut être activé avec un temporisateur spécifique pour l’UE par le NAS ou par le gNB (upper layer or RRC layer)
  • Le terminal UE contrôle sa mobilité (re-sélection de cellule) à partir de la
    configuration réseau
  • L’UE sauvegarde le contexte AS Inactif
  • Une zone de paging RNA (RAN-Based Notification) est configuré sur la couche RRC
  • Le terminal UE :
    • Scrute les messages de notification (paging) sur le canal de contrôle PDCCH à partir de l’identifiant radio P-RNTI embrouillant le message DCI.
    • Scrute le canal de paging avec l’identité 5G-S-TMSI et les paging radio avec
      l’identifiant radioélectrique I-RNTI
    • Réalise des mesures radioélectriques pour la (re)sélection de cellules avec les stations de base voisines
    • Lit les informations de diffusion (SI) et peut éventuellement envoyer une requête SI (si configuré)

Dans l’état NR RRC_CONNECTED

  • L’UE conserve l’état du contexte AS
  • Transfère les données entre le mobile et la station de base
  • L’UE peut être configuré en mode C-DRX sur la couche MAC
  • L’accès radioélectrique contrôle la mobilité de l’UE
  • Le terminal UE :
    • Scrute les messages de notification (paging) sur le canal de contrôle PDCCH à partir de l’identifiant radio P-RNTI embrouillant le message DCI.
    • Scrute les canaux de contrôles associés au canal PDSCH pour être informé de l’ordonnancement
    • Réalise des mesures de qualité du lien radio CSI
    • Réalise des mesures radioélectriques et déclenche la transmission des données vers la station de base pour l’aider à réaliser le handover.
    • Lit les informations de diffusion (SI) et peut éventuellement envoyer une requête  SI (si configuré)

Référence : https://devopedia.org/5g-ue-rrc-states

[1] TS 38.331 : NR; Radio Resource Control (RRC); Protocol spécification (3GPP TS 38.331 version 17.0.0 Release 17)

[2] TS 36.331v15.3.0  TS 36.331 : Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (3GPP TS 36.331 version 15.0.0 Release 15)

 

Thèse : Etude de la couverture 5G par des drones

Posté le by - 869 vues
2

Etude de la couverture 5G par des drones

Encadrants : Frédéric LAUNAY et Patrick COIRAULT
Laboratoire d’accueil : Laboratoire d’Automatique et d’Informatique pour les Systèmes (LIAS)

Contact : frederic.launay@univ-poitiers.fr

Date : Octobre 2023 à Septembre 2026

Contexte : La couverture 5G est classiquement apportée par des noeuds radioélectriques (nommés stations de base gNB) statique. Dans le cadre de manifestation évènementielle (Jeux Olympique, Tour de France, Concert, …) ou d’exercice de sécurité civile/militaire, le déploiement de drones (UAV)
apporte une couverture radioélectrique ponctuelle dont les performances seront à étudier selon les cas d’usage et selon les critères suivants : Débit, latence, densité, consommation énergétique, fiabilité du lien (call drop, radio failure) et minimisation d’énergie.

Sujet : Dans le cadre de missions d’opération d’urgence ou pour des manifestations évènementielles, les opérateurs apportent une connectivité supplémentaire en ajoutant une station de base. Toutefois, la couverture n’est pas optimisée puisque la station de base est fixe et son emplacement est estimée au mieux pour apporter une couverture radioélectrique en fonction de la densité de population donnée.

Financement : Ministère
Mots clés : Contrôle multi-agents, théorie des graphes, services 5G (mMTC, URLLC, eMBB), optimisation énergétique, Canal radio, UAV, déploiement multi-tiers, COMP, massive MIMO

 

Pour en savoir plus :

https://www.lias-lab.fr/jobs/2023_lias_as_optimal_deployment_thesis_fr_en.pdf