Comprendre la 5G – NTN Part 4

Posté le by - 17 vues
Répondre

Suite de l’article : Comprendre la 5G – NTN Part 3

Variabilité Temporelle et Mises à Jour

Mobilité du Satellite (LEO)

Pour les constellations LEO, le satellite se déplace rapidement par rapport à la Terre (vitesse orbitale ~7.5 km/s pour un satellite à 600 km).

Taux de variation de la distance :

dD/dt ≈ v_sat × cos(θ)

où θ est l’angle entre le vecteur vitesse du satellite et la direction UE-satellite.

Impact sur TA : Le TA doit être mis à jour régulièrement. Le taux de variation du TA est :

dTA/dt = (1/c) × dD/dt

Exemple numérique :

  • v_sat = 7 500 m/s
  • Angle défavorable : cos(θ) = 0.7
  • dD/dt = 5 250 m/s
  • dTA/dt = 5 250 / (3×10⁸) ≈ 17.5 µs/s ≈ 1.05 ms/minute

Le TA change donc d’environ 1 ms par minute, nécessitant des mises à jour fréquentes.

Périodicité des Mises à Jour

Le 3GPP TS 38.213 définit que les mises à jour de TA doivent être envoyées lorsque l’erreur de TA dépasse un seuil. En NTN, ce seuil est adapté mais le principe reste :

Fréquence de mise à jour du TA :

  • LEO : Toutes les 10-100 secondes (selon la géométrie)
  • GEO : Très rarement (satellite quasi-stationnaire)

Fréquence de mise à jour de Koffset/Kmac :

  • LEO : Toutes les 1-10 secondes (éphémérides mises à jour)
  • GEO : Rarement (peut être fixe)

Prédiction et Compensation Doppler

La variation de distance induit également un effet Doppler en fréquence qui doit être compensé. La compensation Doppler en NTN (TS 38.821) peut être :

  1. Pré-compensée par l’UE (Common TA/Doppler pre-compensation)
  2. Compensée par le satellite (si régénératif)
  3. Combinaison des deux

Le calcul du décalage Doppler est :

f_doppler = -f_carrier × (v_radiale / c)

où v_radiale = dD/dt (vitesse radiale).

Architectures NTN et Implications

Transparent Payload

Dans une architecture transparente (bent-pipe), le satellite est un simple répéteur :

  • TA pré-compensé : Obligatoire côté UE
  • Koffset : Calculé par l’UE ou fourni par le réseau
  • Kmac : Géré localement par l’UE
  • Commandes TA résiduelles : Envoyées par le gNB au sol

L’UE doit avoir des capacités GNSS et de calcul d’éphémérides.

Regenerative Payload

Dans une architecture régénérative, le satellite décode et ré-encode les signaux :

  • TA : Peut être géré partiellement par le satellite
  • Koffset : Split entre segment spatial et terrestre
  • Kmac : Géré par le satellite gNB

Cette approche réduit la complexité UE mais augmente celle du satellite.

Choix de l’Architecture

Le choix entre transparent et régénératif impacte directement la gestion de TA, Koffset et Kmac :

Aspect Transparent Régénératif
TA pré-compensé UE obligatoire Optionnel
Complexité UE Élevée (GNSS+calcul) Modérée
Complexité satellite Faible Élevée
Latence minimale RTT complet RTT segment
Efficacité spectrale Modérée Élevée

Défis et Limitations

Précision de Localisation

L’efficacité du TA pré-compensé dépend de la précision GNSS de l’UE :

  • GPS standard : Précision ~5-10 m → erreur TA ~33-66 ns
  • GNSS augmenté : Précision ~1 m → erreur TA ~6.6 ns

Avec c = 3×10⁸ m/s, une erreur de position de 10 m induit une erreur de TA de ~33 ns, ce qui reste négligeable par rapport au Tc ≈ 0.509 ns mais peut s’accumuler.

Latence des Éphémérides

Les éphémérides sont diffusées dans les SIB avec une périodicité de quelques secondes. Durant cet intervalle, la position du satellite (LEO) a changé, induisant une erreur dans le calcul de TA pré-compensé.

Atténuation : Utiliser des modèles de prédiction d’orbite (propagateurs Kepler/SGP4) avec les paramètres orbitaux.

Délai de Feeder Link

Le délai feeder link (satellite ↔ gateway) est souvent variable en fonction de :

  • Charge du réseau backbone
  • Routage IP
  • Traitement dans les gateways

Cette variabilité introduit un jitter qui doit être absorbé par les buffers et compensé par les mises à jour de TA résiduel.

Consommation Énergétique

Le calcul fréquent de TA pré-compensé, Koffset et Kmac par l’UE consomme de l’énergie :

  • Acquisition GNSS continue
  • Calculs trigonométriques pour les distances
  • Traitement des éphémérides

Optimisations :

  • Utiliser des prédictions au lieu de recalculer à chaque slot
  • Mode discontinu avec réveil périodique
  • Offload vers le réseau si possible

Conclusion

La gestion temporelle en 5G NTN représente un défi majeur que le 3GPP a relevé par l’introduction de mécanismes sophistiqués :

  1. Le Timing Advance (TA) pré-compensé permet à l’UE de calculer lui-même la majorité de l’avance temporelle nécessaire, réduisant la charge sur le réseau et permettant une synchronisation initiale rapide malgré les délais importants.
  2. Le Round-Trip Time (RTT) étendu, pouvant atteindre 520 ms en GEO, impose une refonte complète des procédures HARQ et des fenêtres de retransmission.
  3. Koffset compense le RTT dans les relations temporelles de scheduling et HARQ, permettant au système de fonctionner malgré des délais de propagation dépassant largement la durée d’une trame.
  4. Kmac assure que la couche MAC prépare les données suffisamment en avance pour que la couche physique puisse appliquer le TA important requis en NTN.

Ces mécanismes, standardisés dans les TS 38.213, 38.214, 38.321 et 38.821, permettent à la 5G NR de s’étendre au-delà de son domaine terrestre initial pour embrasser les réseaux satellites, ouvrant la voie à une connectivité globale véritablement ubiquitaire.

Les défis restants portent sur l’optimisation de la consommation énergétique des UEs, la gestion de la mobilité satellite (particulièrement pour les constellations LEO), et l’interopérabilité entre segments terrestres et non-terrestres dans les architectures hybrides futures.

Références 3GPP

  • TS 38.211 – Physical channels and modulation
  • TS 38.213 – Physical layer procedures for control
  • TS 38.214 – Physical layer procedures for data
  • TS 38.300 – NR and NG-RAN Overall description
  • TS 38.321 – Medium Access Control (MAC) protocol specification
  • TS 38.331 – Radio Resource Control (RRC) protocol specification
  • TS 38.821 – Solutions for NR to support non-terrestrial networks (NTN)

Glossaire

  • ECEF : Earth-Centered, Earth-Fixed (système de coordonnées)
  • GEO : Geostationary Earth Orbit
  • GNSS : Global Navigation Satellite System
  • HARQ : Hybrid Automatic Repeat Request
  • LEO : Low Earth Orbit
  • MAC : Medium Access Control
  • NTN : Non-Terrestrial Networks
  • PDSCH : Physical Downlink Shared Channel
  • PUCCH : Physical Uplink Control Channel
  • PUSCH : Physical Uplink Shared Channel
  • RTT : Round-Trip Time
  • SCS : Subcarrier Spacing
  • SIB : System Information Block
  • TA : Timing Advance
  • TAC : Timing Advance Command
  • UE : User Equipment

 

Comprendre la 5G – NTN Part 3

Posté le by - 40 vues
Répondre

Suite de l’article Comprendre la 5G – NTN Part 2

L’Ordonnancement Temporel : Koffset et Kmac

Le Problème de la Latence HARQ

Dans un réseau 5G NR terrestre, le mécanisme HARQ (Hybrid Automatic Repeat Request) suit un timing strict défini par le 3GPP TS 38.214 :

  1. Slot n : Transmission downlink du PDSCH
  2. Slot n+k : Réception de l’ACK/NACK dans le PUCCH uplink
  3. Slot n+k+k’ : Retransmission éventuelle

Les valeurs de k sont typiquement petites (4 à 8 slots) car le RTT terrestre est faible.

En NTN, avec un RTT de plusieurs millisecondes voire centaines de millisecondes, ces valeurs deviennent inadaptées. Le 3GPP a donc introduit Koffset et Kmac.

Le décalage Koffset associé au temps de propagation introduit une latence élevée pour l’acquittement. La 5G NTN propose d’augmenter le traitement en parallèle de 16 processus à 32 processus pour éviter un effondrement du débit par attente d’acquittement (HARQ Stalling). Mais la 3GPP propose également de désactiver le processus HARQ.

Koffset : Compensation du Délai de Propagation

Le paramètre Koffset est défini dans le TS 38.214 (amendements NTN) et représente un offset temporel additionnel pour compenser le délai de propagation NTN. Afin de comprendre l’intérêt de ce paramètre, revenons sur le cas d’usage de la 5G terrestre.

Lorsque la station de base envoie des informations de contrôle DCI, c’est pour :

  • Informer l’UE qu’il recevra des données en DL. L’UE répondra à la station de base en transmettant un acquittement HARQ.
  • Informer l’UE qu’il peut émettre des données en UL

La 5G terrestre définit des indicateurs K0, K1 et K2 :

  • K0 : retard entre la réception de l’information DCI et la réception des données sur le canal PDSCH
  • K1: retard entre la réception de l’information DCI et l’émission de l’acquittement sur le canal PUCCH
  • K2: retard entre la réception de l’information DCI et l’émission des données sur le canal PUSCH

La valeur de K0, K1 et K2 sont des paramètres d’ordonnancement fixés à la durée de quelques sous-trames. Par exemple K1 vaut 3 ms, ce qui signifie que la station de base s’attend à recevoir cet acquittement 3 ms après l’émission du DCI. Du point de vue de l’UE, celui-ci dispose de moins de 3 ms pour récupérer la trame radio, l’acquitter et l’envoyer à la station de base (il faut prendre en compte la propagation DL et UL donc le TA). Si le TA est supérieur à 3 ms, il est impossible que l’acquittement soit reçu sur la sous-trame dédié.

Figure 1 : L’acquittement émis par l’UE et reçu par le gNB

Dans le cas ou la commande DCI demande à l’UE de transmettre un paquet montant, ce paquet doit être reçu à K2+Koffset trames après la commande DCI. La valeur du Koffset garantit que le nombre de sous-trames pour la réception du paquet au niveau du gNB est supérieur au RTT maximal. Il s’agit bien d’un paramètre d’ajustement d’ordonnancement « grossier ».

Figure 2 : La réception du paquet UL reçu par le gNB (Rohde et Schwarz)

Définition et Calcul

Koffset = ⌈2 × T_propagation / T_slot⌉

où :

  • T_propagation = délai de propagation unidirectionnel UE↔satellite↔gateway
  • T_slot = durée d’un slot (dépend de la numérologie)

Exemple LEO (600 km, élévation 30°) :

  • Distance UE-satellite : ~693 km
  • Distance satellite-gateway : ~693 km
  • T_propagation : (693 + 693) km / c ≈ 4.6 ms
  • Avec SCS 15 kHz (T_slot = 1 ms) : Koffset ≈ 10 slots

