Archives de l’auteur : flaunay

COURS IUT Chapitre 1 (Part 1)

Posté le by - 3 018 vues
Répondre

Chapitre 1 : L’architecture du réseau de mobiles 4G

1-1. L’architecture fonctionnelle

Le réseau de mobiles 4G a été défini dans la Release.8 sous le nom EPS (Evolved Packet System).

L’architecture fonctionnelle du réseau EPS est décrite à la figure 1.1. Elle se découpe en deux sous réseaux : un cœur réseau EPC (Evolved Packet Core) et un réseau d’accès radioélectrique E-UTRAN (Evolved Universal Terrestrial Radio Access Network).

Figure 1.1. L’architecture fonctionnelle du réseau EPS (1)

Le réseau d’accès E-UTRAN assure la connexion des mobiles et la réservation des ressources radio entre le mobile UE  (User Equipment) et l’entité eNB (evolved Node Base station) sur une bande de fréquences (LTE) ou sur plusieurs bandes de fréquences (LTE-Advanced).

Le cœur de réseau EPC interconnecte les réseaux d’accès, fournit l’interface au réseau de données PDN (Packet Data Network) et assure l’attachement des mobiles, l’autorisation d’accès au service et l’établissement des supports (bearers).

L’architecture protocolaire s’appuie sur le protocole IP  (Internet Protocol), chaque entité dispose d’une ou plusieurs adresses IP. Les entités sont connectées entre elles par un réseau de transport (backhaul) constitué de routeurs permettant de faire des marquages de QoS (Quality Of Service). Le protocole de routage utilisé est le MPLS (MultiProtocol Label Switching ) et la QoS est gérée par étiquetage d’un champ d’entête IP nommé DSCP (DiffServ Code Point).

Figure 1.2. Le réseau EPS et le backhaul

1.1.1. L’entité eNB

L’entité eNB est la partie visible du réseau de l’opérateur. L’eNB est composé :

  • d’une ou plusieurs antennes : l’antenne est l’élément passif qui transforme un signal électrique en une onde électromagnétique et réciproquement ;
  • d’un ensemble d’émetteurs/récepteurs nommés TRX modulant le signal numérique en signal analogique vers l’antenne et inversement. Les modules TRX gèrent aussi la compensation du signal modulé ;
  • d’amplificateur de puissance. Le signal issu de l’émetteur est amplifié ;
  • d’une unité de traitement en bande de base BBU (Base Band Unit).

Le système actif est généralement situé dans un local technique constitué :

  • d’une alimentation et des batteries de secours (Power Distribution Module)
  • d’un système de ventilation (Fan Control Module) ;
  • d’un contrôleur (Control and Maintenance Module) ;
  • d’élément de transmission (Transceiver Module) ;
  • des connecteurs d’antennes (Combiner Distribution Unit).

Le local technique est soit positionné au pied de l’antenne, soit dans un abri (shelter) sur le toit (rooftop). La figure 1.3 représente la structure matérielle de l’entité eNb dans laquelle se trouvent l’unité BBU, et le système actif.

Figure 1.3. La description matérielle d’une station de base (2)

Depuis quelques années, on voit apparaître un boitier nommé unité RRU (Remote Radio Unit) ou RRH (Remote Radio Head) proche de l’antenne.

L’unité RRU englobe les fonctions permettant de convertir le signal en bande de base vers un signal radio-fréquence (RF) et inversement.

L’unité RRU est donc composée des modules de transmissions TRX et des amplificateurs.

Figure 1.4. Le découpage BBU et RRU

On sépare ainsi la fonction de bande de base effectuée par l’unité BBU de la fonction Radio Fréquence. Sur la figure 1.4, le module RRU est logé près de l’antenne afin de supprimer l’amplificateur faible bruit TMA (Tower Mounted Amplifier).

L’unité BBU gère la couche physique, elle réalise la pré-modulation, le codage, l’allocation de ressource. L’unité BBU est constituée d’une carte contrôleur et d’une carte SDR (Soft Design Radio) dans un châssis. La carte contrôleur se raccorde à l’entité MME et à l’entité SGW (Serving Gateway) et la carte SDR est connectée au module RRU. La carte SDR (radio logicielle) permet de réaliser le traitement logiciel du signal pour la 2G/3G/4G. Ainsi, le même équipement peut gérer les différents accès radios, ce que réalise l’opérateur lorsqu’il fait évoluer (swap) ses équipements.

Le lien entre l’unité BBU et le module RRU s’appelle le réseau de transport fronthaul. En général, le lien est un câble optique standard nommé CPRI (Common Public Radio Interface). La technologie CPRI transporte les flux de données et la synchronisation entre deux entités : l’entité Radio Equipment (RE) qui correspond au module RRU et l’entité Radio Equipment Control (REC) qui correspond à l’unité BBU. Le rôle du RE est de construire la forme d’onde du signal radio, le REC génère le signal radio. Les données de plan de transport sont numérisées (I/Q) sur M

bits pour chaque secteur d’antenne et pour une seule porteuse (connu sous le nom de concept AC Antenna Carrier).

Il est ainsi possible de transférer différents types de signaux via le CPRI et de reconstruire la forme d’onde au niveau du RE (GSM, UMTS, WiMAX, LTE). Le débit du lien CPRI-1 est de 614.4 Mbps, légèrement inférieur au lien STM-4. La distance entre le RE et le REC peut être de 10 kms. Nativement, le CPRI supporte le multiplexage de 2 CPRI-1, nommée CPRI-2 (1228,8 Mbit/s).

Figure 1.5. REC – CPRI – RE

Prenons un exemple : si l’on suppose que le module RRU doit gérer 4 secteurs opérant chacun sur une bande MIMO 2×2 LTE de 20 MHz, alors il est nécessaire de transmettre 4 groupes (un groupe par secteur) de 2 AC (MIMO 2×2). Si la numérisation est sur M=15 bits par voies (I et Q), alors le débit est de  15*2* 8 AC =240 bits par Te, Te étant la période d’échantillonnage. Sachant que pour 20 MHz, la fréquence d’échantillonnage est de fe=30,72MHz alors le débit est de 7372.8Mbps. Une multi-trame est composée d’une trame de synchronisation et de 15 trames de données, le débit réel est donc de 16/15* 7372.8 soit 7864,32 Mbps. Enfin les données sont encodées par un codeur canal 8B/10B, le débit total est donc de 8/10*7864,32=9830,4 Mbps, ce qui correspond à un multiplexage de 8 CPRI-2.

Dans le cas d’une agrégation de porteuses sur 5 canaux (100 MHz) sur 4 secteurs, avec des antennes MIMO 8×8, le débit est alors multiplié par 20.

Il est également possible d’empiler  (stack) plusieurs unités BBU, chacune connectée à différents modules RRU créant ainsi un pool de cartes BBU (BBU centralization ou BBU Hosteling), afin d’améliorer la fiabilité du réseau d’accès radio. Il s’agit du Cloud RAN ou C-RAN. L’unité BBU n’est plus distribuée mais centralisée et connectée aux modules RRU par des modules de transports optiques CPRI.

 

Figure 1.6. La BBU centralisée

Après avoir présenté la partie matérielle, nous allons lister les fonctions de l’entité eNB.

L’entité eNB assure l’établissement du support radioélectrique DRB (Data Radio Bearer) sur lequel est transmis le trafic du mobile dans le sens montant (UL Uplink) et descendant (DL Downlink). Si le nombre de demandes de connexion est trop élevé, l’entité eNB gère la congestion (contrôle l’accès des mobiles UE sur l’entité eNB) en interdisant l’accès à la cellule pour des nouveaux mobiles UE.

L’entité eNB gère les ressources radio et l’attribution des ressources pour chaque utilisateur. Pour cela, l’entité eNB utilise les mesures effectuées par le mobile UE pour décider du déclenchement d’un changement de cellule en cours de session (handover). En plus de gérer la mobilité des utilisateurs en cours de session, les mesures permettent de réaliser un contrôle en puissance et d’assister l’entité eNB à ordonnancer les flux vers les mobiles UE (priorité des flux et gestion des débits entre chaque mobile UE).

Les données sont transmises sur le plan utilisateur (User Plane) et la signalisation est transmise sur le plan de contrôle (Control Plane). L’architecture du protocole radio est présentée dans le chapitre 1.2 (se référer aux figures 1.7 et 1.8).  La signalisation permet d’établir ou de ré-établir un  tunnel entre le mobile UE et le réseau de données PDN et de préparer les ressources (Accès radio, handover, …).

