Archives de l’auteur : flaunay

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 - 362 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 - 519 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 - 442 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)

 

L’IoT – Evolutions R16 et R17

Posté le by - 321 vues
Répondre

Introduction

Le standard 3GPP a démarré ses travaux de normalisation pour l’IoT à partir de la R.10 pour définir une liste de spécifications pour les terminaux et le cœur de réseau afin d’éviter la congestion (Extended Access Barring), d’avoir moins d’impact sur les smartphones (LAPI), réduire la complexité (Half Duplex, réduction de la puissance, bande plus petite …), avoir une meilleure sensibilité pour une transmission à faible débit (bande plus petite).

Dans la R.11, la 3GPP propose une méthode de réveil de terminaux et une transmission de données par SMS.

Dans la R.12, la 3GPP propose des optimisations pour la réduction de la consommation énergétique (UEPCOP : mode PSM et eDRX) et une méthode de transmission de données de taille réduite (Small Data)

Figure 1 : Le standard 3GPP R10 à R12 pour l’IoT

Dans la R.13, la 3GPP une optimisation du cœur de réseau pour prendre en charge la transmission de données :

  • dans le plan de contrôle Control-Plane CIoT EPS Optimization ;
  • dans le plan de trafic User-Plane CIoT EPS Optimization.

L’optimisation CP CIoT EPS Optimization propose de transmettre des données dans un message NAS entre l’UE et le MME. Sur l’interface radioélectrique, le message NAS est encapsulé dans un message RRC, lorsque le mobile est à l’état RRC_CONNECTED, c’est-à-dire à la suite de la procédure d’accès aléatoire. Dans l’optimisation CP CIoT EPS Optimization , la mise en sécurité AS n’est pas mise en œuvre, c’est-à-dire la connexion RRC n’est ni chiffrée, ni authentifié (intégrité).

L’optimisation UP CIoT EPS Optimization permet de transmettre des données entre l’UE et le MME lorsque le mobile est à l’état RRC_CONNECTED avec la mise en sécurité AS. Cela suppose que le contexte AS soit conservé au niveau du terminal UE et de la station de base. La R.13 propose une procédure de suspension/reprise de la connexion RRC lorsque le mobile passe de l’état RRC_CONNECTED à l’état RRC_IDLE.

Figure 2 : L’optimisation du coeur de réseau

Sur l’interface LTE, l’optimisation CIoT EPS Optimization permet de transporter les données sur la couche RRC. Le MME peut ensuite transférer les données vers le plan de transport SGW ou l’entité SCEF (Service Capability Exposure Function).

La R.14 introduit les spécifications à mettre en oeuvre pour le 5G MTC.

Figure 3 : Les améliorations proposées de la spécification R.10 à la R.14

La transmission EDT

Pour réduire la signalisation, la transmission EDT (Early Data Transmission [1]) propose de transmettre les données dans un message RRC au cours de la procédure d’accès aléatoire (RACH EDT). On distingue la transmission CP-EDT s’appuyant sur l’optimisation du plan de contrôle CP-EDT (sans chiffrement) de l’optimisation du plan utilisateur UP-EDT (avec chiffrement).

L’inconvénient de la procédure EDT est la transmission du message sur le canal de contrôle commun. Celle-ci est donc interférée par les demande d’accès aléatoire pouvant simultanément avoir lieu sur les mêmes bandes de fréquences.

La transmission UP-EDT est :

    • soit à l’initiative du terminal (Mobile Originated MO-EDT) spécifiée dans la R.15
    • soit à destination du terminal (Mobile Terminated MT-EDT) spécifiée dans la R.16.

La transmission EDT a été proposée dans la R.15 pour optimiser la transmission de messages courts lors de la procédure d’accès aléatoire. Au cours de cette procédure, le mobile reste à l’état RRC_IDLE sans contexte AS (CP EDT – Contol Plane EDT) ou en ayant conservé le contexte AS (UP EDT – User Plane EDT). A l’issue de la demande d’accès aléatoire, la transmission EDT étant finalisée, le mobile rester à l’état RRC_IDLE. Si d’autres données doivent être émises ou reçues, le terminal passe à l’état RRC_CONNECTED.

Dans ce cas, le premier paquet est transmis selon la procédure EDT, les autres paquets seront transmis de manière traditionnel.

La transmission PUR (Preconfigured Uplink Resource) consiste à pré-configurer les ressources du lien montant (UL) au cours d’une première connexion radioélectrique (RRC_CONNECTED). Cela signifie que la transmission PUR nécessite qu’en amont le terminal ait été dans l’état RRC_CONNECTED afin de recevoir la pré-configuration désirée.

La transmission PUR est utilisable par le terminal à l’état RRC_IDLE sans nécessité de procédure d’accès aléatoire mais en ayant conservé un contexte AS et l’allocation UL.