Exemple GEO (35 786 km) :

  • Distance totale : ~80 000 km (UE-SAT-GW)
  • T_propagation : ~267 ms
  • Avec SCS 15 kHz : Koffset ≈ 534 slots

Application de Koffset

Koffset est appliqué aux relations temporelles suivantes (TS 38.214) :

Pour PDSCH → HARQ-ACK :

Slot_HARQ-ACK = Slot_PDSCH + K1 + Koffset

Pour DCI → PUSCH :

Slot_PUSCH = Slot_DCI + K2 + Koffset

où K1 et K2 sont les valeurs configurées normalement en NR terrestre.

Configuration de Koffset

Koffset peut être :

  1. Calculé par l’UE (mode pré-compensé) en fonction des éphémérides et de sa position
  2. Signalé par le réseau via les SIB ou RRC (mode transparent)

Le choix dépend de l’architecture NTN (transparent vs régénératif) et de la capacité de l’UE à calculer les paramètres temporels.

Kmac : Timing Advance pour la Couche MAC

Le paramètre Kmac est intimement lié au Timing Advance mais opère au niveau de la couche MAC. Il représente le délai à appliquer aux PDU MAC pour tenir compte du TA en NTN.

Distinction TA vs Kmac

  • TA (Timing Advance) : Appliqué au niveau physique (PHY), avance le timing de transmission RF

Kmac : Appliqué au niveau MAC, avance la préparation et l’envoi des MAC PDU à la couche physique

Figure 3 : La liaison NTN (illustration 3GPP)

Le point de référence correspond à l’alignement entre la trame physique UL et DL. Mais il faut prendre en compte la distance entre la couche MAC du gNB terrestre et le point de référence. La 3GPP propose un décalage UL/DL afin de compenser de manière transparente à l’UE.

Figure 4 : Les timers Koffset et Kmac (Rohde et Schwarz)

De plus, lorsque le satellite se déplace, il peut suspendre sa connexion feeder avec une passerelle terrestre (nommée passerelle source) et activer une connexion feeder avec une autre passerelle terrestre (nommée passerelle cible). Le routage IP est anticipé pour éviter d’avoir une latence importante, mais on peut imaginer que qu’avant routage la passerelle terrestre contient le gNB DU et le RRU et après routage, le gNB DU est resté sur la passerelle source et le RU est au niveau de la passerelle cible ce qui modifie le désalignement DL/UL.

Cas Pratiques et Dimensionnement

Scénario LEO (600 km)

Considérons un satellite LEO à 600 km d’altitude, avec un UE à une élévation de 30°.

Paramètres géométriques :

  • Distance UE-satellite : ~693 km
  • Distance satellite-gateway (supposé au nadir) : ~693 km
  • Distance totale : 1 386 km

Calculs temporels :

RTT = 2 × 1 386 / 300 000 ≈ 9.24 ms

TA_precomp = 1 386 / 300 000 ≈ 4.62 ms

Avec SCS 15 kHz (T_slot = 1 ms) :

Koffset = ⌈9.24⌉ = 10 slots

Kmac = ⌈4.62⌉ = 5 slots

Avec SCS 30 kHz (T_slot = 0.5 ms) :

Koffset = ⌈9.24 / 0.5⌉ = 19 slots

Kmac = ⌈4.62 / 0.5⌉ = 10 slots

Scénario GEO (35 786 km)

Pour un satellite géostationnaire :

Paramètres géométriques :

  • Distance UE-satellite : ~38 000 km (élévation 30°)
  • Distance satellite-gateway : ~40 000 km
  • Distance totale : ~78 000 km

Calculs temporels :

RTT = 2 × 78 000 / 300 000 ≈ 520 ms

TA_precomp = 78 000 / 300 000 ≈ 260 ms

Avec SCS 15 kHz :

Koffset = ⌈520⌉ = 520 slots

Kmac = ⌈260⌉ = 260 slots

Impact sur les Ressources Système

Ces valeurs importantes ont des conséquences majeures :

  1. Processus HARQ :
  • Nombre de processus HARQ nécessaires : Au moins RTT/TTI
  • En GEO avec SCS 15 kHz : 520 processus HARQ minimum
  • En NR terrestre : Typiquement 8-16 processus
  1. Mémoire requise :
  • Buffers MAC : Kmac × taille_MAC_PDU × nombre_UE
  • Buffers HARQ : RTT × débit_pic
  • En GEO : Plusieurs dizaines de MB par UE
  1. Complexité du scheduleur :
  • Fenêtre de scheduling : Kmac + Koffset slots
  • En GEO : Planification sur ~780 slots (7.8 secondes avec SCS 15 kHz)

Comprendre la 5G – NTN Part 2

Posté le by - 53 vues
Répondre

Suite de l’article Comprendre la 5G – NTN Part 1

Le Timing Advance (TA) : Compenser le Délai de Propagation

Principe Fondamental du TA

Le Timing Advance est un mécanisme fondamental des réseaux de mobiles (cf. 3GPP TS 38.213 pour la 5G NR – Section 4.2). Son objectif est de garantir que les transmissions uplink de tous les UEs arrivent synchronisées à la station de base (gNB ou satellite).

Sans TA, les transmissions de différents UEs situés à des distances variables arriveraient à des instants différents, causant des interférences inter-symboles et dégradant les performances du système.

Le principe : L’UE avance temporellement sa transmission uplink d’une valeur TA pour compenser le délai de propagation, de sorte que : T_arrivée_gNB = T_transmission_UE + T_propagation – TA ≈ T_référence

Calcul du TA dans les Réseaux Terrestres

Dans les réseaux terrestres (TS 38.213 pour la 5G), le TA est calculé par le gNB en mesurant la différence de temps entre la réception du signal Uplink et le début de la sous-trame dédiée à la réception de ce message. Le gNB envoie ensuite des commandes de TA à l’UE via :

  • Timing Advance Command (TAC) dans le Random Access Response (RAR) afin de calculer la valeur du TA initial. On parle de boucle ouverte et le gNB mesure la différence de temps entre la réception du préambule d’accès RACH et la sous-trame dédiées à la réception des RACH
  • TA adjustments via des commandes MAC CE (Control Element) permettant de compenser en boucle fermée la variation du TA lorsque l’UE se déplace. On compense ainsi le delta supplémentaire lorsque l’UE se déplace par rapport à la valeur du TA précédent.

Ajustement en boucle ouverte

La valeur de TA est quantifiée en unités de Tc (temps d’échantillonnage de base) :

TA = NTA × Tc.

On retrouve parfois en 4G-LTE le calcul suivant 1 TA = 16 Ts avec Ts = 1/(15000 × 2048) ≈ 32,55 ns (durée d’échantillonnage de base).

En NR (5G) :

  • TA dépend de la numérologie (SCS – Subcarrier Spacing)
  • Pour SCS = 15 kHz : 1 TA unit = 16 × 64 Tc ≈ 0,51 μs
  • Pour SCS = 30 kHz : 1 TA unit = 16 × 64 Tc / 2
  • Tc = 1/(480000 × 4096) (période d’échantillonnage de base)

Avec Tc ≈ 0.509 ns on peut calculer l’erreur de distance : 0,51 μs / 2× c ≈ 78 m

En boucle ouverte, le gNB transmet la valeur TA absolue

  • NR : MAC CE « Absolute Timing Advance Command » Absolute : 12 bits (valeur complète) Le calcul est le suivant : TA = TA_command × N_TA
  • TA_command : valeur reçue (0 à 4095 pour 12 bits)
  • N_TA : granularité qui dépend de la numerology (SCS)

Granularité N_TA selon le SCS :

  • μ = 0 (SCS 15 kHz) : N_TA = 16 × 64 Tc
  • μ = 1 (SCS 30 kHz) : N_TA = 16 × 64 Tc / 2¹ = 16 × 32 Tc
  • μ = 2 (SCS 60 kHz) : N_TA = 16 × 64 Tc / 2² = 16 × 16 Tc
  • μ = 3 (SCS 120 kHz) : N_TA = 16 × 64 Tc / 2³ = 16 × 8 Tc

Le TA est codé sur :

  • 11 bits en LTE : valeurs de 0 à 2047
  • 12 bits en NR : valeurs de 0 à 3846 (valeurs utilisables max actuellement)

Distance maximale :

  • LTE : 2047 × 78 m ≈ 160 km
  • NR (15 kHz) : environ 200 km

Ajustement en boucle fermée

Une fois la connexion établie, le réseau effectue des ajustements fins du TA. Commandes TA :

  • LTE : MAC CE (Control Element) « Timing Advance Command »
    • 6 bits : valeurs de 0 à 63
    • Représente un ajustement relatif : TA_new = TA_old + (TA_command – 31) × 16 Ts
    • Plage : ±31 unités TA (±1,6 km environ)
  • NR : MAC CE  » « Relative Timing Advance Command »
    • Relative : 6 bits (ajustement incrémental)

Pour le TA relatif

TA_new = TA_old + (TA_adjustment – 31) × N_TA

Timer TA :

  • timeAlignmentTimer : si l’UE ne reçoit pas de commande TA pendant cette durée, elle considère que le TA n’est plus valide
  • Valeurs typiques : 500 ms à 10 s
  • Expiration → l’UE doit refaire un RACH

TA Offset dans le réseau terrestre

Le TA offset est un désalignement intentionnel entre les trames downlink et uplink qui est transmis par le paramètre 5G NR n-TimingAdvanceOffset diffusé par un message RRC SIB.

Valeurs possibles : •

  • n0 : TA_offset = 0 (comportement par défaut)
  • n25600 : TA_offset = 25600 Tc ≈ 13 μs
  • n39936 : TA_offset = 39936 Tc ≈ 20 μs