Le point de contrôle du réseau 4G est l’entité MME (Mobility Management Entity). L’entité eNB transfère la signalisation NAS (Non Access Stratum) du mobile UE vers l’entité MME et de l’entité MME vers le mobile UE via l’interface S1-MME. L’entité eNB effectue la sélection de l’entité MME du cœur de réseau à laquelle s’attache le mobile.

En qualité de point d’accès pour le plan de transport, l’entité eNB transfère les données de trafic provenant du mobile vers l’entité SGW (Serving Gateway), et celles provenant de l’entité SGW vers le mobile à travers un tunnel IP. Ce tunnel est défini par un identifiant d’acheminement nommé TEID  (Tunnel End Identifier) et d’un identifiant de la classe de service QCI (QoS Class Identifier). L’identifiant TEID et l’identifiant QCI sont nécessaire pour établir l’acheminement des données et la mise en œuvre du mécanisme d’ordonnancement des données. Ces informations forment un contexte et sont stockées au niveau de l’entité SGW et l’entité PGW (PDN Gateway). L’identifiant QCI permet de marquer les champs DSCP des paquets IP afin de différencier les services proposés par ordre de priorité et de garantir les débits pour certaines applications.

En termes de sécurité, les données entre l’entité eNB et le mobile UE sont chiffrées. La signalisation est également chiffrée et un contrôle d’intégrité permet d’éviter une attaque de type Man In the Middle.

1.1.2. L’entité MME

L’entité MME contrôle le droit d’accès des mobiles UE et les services accessibles pour chaque mobile UE dans le réseau de l’opérateur (PLMN Public Land Mobile Network).

Le droit d’accès au réseau (Home HPLMN ou Visité VPLMN) s’effectue via la procédure d’attachement. Lors de l’attachement, l’entité MME récupère le profil et les données d’authentification du mobile stockés dans l’entité HSS (Home Subscriber Server) et procède à l’authentification du mobile. Cette procédure permet au mobile UE d’authentifier le réseau sur lequel il se connecte et au réseau d’authentifier le mobile UE.

Si la double authentification aboutie, l’entité MME sauvegarde le contexte du mobile UE. Le contexte contient l’abonnement du profil du mobile UE (profil récupéré auprès du HSS) ainsi qu’un ensemble d’informations sur les capacités du mobile UE, la localisation du mobile UE, son identifiant, et les clés de sécurités dérivées.

Les capacités correspondent aux caractéristiques techniques (Information Element) du mobile UE (nombre d’antennes, débit maximum, … ) alors que le profil d’abonnement récupéré au niveau du HSS permet de définir l’accès aux services de l’utilisateur (service voix sur IP, accès Internet, applications objets connectés, …). Le MME récupère également les points d’accès APN (Access Point Name) permettant de déterminer la passerelle permettant d’atteindre le PDN spécifique.

Lors de l’attachement, l’entité MME enregistre l’identité de la zone de localisation TAI (Tracking Area Identity) du mobile et lui attribue l’identité temporaire GUTI (Globally Unique Temporary Identity) qui remplace l’identité privée IMSI (International Mobile Subscriber Identity). Le GUTI devient l’identifiant unique temporaire de l’UE. Le GUTI est composé d’un identifiant du PLMN/MME suivi d’un identifiant unique de l’UE sur le MME. A partir du GUTI, il est donc possible de retrouver le MME qui gère l’UE.

L’entité MME sélectionne l’entité SGW et à partir du point d’accès APN, l’entité MME contacte l’entité PGW. La signalisation émise par l’entité MME permet de créer une entrée supplémentaire à la table de contexte de l’entité SGW et de l’entité PGW. Cette table contient les informations concernant le tunnel par défaut (default bearer) entre le mobile UE et l’entité PGW.

Une fois le mobile UE attaché, l’entité MME contrôle l’établissement et le ré-établissement des tunnels (par défaut ou dédié) pour la transmission des données de trafic pour chaque mobile UE.

Le mobile UE contacte l’entité MME via une station de base eNB. Chaque station de base eNB est connectée à une ou plusieurs entités MME. On parle alors d’un groupe de MME (pool). Afin de gérer l’équilibrage de la charge des entités MME, chaque entité MME transmet une information de facteur de charge à la station de base eNB.  L’équilibrage de charge est donc réalisé par les entités eNB en fonction des informations émises par les entités MME.

En cas de mobilité, l’entité MME gère une liste de zones de localisation allouées aux mobiles, dans lesquelles le mobile, à l’état de veille, peut se déplacer sans contacter l’entité MME pour mettre à jour sa localisation. L’entité MME constitue le point d’ancrage du plan de contrôle à condition que le mobile ne change pas de groupe. Si le mobile UE se déplace vers une station de base eNB non connectée à l’entité MME qui contient le contexte du mobile UE, alors l’entité MME source sélectionne l’entité MME cible pour lui transférer le contexte.

L’entité MME fournit les informations requises pour les interceptions légales, par exemple l’état du mobile (en veille ou connecté), sa localisation TAI si le mobile est en veille ou l’identité de la cellule ECGI (E-UTRAN Cell Global Identifier) si le mobile est en session.

1.1.3. L’entité SGW

L’entité SGW constitue le point d’ancrage du plan utilisateur pour le handover intra-système (mobilité à l’intérieur du réseau 4G) à condition que le mobile ne change pas de groupe. Dans le cas contraire, l’entité PGW assure cette fonction. Les entités SGW sont également organisées en groupes (pools) et afin d’assurer l’équilibrage de la charge des entités SGW, chaque entité eNB d’un groupe doit avoir accès à chaque entité SGW du même groupe.

L’entité SGW constitue également le point d’ancrage lors du handover inter-système en mode PS (Packet-Switched), nécessitant le transfert du trafic du mobile vers un réseau de mobiles de 2ème ou de 3ème génération.

L’entité SGW transfère les données entrantes provenant de l’entité PGW vers la station de base eNB et les données sortantes provenant de la station de base eNB vers l’entité PGW.

L’entité SGW informe l’entité MME pour les données entrantes lorsque le mobile est à l’état de veille, ce qui permet à l’entité MME de déclencher une procédure de notification (paging) à destination de toutes les stations de bases eNB de la zone de localisation TAI.

Lorsque l’entité SGW reçoit des données des entités eNB ou PGW, elle se réfère au contexte afin de connaitre l’identifiant de la classe de service QCI pour la mise en œuvre du mécanisme d’ordonnancement des données et pour le marquage du champ DSCP des paquets IP.

Dans le cas de l’itinérance correspondant à l’architecture Home Routed (le flux est transféré vers le PGW du réseau Home), l’entité SGW du réseau visité dérive le trafic du mobile dans le cadre des interceptions légales.

1.1.4. L’entité PGW

L’entité PGW est le routeur de passerelle assurant la connexion du réseau EPS au réseau de données PDN.

Au cours de la procédure d’attachement, l’UE se voit affecter une adresse IP (IPv4 ou IPv6) attribuée par l’entité PGW. Ainsi, en cas de l’itinérance (roaming) dans le mode HR (Home Routed), le mobile obtient une adresse IP fournie par le HPLMN et est vu comme une entité du réseau Home même si le point d’ancrage du trafic (SGW) appartient au réseau visité. Si l’adresse IPv4 attribuée est une adresse privée, l’entité PGW effectue la fonction NAPT (Network Address and Port Translation) consistant à traduire l’adresse IP et du numéro de port de TCP ou UDP du flux.

Lorsque l’entité PGW reçoit des données de l’entité SGW ou du réseau PDN, elle se réfère à l’identifiant de la classe de service QCI pour la mise en œuvre du mécanisme d’ordonnancement des données et pour le marquage DSCP des paquets IP.

L’entité PGW constitue le point d’ancrage pour la mobilité inter-SGW, lorsque le mobile change de groupe.

L’entité PGW héberge la fonction PCEF (Policy and Charging Enforcement Function) qui applique les règles relatives au trafic du mobile, concernant le filtrage des paquets, la taxation et la qualité de service à appliquer au support à construire.

L’entité PCRF (Policy Charging and Rules Function), extérieure au réseau EPS, fournit à la fonction PCEF de l’entité PGW les règles à appliquer lors de l’établissement du support.

L’entité PGW dérive le trafic du mobile dans le cadre des interceptions légales, pour les cas suivants :

  • le mobile est attaché sur son réseau nominal ;
  • le mobile est attaché sur un réseau visité, pour les deux types d’architecture, HR ou LBO (Local Breakout). Dans le cas de l’architecture LBO, le mobile UE est connecté au PGW du réseau visité alors que pour l’architecture HR, le mobile UE est connecté au PGW du réseau home.