Ensuite, lorsque le mobile est en mode de veille, il peut utiliser les ressources qui lui sont réservées pour transmettre ses données sans avoir à mettre en œuvre la procédure d’accès aléatoire

Sur un cœur de réseau 5GC, la 3GPP propose un nouvel état radioélectrique du mobile nommé RRC_INACTIVE dédié aux terminaux IoT.

Le cœur de réseau 5GC pouvant être connecté à l’interface radioélectrique 4G E-UTRA et 5G-NR, l’état RRC_INACTVE s’appliquera à l’UE sur chacune des interfaces.

La transmission SDT (Small Data Transmission) est une procédure permettant de transmettre des petites quantités de données entre un terminal UE et le cœur de réseau 5GC en passant soit par l’accès radioélectrique 4G E-UTRA ou l’accès radioélectrique 5G-NR lorsque le terminal UE reste à l’état RRC_INACTIVE. La transmission SDT peut se faire sur l’interface E-UTRA comme sur l’interface 5G-NR.

La transmission non SDT correspond à la transmission traditionnelle de données entre un UE et le cœur de réseau 5GC via l’établissement de bearers lorsque l’UE est à l’état RRC_CONNECTED.

La transmission SDT sur l’interface 5G-NR a été introduite dans la spécification R.16 sous le nom NR SDT. La spécification R.17 propose deux technologies nommées RA-SDT (RACH SDT) et CG-SDT (Configured Grant SDT) lorsque le mobile est à l’état RRC_INACTIVE.

Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G

[1] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

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

Posté le by - 528 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

Sujet de Master Recherche

Posté le by - 255 vues
Répondre

Déploiement optimal d’une couverture radio 5G par UAV

Date : Mars à Juillet 2023

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

Contact : frederic.launay@univ-poitiers.fr

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.

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

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.

Profil souhaité :
Le candidat devra posséder des connaissances en mathématiques appliqués, en automatique et/ou en traitement du signal.
Une bonne connaissance en programmation (Matlab) est nécessaire. Un bon niveau en français et en anglais est fondamental.

Sujet de Master/Ecole d’Ingénieur

Posté le by - 255 vues
Répondre

Mise en oeuvre d’une architecture 5G privée expérimentale

Lien : https://t.co/5orLRbxYm2

Date : Mars 2023 à Juillet 2023

Encadrant: Frédéric LAUNAY
Contact : frederic.launay@univ-poitiers.fr

Le département R&T de Poitiers – site de Châtellerault dispose d’un mini Datacenter DELL, d’une carte radio USRP NI (SDR) et de cartes SIMs.
Les techniques de radio logicielle (SDR) font partie des technologies privilégiées ces dernières années pour l’évaluation expérimentale des réseaux de communication sans fil, et notamment OpenAirInterface, une plateforme logicielle open-source pour les réseaux 4G et 5G.
Le projet utilisera la base logicielle de l’OAI ainsi que d’autres logiciels open source pour construire une solution complète et native pour la 5G privée.
La solution OAI sera comparée à une autre solution OpenSource (Bubble, Free5GC, SRSRAN, …).

Le travail du stage consistera donc à la mise en place de la plateforme 5G expérimentale, et à ensuite évaluer la mise en œuvre de service complémentaires (IMS pour la Vo5G, missions critiques, …) pour que la plateforme 5G devienne un banc de test des modes de slicing.
L’étudiant(e) stagiaire devra tester deux solutions OpenSource, réalisera une documentation complète pour la configuration du serveur et de la carte USRP et une documentation sur la configuration de cœur de réseau et de l’accès radio.

 

Le/La candidat(e) recherché(e) est étudiant(e) en master ou école d’ingénieur ayant des compétences en informatique et télécommunications afin de mettre en oeuvre des instances virtuelles pour la configuration d’équipements physiques et proposer des API.

Connaissances exigées
L’étudiant(e) doit avoir :
 Une connaissance des systèmes de Télécommunication et principalement de la station de base gNB pour la configuration de cette dernière.
 Une connaissance Linux
 Une connaissance de la virtualisation (VM et conteneur)

 

 

BL UE, non BL UE et NB-IoT, quelles sont les différences?

Posté le by - 781 vues
Répondre

Les procédures relatives au fonctionnement des terminaux UE différent selon le type de terminal.

A titre d’exemple, la procédure d’accès aléatoire (se référer au paragraphe 5.1.1 de la spécification TS36.321) indique :

« Before the procedure can be initiated, the following information for related Serving Cell is assumed to be available for UEs other than NB-IoT UEs, BL UEs or UEs in enhanced coverage « 

L’objectif de cet article est de préciser à quel terminal fait référence la spécification.