Le TA_offset vaut 0 dans le cas FDD (les trames UL et DL sont synchronisées en temps sur des bandes de fréquences différentes.

Dans le cas TDD il faut prendre en compte le délai du temps de garde (Special). Exemple de pattern TDD (D = Downlink, U = Uplink, S = Symbole flexible)

  1. Slot n : DDDDDDDDDDDDD (tout DL)
  2. Slot n+1 : DDDSUUUUUUUUU (DL + spécial + UL)
  3. Slot n+2 : UUUUUUUUUUUUU (tout UL)

Le Ta_offset permet de prendre en compte ce délai. Ainsi en 5G pour les réseaux terrestres, TA=(N_TA+N_TAoffset).Tc

Ainsi en 5G pour les réseaux terrestres, TA=(N_TA+N_TAoffset).Tc

TA Pré-Compensé en NTN : Une Approche différente

Alors que pour le réseau terrestre la valeur du TA est calculée par la station de base, l’évolution majeure pour les terminaux 5G NTN est la capacité à pré-calculer le TA.

Pré-calcul du TA

En NTN, les délais de propagation sont beaucoup trop importants. Le 3GPP a introduit un concept dans le TS 38.821 : le TA pré-compensé (pre-compensated TA).

Dans le cas du réseau non terrestre, l’UE communique vers un satellite et le satellite transmet le trafic vers une passerelle satellitaire terrestre. On parle de lien de service le lien entre l’UE et le satellite et de lien de feeder, le lien entre le satellite et la passerelle satellitaire terrestre.

Figure 1 : Liaison NTN

Le standard 3GPP propose actuellement 2 architectures 5G NTN :

  • Architecture Transparente
  • Architecture Regénérative

Dans l’architecture transparente, la station de base est au sol, c’est-à-dire après la passerelle terrestre. Le temps de propagation radio aller/retour prend en compte le temps de propagation sur le lien de service et sur le lien du feeder.

Dans l’architecture régénérative, la station de base est située dans le satellite. Le temps de propagation radio prend en compte le temps de propagation sur le lien de service uniquement.

Principe du Pré-calcul

L’idée clé est que l’UE calcule lui-même la valeur du TA en utilisant :

  1. Les éphémérides du satellite : Position et vitesse du satellite, diffusées dans les System Information Blocks (SIB19 selon TS 38.331)
  2. Sa propre position GNSS : Latitude, longitude, altitude obtenues via GPS/Galileo/etc.
  3. Le temps de référence commun : Fourni par le satellite

Le calcul du TA pré-compensé suit la formule (TS 38.821, Section 6.3.1.1) :

TA_precomp = (d_UE→SAT + d_SAT→GW) / c

où :

  • d_UE→SAT = distance UE vers satellite (calculée géométriquement)
  • d_SAT→GW = distance satellite vers gateway (fournie dans SIB19)
  • c = vitesse de la lumière

Calcul Géométrique de la Distance UE-Satellite

La distance UE-satellite se calcule en coordonnées ECEF (Earth-Centered, Earth-Fixed) :

d_UE→SAT = √[(X_sat – X_UE)² + (Y_sat – Y_UE)² + (Z_sat – Z_UE)²]

Les coordonnées du satellite (X_sat, Y_sat, Z_sat) sont dérivées des éphémérides, tandis que les coordonnées de l’UE (X_UE, Y_UE, Z_UE) sont converties depuis ses coordonnées GNSS (latitude, longitude, altitude).

Mais, un satellite LEO se déplace environ à 28000 km/h (7,8 km/s). Le délai de propagation varie donc entre le sens montant et le sens descendant.

Figure 2 : La distance entre le satellite et l’UE en fonction de la position du satellite (Rohde et Schwarz)

Figure 3 : Le temps RTT sur le lien de service (Rohde et Schwarz)

Lorsque l’UE envoi une demande d’accès aléatoire à l’instant t0, la 3GPP propose de calculer le RTT à partir :

  • du délai t1 entre l’UE et le satellite (lien de service). Le satellite reçoit la demande d’accès à l’instant t1 et le transmet à la passerelle. Il est nécessaire de connaitre la position du satellite à l’instant t1.
  • du temps RTT_feeder nommé t2 entre le satellite et la passerelle terrestre.
  • du délai satellite-UE (lien de service) à l’instant t2. Il est donc nécessaire de connaitre la position du satellite à l’instant t2.

Pour calculer la position du satellite à l’instant t1 et t2, l’UE connait :

  • le temps de référence tepoch. Celui-ci correspond par exemple à l’instant de le sous-trame n°5
  • des informations éphémérides du satellite
    • Sa position à l’instant tepoch
    • Son vecteur vitesse à l’instant tepoch
    • Son vecteur accélération à l’instant tepoch

Toutefois, en connaissant la position de l’UE et du satellite (à l’instant t0, t1 et t2), il est possible de localiser la position de la passerelle satellitaire terrestre à partir du RTT_feeder. Afin de masquer cette information, la 3GPP propose une subtilité qui consiste à définir un point de référence sur le lien feeder nommé RP ou UTSRP (uplink time synchronization) comme point de référence.

Ainsi, la station de base diffuse dans le SIB19 les paramètres Common TA. Cette information (éphéméride et temps de référence tepoch) permet de calculer le RTT du lien feeder et s’applique donc à tous les UE :

  • Le délai NTA,common entre le point de référence et le satellite à l’instant tepoch
  • La vitesse NTA,commondrift entre le point de référence et le satellite à l’instant tepoch
  • L’accélération NTA,commondriftvariation entre le point de référence et le satellite à l’instant tepoch

Dans le cas ou l’architecture choisie par l’opérateur est l’architecture regénérative, alors les paramètres Common TA (NTA,common, NTA,commondrift, NTA,commondriftvariation) sont toutes égales à 0.

Ainsi le pré-calcul du TA effectué par l’UE est le suivant :

  • NTA,adjUE: avance temporelle estimée par l’UE lui-même pour pré-compenser le délai de la liaison de service. Elle est calculée à partir de :
    • La position de l’UE estimée via positionnement GNSS
    • La position estimée du satellite basée sur les informations d’éphémérides que l’UE possède
  • NTA,adjcommon est l’avance temporelle commune contrôlée par le réseau sur le lien feeder. Elle est dérivée des paramètres reçus par l’UE en provenance de la couche supérieure RRC SIB 19 et se calcule à partir du délai feeder à l’instant t1 et à l’instant t2 :
    • TACommon : estimation initiale du délai de propagation entre le satellite et la passerelle terrestre ou du point de référence
    • TACommonDrift : représente la vitesse de dérive de l’avance temporelle commune
    • TACommonDriftVariation (si configurés). Si non configurés, sa valeur par défaut est 0. Ce paramètre représente la variation (ou accélération) de la dérive du timing. Il modélise le fait que la vitesse de changement de distance n’est pas constante en raison de l’orbite non circulaire du satellite et d’autres facteurs.

Le délai vaut :

Tepoch est la référence temporelle qui correspond à l’instant où le récepteur UE doit recevoir une sous-trame définie. Cela permet d’avoir une référence de temps commune entre le réseau et l’UE.

Figure 4 : Le calcul du délai sur le feeder en fonction de la position du satellite à l’instant t

 

3.2 Timing Advance Résiduel

Même avec le TA pré-compensé, il subsiste une erreur due à :

  • Imprécisions de position GNSS de l’UE (quelques mètres)
  • Latence dans les éphémérides (propagation des SIB)
  • Délai de feeder link variable

Le réseau envoie donc encore des commandes TA résiduelles via MAC CE pour affiner l’alignement temporel. Ces corrections sont beaucoup plus petites qu’en réseau terrestre. Mais, de par la vitesse du satellite LEO, la variation de délai est de 40 µs toutes les 1 ms ce qui nécessite de mettre à jour régulièrement le TA lorsque l’UE est en mode connecté. La charge en signalisation est trop importante pour conserver ce mode de fonctionnement. Le pré-calcul du TA permet à l’UE de compenser automatiquement la variation du délai sur le lien de service et le lien de feeder.

Ainsi, si la station de base gNB mesure une différence de temps entre la réception de la sous-trame UL par rapport à la sous-trame de réception, cette différente étant négligeable, peut être  compensée par le gNB.

Ainsi, le TA global se calcule de la manière suivante :

Avec NTa,offset défini par le paramètre nr-TimingAdvanceOffset : Un offset supplémentaire appliqué au TA pour tenir compte de la configuration spécifique NTN (TS 38.213 Section 4.2).

 

 

 

 

Comprendre la 5G – NTN Part 1

Posté le by - 71 vues
Répondre

Cet article a été écrit avec la collaboration de Mohamed El Jaafari, expert Réseau radio 3GPP et satellitaire chez Thales AleniaSpace, et en attente de relecture.

Mohamed El Jaafari est un des auteurs du livre 5G Non-Terrestrial Networks: Technologies, Standards, and System Design

Introduction

L’intégration des réseaux non-terrestres (NTN – Non-Terrestrial Networks) dans l’écosystème 5G New Radio (NR) constitue l’une des évolutions majeures des télécommunications modernes.

Initialement conçue pour des réseaux cellulaires terrestres, la 5G doit désormais s’adapter à des infrastructures hybrides capables d’assurer une connectivité via des satellites en orbite basse (LEO), moyenne (MEO) ou géostationnaire (GEO). Cette convergence entre réseaux terrestres et spatiaux est aujourd’hui considérée comme un élément structurant des futures architectures 6G.

Cependant, l’extension de la 5G NR vers les réseaux NTN ne consiste pas simplement à remplacer une station de base terrestre par un satellite. Les caractéristiques physiques des liaisons satellite-terre introduisent des contraintes radicalement différentes, notamment en matière de propagation radio et de synchronisation temporelle. Alors qu’un réseau terrestre traditionnel fonctionne avec des distances de quelques kilomètres entre l’UE et la station de base, les réseaux NTN doivent gérer des distances pouvant dépasser 36 000 km dans le cas des satellites GEO, entraînant des délais de propagation plusieurs ordres de grandeur supérieurs à ceux des réseaux cellulaires conventionnels.

Ces délais ont un impact direct sur les mécanismes fondamentaux de la couche radio 5G NR. Les procédures de synchronisation temporelle, conçues à l’origine pour des environnements terrestres à faible latence, doivent être adaptées afin de maintenir l’orthogonalité des transmissions et garantir le bon fonctionnement de l’interface radio. Le 3GPP a ainsi introduit plusieurs évolutions spécifiques au NTN concernant notamment le Timing Advance (TA), l’estimation du Round-Trip Time (RTT) ainsi que les mécanismes d’ordonnancement temporel reposant sur les paramètres Koffset et Kmac.

Il faut séparer deux ajustements temporels complémentaires : •

  • Ajustement précis par le calcul du TA afin de se synchroniser au niveau de la station de base afin d’éviter les interférences inter-symboles
  • Ajustement grossier pour l’ordonnancement afin de laisser plus de temps au récepteur d’envoyer sa réponse. Cet ajustement a un impact sur la latence (Koffset et Kmac).

L’un des aspects les plus novateurs de cette évolution réside dans la capacité de l’UE à pré-calculer certaines corrections temporelles à partir de sa position géographique et des éphémérides satellites. Cette approche marque une rupture importante avec le fonctionnement des terminaux 5G terrestres traditionnels et soulève de nouveaux enjeux autour de la dépendance aux systèmes GNSS, de la complexité terminale et de l’expérience utilisateur.

À plus long terme, les travaux du 3GPP s’orientent vers des approches GNSS-free afin de supprimer la nécessité de pré-calculs basés sur la position de l’UE. Cette évolution est essentielle pour limiter la complexité des terminaux NTN et éviter qu’une dépendance aux capacités GNSS ne devienne un obstacle à la démocratisation du service satellite sur smartphone. On peut citer comme exemple l’échec de l’offre Unik qui imposait au client un changement de téléphone. L’offre Unik d’Orange était une offre de convergence fixe-mobile lancée vers 2006, basée sur la technologie UMA (Unlicensed Mobile Access), plus tard renommée GAN (Generic Access Network).

Dans cet article, nous allons analyser les principaux mécanismes temporels introduits pour la 5G NTN et comprendre comment le 3GPP adapte l’architecture NR afin de faire fonctionner efficacement des communications radio sur des liaisons satellitaires à très longue distance.

L’alignement de la trame

Le délai : UE – gNB terrestre

Dans un réseau terrestre classique (TN – Terrestrial Network), le délai  d’un signal entre un équipement utilisateur (UE) et une station de base (gNB) est typiquement de l’ordre de quelques microsecondes à quelques dizaines de microsecondes. L’allocation de ressource en 4G est basée sur la sous-trame d’une durée de 1 ms. L’allocation de ressource en 5G est basée sur le slot.

Si d est la distance entre l’UE et la station de base, le délai UE – gNB – UE est égal à 2*d/c, avec c la vitesse de la lumière (300 m en 1 µs).

Ainsi, pour une station de base située à 1,2 km, le temps de propagation radio RTT (Radio Round Trip Time ou two way radio latency) est de 8 µs.

On appelle :

  • RTT radio : Aller-retour UE ↔ gNB sur l’interface radio
  • End-to-end RTT : Aller-retour complet jusqu’au serveur/applicatif
  • HARQ RTT : Temps d’un cycle HARQ ACK/NACK
  • Ping RTT : RTT IP mesuré par ICMP

Le délai UE – Satellite – gNB

La situation change radicalement en NTN. Selon le 3GPP TS 38.821, les scénarios NTN considèrent :

Satellites LEO (Low Earth Orbit) :

  • Altitude : 400 kms à 1100 kms (600 km cas nominal)
  • Distance maximale UE-satellite : ~1 200 km (élévation minimale pour un satellite à 600 kms et un angle de 30°)
  • Delai UE – satellite – UE :  ~8 ms pour une distance de 1200 kms

Satellites GEO (Geostationary Earth Orbit) :

  • Altitude : 35 786 km
  • Distance maximale UE-satellite : ~41 000 km
  • Delai UE – satellite – UE maximal : ~270 ms

Ces valeurs de RTT sont supérieures à la durée d’un slot 5G NR (TS 38.211), ce qui pose des problèmes fondamentaux pour les mécanismes de synchronisation (alignement de trame) conçus initialement pour les réseaux terrestres.

Impact sur la Synchronisation Temporelle et l’effet Doppler

La durée élevée du délai UE – Satellite – UE et la vitesse élevée du satellite ont plusieurs conséquences critiques :

  1. Variation temporelle du délai : Pour les satellites LEO en mouvement, le délai change continuellement en raison du déplacement relatif du satellite par rapport à l’UE. Le délai de propagation devient asymétrique : Le signal montant (uplink) et le signal descendant (downlink) varie en fonction de la position du satellite pour les LEO non-géostationnaires.
  2. La fréquence Doppler : le satellite LEO se déplace à 28 000 km/h ce qui provoque un décalage élevé de la fréquence de réception.
  3. Budget temporel HARQ : Les mécanismes de retransmission automatique (HARQ) doivent être adaptés pour accommoder ces délais importants.

Le prochain article (Part2) mettra en avant les mécanismes pour pré-compenser le Timing Advance.

DM-RS du PBCH : Le signal de référence du bloc SSB

Posté le by - 76 vues
Répondre

Pourquoi un DM-RS dédié au PBCH en 5G NR ?

En LTE, le décodage du PBCH s’appuie sur le signal de référence CRS (Cell-specific Reference Signal). Le CRS nommé Cell Reference Signal est un signal de référence permanent diffusé sur l’ensemble de la bande à chaque sous-trame. Le CRS permet à l’UE d’estimer le canal avant même de savoir où se trouve le PBCH. Le CRS est utilisé en 4G-LTE, initialement pour du SISO mais le signal est transmis sur chaque antenne, jusqu’à 4 antennes. Au delà de 4 antennes, le signal de référence CSI-RS remplace le CRS. Ainsi pour 8 antennes, le signal de références CRS est émis sur les antennes 1 à 4 et CSI-RS est émis sur les antennes 5 à 8.

Les signaux CRS et CSI-RS sont utilisés pour remonter l’état du canal ressenti par l’UE en mode connecté. Cette connaissance est nécessaire à l’ordonnanceur situé sur la couche MAC (Medium Access Control) du gNB à choisir le format MCS (Modulation and Coding Scheme) adapté.

En mode de veillle, le mobile doit récuperer le canal de diffussion PBCH. Ce signal occupe les symboles OFDM 0–3 du premier slot de la sous-trame 0. Pour démoduler ce canal, l’UE effectue une égalisation du canal. La démodulation s’appuie sur les Cell-specific RS présents dans cette zone. Techniquement les CRS des antennes port 0 (et éventuellement 1, 2, 3 selon le rang) sont utilisés par l’UE pour l’estimation du canal, mais l’UE se limite aux positions qui tombent dans les 6 PRB centraux.

Dans un souci d’efficacité spectrale, la 5G-NR supprime le CRS : il n’existe plus de signal de référence qui couvre en permanence l’ensemble de la bande. Chaque canal physique embarque donc ses propres signaux de référence, étroitement localisés à ses ressources temps-fréquence.

En 5G, comme en 4G, le PBCH transporte le MIB (Master Information Block), premier message de configuration qu’un UE doit décoder lors de la procédure de synchronisation cellulaire. Il est contenu dans le SS/PBCH Block (SSB), une structure compacte de 4 symboles OFDM × 240 sous-porteuses. Puisque ce bloc transporte des informations essentielles pour l’UE, la transmission de ce bloc doit être auto-suffisant : les DM-RS PBCH en font partie intégrante.

Référence : TS 38.211 §7.4.1.4 (séquence et cartographie RE) — TS 38.211 §7.4.3 (structure du SSB) — TS 38.213 §4 (procédure UE)

Structure du SS/PBCH Block : vue d’ensemble

Le SSB occupe 4 symboles OFDM consécutifs (numérotés 0 à 3) et 240 sous-porteuses réparties sur 20 PRBs (12 sous-porteuses par PRB). Les 4 symboles se répartissent comme suit :

  • Symbole S0 — PSS sur les sous-porteuses 56 à 182 (127 SCs) + zéros sur les bords. Aucun DM-RS.
  • Symbole S1 — PBCH sur les 240 sous-porteuses. DM-RS répartis sur l’ensemble des 240 SCs à une densité de 1 RE sur 4.
  • Symbole S2 — SSS sur les sous-porteuses 56 à 182 (127 SCs) + PBCH sur les bords (SCs 0–55 et 192–239). DM-RS uniquement dans les zones PBCH, aucun DM-RS dans la zone SSS.
  • Symbole S3 — PBCH sur les 240 sous-porteuses. DM-RS répartis sur l’ensemble des 240 SCs à une densité de 1 RE sur 4.

La figure ci-dessous représente la grille réelle du SSB avec les 240 sous-porteuses individuelles pour chacun des 4 symboles. Chaque colonne correspond à une sous-porteuse ; les repères verticaux délimitent les PRBs (12 SCs). La figure est donnée pour v = 0 (PCI mod 4 = 0).

Fig. 1a : Grille SSB pour v=0, DM-RS sur SCs 0, 4, 8, …, 236]