1.1.5. L’entité HSS

L’entité HSS est une base de données assurant le stockage des données propres à chaque abonné. Les principales données stockées comprennent les identités de l’abonné, les paramètres d’authentification et le profil de service.

Lors de la souscription au réseau EPS, le mobile se voit attribuer une identité privée IMSI (International Mobile Subscriber Identity) à laquelle est associée un profil de service et une clé secrète Ki.

Lors de l’attachement, l’entité MME contacte l’entité HSS pour récupérer les valeurs d’authentification calculées au niveau du HSS à partir de la clé secrète Ki. Une fois authentifiée, l’entité HSS transmet le profil de service du mobile au MME et conserve l’adresse du MME sur lequel l’abonné (IMSI) est enregistré.

1.1.6. L’entité PCRF

Les opérateurs proposent différents abonnements pour l’accès aux services du réseau mobile. Afin de contrôler l’accès au réseau pour chaque client, il est nécessaire de contrôler l’usage du réseau et des services. L’entité PCRF permet de contrôler en temps réels l’usage du client par rapport à son abonnement et son forfait restant. Ainsi, en cas  de dépassement de forfait, le PCRF va imposer une règle pour réduire le débit (fair-use). De plus, dans le cadre de la VoLTE (Voix sur LTE),  l’opérateur doit mettre en place de la priorité de service.

La fonction PCC (Policy and Charging Control) définit les fonctions d’autorisation et de blocage des flux IP avec la QoS associée à chaque flux (policy)  et la méthode de taxation des flux IP (charging). L’entité PCRF fournit à la fonction PCEF, intégrée dans l’entité PGW, les informations nécessaires pour le contrôle et la taxation du trafic.

Ces informations sont stockées dans la base de données SPR (Subscription Profile Repository) lors de la création de l’abonnement.

Le contrôle du trafic comprend les opérations suivantes :

  • l’association entre un flux de données de service SDF (Service Data Flow) et un support EPS (EPS bearer) ;
  • le blocage ou l’autorisation des paquets IP ;
  • l’attribution du paramètre QCI au support EPS.

L’entité PCEF exécute les règles fournies par l’entité PCRF, pour le contrôle des flux de trafic et la taxation. En situation d’itinérance (roaming) correspondant à l’architecture LBO, l’entité PCEF localisée dans le réseau visité demande les règles à l’entité V-PCRF (Visited-PCRF), qui les obtient de l’entité H-PCRF (Home-PCRF) du réseau nominal

La fonction PCEF peut rapporter à l’entité PCRF un changement d’état d’un flux de service comme dans le cas d’une perte de couverture radioélectrique du mobile.

L’entité PCRF peut recevoir une requête de session de la part de l’entité AF (Application Function) comme dans le cas de l’établissement d’une communication téléphonique ou visiophonique initialisée au niveau du réseau IMS (IP Multimedia Sub-system).

L’entité PCRF peut fournir à l’entité AF des informations concernant des événements se produisant dans le réseau mobile comme par exemple une perte de couverture radioélectrique du mobile.

 

 

Références

1 : Livre LTE-Advanced Pro

2: Documentation ZTE

 

IAB – Cas d’usage

Posté le by - 1 090 vues
Répondre

Les explications techniques du réseau de liaison terrestre et d’accès intégrés ont été partiellement présentées dans les trois articles précédents.

Cette article reprend l’illustration de SAMSUNG : Différentes zones urbaines sont couvertes par le mécanisme de relais IAB.

Le réseau de liaison terrestre et d’accès intégré IAB – Integrated Access Backhaul (part 3)

Posté le by - 1 573 vues
Répondre

Cet article est le troisième et dernier traitant de l’IAB. Si besoin, n’hésitez pas à relire le premier article et le second.

III) Les mécanismes de routage IAB

III-1) Les entités BAP de la fonction DU et de la fonction MT

Le réseau d’accès IAB est constitué d’un ensemble de nœud IAB IAB-node, et d’une topologie de routage définie par un graphe orienté acyclique (DAG : Directed Acyclic Graph). Ainsi, plusieurs routes peuvent exister entre deux nœuds. La topologie peut ainsi être exploitée pour fiabiliser le routage (en cas de d’échec de lien – backhaul link failure) ou pour équilibrer la charge.

La sélection de la route et l’optimisation doit s’effectuer à chaque fois qu’un nouveau nœud IAB se connecte ou lorsque la topologie du réseau change.

Lorsqu’un nouveau nœud IAB intègre le réseau, l’unité Donor-CU attribue une adresse L2 unique (BAP Address).

Figure 9 : Configuration des instances de routage (Ericsson (1))

Au niveau du donneur IAB, la sous-couche BAP ne contient qu’une seule entité BAP.

Au niveau du nœud IAB, la sous-couche BAP contient une entité BAP sur la fonction MT et une entité BAP co-localisée sur la fonction DU.

La partie émettrice de l’entité BAP communique avec l’entité réceptrice de l’entité BAP.

L’entité réceptrice peut être située :

  • soit sur le même nœud
  • soit sur un autre nœud
  • soit sur l’IAB donneur.

Lorsqu’il est situé sur un autre nœud, la communication s’effectue à travers le lien backhaul.

Ainsi, la partie émettrice de l’entité BAP (Transmitting part) peut recevoir des unités de sessions de données SDU (Session Data Unit) des couches supérieures ou des données BAP PDU délivrées par l’entité BAP réceptrice co-localisée.

Figure 10 : Les fonctions de l’entité BAP (3GPP TS38.240)

L’entité BAP de réception supprime l’en-tête BAP du SDU et l’entité BAP de transmission rajoute l’en-tête BAP avec le même identifiant de routage BAP ID porté par l’en-tête du PDU avant d’être supprimée.

Au niveau de la fonction MT, la partie émettrice de l’entité BAP peut recevoir des BAP SDU des couches supérieures ou des paquets provenant de (et reçu par) l’entité BAP de la fonction DU du même nœud IAB ce qui lui permet de construire le paquet BAP PDU.

Au niveau de la fonction DU :

  • la partie émettrice de l’entité BAP d’un nœud IAB peut recevoir des paquets qui ont été réceptionnés par la partie réceptrice de l’entité BAP de la fonction MT situé sur le même nœud IAB afin de construire le paquet BAP PDU.
  • la partie émettrice de l’entité BAP d’un donneur IAB reçoit les BAP SDU des couches supérieures.

La partie émettrice de l’entité BAP doit :

  • à la réception d’un SDU (couche supérieure) :
    • sélectionner une adresse BAP et une identité de chemin BAP pour créer l’en-tête ;
    • construire le PDU.
  • à la réception d’un PDU (entité BAP de même niveau):
    • réaliser le routage vers le prochain saut ;
    • définir le canal RLC du lien backhaul de sortie.

 

3.2) Les mécanismes de routage

Dans le cas ou plusieurs chemins permettent de transmettre un paquet IP entre le nœud IAB de terminaison et le nœud donneur IAB, des Identifiants de route ID sont associés. L’unité donneur Donor-CU configure alors une table de routage indiquant le prochain saut pour chaque direction UL/DL en fonction de l’identifiant de route. La table de routage sépare la direction DL et UL, la table DL est utilisée par le module DU et la table UL est utilisée par le module MT.

 

Lorsqu’un paquet IP doit être transmis, le nœud à l’origine (le nœud donneur IAB IAB-donor pour le sens descendant ou le nœud IAB pour le sens montant) rajoute un en-tête BAP comprenant l’adresse L2 du nœud d’origine, l’adresse L2 du nœud de destination et optionnellement (si plusieurs chemins existent) l’identifiant du chemin.

Lorsque l’entité RLC du nœud IAB reçoit plusieurs trames en direction d’un même nœud, l’entité RLC peut multiplexer l’ensemble des trames (correspondance N :1) ou transmettre les trames 1 à 1. La correspondance N :1 est un multiplexage de plusieurs bearer radio dans un seul canal RLC à condition que tous les bearers radio aient les mêmes profils de QoS. La correspondance N :1 permet de transmettre moins de canaux RLC et réduit les en-têtes à rajouter.

La correspondance 1 :1 permet de transmettre des bearers radio dans des canaux RLC spécifique afin de prendre en charge la QoS à appliquer pour chaque bearer.

Figure 11a: La correspondance 1 :1

Figure 11b: La correspondance N :1