Dans le cadre des transmissions IoT, la spécification 3GPP a proposé plusieurs techniques :

  • d’optimisation d’énergie (eDRX, PSM, Half Duplex, réduction de la puissance d’émission)
  • de simplification des terminaux (Half Duplex/absence de duplexeur, réduction de la puissance d’émission – PA optionnel, largeur de bande réduite – moindre complexité des antennes et des filtres)
  • d’amélioration de la couverture dite aussi CE Coverage Enhanced (réduction de la bande – meilleure sensibilité, répétition – mode A ou mode B)

L’implémentation de ces optimisations a permis de définir différentes catégories de terminaux dédiés à l’IoT :

  • NB-IoT qui émet/reçoit sur une sous porteuse jusqu’à 12 sous porteuses maximums (RB)
  • BL UE (Bandwidth reduced Low Complexity) qui utilise une sous bande réduite de l’interface LTE, typiquement de :
    • 6 RB (LTE-M1) pour les liens montants et descendants
    • 24 PRB (LTE-M2) pour augmenter le débit de transmission. Ces terminaux augmentent uniquement la largeur de bande des canaux PDSCH et PUSCH
  • Non BL UE fonctionnant dans le mode CE (Coverage Enhanced) utilisant jusqu’à 24 PRB dans le lien montant et 24 PRB ou 96 PRB dans le sens descendant.

La largeur de bande pour le lien montant et descendant est configurée par la signalisation RRC.

Un terminal BL UE se synchronise sur les canaux PSS/SSS de l’interface LTE mais, le terminal ne peut camper sur la cellule seulement si l’information MIB indique la présence d’un SIB1 (nommée SIB1-BR) dédié aux terminaux UE BL La cellule est considérée comme barrée en absence de cette information.

Les informations sur la localisation du SIB1 est diffusée par le MIB via l’information schedulingInfoSIB1-BR-r13 codée sur 5 bits. Si la valeur est égale à 0, le SIB1-BR n’est pas transmise. La valeur entre 1 et 31 indique la transmission du SIB-BR et la répétition du canal PDSCH qui transporte le SIB1-BR.

Les autres SIB sont séquencés à partir du SIB1-BR. Le SIB2-BR permet au terminal BL UE d’acquérir les informations sur les préambules d’accès aléatoires.

On différence ainsi les catégories de terminaux :

  • NB-IoT
  • BL UE : LTE-M1/LTE-M2
  • Non BL UE : LTE cat.0

La taille du bloc de transport TBS (Transport Block Set) pour la diffusion d’information est limitée à 1000 bits pour les terminaux BL UE.

La taille du bloc de transport pour le canal de trafic PDSCH/PUSCH est limitée à 1000 bits pour les terminaux LTE-M1 et à 680 bits pour les terminaux NB-IoT.

.

PCell, SCell, PScell et SpCell

Posté le by - 1 069 vues
Répondre

L’augmentation en débit entre le déploiement de la 4G et le déploiement de la 4G+/4G++ (UHD) a été rendue en partie possible par la technique d’agrégation de porteuses radioélectriques supplémentaires 4G. La technique d’agrégation de porteuses (ou CA : Carrier Agregation) à 2/3/4 ou 5 bandes 4G (LTE Advanced/LTE Advanced Pro) permet ainsi au mobile de disposer théoriquement jusqu’à 100 MHz de bande radioélectrique (ce qui correspond à 5 bandes de 20 MHz) [1].

La technique d’agrégation de porteuses est supportée par la couche MAC et la couche physique. On différencie la porteuse composante primaire (PCC : Primary Component Carrier) et la porteuse composante secondaire (SCC : Secondary Component Carrier). La PCC correspond à la porteuse principale LTE et les SCC correspondent aux porteuses agrégées.

On définit la cellule principale (PCell) la cellule sur la porteuse PCC. La PCell correspond à la cellule choisie par le mobile pour demander l’établissement ou le ré-établissement du lien radioélectrique. La Pcell est modifiée lors d’un handover ou libérée en fin de session. Les porteuses secondaires SCC permettent au mobile d’augmenter sa bande passante sur les cellules correspondantes aux fréquences secondaires. Les cellules secondaires (SCell) sont configurées lors d’un message RRC (RRC connection) et sont ensuite activées ou désactivées par la couche MAC via un message DCI.

Le message DCI est porté par le canal physique PDCCH. Le canal PDCCH ne porte l’allocation que d’une seule porteuse.

L’allocation de ressource via le canal PDCCH peut être transmise [2] :

  • soit sur la porteuse correspondante aux ressources désirées, on parle de self-scheduling car chaque porteuse agrégée alloue ses ressources sur le canal PDCCH de la porteuse agrégée ;
  • soit sur la porteuse principales et chaque canal PDCCH porte l’allocation de ressources de la porteuse principale ou d’une porteuse agrégée. On parle alors de cross-scheduling.