Fig. 1b : Grille SSB pour v=1, DM-RS sur SCs 1, 5, 9, …, 237]

Fig. 1c : Grille SSB pour v=2, DM-RS sur SCs 2, 6, 10, …, 238]

Fig. 1d : Grille SSB pour v=3, DM-RS sur SCs 3, 7, 11, …, 239]

Cartographie précise des RE : densité et décalage fréquentiel

Règle de base : densité 1/4 avec décalage v

Sur les symboles portant du PBCH (S1, S2 partiel, S3), les DM-RS sont placés à raison d’un RE tous les 4 sous-porteuses. Le premier RE est décalé d’un offset fréquentiel v dépendant du Physical Cell ID :

v = N_IDcell mod 4, avec v ∈ {0, 1, 2, 3}

Les indices des RE DM-RS sont donc : k = v, v+4, v+8, v+12, …, v+236, soit 60 RE de DM-RS par symbole PBCH plein.

Ce mécanisme sert deux objectifs : répartir uniformément les DM-RS entre cellules voisines pour limiter les interférences inter-cellules, et encoder partiellement le PCI dans la position fréquentielle même des pilotes.

Symboles S1 et S3 : PBCH plein

Les 240 sous-porteuses sont entièrement dédiées au PBCH. Les 60 RE de DM-RS se positionnent aux indices k = v, v+4, …, v+236. Les 180 RE restants transportent les données PBCH encodées.

Symbole S2 : SSS au centre, PBCH sur les bords

Les 127 sous-porteuses centrales (indices 56 à 182) sont occupées par le SSS. Les zones PBCH se trouvent sur les sous-porteuses 0 à 55 et 192 à 239. Les DM-RS suivent le même motif k = v + 4m mais uniquement dans ces zones PBCH. La zone SSS ne contient aucun DM-RS.

Référence 3GPP TS 38.211 §7.4.1.4.2 : la cartographie est définie par k = 4·m + v pour m = 0, 1, …, 59 sur les symboles PBCH complets (S1, S3). Pour S2, les indices k ∈ [56, 182] sont exclus.

Récapitulatif de la cartographie

  • S0 — 0 RE DM-RS. PSS + zéros uniquement.
  • S1 — 60 RE DM-RS. Sous-porteuses 0 à 239, pas de 4, décalage v. PBCH plein.
  • S2 — environ 24 RE DM-RS. Sous-porteuses 0–55 et 192–239 uniquement, pas de 4, décalage v. Zone SSS (56–182) exclue.
  • S3 — 60 RE DM-RS. Sous-porteuses 0 à 239, pas de 4, décalage v. PBCH plein.

Visualisation du décalage selon v

La figure ci-dessous montre les 24 premières sous-porteuses (2 PRBs) d’un symbole PBCH plein pour les 4 valeurs de v. Chaque cellule correspond à exactement une sous-porteuse. Le numéro inscrit dans les cellules bordeaux indique l’indice de SC portant un DM-RS.

Fig. 2 : Décalage DM-RS selon v = PCI mod 4, zoom sur SCs 0 à 23 (2 PRBs). Cellules rouge = DM-RS PBCH. Cellules orange= données PBCH. Le motif se répète identiquement sur les 240 SCs du SSB. Cellules bleue : SSS/PSS.

Génération de la séquence DM-RS

La séquence des symboles DM-RS est générée par un générateur Gold de longueur 31, initialisé par une valeur c_init incorporant plusieurs informations cellulaires (TS 38.211 §7.4.1.4.2).

L’index SSB : identifiant du faisceau reçu

La valeur centrale encodée dans c_init est i_SSB, l’index du SS/PBCH Block au sein de la demi-trame radio. Ce paramètre est fondamental : chaque SSB candidat porte une séquence DM-RS distincte, ce qui permet à l’UE d’identifier non seulement la cellule, mais aussi quel faisceau il reçoit.

En 5G NR, la gNB peut émettre jusqu’à L_max SSB candidats par demi-trame de 5 ms, chacun pouvant correspondre à une direction de faisceau différente (beam sweeping). L_max dépend de la bande de fréquence :

  • FR1 sub-3 GHz (< 3 GHz) — L_max = 4 : 2 bits LSB de l’index SSB encodés dans les DM-RS (ī_SSB mod 4). Le numéro de demi-trame n_hf vaut 0 ou 1 selon la demi-trame considérée.
  • FR1 mid-band (3–7,125 GHz) — L_max = 8 : 3 bits LSB de l’index SSB encodés dans les DM-RS (ī_SSB mod 8). n_hf est toujours 0.
  • FR2-1 mmWave (24,25–52,6 GHz) — L_max = 64 : seulement 3 bits LSB de l’index SSB dans les DM-RS. Les 3 bits de poids fort sont transportés dans le PBCH. n_hf est toujours 0.
  • FR2-2 mmWave (52,6–71 GHz) — L_max = 64 : même fonctionnement que FR2-1.