IV) Conclusion

La solution IAB a pour objectif de réduire le coût de déploiement de nouvelles stations de base principalement pour les antennes relais dans les bandes millimétriques dans les zones très denses. Toutefois, la solution IAB permet également de densifier le déploiement de nœuds radioélectrique dans le cadre des services V2X (exemple le long des routes/autoroutes).

Figure 12 : Un exemple de déploiement le long d’une autoroute

Enfin, le nœud IAB peut également être mobile (camion) pour mettre en place une infrastructure évènementielle.

 

Références

 

Le réseau de liaison terrestre et d’accès intégré IAB – Integrated Access Backhaul (Part 2)

Posté le by - 1 813 vues
2

Cet article est la suite de l’article :

Le Réseau de liaison terreste et d’accès intégré

II) L’Architecture IAB (Integrated Access Backhaul)

L’architecture IAB (figure 5) permet la connexion entre le mobile UE et le nœud radioélectrique par une connexion radioélectrique 5G multi-sauts entre les nœuds IAB.

On appelle IAB-donor la station de base connectée au cœur de réseau (en général une macro-cell) et le nœud-IAB, une station de base permettant le relai entre le mobile et l’IAB-donor.

On distingue deux types de lien, le lien d’accès et le lien backhaul (Integrated Access and Backhaul) :

  • Le lien d’accès est le lien entre le terminal UE et l’antenne relais nœud IAB (IAB-node). Traditionnellement, dans un contexte hors-IAB, ce lien représente la connexion radioélectrique entre le mobile et la station de base.
  • Le lien backhaul est le lien entre un nœud IAB parent et un nœud IAB fils. Il peut s’agir d’une connexion radioélectrique entre un nœud IAB-donor et le nœud IAB ou entre deux nœuds IAB.

Le nœud IAB parent est responsable du séquencement du trafic DL/UL s’établissant à la fois sur le lien d’accès et sur le lien backhaul.

Le nœud IAB fils en tant que dernier maillon de la chaine de transmission est responsable du séquencement de trafic DL/UL entre le nœud IAB et le mobile UE.

Les fonctionnalités de l’IAB sont gérées par deux nouvelles entités réseaux : nœud donneur IAB (IAB-Donor) et un nœud IAB (IAB-node). Chaque nœud IAB a une adresse IP qui est routable par la station de nœud donneur IAB-donor.

Figure 5 : Architecture IAB

Chaque nœud IAB gère deux modules de transmission (figure 6) : un module MT (Mobile Termination) et un module DU.

  • Le module MT maintient la connexion radioélectrique backhaul montante vers un nœud parent (nœud IAB-Donor ou un nœud IAB-node) ;
  • Le module DU fournit l’accès radioélectrique au mobile et assure la connexion radioélectrique backhaul descendante en provenance d’un autre nœud IAB ou du nœud IAB-donor.

Le nœud donneur IAB-donor est un gNB, il gère les deux unités  CU et DU. Il fournit l’accès au cœur de réseau via le réseau backhaul et le réseau d’accès radioélectrique.

Comme tout gNB, le noeud IAB-donor est constitué d’un seul IAB-donor-CU et d’un ou plusieurs IAB-donor-DU, connecté l’un et l’autre via l’interface F1.

Le noeud IAB-donor est connecté au nœud IAB-node par l’interface NR.

Figure 6 : Architecture CU/DU de la solution IAB

Le nœud IAB-node se connecte en amont à un nœud IAB-node ou à un nœud IAB-donor en exploitant les fonctionnalités UE. Ainsi, le nœud IAB-node :

  • est perçu comme l’entité gNB-DU pour les terminaux. Il est ainsi sous le contrôle du gNB-CU du nœud donneur ;
  • supporte une partie des fonctionnalités des terminaux UE (fonctionnalités IAB-MT).

Le nœud IAB-Donor :

  • est perçue comme l’entité gNB-CU par rapport au nœud IAB-node ;
  • gère les fonctionnalités RRC/PDCP en complément du MT.

Toutes les fonctions spécifiées pour un gNB-DU sont également appliquées pour un IAB-node-DU et toutes les fonctions spécifiées pour le contexte UE sont également utilisées dans la gestion du contexte de l’IAB-MT.

Le nœud IAB-Node doit avoir une adresse IP pour le plan de contrôle (F1-C) et pour le plan de trafic (F1-U).

La pile protocolaire est similaire à celle de la station de base gNB avec l’ajout d’une sous-couche d’adaptation BAP (Backhaul Adaptation Protocol) située au-dessus de la couche RLC.

Sur l’IAB-donneur-DU, la sous-couche BAP contient une seule entité BAP.

Sur le nœud IAB, la sous-couche BAP contient une entité BAP au niveau de la fonction MT et une entité BAP colocalisée distincte à la fonction DU.

Chaque entité BAP a une partie émettrice et une partie réceptrice. L’entité BAP a pour rôle d’apporter les informations de routage de flux et d’autoriser la transmission multi-sauts. La table de routage est fournie par l’entité gNB-CU via le message BH Routing Configuration.

Les fonctions de la couche d’adaptation BAP permettent :

  • de gérer efficacement le transfert multi-sauts (lien backhaul) ;
  • de router les paquets vers le prochain nœud via la topologie backhaul ;
  • de contrôler les flux de la signalisation.

Figure 7 : L’architecture protocolaire IAB

Le nombre de saut n’est pas limité, il est néanmoins nécessaire de s’assurer du respect des contraintes de latence.

Le donneur IAB-donor assigne une adresse de niveau 2 (adresse BAP) à chaque nœud IAB qu’il contrôle. En cas de plusieurs chemins, plusieurs identifiant de route peuvent être associés à chaque entité BAP. L’entité BAP du nœud d’origine (IAB-donor DU pour le trafic DL, et le nœud d’accès IAB pour l’UL) ajoutera un en-tête BAP aux paquets que chacun transfère. Cet en-tête comprend un identifiant ID de routage BAP (par exemple, l’adresse BAP du nœud IAB de destination / source et un ID de chemin facultatif).

Chaque nœud IAB met en place une table de routage qui est configurée par l’unité CU du donneur IAB (message BH Routing Configuration). Cette table contient l’identificateur de saut suivant pour chaque ID de routage BAP.

Figure 8 : Le transfert IAB

 

 

Le réseau de liaison terrestre et d’accès intégré IAB – Integrated Access Backhaul

Posté le by - 2 106 vues
Répondre

Introduction

Le réseau d’accès radioélectrique NG-RAN est composé de nœuds radioélectriques permettant la transmission de flux à très haut débit. Selon la spécification TS 38.300, le nœud NG-RAN peut être une station de base gNB (avec une interface radioélectrique 5G-NR) ou une station de base ng-eNB (avec une interface radioélectrique 4G-LTE).

Pour apporter plus de flexibilité et optimiser le transport de données à très haut débit, la spécification 3GPP TS 38.804 propose une division fonctionnelle des éléments de la BBU en deux unités CU et DU.

Un nœud gNB (ng-eNb) est composé d’une unité centrale (CU, Central Unit), et d’un ensemble d’unités distribuées (DU, Distributed Unit) et d’unité radio RU (Remote Unit) ou AAU (Activa Antenna Unit). Certaines fonctions de la couche physique de bas niveau peuvent être détachées du DU et implémentées dans une unité radio distante (RU, Remote Unit).

L’interconnexion entre les différentes entités (coeur de réseau, CU, DU et tête radioélectriques) sont assurées par des liens en fibre optique.

Le réseau de transport 5G est constitué de 3 segments :

  • le backhaul est la liaison entre le CU et le cœur du réseau (5GC). Il est généralement implémenté à l’aide des technologies de transport optique à très haut débit de type WDM (Wavelength Division Multiplexing) ;
  • le midhaul entre le CU et le DU. La liaison midhaul est une liaison IP/Ethernet qui transporte le trafic de données (F1-U) et de signalisation (F1-C) de l’interface F1;
  • le fronthaul entre le DU et le RU via le déploiement des réseaux optiques ODN (Optical Distribution Network) ou FTTH (Fiber To The Home).

Dans les zones denses, pour éviter la saturation des stations de base, l’opérateur doit rajouter des points de transmission. La multiplication des unités radio distante nécessite le déploiement d’une infrastructure en fibre optique (RoF : Radio Over Fiber). Pour simplifier le déploiement de nouveaux points de transmission, la 3GPP propose la solution de relais radioélectrique IAB (Integrated Access Backhaul).