Lorsque le mobile est en mode connecté, la cellule serveuse (Serving Cell) correspond à une porteuse composante (CC : Component Carrier) c’est à dire la cellule primaire ou une cellule secondaire. La station de base gère la cellule principale ainsi que les cellules secondaires via les messages DCI de la couche MAC.

Le déploiement de la 5G-NSA met en œuvre un mécanisme de double connectivité multi-radio (MR-DC), mécanisme pour lequel on différencie le nœud maître (MN : Master Node) du nœud secondaire (SN : Secondary Node).

Le nœud maître établie la connexion de signalisation entre le mobile UE et le cœur de réseau. Dans le cas de la 5G NSA option 3, le nœud maitre est une station de base 4G. Le nœud maître correspond toujours au nœud sélectionné par l’UE en mode de veille et sur lequel l’UE fait sa demande initiale d’accès aléatoire.

Le nœud secondaire quant à lui a pour rôle de fournir des ressources radioélectriques supplémentaire et contrairement au nœud maître, il ne permet pas l’établissement d’un plan de contrôle avec le cœur de réseau. Dans le cas de la 5G-NSA, le nœud secondaire est une station de base 5G nommée en-gNB.

La technique d’agrégation de porteuses peut être mise en œuvre sur le nœud maître et/ou sur le nœud secondaire. On différencie l’agrégation de porteuses sur le nœud maître par un groupement de cellules MCG (Master Cell Group) et l’agrégation de porteuses sur le nœud secondaire par un groupement de cellules SCG (Secondary Cell Group).

Lorsque le nœud maître initie la demande d’établissement avec le nœud secondaire, le mobile recevra l’ordre via un message RRC (RRC reconfiguration) d’établir une demande d’accès aléatoire RACH avec la cellule secondaire SN et de faire des mesures radioélectriques sur le nœud secondaire et plus particulièrement sur la cellule sur laquelle le mobile aura établi sa demande d’accès aléatoire. Il s’agit donc de la cellule principale du groupe de cellules secondaires PSCell (Primary SCG Cell soit Primary Secondary Cell Group Cell).

Ainsi, lors de la double connectivité, l’UE réalise des mesures radioélectriques sur la cellule principale de la cellule serveuse maîtresse (PCell du MCG) et sur la cellule principale de la cellule serveuse secondaire PSCell ainsi que des mesures sur les cellules agrégées.

On appelle PCell la cellule principale de la station de base maîtresse et en cas d’agrégation de porteuse sur cette cellule, on appelle SCell, les cellules secondaires du MCG.

On appelle PSCell, la cellule principale de la station de base secondaire et on appelle également Scell les cellules secondaires du SCG.

La signalisation RRC n’étant émise que sur les cellules principales PCell et PSCell, le concept de Special Cell détermine la signalisation vers les cellules Maîtres et Secondaires : SpCELL = PCell + PSCELL

 

Reférences

[1] : ETSI TS 138 133 V15.2.0 (2018-07)

[2] https://www.3gpp.org/technologies/keywords-acronyms/101-carrier-aggregation-explained#:~:text=Carrier%20Aggregation%3B%20Primary%20and%20Secondary,coverage%2C%20i.e.%20different%20cell%20size.

MOOC 5G – 2022

Posté le by - 1 104 vues
Répondre

MOOC 5G : A ne pas rater.

Xavier Lagrange est professeur à l’institut IMT Atlantique ; il est responsable de l’équipe de recherche ADOPNET du département (Réseaux, Télécommunications et Services) de l’IRISA. Dans ce Mooc M Lagrange propose de nouvelles vidéos très pédagogiques sur le fonctionnement de la 5G.

Au cours de la semaine 2, M Lagrange et son équipe présentent l’architecture du réseaux 5G et les services attendus (5G SA).

La semaine 3, l’interface radio est présentée avec un rappel de l’interface radio 4G.

La semaine 4, les protocoles et procédures de gestions de flux sont abordés

La semaine 5, les mécanismes de sécurité permettent de comprendre les protections mises en œuvre pour l’authentification (AKA), le chiffrement et l’intégrité (CIA). Une présentation détaillée du SUCI est remarquable. Bien que très complexe, M Lagrange a réussi à expliquer simplement l’échange de clé, le calcul de la clé éphémère partagée et le calcul du SUCI.

La semaine 6, l’architecture Cloud Native est présentée (SBA et SBI)

La semaine 7, on découvre l’interconnexion entre réseaux et les fonctions de sécurités.

La formation est très intéressante (il existe aussi une formation sur la 4G) et l’approche très didactique et pédagogique.

Si vous ne vous êtes pas encore inscrit, cliquez sur le lien suivant :

https://www.coursera.org/learn/5g-principes-de-fonctionnement#instructors

Et bonne formation.