Note sur FR2 : avec L_max = 64, il faut 6 bits pour indexer tous les faisceaux. Les DM-RS n’encodent que les 3 bits de poids faible (ī_SSB mod 8). L’UE effectue une corrélation sur un ensemble fini et connu de 8 DM-RS possible (8 séquences de Gold possible). Les 3 bits de poids fort (bits 3–5) sont transportés dans le contenu du PBCH après décodage canal. L’UE combine les deux sources pour reconstituer l’index SSB complet sur 6 bits.

Construction de i_SSB selon L_max

Cas L_max = 4 (FR1 sub-3 GHz) :
ī_SSB = 2 bits LSB de l’index SSB physique, soit ī_SSB ∈ {0, 1, 2, 3}
i_SSB = ī_SSB + 4·n_hf, avec n_hf = 0 ou 1 selon la demi-trame
→ i_SSB ∈ {0, 1, 2, 3, 4, 5, 6, 7} sur les deux demi-trames

Cas L_max = 8 (FR1 mid-band) :
ī_SSB = 3 bits LSB, soit ī_SSB ∈ {0, …, 7}, n_hf = 0
i_SSB = ī_SSB

Cas L_max = 64 (FR2-1 et FR2-2) :
ī_SSB = 3 bits LSB, soit ī_SSB ∈ {0, …, 7}, n_hf = 0
i_SSB = ī_SSB dans les DM-RS ; bits 3–5 transportés dans le PBCH

Pour L_max = 4, la demi-trame est encodée implicitement : deux SSBs avec le même ī_SSB mais émis dans des demi-trames différentes ont des i_SSB différents (écart de 4) et donc des séquences DM-RS différentes. C’est ce qui permet à l’UE de distinguer les deux demi-trames de la trame radio de 10 ms et de reconstituer le SFN complet.

Formule d’initialisation c_init

Une fois i_SSB déterminé, la valeur d’initialisation du générateur Gold est :

c_init = 2¹¹ · (i_SSB + 1) · (⌊N_IDcell / 4⌋ + 1) + 2⁶ · (i_SSB + 1) + (N_IDcell mod 4)

Source : TS 38.211 §7.4.1.4.2, équation (7.4.1.4.2-1)

Cette formule intègre simultanément :

  • Le Physical Cell ID (N_IDcell ∈ [0, 1007]) via son quotient par 4 et son reste (= v)
  • L’index du SSB / faisceau (i_SSB) — chaque faisceau produit une séquence DM-RS unique à la fois en fréquence (via v) et en valeur des symboles QPSK (via c_init)
  • Implicitement le numéro de demi-trame (n_hf) pour L_max = 4

Génération des symboles complexes r(m)

Une fois c_init déterminé, deux séquences binaires x₁(n) et x₂(n) sont générées par récurrences polynomiales (registres à décalage sur GF(2)), puis combinées en une séquence de scrambling c(n). Les symboles complexes DM-RS sont :

r(m) = (1/√2) · (1 − 2·c(2m)) + j · (1/√2) · (1 − 2·c(2m+1))

Il s’agit d’une constellation QPSK à puissance unitaire normalisée. Chaque DM-RS est un symbole QPSK dont la phase est pseudo-aléatoire mais parfaitement reproductible par l’UE dès que celui-ci connaît N_IDcell, i_SSB et n_hf. L’UE compare les symboles reçus aux symboles attendus pour estimer la réponse en fréquence du canal sur les 60 RE pilotes, puis interpole pour démoduler les 180 RE PBCH.

Rôle dans la procédure de synchronisation cellulaire

La procédure de cell search d’un UE 5G NR suit la séquence suivante :

  1. Détection du PSS (symbole S0) : synchronisation à 5 ms et identification du groupe PCI (N_ID² ∈ {0, 1, 2}).
  2. Détection du SSS (symbole S2) : identification complète du PCI selon N_IDcell = 3·N_ID¹ + N_ID².
  3. Estimation de canal via les DM-RS PBCH (symboles S1, S2 partiel, S3) : v = PCI mod 4 est désormais connu, permettant de localiser précisément les 60 pilotes. Corrélation sur les i_SSB candidats pour identifier le faisceau reçu.
  4. Décodage du PBCH : extraction du MIB, SFN, timing, bande passante initiale. En FR2, récupération des 3 bits de poids fort de l’index SSB.

En corrélant le signal reçu avec les séquences candidates, l’UE extrait sans décodage canal : l’index du SSB / faisceau reçu (2 ou 3 bits LSB selon L_max) ; le numéro de demi-trame n_hf pour L_max = 4 permettant de reconstituer le SFN complet ; une indication partielle du PCI via la position fréquentielle des DM-RS (v = PCI mod 4). En FR2 (L_max = 64), les 3 bits de poids fort de l’index SSB sont obtenus après décodage du PBCH.

Conclusion

Le DM-RS PBCH est un élément discret mais fondamental du SS/PBCH Block en 5G NR. Son existence découle directement de la suppression du CRS de LTE. Sa cartographie — 60 RE par symbole PBCH plein, espacés de 4 sous-porteuses et décalés par v = PCI mod 4 — lui confère une double fonction dans le domaine fréquentiel. Dans le domaine temporel, la séquence elle-même varie selon i_SSB : chaque faisceau du SSB burst porte une signature DM-RS distincte, permettant à l’UE d’identifier précisément lequel des L_max faisceaux candidats il reçoit. En FR1 sub-3 GHz (L_max = 4), cette identification inclut aussi le numéro de demi-trame. En FR2 (L_max = 64), seuls 3 bits sur 6 sont dans les DM-RS, les 3 restants étant dans le PBCH. L’UE exploite ainsi la position des RE et la valeur des symboles pour s’ancrer temporellement, spatialement (faisceau) et cellulairement dans le réseau, avant d’avoir décodé un seul bit de données.

Références

  • 3GPP TS 38.211 — NR; Physical channels and modulation, §7.4.1.4 et §7.4.3
  • 3GPP TS 38.213 — NR; Physical layer procedures for control, §4
  • 3GPP TS 38.212 — NR; Multiplexing and channel coding
  • ShareTechnote — 5G PBCH DMRS

Pourquoi le SMF interroge‑t‑il à nouveau l’UDM lors de la création d’une session PDU en 5G

Posté le by - 97 vues
Répondre

Pourquoi le SMF interroge‑t‑il à nouveau l’UDM lors de la création d’une session PDU en 5G ?

🔍 Problématique :
Dans une procédure 5G Stand‑Alone, l’AMF contacte l’UDM pendant l’enregistrement de l’UE. Puis, lors de la création d’une session PDU, le SMF contacte à nouveau l’UDM avec le même service Nudm_SDM_Get. Pourquoi l’AMF ne transmet‑il pas directement les informations au SMF ?

Cet article détaille d’abord les deux procédures (enregistrement puis session PDU), puis répond à cette question fondamentale d’architecture 5G.

1. Rappel : les acteurs 5G (NF) et leurs rôles

  • UE : terminal mobile
  • gNB : station de base 5G
  • AMF : Access & Mobility Management Function – gestion de l’enregistrement et de la mobilité
  • UDM : Unified Data Management – base de données d’abonnement (profil utilisateur)
  • AUSF : Authentication Server Function – gestion de l’authentification
  • SMF : Session Management Function – création et contrôle des sessions PDU
  • UPF : User Plane Function – plan utilisateur (routage IP/GTP)
  • PCF : Policy Control Function – règles de QoS et de facturation
  • NRF : NF Repository Function – annuaire dynamique des NF
  • NSSF : Network Slice Selection Function – sélection des tranches réseau (slices)

2. Première procédure : l’enregistrement de l’UE (5G attachment)

L’UE doit d’abord se rendre visible auprès du réseau 5G. Cette procédure est décrite dans la 3GPP TS 23.502 §4.2.2.2.

Étapes simplifiées (celles qui nous intéressent) :

  1. UE → gNB → AMF : Registration Request (avec SUCI, Requested NSSAI)
  2. AMF → NRF : découverte d’une AUSF
  3. AMF → AUSF → UDM : authentification 5G‑AKA (échange de clés)
  4. AMF → UE : Security Mode Command (protection NAS activée)
  5. AMF → UDM : Nudm_SDM_Get (type Access and Mobility Subscription Data)

Que récupère l’AMF ?

  • AM Policy (règles de mobilité)
  • S‑NSSAI autorisées (tranches réseau)
  • GPSI (MSISDN ou email)
  • Restrictions de zone / RAT
  • UE‑AMBR (débit maximal)

L’AMF ne voit absolument pas les données de session (DNN, QoS, IP statique…).

3. Deuxième procédure : création d’une session PDU

Une fois l’UE enregistré, il peut demander une connexion à un réseau de données (ex. internet). Procédure TS 23.502 §4.3.2.

Étapes simplifiées :

  1. UE → AMF : PDU Session Establishment Request (DNN, S‑NSSAI, type PDU)
  2. AMF → NRF : sélection d’une SMF supportant ce DNN et cette S‑NSSAI
  3. AMF → SMF : Nsmf_PDUSession_CreateSMContext (transmet SUPI, DNN, localisation…)
  4. 🔑 SMF → UDM : Nudm_SDM_Get (type Session Management Subscription Data)
  5. SMF → PCF : récupération des PCC rules
  6. SMF → UPF : établissement du tunnel PFCP (N4)
  7. SMF → AMF → gNB → UE : configuration radio et acceptation de la session

4. Le cœur du problème : deux appels Nudm_SDM_Get différents

Le service Nudm_SDM_Get est générique. Il permet à une NF de demander un type spécifique de données d’abonnement.

Qui appelle ? Quand ? Type de données demandé Données retournées (exemples)
AMF Enregistrement Access and Mobility Subscription Data S‑NSSAI, GPSI, AM Policy, restrictions mobilité
SMF Création session PDU Session Management Subscription Data Configuration DNN, QoS, SSC Mode, adresse IP statique

L’AMF n’a donc jamais reçu les données que le SMF demande. Il ne peut pas les lui transmettre.

5. Pourquoi l’architecture 5G a‑t‑elle été conçue ainsi ?

Trois raisons fondamentales (TS 23.501) :

  •  Séparation des responsabilités (CUPS)
    L’AMF gère la mobilité, le SMF gère les sessions. Chacun ne doit voir que ce dont il a besoin (principe du moindre privilège).
  •  Volume de données
    Un abonnement peut contenir des dizaines de DNN avec des configurations QoS complexes. Charger l’AMF avec tout cela serait inefficace.
  •  Confidentialité
    Certaines données (adresse IP statique, clés de facturation) ne concernent que le SMF et le PCF, pas l’AMF.

6. Ce que l’AMF transmet réellement au SMF

Lors de l’étape Nsmf_PDUSession_CreateSMContext, l’AMF donne au SMF :

  • SUPI (identifiant de l’abonné)
  • DNN et S‑NSSAI demandés
  • PDU Session ID
  • Localisation de l’UE (TAI, cellule)
  • RAT Type

Aucune donnée d’abonnement de session n’est transmise. Le SMF va donc les chercher lui‑même auprès de l’UDM.

7. Schéma récapitulatif

[UE] --Registration--> [AMF] --Nudm_SDM_Get(Access&Mobility)--> [UDM]
                            │
                            │ (données mobilité)
                            ▼
                        S‑NSSAI, GPSI, AM Policy