Dans cet article, nous allons détailler le déploiement de relais par la mise en place d’une lien radioélectrique backhaul entre la station de base initiale et les relais.

  1. Architecture gNB

Le nœud NG-RAN est constitué de deux unités : une unité centralisée CU (Centralized Unit) et une unité distribuée DU (Distributed Unit). L’une et l’autre communiquent par une interface F1.

L’unité gNB-CU contrôle plusieurs unités DU et une unité DU n’est contrôlée que par une seule unité CU.

De par la décomposition fonctionnelle entre les données de signalisation (control plane) et les données de trafic (user plane), une station de base peut être constituée :

  • pour l’unité CU : d’un unique gNB-CU-CP et de plusieurs gNB-CU-UP ;
  • pour le module DU, de plusieurs gNB-DU.

Figure 1 : Architecture d’un nœud NG-RAN

L’organisme de normalisation 3GPP propose plusieurs découpages fonctionnels entre les entités gérées au niveau de l’unité CU et celles gérées au niveau de l’unité DU. La figure 1 correspond à l’option 2. La figure 2 présente les 8 découpages possibles.

Figure 2 : Les options de découpage CU/DU

Cette décomposition apporte un nouveau lien entre l’unité CU et l’unité DU. Ce lien est nommé midhaul.

L’organisme de normalisation 3GPP a retenu dans un premier temps (R.15) l’option 2 avec l’introduction de l’interface F1 sur le lien midhaul entre les unités DU et CU.

Figure 3 : Le découpage fonctionnel de la station de base (Nokia)

Le lien fronthaul est la connexion entre l’unité de bande de base (BBU) et la tête radioélectrique déportée (RRH). Ce lien s’appuie sur une connexion en fibre optique. Différents protocoles d’interfaces de réseau fronthaul ont été spécifiés comme le protocole OBSAI et le protocole CPRI. Le protocole CPRI est apparu en 2003 pour connecter les stations de bases BBU aux têtes radioélectriques déportées RRH. Le lien CPRI est mis en œuvre pour l’interconnexion entre le RRU et le BBU 4G et 5G-NSA. Il s’agit de l’option 8.

L’arrivée de nouvelles technologies antennaires comme le massive MIMO permet d’augmenter considérablement les capacités de transport sur l’interface CPRI. Pour réduire cette forte augmentation en débit, le protocole eCPRI, défini en 2017, réduit cette tension en débit de transmission grâce à une décomposition fonctionnelle plus flexible de la partie BBU. Le protocole eCPRI identifie trois plans nécessaires à l’interaction entre l’équipement radioélectrique eRE et l’équipement de contrôle eREC. Ces trois plans sont les suivants : le plan utilisateur, le plan de synchronisation, et le plan de contrôle et gestion. La synchronisation est essentielle pour le mode de duplexage temporel.

La flexibilité est aussi apportée par les fonctions de virtualisation réseau NFV. Les 8 options peuvent facilement se déployer par la virtualisation de l’accès radioélectrique (V-RAN) : Les entités fonctionnelles de l’unité DU et/ou de l’unité CU peuvent être intégrées à l’entité physique RU, l’entité physique DU peut être combinée à l’entité physique CU, ou bien chaque entité matérielle peut fonctionner de manière indépendante à des emplacements séparés. Dans chacun de ces cas, le backhaul fournit toujours le lien établissant la connexion au backbone.

Le terme crosshaul (ou x-haul, ou xhaul) désigne indépendamment lien fronthaul, midhaul ou backhaul.

Figure 4 : Différentes options du découpage fonctionnel de la station de base

En Juin 2018, l’alliance O-RAN a été créée pour standardiser l’interconnexion des différentes interfaces en fonction des 8 découpages proposés. Le but est de permettre la migration des entités du réseau d’accès radioélectrique indépendamment du ou des fournisseurs.

Si la fibre optique est le média de transport favorisé, la densification des stations de base consécutive à l’exploitation des bandes millimétrique pose le problème de connectivité entre les nouvelles antennes et le cœur de réseau.

Pour résoudre ce problème et pour réduire les couts de déploiement (CAPEX), le standard 3GPP propose (dans la spécification R.16) la mise en place d’une solution de connectivité IAB (Integrated Access Backhaul), se substituant ainsi à la solution sur Fibre Optique pour le réseau d’accès.

 

 

 

 

Internet des Objets

Posté le by - 1 994 vues
3

L’Internet Des Objets

Selon l’étude de marché menée par Statista en 2018 [1], plus de 75 milliards d’objets seront connectés à Internet en 2025, soit deux fois plus qu’en 2021 (35 milliards d’objets connectés).

Un grand nombre d’objets seront connectés via un réseau bas débit et faible coût, comme LoRaWAN, SIGFOX, ou à travers les réseaux cellulaires (LTE-M/NB-IoT).

En 2009, Christophe Fortet et Ludovic Le Moan ont créé la société SIGFOX pour le marché M2M.

Dans le secteur des objets connectés, SIGFOX est le premier à s’être positionné comme Opérateur IoT en déployant son propre réseau sur plusieurs continents (déploiement de l’accès radio-électrique et du cœur de réseau).

A la même année (2009) Nicolas Sornin et Olivier Seller travaillaient sur un module de transmission longue portée pour des télé-relevées (comptage eau-électricité). L’entreprise Cycleo fut rachetée par SEMTECH en 2012. Les puces SX1272 et SX1276 pour les modules LoRa et SX1301 pour la passerelle ont été produites en 2012.

En 2015, LoRaWAN est une alliance entre opérateurs (Orange, Bouygues …), équipementiers (SEMTECH, ST, …),  des sociétés qui déploient des solutions de connectivités (modules radio, cœur de réseau comme Actility, Sagemcom, Birdz, Cisco).

LTE-M et NB-IoT s’appuient sur les réseaux de mobiles 4G/5G permettant ainsi d’apporter rapidement une connectivité mondiale.

Les premiers marchés nécessitant des solutions de connectivités longue portée, faible cout et consommant peu d’énergie (LPWAN : Low Power WAN) ont été la collecte de données pour la gestion d’eau et d’Energie. A ce titre, VEOLIA a racheté l’activité Energie de la start-up Actility, complétant ainsi son activité de télé-relevé (Smart-City et environnement urbain) qu’elle réalise avec la société Birdz (exemple pour la gestion des déchets).

En 2020, l’IoT s’est positionné sur le marché de suivi de marchandise (tracker) afin d’améliorer les process logistique et afin de réduire la durée d’approvisionnement.

Ainsi, dans le cadre du suivi de la préservation des vaccins Covid réalisé par Pfizer et Moderna, nécessitant une congelation à -70°C pour Pfizer et -20°C pour Moderna, les laboratoires ont mis en place une procédure de suivi des vaccins pour suivre l’acheminement (GPS/NFC) avec un suivi de la température. Les solutions LoRaWAN et 5G ont été écartées (difficulté de roaming) pour retenir la solution NB-IoT.

L’Internet des Objets Industriel (IIoT), qui est la base de l’Industrie 4.0 (Smart Factory) fournit également une connectivité pour les usines intelligentes, aux machines, aux systèmes de gestion, et à la logistique/approvisionnement.

Ce blog étant consacré aux réseaux cellulaires, je n’aborderai que les solutions portées par les réseaux cellulaires. Néanmoins, pour ceux(celles) qui sont intéressé(e)s par le fonctionnement de LoRa et LoRaWAN, contactez moi

[1] https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

Les bandes de fréquences 5G : choix stratégique des opérateurs.

Posté le by - 4 375 vues
4

Les opérateurs proposent la 5G sur la bande de 3,5 GHz et sur la bande 2,1 GHz.

A partir de 2022, la bande de 26 GHz devrait également être utilisée.

La bande 3,5 GHz est déployée pour répondre à la croissance du trafic de données (ARPU 50 % par an) ce qui à terme va générer des congestions au niveau des stations de base dans les zones urbaines denses. Les opérateurs interrogés évoquent un manque de ressources attendu vers 2022 en France, avec un risque de baisse de la qualité de service pour l’utilisateur.

La bande de 2,1 GHz permet d’avoir une meilleure couverture par rapport à la bande de 3,5 GHz.

La bande 26 GHz, caractérisée par une faible propagation et une mauvaise pénétration à l’intérieur des locaux, sera déployée dans un second temps pour couvrir des zones limitées à fort trafic (hot spot)
probablement majoritairement pour les entreprises (usines 4.0, …) et marginalement pour le grand public (par exemple stades ou terminaux de transport).

Carte de déploiement de la 5G 