[UE] --PDU Session--> [AMF] --CreateSMContext--> [SMF] --Nudm_SDM_Get(Session)--> [UDM]
                                                                 │
                                                                 ▼
                                                     DNN, QoS, SSC Mode, IP statique

8. Conclusion

Le SMF refait un Nudm_SDM_Get à l’UDM non pas par redondance, mais par nécessité fonctionnelle :

  • L’AMF ne récupère que les données de mobilité.
  • Le SMF récupère les données de session PDU.
  • L’AMF ne peut transmettre au SMF ce qu’il ne possède pas.

Cette séparation est un choix délibéré de la 3GPP pour garantir une architecture modulaire, sécurisée et scalable.

Références : 3GPP TS 23.501, TS 23.502, TS 29.503.
📚 Article basé sur le support de cours “5G Stand‑Alone (SA) – Procédure d’enregistrement & création de session PDU” – Université de Poitiers.

6G et réseaux AI-native : vers une connectivité intelligente et autonome

Posté le by - 145 vues
Répondre

L’article précédent a permis de donner une définition simple de l’IA native. Nous allons maintenant reprendre l’évolution des réseaux vers la 6G-native.

Introduction

Alors que la 5G continue de se déployer à l’échelle mondiale, la recherche sur la 6G est déjà bien engagée. Cette future génération de réseaux mobiles ne se contentera pas d’améliorer les performances en termes de débit ou de latence : elle introduira une transformation bien plus profonde. Au cœur de cette évolution se trouve un concept clé : celui de réseau “AI-native”, où l’intelligence artificielle devient une composante fondamentale de l’architecture réseau.

Cet article propose d’explorer cette notion et de comprendre en quoi elle redéfinit la manière dont les réseaux sont conçus, exploités et optimisés.

De la 5G à la 6G : un changement de paradigme

Les réseaux actuels, y compris la 5G, intègrent déjà des mécanismes d’intelligence artificielle. On parle alors de réseaux “AI-enabled” (assistés par l’IA). Dans ces systèmes, l’IA est utilisée pour améliorer certaines fonctions spécifiques, comme :

  1. la prédiction des congestions,
  2. l’optimisation des handovers,
  3. ou la gestion du trafic.

Cependant, le fonctionnement global du réseau reste basé sur des règles définies par des ingénieurs. L’IA agit comme un outil d’optimisation, mais elle n’est pas indispensable au fonctionnement du système.

Avec la 6G, cette logique change radicalement.

Le concept de réseau AI-native

Un réseau AI-native est conçu dès l’origine pour intégrer l’intelligence artificielle à tous les niveaux de son fonctionnement. L’IA n’est plus un module ajouté a posteriori : elle est une propriété intrinsèque du réseau.

Concrètement, cela signifie que :

  • des algorithmes d’apprentissage sont présents à tous les niveaux (du terminal utilisateur jusqu’au cœur de réseau),
  • les décisions sont prises de manière dynamique et autonome,
  • les données sont exploitées en continu pour adapter le comportement du réseau.

Dans un tel système, certaines fonctions critiques reposent entièrement sur l’IA, sans solution de secours basée sur des règles fixes.

Une intelligence distribuée et collaborative

Contrairement à une idée reçue, un réseau AI-native ne repose pas sur une intelligence centralisée unique. L’intelligence y est distribuée et hiérarchisée :

  • au niveau des appareils (edge), pour des décisions ultra-rapides,
  • au niveau des stations de base ou des clouds en périphérie,
  • au niveau central (cœur de réseau et data centers), pour des optimisations globales.

Ces différentes instances d’IA collaborent entre elles. Par exemple, des appareils peuvent effectuer des inférences locales à très faible latence, tandis que des systèmes centraux agrègent les données pour entraîner des modèles globaux. Ce type de coopération s’inscrit dans des approches comme l’apprentissage fédéré.

Le rôle essentiel de l’écosystème de gestion de l’IA

Pour fonctionner efficacement, un réseau AI-native nécessite une infrastructure dédiée à la gestion de l’intelligence artificielle. Cela inclut notamment :

  • des mécanismes d’orchestration pour déployer et mettre à jour les modèles,
  • des systèmes de collecte et de gestion des données,
  • des outils de suivi des performances.

Cette couche, parfois appelée “plan de gestion de l’IA”, est essentielle pour garantir la cohérence, la fiabilité et l’évolutivité du réseau. Sans elle, la multiplication des modèles d’IA entraînerait un système difficile à contrôler.

L’apprentissage en boucle fermée : vers l’autonomie

Un des piliers des réseaux AI-native est le fonctionnement en boucle fermée. Le réseau :

  1. observe en continu son environnement (trafic, conditions radio, usages),
  2. analyse ces données grâce à l’IA,
  3. ajuste automatiquement ses paramètres,
  4. et répète ce cycle en permanence.

Ce processus se déroule à différentes échelles de temps :

  • en millisecondes pour les ajustements radio,
  • en minutes pour la gestion du trafic,
  • en heures pour des optimisations globales.

L’objectif est de créer un réseau capable de s’adapter en temps réel, sans intervention humaine constante.

Gouvernance et contrôle humain

Malgré ce haut niveau d’autonomie, les réseaux AI-native ne sont pas totalement indépendants des humains. Les opérateurs jouent toujours un rôle clé en définissant :

  • des objectifs,
  • des politiques,
  • et des contraintes.

On parle ici de “réseaux basés sur l’intention” : les humains spécifient ce qu’ils veulent (par exemple, garantir une certaine latence), et l’IA détermine comment atteindre ces objectifs.

AI-native vs “network for AI”

Il est important de distinguer les réseaux AI-native des réseaux simplement conçus pour supporter des applications d’IA. La 6G offrira effectivement des capacités avancées (haut débit, edge computing) pour des usages comme :

  • la réalité augmentée,
  • la robotique connectée,
  • les systèmes autonomes.

Mais ces capacités relèvent du concept de “network for AI”. Un réseau AI-native, lui, concerne l’intelligence intégrée dans le fonctionnement interne du réseau.

Conclusion

La 6G marque une évolution majeure dans l’histoire des réseaux de télécommunications. En intégrant l’intelligence artificielle comme élément central de leur architecture, les réseaux AI-native promettent un niveau d’autonomie, d’adaptabilité et d’efficacité inédit.

Ces réseaux ne se contenteront plus de transporter des données : ils deviendront des systèmes intelligents capables de percevoir, d’apprendre et d’agir de manière coordonnée. Cette transformation ouvre la voie à une nouvelle génération de services et d’applications, tout en posant des défis importants en matière de gouvernance, de sécurité et de confiance.

La 6G ne sera pas seulement plus rapide. Elle sera, avant tout, plus intelligente.

Si vous avez besoin de comprendre la transition vers la 6G, je propose une formation de 2,5 jours sur l’évolution des réseaux 4G vers la 6G et une formation de 2 jours sur la 6G. Si vous êtes intéressés, contactez moi frederic.launay@univ-poitiers.fr

 

6G IA native

Posté le by - 112 vues
Répondre

Définition d’un réseau AI-natif

1 Qu’est-ce que l’AI-natif ?

Un réseau AI-natif est un réseau dans lequel l’intelligence n’est pas une application externe ou un outil d’optimisation, mais une propriété native de l’architecture et des opérations du réseau. En pratique, cela signifie que les algorithmes d’IA et les fonctions d’apprentissage sont intégrés à toutes les couches et domaines du réseau, depuis l’interface radio jusqu’au cœur, depuis les appareils utilisateurs jusqu’aux serveurs cloud. Le réseau est conçu, dès la phase de conception, pour exploiter les données et la prise de décision basée sur l’IA à chaque opportunité.

Lors de la journée France6G, organisée par Hakima Chaouchi le 20 mars 2026, Dorin Panaitopol (Thales) a présenté une architecture 5G-NTN avec une vision 6G et une intégration de l’IA à tous les niveaux, même satellitaire.

Dans un réseau 5G AI-assisté, si l’on retire le modèle d’apprentissage automatique qui optimise les paramètres de handover, le réseau continue de fonctionner. Dans un réseau 6G AI-natif, certaines boucles de contrôle et optimisations n’ont pas d’algorithme de repli déterministe, parce qu’elles sont conçues pour être gérées par des agents IA en apprentissage continu.

2 Caractéristiques clés d’un réseau AI-natif

  • Intelligence distribuée et hiérarchique : des agents IA au niveau des appareils (edge), des stations de base, des clouds de périphérie et des centres de données centraux, tous coordonnés de manière cohérente.
  • Apprentissage fédéré : les instances d’IA collaborent et fédèrent leur apprentissage sans centraliser les données brutes, préservant ainsi la confidentialité.
  • Boucle fermée autonome : le réseau capte en continu les données de télémesure, les alimente dans des algorithmes d’apprentissage, et ajuste de manière autonome les configurations ou politiques réseau.
  • Écosystème de support IA intégré : orchestration des modèles, cycle de vie (entraînement, déploiement, surveillance, retrait), gestion des données et référentiel de connaissances.
  • Interfaces basées sur des intentions (Intent-Based) : les opérateurs formulent des objectifs de haut niveau (« assurer une latence vidéo < 20 ms pour cet événement »), et les agents IA déterminent comment les atteindre.

Conclusion

Un réseau AI-natif ne désigne pas simplement un réseau qui offre un bon support pour les applications IA (c’est un concept complémentaire souvent formulé comme « réseaux pour l’IA »). Il ne signifie pas non plus « entièrement autonome dans l’absolu » : les humains conservent la définition des objectifs, politiques et contraintes. En revanche, l’IA détermine les moyens de les satisfaire, sans intervention manuelle sur les contrôles de bas niveau.

 

Posté le by - 115 vues
Répondre

 

eRedCap : L’évolution de la 5G pour l’IoT à coût réduit

Introduction

eRedCap (enhanced Reduced Capability) a été introduit dans la Release 18,et vient compléter RedCap pour offrir une connectivité 5G encore plus économique et efficace énergétiquement.

Contexte et motivations

Le continuum des technologies cellulaires IoT

L’écosystème 5G propose désormais un continuum de technologies adaptées aux différents besoins :

  • NB-IoT et LTE-M : Technologies LPWAN (Low-Power Wide-Area Network) pour les communications à très faible débit
  • RedCap (Release 17) : Dispositifs à capacités réduites remplaçant les catégories LTE Cat-2/3/4
  • eRedCap (Release 18) : Dispositifs à capacités encore plus réduites ciblant les catégories LTE Cat-1/1bis

eRedCap

Suite à l’introduction de RedCap dans la Release 17 en 2022, le 3GPP a mené une étude approfondie qui a révélé qu’un débit plafonné à 10 Mbps serait suffisant pour de nombreux cas d’usage IoT. Cette constatation a conduit à la spécification d’eRedCap dans la Release 18, finalisée en juin 2024, avec pour objectif de créer un nouveau type de dispositif encore plus économique tout en préservant les avantages fondamentaux de la 5G.

Caractéristiques techniques d’eRedCap

Simplifications principales

eRedCap introduit plusieurs simplifications par rapport à RedCap et à la 5G NR standard :

1. Limitation du débit de pointe

La caractéristique la plus distinctive d’eRedCap est le plafonnement du débit à 10 Mbps en liaison descendante (downlink) et montante (uplink), indépendamment des autres fonctionnalités optionnelles supportées par le dispositif. Cette approche diffère de RedCap, où le débit dépend des choix de conception (nombre d’antennes, bande passante).

2. Bande passante flexible

Principe de la double bande passante

L’une des innovations les plus significatives introduites par eRedCap dans la 3GPP Release 18 réside dans son architecture de bande passante hybride, qui dissocie intelligemment deux aspects complémentaires du système radio :

2.1 La bande passante RF (RadioFréquence) : 20 MHz

La partie radiofréquence (frontend RF) du dispositif eRedCap maintient une capacité de 20 MHz, identique à RedCap. Cette caractéristique n’est pas anodine : elle permet au dispositif de recevoir et de décoder l’ensemble du spectre de 20 MHz utilisé par la station de base pour transmettre les signaux de contrôle et d’information système.

Concrètement, cela signifie que le dispositif eRedCap peut :

  • Recevoir les canaux de diffusion (PBCH – Physical Broadcast Channel)
  • Décoder les signaux de synchronisation (PSS/SSS – Primary/Secondary Synchronization Signals)
  • Lire les informations système (SIB – System Information Blocks)
  • Traiter les canaux de contrôle (PDCCH – Physical Downlink Control Channel)

Ces signaux de contrôle et de synchronisation, spécifiés dans les releases précédentes de la 5G NR, occupent des positions fixes dans la bande passante de 20 MHz. En maintenant cette capacité RF complète, eRedCap assure une rétrocompatibilité totale avec l’infrastructure réseau 5G existante.

2.2. La bande passante des canaux de données : 5 MHz (option réduite)

Parallèlement, la Release 18 introduit la possibilité pour un dispositif eRedCap de limiter la bande passante utilisée spécifiquement pour les canaux de données (PDSCH en downlink et PUSCH en uplink) à environ 5 MHz. Cette limitation se traduit par une restriction du nombre de PRB (Physical Resource Blocks) alloués pour la transmission des données utilisateur.

Pour un dispositif eRedCap configuré avec une bande passante de données réduite :

  1. Frontend RF complet (20 MHz) : Le dispositif maintient la capacité de recevoir sur toute la bande de 20 MHz
    • Filtre RF : 20 MHz
    • Convertisseur analogique-numérique (ADC) : fréquence d’échantillonnage correspondant à 20 MHz
    • FFT (Fast Fourier Transform) initiale : taille correspondant à 20 MHz
  2. Traitement des canaux de contrôle : Sur les 20 MHz complets
    • Détection et décodage du PDCCH
    • Réception des SIB et messages de paging
    • Synchronisation et estimation de canal
  3. Traitement des canaux de données : Limité à ~25 PRB (≈ 5 MHz)
    • L’allocation de ressources (Resource Allocation) est restreinte
    • Le traitement en bande de base (égalisation, démodulation, décodage canal) ne s’applique que sur ces 25 PRB
    • La complexité de traitement est proportionnellement réduite

3. Réduction du nombre d’antennes

Comme RedCap, eRedCap peut fonctionner avec :

  • 1 branche de réception (1Rx) : supportant 1 couche MIMO en liaison descendante
  • 2 branches de réception (2Rx) : supportant 2 couches MIMO en liaison descendante
  • 1 antenne d’émission : pas de diversité ou MIMO en liaison montante

Cette réduction du nombre d’antennes (comparé aux 4 antennes minimales de la 5G NR standard) permet de concevoir des dispositifs beaucoup plus compacts.

4. Modulation simplifiée

eRedCap rend obligatoire uniquement la modulation 64QAM (contre 256QAM ou même 1024QAM pour la 5G NR standard). Cette simplification réduit les exigences de traitement et permet au dispositif de fonctionner dans des conditions de canal moins favorables.

5. Optimisations énergétiques avancées

La Release 18 améliore considérablement les mécanismes d’économie d’énergie :

  • eDRX étendu (extended Discontinuous Reception) : cycles de réception discontinue encore plus longs que dans la Release 17, permettant d’atteindre une autonomie de batterie de plusieurs années pour les capteurs industriels et les objets connectés portables
  • Cycles eDRX supérieurs à 10,24 secondes : pour les dispositifs en état RRC inactif
  • Optimisations de couche physique : réduction de la consommation en mode veille et actif

Architecture réseau

eRedCap s’appuie exclusivement sur l’architecture 5G Standalone (SA), ce qui permet de bénéficier de fonctionnalités avancées :

  • Network slicing : isolation et garanties de qualité par tranche réseau
  • URLLC (Ultra-Reliable Low-Latency Communications) : pour les applications critiques
  • API natives cloud : intégration facilitée avec les plateformes IT
  • Orchestration native cloud : déploiement et gestion automatisés

Cas d’usage d’eRedCap

Applications industrielles

Capteurs industriels sans fil eRedCap est particulièrement adapté aux capteurs de surveillance d’équipements, de température, de vibrations ou de qualité environnementale dans les usines. Le débit de 10 Mbps est largement suffisant pour transmettre des données de télémétrie, tandis que la faible consommation énergétique permet des déploiements sur batterie durant plusieurs années.

Automatisation industrielle Dans les environnements de production, eRedCap permet la connexion de dispositifs de contrôle-commande ne nécessitant pas de latence ultra-faible mais requérant une connexion fiable et sécurisée.

Ville intelligente et santé connectée

Compteurs intelligents Les réseaux électriques intelligents peuvent utiliser eRedCap pour la télémétrie des sous-stations et l’automatisation de la distribution, bénéficiant particulièrement du profil de trafic orienté liaison montante.

Dispositifs médicaux portables Les moniteurs de santé, capteurs physiologiques et dispositifs de télésurveillance médicale représentent un marché majeur pour eRedCap. Ces dispositifs nécessitent une connexion fiable mais avec des débits modérés, tout en étant extrêmement contraints en termes de taille et d’autonomie.

Infrastructure urbaine Éclairage public connecté, gestion des déchets, surveillance environnementale : autant d’applications où eRedCap offre un excellent compromis entre performance et coût.

Objets connectés grand public

Wearables et accessoires connectés Montres connectées, trackers d’activité, vêtements intelligents et dispositifs de localisation bénéficient de la compacité et de l’efficacité énergétique d’eRedCap.

Terminaux point de vente (POS) Dans le secteur de la distribution, les terminaux de paiement mobiles et caisses enregistreuses sans fil constituent un cas d’usage privilégié.

Comparaison avec les autres technologies

eRedCap vs RedCap

Caractéristique RedCap (Rel-17) eRedCap (Rel-18)
Débit DL Jusqu’à 226 Mbps 10 Mbps (plafonné)
Débit UL Jusqu’à 120 Mbps 10 Mbps (plafonné)
Bande passante RF 20 MHz (FR1), 100 MHz (FR2) 20 MHz (FR1 uniquement)
Bande passante données 20 MHz 5 MHz ou 20 MHz
Équivalent LTE Cat-2/3/4 Cat-1/1bis
Réduction complexité ~65% (FR1) ~70%

eRedCap vs LTE Cat-1/1bis

eRedCap offre plusieurs avantages par rapport à LTE Cat-1/1bis :

  • Architecture end-to-end 5G native
  • Accès au spectre 5G (bandes FR1)
  • Gestion QoS améliorée et network slicing
  • Latence réduite
  • Efficacité spectrale supérieure
  • Support de VoNR (Voice over NR)
  • Sécurité renforcée (authentification basée SIM, chiffrement fort)

Déploiement et écosystème

Compatibilité dual-mode

Les spécifications eRedCap facilitent les implémentations dual-mode supportant à la fois 4G (Cat-1/1bis) et 5G (eRedCap), grâce à l’alignement des exigences matérielles. Cette caractéristique permet une migration progressive et économique de la 4G vers la 5G.

Calendrier de disponibilité

  • 2022 : Introduction de RedCap (Release 17)
  • Juin 2024 : Finalisation des spécifications eRedCap (Release 18)
  • 2025-2026 : Déploiements commerciaux des premiers dispositifs eRedCap
  • 2030 : Projections indiquent qu’eRedCap pourrait représenter jusqu’à 8% des modules IoT cellulaires

Perspectives et évolutions futures

Release 19 et au-delà

Le 3GPP poursuit l’évolution d’eRedCap dans les releases suivantes :

  • Wake-up receiver : récepteur de réveil ultra-basse consommation pour optimiser davantage l’efficacité énergétique
  • Améliorations de couverture : techniques avancées pour étendre la portée
  • Optimisations pour réseaux privés : fonctionnalités spécifiques aux campus industriels

Vers la 6G

eRedCap fait partie de la 5G-Advanced et constitue une brique fondamentale de la transition vers la 6G. Les concepts d’optimisation de complexité et de différenciation des classes de dispositifs développés pour eRedCap influenceront les futures générations de technologies cellulaires.

Enjeux et défis

Plusieurs défis subsistent pour une adoption massive d’eRedCap :

  • Scalabilité : gestion d’un grand nombre de dispositifs eRedCap tout en maintenant la qualité de service
  • Coexistence : optimisation du partage de ressources entre dispositifs eRedCap et 5G NR haute performance
  • Standardisation continue : coordination avec l’évolution des use cases industriels
  • Écosystème de modules : développement d’une offre diversifiée et compétitive

Conclusion

eRedCap représente une avancée majeure dans l’écosystème 5G, comblant le fossé entre les technologies LPWAN (NB-IoT, LTE-M) et les dispositifs 5G haute performance. En offrant un débit de 10 Mbps avec une complexité réduite de 70% par rapport à la 5G NR standard, eRedCap ouvre la voie à une nouvelle génération de dispositifs IoT 5G économiques, compacts et énergétiquement efficaces.

Cette technologie permet la migration des catégories LTE Cat-1/1bis vers la 5G tout en bénéficiant de l’architecture 5G Standalone et de ses fonctionnalités avancées (network slicing, faible latence, sécurité renforcée). Avec un calendrier de déploiement commercial prévu pour 2026 et des projections optimistes pour 2030, eRedCap est appelé à jouer un rôle central dans la transformation numérique industrielle et l’expansion massive de l’IoT cellulaire.

L’alignement des exigences matérielles avec LTE Cat-1/1bis facilite les implémentations dual-mode et assure une transition en douceur pour les fabricants de dispositifs. Couplé aux améliorations continues du 3GPP dans les releases futures, eRedCap constitue une solution pérenne et évolutive pour répondre aux besoins diversifiés de connectivité de l’ère IoT 5G.

Références 3GPP :

  • TS 38.306 : UE radio access capabilities
  • TS 38.300 : NR overall description
  • Release 17 : Spécifications RedCap
  • Release 18 : Spécifications eRedCap (finalisées juin 2024)

Les Réseaux Autonomes : Appréhender une évolution vers la 6G

Posté le by - 369 vues
Répondre

La Transformation Digitale des Réseaux

Cet article vous propose de découvrir cette évolution majeure qui va redéfinir la manière dont les opérateurs télécoms gèrent leurs infrastructures et répondre principalement à ces deux questions :

  1. Comment les réseaux peuvent-ils devenir « autonomes »
  2. Quel rôle joue l’Intelligence Artificielle dans cette transformation ?

Le Contexte : Des Réseaux Entièrement Numériques