SFR est le premier opérateur à avoir commercialisé son réseau 5G avec plus de 120 communes couvertes dont la liste est communiquée par communiqué de presse.

La couverture de SFR en temps réel est affiché sur son site.

Le 3 décembre 2020, Orange a lancé son réseau 5G dans une quinzaine d’agglomérations regroupant plus de 160 communes. La liste des villes est accessible sur le lien d’Orange.

Le 10 décembre 2020, Bouygues Telecom annonçait plus de 1000 communes couvertes dont 67 villes de plus de 50 000 habitants. L’opérateur propose une carte du déploiement de la 5G sur son site.

Quant à Free, le lancement est prévu pour le 15 décembre et propose d’ouvrir plus de 12000 sites en 5G, soit deux fois plus que les autres opérateurs.

Le choix des fréquences des opérateurs  

Les bandes de fréquences acquises par les opérateurs sont présentées dans l‘article précédent.

Free dispose de 12000 site dans la bande de la 5G. Free s’appuie donc sur les sites actuellement 4G pour partager le spectre entre 4G et 5G. Cela signifie donc que la couverture 5G de Free sera la plus importante, mais les débits seront identiques à ceux de la 4G.

On trouve parfois le terme de fausse 5G lorsque l’opérateur utilise les bandes de la 4G pour faire de la 5G (700 MHz, 800 MHz, 900 MHz, 1,8 GHz, 2,1 GHz, 2,6 GHz).

Les attributions sont neutres technologiquement cela veut dire que Les bandes de fréquences déjà utilisées par les réseaux mobiles ouverts au public pourraient aussi être utilisées pour l’introduction de la 5G puisque ces bandes de fréquences ont été définies par les instances de standardisation et que les autorisations d’utilisation de fréquences délivrées sont donc neutres technologiquement.

Les autres opérateurs ont déployés des sites à 3,5 GHz et proposent de la vraie 5G. On dénombre plus de 1000 sites 5G à 3,5 GHz

Néanmoins SFR et Bouygues ont de plus commencé à utiliser la bande de 2.1 GHz car celle-ci offre un bon compromis entre couverture et débit. Il faut savoir que SFR et Bouygues ont également un accord de RAN Sharing (Le partage de réseau d’accès radioélectrique : accord CROZON). Au 1er décembre SFR et Bouygues ont l’autorisation d’activer la 5G sur plus de 5000 sites.

Le partage de la bande 4G et 5G est réalisé de manière dynamique par la station de base via la technique DSS (Dynamic Spectrum Sharing).

La 5G NSA s’appuie sur une station de base 4G couplée avec une station de base 5G. La 4G est la station de base maitresse. Les opérateurs ont choisi la bande à 700 MHz pour les sites 4G/5G. La bande de 700 MHz peut également être utilisée pour partager l’interface 4G/5G.

Dans le principe, la bande à 3,5 GHz est utilisée comme la bande 5G pour le trafic bidirectionnel et la bande de 700 MHz ou 2100 MHz est utilisée comme un lien Uplink (SUL : Supplementary UpLink).

Dans les faits, la bande à 3,5 GHz ou 700 MHz peut être utilisée comme noeud secondaire.

Ainsi la carte de déploiement est la suivante (cf site ANFR) :

Entre les différents opérateurs :

Sur les bandes de fréquences 5G

L’allocation de bande 5G à 3.5 GHz

Posté le by - 3 113 vues
Répondre

Le 12 novembre 2020, l’ARCEP a attribué les bandes de fréquences 3.5 GHz aux différents opérateurs (figure 1).

Figure 1 : La répartition des fréquences 5G

Une seule bande est représentée car la bande de fréquence 5G à 3.5 GHz utilise une méthode de duplexage en temps (TDD).

La méthode de duplexage TDD a deux principaux avantages :

  1. améliorer la gestion des faisceaux par rapport à la méthode FDD. Le fonctionnement Massive-MIMO permettant de s’appuyer sur les estimations du canal en réception pour mettre en oeuvre un codage analogique au niveau des antennes de transmission dans le but d’orienter le faisceau dans une direction donnée (se référer à l’article Massive MIMO : Fonctionnement (Troisième Article) avec des algorithmes comme MMUSIC ou ESPRIT.
  2. augmenter le débit descendant au dépend du débit montant en proposant plus d’allocation temporelle pour le sens descendant par rapport au sens montant. Dans le cas de la 5G, le rapport est de  4 slots pour le sens descendant contre un slot pour le sens montant.

La répartition des slots proposée par l’ARCEP suit la recommandation ECC 20(03), adoptée en octobre 2020. Cette recommandation limite le nombre de trames 5G aux deux formats suivants :

  • DDDSUUDDDD / DDDDDDDSUU+3ms
  • DDDSU

D pour Downlink, U pour Uplink, S est une sous-trame spéciale permettant la commutation du sens de transmission D vers U.

Le premier choix présente l’avantage d’une compatibilité avec la structure de trame LTE utilisée par les réseaux français.

Le deuxième choix n’est pas  compatible avec le LTE.

Ces deux trames, incompatibles entre elles, vont nécessiter de nouvelles fonctionnalités pour éviter les brouillages aux frontières comme le « DL Blanking ».

Figure 2 : Les modes de duplexage en Europe

La solution « DL symbol blanking » consiste à neutraliser les intervalles de temps (sous-trames) d’émission des stations (« D ») lorsque ces sous-trames sont simultanés avec les créneaux de réception (« U ») du réseau voisin. Il faut pour cela que les opérateurs partagent la même horloge (UTC +/- 1.5µs) et alignent chaque début de trame.

La figure ci-dessous illustre cette solution pour les deux trames retenues pour l’instant. Les trames originelles sont tout en haut et tout en bas de la figure. Dans les trames adaptées, au centre de la figure, les émissions « D » sont supprimées (en rouge) lorsqu’elles coïncident avec la réception « U » dans le pays voisin.

Figure 3 : La gestion des interférences entre pays

Si la bande 3,5 GHz est définie comme la vrai 5G, les opérateurs peuvent également utiliser la bande de 2,1 GHz. Celle-ci ne dispose cependant pas d’une largeur de bande suffisante pour apporter les mêmes débit que la 5G. Toutefois, la couverture et la pénétration indoor est meilleure par rapport à la bande de 3.5 GHz.

 

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

Posté le by - 4 187 vues
2

Voici la troisième et dernière partie

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

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

IV) La virtualisation de l’accès radio

IV-1) Description des fonctionnalités de la station de base

Le découpage du réseau est une tranche de bout en bout comme le montre la figure 13.

Figure 13 : Le découpage du réseau de bout en bout.

Les fonctionnalités réseaux sont partagées au niveau du cœur de réseau (SNI CN) et de l’accès radioélectrique (SNI RAN). Nous allons maintenant nous intéresser au découpage sur l’infrastructure radioélectrique et à la gestion de ressources.

Une station de base 5G réalise les tâches suivantes :

  • fonction RRM pour la gestion de ressources radioélectriques : Contrôle du support radioélectrique, contrôle d’admission radioélectrique, contrôle de la mobilité pour les mobiles connectés, allocation dynamique des ressources radioélectriques dans le sens montant et descendant (ordonnancement) ;
  • compression d’entêtes IP, chiffrement et intégrité des données ;
  • sélection de la fonction AMF lors de l’attachement du mobile ;
  • routage des données du plan de transport dans un tunnel ;
  • routage des informations de signalisation vers la fonction AMF ;
  • établissement et libération de la connexion ;
  • mesures radioélectriques et configuration du rapport de mesures demandé au mobile ;
  • ordonnancement et transmission des informations de diffusions SIB (System Information Block);
  • marquage des paquets dans le sens montant (étiquettes DSCP) ;
  • gestion des sessions ;
  • support du découpage en tranche de réseaux ;
  • gestion de la QoS et correspondance entre les flux IP provenant du plan de transport UPF en support radioélectrique ;
  • partage de l’accès radioélectrique ;
  • gestion de la double connectivité ;
  • interfonctionnement entre les fonctions 5G-NR et 4G-LTE.

Pour réaliser ces tâches, la station de base s’appuie sur la pile protocolaire présentée sur la figure 14. La station de base 5G peut également se décomposer en deux unités : une unité centralisée gNB-CU et une unité distribuée gNB-DU).

Figure 14 : Présentation de la pile protocolaire de la station de base 5G

La spécification 3GPP propose le découpage du plan de contrôle (RRC) et du plan de trafic IP (SDAP). La signalisation et les données sont gérées par la couche de niveau 2 décomposée en trois sous-couches : PDCP, RLC, MAC et par la couche physique.