Aujourd’hui, les réseaux de communications sont quasiment tous numériques et basés sur l’IP (par exemple, nous avons assisté au déploiement de la TNT et actuellement au DAB+). Les opérateurs interagissent entre eux et avec leur client via des solutions SDWAN.

Ces réseaux transportent du contenu numérisé et la transmission s’appuie sur des protocoles de signalisation numérique.

Dans ce contexte, les Réseaux Autonomes représentent la prochaine étape logique. L’objectif est ambitieux : capturer une connaissance détaillée et en temps réel du réseau pour intégrer le contrôle directement dans son comportement natif. Autrement dit, faire en sorte que le réseau puisse se gérer lui-même, de manière autonome.

Les 5 Niveaux d’Autonomie : Une Progression vers l’Intelligence

Le TM Forum [1] a défini un cadre structuré autour de 5 niveaux d’autonomie. Comprendre ces niveaux permet de mesurer où nous en sommes et vers quoi nous nous dirigeons.

Niveau 0 : Gestion Manuelle

À ce stade, il n’y a aucune automation. Tout est géré manuellement par les opérateurs humains : configurations, interventions, modifications. C’est lent, coûteux et sujet aux erreurs. Heureusement, ce niveau appartient de plus en plus au passé.

Niveau 1 : Automation Assistée

Les premières briques d’automation apparaissent. Quelques tâches répétitives sont automatisées grâce à des scripts simples, mais toujours sous supervision humaine. L’opérateur décide, le système exécute. On commence à gagner en efficacité, mais le potentiel reste limité.

Niveau 2 : Automation Partielle

L’automation s’étend à des domaines spécifiques du réseau avec l’introduction de systèmes en boucle fermée. Le réseau peut analyser certaines situations et prendre des décisions dans des périmètres bien définis. C’est ici qu’apparaissent les premiers réseaux auto-organisants (SON – Self-Organizing Networks) dans le domaine radio, capables d’optimiser automatiquement certains paramètres ou de se « guérir » face à des problèmes connus.

Niveau 3 : Autonomie Conditionnelle

Nous entrons dans une dimension nouvelle : l’automation devient cross-domaine. Le système peut gérer de manière autonome plusieurs domaines du réseau et prendre des décisions complexes. L’Intelligence Artificielle et le Machine Learning font leur apparition pour prédire les comportements et optimiser les performances. L’opérateur ne définit plus comment faire, mais ce qu’il veut obtenir : on parle alors de pilotage par intention (intent-based networking).

Niveau 4 : Haute Autonomie

Le réseau devient largement autonome avec une intelligence cognitive avancée. Il s’auto-optimise en continu, s’auto-guérit de manière sophistiquée, et s’adapte dynamiquement aux conditions changeantes. L’opérateur définit simplement les objectifs business, et le réseau se gère lui-même pour les atteindre. C’est ce niveau que visent actuellement les opérateurs, car c’est là que se trouvent les gains les plus significatifs.

Niveau 5 : Autonomie Complète

La vision ultime : une autonomie totale du réseau dans tous les domaines et toutes les situations. Le réseau possède une capacité cognitive complète, apprend en continu, anticipe les besoins futurs et s’adapte même à des situations jamais rencontrées. Le rôle humain devient minimal, se concentrant sur la stratégie globale et les principes éthiques. Cette vision à long terme n’est pas encore atteinte, mais elle guide les développements actuels.

Le Rôle Central de l’Intelligence Artificielle

Une précision importante s’impose : conceptuellement, les Réseaux Autonomes n’impliquent pas nécessairement l’Intelligence Artificielle. Les concepts fondamentaux sont indépendants :

  • Les capacités Self-X (auto-configuration, auto-optimisation, auto-guérison)
  • Les boucles fermées (Closed Loop) qui permettent au système d’observer, décider et agir
  • Le pilotage par intention (Intent-driven)
  • L’intelligence réseau distribuée

Cependant, dans la pratique, l’IA représente un catalyseur extraordinaire pour accélérer la progression vers l’autonomie complète. Sans IA, atteindre les niveaux 4 et 5 serait extrêmement difficile, voire impossible. L’apprentissage automatique permet notamment de :

  • Analyser des volumes massifs de données en temps réel
  • Détecter des patterns complexes invisibles à l’œil humain
  • Prédire les pannes avant qu’elles ne surviennent
  • Optimiser automatiquement des milliers de paramètres simultanément
  • Adapter le réseau à des situations nouvelles jamais programmées

L’Intent-Based Networking : Parler Business, Pas Technique

Au cœur des Réseaux Autonomes se trouve un changement de paradigme fondamental incarné par l’Intent-Based Networking (IBN), ou réseau piloté par intention.

Le Changement de Perspective

Traditionnellement, un opérateur devait spécifier précisément comment configurer le réseau :

« Configure le VLAN 100 sur les ports 1-24, active la QoS avec priorité 5, configure le routage OSPF avec area 0, ajuste les paramètres de bande passante à 10 Gbps… »

Avec l’approche Intent-Based, l’opérateur exprime simplement ce qu’il veut obtenir :

« Je veux que l’application vidéo du service client ait une latence inférieure à 50ms et une disponibilité de 99,9% »

Le système se charge ensuite automatiquement de traduire cette intention en configurations techniques concrètes sur tous les équipements concernés.

Les Quatre Piliers de l’IBN

Un système Intent-Based repose sur quatre composantes essentielles :

1. La Traduction
Le système traduit les intentions de haut niveau (souvent exprimées en termes business) en configurations techniques détaillées. Une intention comme « assurer une connectivité sécurisée entre le site A et le datacenter B » se transforme automatiquement en VPN, règles de pare-feu, QoS, routage et chiffrement.

2. L’Activation
Une fois la traduction effectuée, le système configure automatiquement tous les équipements nécessaires : routeurs, switches, pare-feu, mais aussi ressources cloud et fonctions virtualisées.

3. Le Monitoring Continu
Le système surveille en permanence que l’intention est bien respectée. Il mesure les indicateurs clés (latence, débit, disponibilité) et détecte toute dérive par rapport à l’objectif fixé.

4. L’Assurance et l’Auto-correction
Si l’intention n’est plus respectée, le système se corrige automatiquement : réoptimisation des chemins réseau, allocation dynamique de ressources, auto-guérison en cas de panne.

Un Exemple Concret : Le Network Slicing 5G

Imaginons qu’un opérateur veuille créer un service pour les véhicules connectés. Avec l’approche Intent-Based, il exprime simplement son intention :

« Créer un network slice pour véhicules connectés avec une ultra-faible latence (< 10ms), une haute fiabilité (99,999%), une isolation totale du trafic, et une couverture sur les autoroutes de la zone Sud »

Le système Intent-Based va alors automatiquement :

  • Allouer les ressources radio nécessaires (RAN slicing)
  • Configurer le cœur de réseau dédié (Core slicing)
  • Mettre en place la QoS end-to-end
  • Assurer l’isolation et la sécurité
  • Activer un monitoring spécifique pour vérifier en permanence que les objectifs sont atteints

Tout cela sans que l’opérateur n’ait eu à configurer manuellement des milliers de paramètres sur des centaines d’équipements.

Les Bénéfices Business : Pourquoi Investir dans l’Autonomie ?

Une enquête récente menée auprès des principaux opérateurs télécoms révèle que l’objectif prioritaire est d’atteindre le niveau 4 d’autonomie. Pourquoi cet engouement ? Parce que c’est à ce niveau que se trouvent les gains business les plus significatifs :

Réduction des Coûts Opérationnels

L’automation avancée permet de réduire drastiquement les coûts d’exploitation. Moins d’interventions manuelles signifie moins d’erreurs, moins de temps perdu, et des équipes qui peuvent se concentrer sur des tâches à plus forte valeur ajoutée plutôt que sur des opérations répétitives.

Amélioration de la Durabilité

Les Réseaux Autonomes optimisent en permanence la consommation énergétique. L’IA peut, par exemple, désactiver temporairement des cellules radio peu utilisées, ajuster les puissances d’émission, ou optimiser les flux de climatisation dans les datacenters. Dans un contexte où la sobriété énergétique devient cruciale, ces gains sont essentiels.

Nouveaux Services et Agilité

La capacité à déployer rapidement de nouveaux services devient un avantage compétitif majeur. Avec l’Intent-Based Networking, ce qui prenait des semaines de configuration peut se faire en quelques minutes. Les opérateurs peuvent ainsi répondre plus rapidement aux demandes de leurs clients entreprises et proposer des services innovants.

Amélioration de l’Expérience Client

Un réseau qui s’auto-optimise en permanence, qui prévoit les pannes avant qu’elles n’affectent les utilisateurs, et qui s’adapte automatiquement à la charge, c’est l’assurance d’une meilleure qualité de service. L’expérience utilisateur s’améliore sans que le client ne s’en rende compte.

Les Technologies Clés à Maîtriser

Pour réaliser cette vision des Réseaux Autonomes, plusieurs briques technologiques doivent converger :

  • L’Intelligence Artificielle et le Machine Learning : pour l’analyse prédictive, l’optimisation et la prise de décision
  • Les boucles fermées (Closed-Loop Automation) : pour observer, décider et agir de manière autonome
  • SDN et NFV : pour rendre le réseau programmable et flexible
  • La télémétrie en temps réel : pour avoir une vision précise et instantanée du réseau
  • L’orchestration multi-domaine : pour coordonner tous les éléments du réseau

Où en Sommes-nous Aujourd’hui ?

La majorité des opérateurs se situent actuellement entre les niveaux 1 et 2 d’autonomie. Les investissements se concentrent massivement sur l’atteinte des niveaux 3 et 4, où se trouvent les gains les plus importants. Le niveau 5 reste une vision à long terme, mais il guide dès aujourd’hui les choix technologiques et architecturaux.

La progression n’est pas linéaire. Certains domaines du réseau peuvent atteindre un niveau d’autonomie élevé (par exemple, l’optimisation radio) tandis que d’autres restent plus manuels. L’objectif est d’harmoniser progressivement l’ensemble vers une autonomie cross-domaine.

Conclusion : Une Révolution en Marche

Les Réseaux Autonomes ne sont pas une simple évolution technologique : ils représentent un changement profond dans la manière de concevoir, d’exploiter et de gérer les infrastructures de télécommunications. En libérant les opérateurs de tâches manuelles complexes, en optimisant continuellement les performances, et en permettant une agilité sans précédent, ils ouvrent la voie à une nouvelle ère des télécommunications.

L’Intelligence Artificielle joue un rôle de catalyseur essentiel dans cette transformation, même si elle n’est pas conceptuellement indispensable aux principes d’autonomie. Couplée au pilotage par intention, elle permet aux opérateurs de se concentrer sur leurs objectifs business plutôt que sur les détails techniques de mise en œuvre.

La route vers l’autonomie complète (niveau 5) est encore longue, mais le chemin est tracé. Les bénéfices observés dès le niveau 4 justifient amplement les investissements actuels. Dans les années à venir, nous verrons probablement émerger des réseaux toujours plus intelligents, capables non seulement de s’adapter à notre monde en constante évolution, mais aussi de l’anticiper.

La 6G sera autonome, intelligente et pilotée par l’intention.

Références

[1] https://www.tmforum.org/topics/an-resources/