La couche physique réalise la modulation et la démodulation de données des signaux sur l’interface radioélectriques.

Le rôle de la sous-couche MAC est de faire :

  • la correspondance entre les canaux logiques et les canaux de transport ;
  • le multiplexage/démultiplexage des unités de données MAC SDU en provenance d’un canal logique ou de plusieurs canaux de transport (TB) ou de plusieurs canaux de transport à destination des canaux logiques ;
  • la correction d’erreur rapide HARQ ;
  • la gestion de priorité entre les mobiles ;
  • la gestion de priorité sur les canaux logiques pour un mobile.

Le rôle de la sous-couche RLC est de faire :

  • le transfert des paquets PDU issu de la couche supérieure ;
  • une numérotation des séquences RLC pour le mode sans acquittement UM et avec acquittement AM;
  • la correction d’erreur ;
  • la segmentation/re-segmentation des données ;
  • la détection d’erreur (pour le mode AM).

Le rôle de la sous-couche PDCP est de faire pour le plan utilisateur :

  • la numérotation de séquence ;
  • la compression et décompression d’entête ;
  • le transfert des données ;
  • la détection des paquets dupliqués et la mise en ordre ;
  • le routage des bearer PDCP PDU dans le cas de la double connectivité ;
  • le chiffrement/déchiffrement et la protection d’intégrité;
  • le rétablissement des données PDCP et la récupération des données pour le mode RLC ;
  • la duplication des paquets PDCP PDU.

Le rôle de la sous-couche SDAP est :

  • la correspondance entre la QoS d’un flux IP et le support radioélectrique ;
  • le marquage de l’identité de la QoS sur les paquets UL.

Le partage de la station de base gNB en deux unités gNB-DU et gNB-CU est spécifié par le standard 3GPP lequel propose différentes options. Toutefois actuellement le gNB reste mono-constructeur même en cas de découpage en deux sous unités gNB-CU et gNB-DU.

Les différentes options sont proposées sur la figure 15 :

Figure 15 : Le découpage des fonctions du gNB

A titre d’exemple, on pourrait imaginer le découpage suivant :

Figure 16 : Un découpage du gNB

Actuellement (standard R.15) l’unité gNB-CU est composée de la sous-couche RRC/SDAP et PDCP, l’unité gNB-DU est composée des sous-couches RLC et MAC et physique. Mais les autres partages de fonctions décrites sur la figure 11 peuvent virtuellement être mise en œuvre.

La couche physique a pour rôle de transférer le signal issu de la couche MAC (le bloc de transport) en un signal RF et inversement récupérer un signal RF pour l’envoyer vers la couche MAC.

La couche physique se compose de plusieurs fonctions :

  • code détecteur d’erreurs CRC ;
  • code correcteur d’erreur et adaptation de débit ;
  • embrouillage ;
  • modulation ;
  • affectation des symboles par sous-couches antennaires ;
  • précodage numérique ;
  • affectation des signaux et canaux sur chaque élément de ressources ;
  • transformée de Fourier Discrète et insertion d’un préfixe cyclique ;
  • chaîne RF (convertisseur CNA, conversion RF, amplification).

Les signal RF est envoyé à l’antenne.

La tête radioélectrique déportée (RRH) correspond à la chaîne RF. Pour la 4G, l’entité eNB se composait de deux parties : BBU et RRH. Cette option est maintenue pour la 5G (option 8) toutefois, le débit du bus série CPRI (Common Public Radio Interface) qui transporte les symboles I/Q est d’autant plus élevé que :

  • la bande de fréquence est importante (cellule principale et secondaire en cas d’agrégation de porteuses) ;
  • le nombre d’antennes est élevé (FD-MIMO ou Massive MIMO).

Pour réduire le débit entre le gNB-DU et la tête radioélectrique déportée, il est également prévu de proposer un découpage au niveau de la couche physique différent (figure 17) :

Figure 17 : Les options de décomposition de la station de base gNB

Le transport des données sur les interfaces optionnelles est normalisé par le protocole eCPRI  (evolved Common Public Radio Interface) et est véhiculé sur une fibre optique.

La gestion des ressources radioélectrique (protocole RRM) est réalisée par la station de base gNB. La gestion des ressources radioélectrique a pour objectif :

  • de gérer le spectre de fréquence : cette fonction décide comment les ressources spectrales sont réparties en porteuses 5G-NR et comment ces porteuses sont allouées aux différents site;
  • de gérer l’interférences entre cellules (mécanisme ICIC). Dans la continuité de la gestion du spectre, le mécanisme ICIC impose une puissance limitée sur un ensemble de sous-porteuses afin d’éviter les interférences avec un point de transmission voisin utilisant les mêmes sous-porteuses ;
  • d’ordonnancer les paquets : cette fonction décide, pour chaque porteuse 5G-NR affectée à une cellule, quelles sont les ressources bloc (RB) disponibles pour transférer les paquets sur chaque bearer radioélectrique établi ;
  • de réaliser les fonctions liées à la prise en charge radioélectrique tels que le contrôle de bearer, le contrôle d’admission radioélectrique, le contrôle de la mobilité (lorsque le mobile est en mode connecté).

L’implémentation logicielle de la partie RRM n’est pas du ressort de la 3GPP, c’est pour cela qu’il n’est pas envisageable d’avoir une unité gNB-CU et gNB-DU de deux équipementiers différents.

IV-2) La virtualisation de la station de base : C-RAN

Le point de départ consiste à respecter le contrat SLA et d’apporter la QoE défini par le contrat. Ce contrat peut concerner la QoS pour un utilisateur. Toutefois, la virtualisation et l’isolation des slices permet à l’opérateur de louer les services de la station de base à des opérateurs virtuels ou à des entreprises.

Pour des entreprises privées, cela revient à mettre en place un DAS et la station de base est uniquement dédiée à l’entreprise.

Pour les opérateurs, il est possible de faire un partage de l’accès radioélectrique (Shared RAN) connecté directement au cœur réseau des différents opérateurs (MOCN : Multi-operator Core Network).

Jusqu’à présent, les stations de base étaient des entités physiques (PNF) installées au niveau de l’antenne. Ainsi, la gestion du spectre (contrôle d’admission, séquencement), la gestion des acquittements (HARQ/ARQ), le chiffrement étaient réalisés localement.

Dans le cas où l’entité est physique (PNF) alors les ressources matérielles de la station de base (CPU/RAM/Carte réseaux) doivent gérer les différents services (eMBB/mMTC pour la 4G).

Le découpage de la station de base en deux unités permet de mieux allouer les ressources matérielles aux fonctions protocolaires de la station de base. Excepté la tête radioélectrique déportée, les fonctionnalités de la station de base gNB-CU et gNB-DU sont toutes virtualisables.

La virtualisation est demandée par le support opérationnel OSS/BSS qui utilise le gabarit NST du slice pour imposer à l’orchestrateur (MANO ou ONAP) de gérer le cycle de vie dans l’instance virtuelle.

L’alliance O-RAN  portée par les opérateurs propose une normalisation (figure 18) sur la gestion du slice RAN. L’orchestrateur dispose d’un contrôleur SDN nommé RIC non-RT (RAN Intelligent Controller non Real Time) permettant de configurer le déploiement, la mise en échelle ou le relâchement de la sous-instance radioélectrique par un découplage du plan de contrôle et du plan utilisateur.

Figure 18 : Le fonctionnement du Cloud-RAN

La virtualisation du RAN est réalisée en suivant le protocole NFV de l’ETSI. Nous n’aborderons pas ici les solutions OpenSource existantes (OPNFV, OpenStack, QEMU, …).

Pour l’alliance O-RAN,

  • Le RIC non-RT a pour objectif le respect du SLA et de la supervision en gérant le déploiement, la mise à l’échelle ou la libération des sous-couches de virtualisations radioélectrique SNI.
  • Le contrôleur RIC near RT gère les ressources radioélectrique (fonctionnalités RRM) en proposant un découpage fonctionnel entre l’unité gNB-CU et les entités gNB-DU.

La configuration des gNB permet de définir la liste des services S-NSSAI supportés par le gNB par une procédure de configuration du paramétrage des stations de base (cf. figure 8). Cette phase de provisionning est gérée au moment de la création du slice radioélectrique (figure 19).

Figure 19 : La configuration des slices supportées par les gNB

Lorsque le gNB s’active, il informe la fonction AMF de l’ensemble des slices supportés avec la localisation TAC correspondante. Si la station de base est connectée à plusieurs fonctions AMF, alors elle transmet l’information à toutes les fonctions AMF. Chaque fonction AMF l’informe en retour des services S-NSSAIs supportés par la fonction AMF.

Au niveau du gNB, le découpage entre le gNB-DU et le gNB-CU est ordonné au niveau du contrôleur RIC-near RT. Un descripteur de slice permet de définir les fonctions gérées au niveau de chaque unité (gNB-CU et gNB-DU).

Une entité gNB peut supporter plusieurs slices. Le découpage entre gNB-CU et le gNB-DU est identique pour chaque slice par contre les fonctions utilisées sur chaque sous-couches peuvent être communes ou spécifiques. Par exemple, il est possible de définir un slice pour les terminaux statiques et de désactiver la fonction handover pour ce slice.

Figure 20 : La mise en place de plusieurs slices au niveau d’un gNB

On définit ainsi le comportement attendu pour chaque sous-couche et lorsque le mobile fera une demande de connexion radioélectrique, le message RRC transmis du mobile à l’entité gNB-CU contiendra l’information S-NSSAI du slice demandé. Ainsi, lors de la connexion radioélectrique, l’entité gNB créera un context UE avec le numéro de slice correspondant (figure 21).

 

Figure 21 : L’identification du slice

IV-3) Exemple de C-RAN

L’objectif de la virtualisation consiste à répartir la charge sur différents serveurs en fonction de la QoE demandée.  Ainsi :

  • Pour les terminaux IoT, la station de base devant couvrir une superficie sur laquelle on peut avoir 1 million d’IoT par km2 (ce chiffre est la limite haute du standard), les ressources matérielles de la station de base peuvent rapidement saturer si, il y a un réveil en cascade des terminaux IoT, ou si plusieurs terminaux sont dans le mode RRC_Inactive, ou … Il est donc recommandé de déporter les fonctions suivantes vers un DataCenter (DC) :
    • contrôle RRC de chaque terminal IoT ;
    • chiffrement/déchiffrement ;
    • segmentation, contrôle d’erreur ARQ ;
    • multiplexage, contrôle d’erreur HARQ.

En contrepartie, le fait de déporter les calculs vers le DataCenter va avoir comme incidence d’augmenter la latence, ce qui n’a aucune importante pour les terminaux IoT HLCom (High Latency Communication). En effet, la QoS pour le service IoT n’est pas la latence mais la problématique est la gestion d’un nombre très élevé de terminaux (mMTC :massive MTC).

  • Pour les smartphones eMBB, la station de base doit offrir des services avec une latence d’environ 10 ms pour le plan de trafic et 100 ms pour le plan de transport. On peut donc envisager un découpage avec l’unité gNB-CU au niveau du point de présence (PoP) sur lequel l’opérateur déploie des lames de serveurs (mini Data Center nommé MEC – Multi-access Edge Computing). Ainsi :
    • l’entité gNB-CU gère la couche RRC/PDCP haute ;
    • l’entité gNB-DU au niveau de la station de base gère les sous-couches PDCP base, RLC, MAC et physique.
  • Pour les communications critiques (URLLC et V2X), afin de réduire la latence, tout le traitement du gNB s’effectue au niveau local (près de l’antenne).

Toutefois, le mobile n’est pris en charge que par une seule paire gNB-CU et gNB-DU, le choix du gNB-CU s’effectue par rapport aux paramétrages radioélectrique du mobile sur le module USIM (PLMN), c’est-à-dire par la sélection d’un PLMN.

La tranche de réseau par PLMN est identifiée par un indicateur de slice Slide ID NSSAI. Les slices gérés par le PLMN sont stockés au niveau du gNB-CU.

L’exemple (figure 22) ci-dessous est extraite de l’article [ferrus] :

Figure 22 : Déploiement 5G-NR

La figure présente 2 PLMN différents, PLMN#A et PLMN#B.

Le PLMN#A est géré par une entité gNB monolithique déployée sur un MEC du PoP #1 puisqu’on est sur une infrastructure légère (LW NFVI)

Le PLMN#B est géré par une unité gNB-CU qui est située sur le DC du PoP #2. L’unité gNB-CU est connectée à deux unités gNB-DU, une située sur le MEC PoP#1 et l’autre sur le MEC #PoP3.

Lorsque le mobile s’allume, il cherche le PLMN correspondant, soit le PLMN#A soit PLMN#B.

On peut supposer que le PLMN#A est dédié pour l’IoT sur une bande de fréquences à 700 MHz (@RF Carrier#1), la zone de couverture est étendue (NR Cell#1). Lorsque le terminal s’allume, il scanne une fréquence basse et cherche le PLMN #A. Une fois synchronisé, il fait une demande de connexion radioélectrique avec le gNB#1.

Le PLMN#B exploite une bande de fréquence @RF Carrier#2 sur deux cellules NR Cell#2 et NR Cell#3. Lorsque le smartphone s’allume, il scanne la bande de fréquences et une fois synchronisée il fait une demande de connexion auprès du gNB-CU. Selon sa position, il fait la demande auprès du gNB-DU du PoP#1 ou du PoP#3.

Conclusion

Le découpage du réseau en tranche est constitué de deux sous instances virtuelles (NSI), une sous-instance au niveau du cœur de réseau et une sous-instance au niveau de l’accès radioélectrique.

Le mobile est enregistré sur une seule fonction AMF mais peut activer plusieurs slice simultanément. Au niveau accès radioélectrique, le mobile est géré par un unique gNB.

La figure 23 est issue d’une documentation NoKia et réprésente le découpage du réseau 5G.

La figure 24 est issu d’une documentation Samsung et réprésente le découpage du réseau, l’orchestration de bout en bout. Ce document reprend donc l’ensemble des fonctionnalités et le découpage du réseau décrit dans cet article.

Figure 23 : Un découpage de réseau de bout en bout [Nokia]

Figure 24: Un découpage de réseau de bout en bout [Samsung]

References :

Liens 3GPP :

3GPP TS 28.530 V16.1.0 : Management and orchestration; Concepts, use cases and requirements

3GPP TS 38.300 : NR; NR and NG-RAN Overall Description; Stage 2, Release 16

  • http://www.3gpp.org/ftp//Specs/archive/38_series/38.300/38300-g10.zip

3GPP TS 23.501 V16.1.0 : System architecture for the 5G System (5GS); Stage 2, Release 16

3GPP TS 29.510 V15.1.0 : 5G System; Network function repository services; Stage 3, Release 15

3GPP TS 29.531 V15.1.0 : 5G System; Network Slice Selection Services; Stage 3, Release 15

3GPP TS 28.500 : Management concept, architecture and requirements for mobile networks that include virtualized network functions, Release 15

3GPP TS 24.501 : Non-Access-Stratum (NAS) protocol  for 5G System (5GS); Stage 3;             (Release 16)

  • http://www.3gpp.org/ftp//Specs/archive/24_series/24.501/24501-g41.zip

3GPP TS 21.915 : Release Description ; Release 15

 

ETSI

Article

[ferrus] R. Ferrús, O. Sallent, J. Pérez-Romero, R. Agustí , « Management of Network Slicing in 5G Radio Access Networks: Functional Framework and Information Models ».

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/onf2015.310_Architectural_comparison.08-2.pdf

Equipementiers

  • Huawei : 5G Network Slicing for Vertical Industries
  • Huawei : 5G Network Slicing for Cross Industry Digitization Position Paper
  • Nokia : Network Slicing in 5GS E2E
  • Samsung

 

https://www.huawei.com/minisite/5g/img/gsa-5g-network-slicing-for-vertical-industries.pdf

http://www-file.huawei.com/-/media/CORPORATE/PDF/white%20paper/5G-Network-Slicing-for-Cross-Industry-Digitization-Position-Paper.pdf

Figure 13 : https://www.5g-ks.org/pdf/Network_Slicing_in_5GS-E2E_View-Nokia.pdf

Figure 23 : https://www.5g-ks.org/pdf/Network_Slicing_in_5GS-E2E_View-Nokia.pdf

Figure 24 : https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/network-slicing/200420_Samsung_Network_Slicing_Final.pdf

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

Posté le by - 4 292 vues
5

[bws_captcha]Cet article est la suite de :

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

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

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

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

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

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

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

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

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

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

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

Voici un exemple de configuration de la fonction NSSF :

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

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

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

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

Figure 6 : La mise à jour de la fonction NSSF

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Le dernier paragraphe sera traité dans un autre article.