Intégration de la détection et de la communication : ISAC Cas d’usage 11 à 15

Posté le 28 février 2025 by flaunay - 88 vues

Ce document est issu de la TR 22.827 et à pour objectif de résumer les cas d’usages

Résumé du cas d’utilisation 5.11 : Détection aux croisements routier avec/sans obstacle

Description :
Ce cas d’utilisation porte sur la surveillance des croisements routiers où diverses formes de transport (véhicules, piétons, véhicules motorisés et non motorisés) rendent la circulation complexe. Les accidents se produisent souvent aux croisements, notamment lorsque des piétons surgissent soudainement d’un endroit invisible, comme derrière des bâtiments ou des arbres hauts. Il est donc essentiel de surveiller en temps réel l’état de la route. En collaboration avec des tiers de confiance, comme des fournisseurs de services cartographiques ou des plateformes de gestion des systèmes de transport intelligents (ITS), des informations d’assistance à la conduite peuvent être fournies aux véhicules pour améliorer la sécurité routière.

Fonctionnement :
Les informations sur l’état de la route (par exemple, le mouvement des véhicules, la position et la vitesse des usagers vulnérables de la route, ainsi que la détection d’obstacles et de comportements anormaux) peuvent être capturées par des caméras et des radars installés sur des unités de bord de route (RSU). Cependant, il subsiste des angles morts que la technologie 5G permet de combler en fournissant des données de détection en temps réel au réseau central. Ce réseau peut ensuite analyser et combiner ces données avec des cartes de navigation pour informer les conducteurs des congestions et accidents potentiels, améliorant ainsi la sécurité et le confort de la conduite.

Performance requise pour le cas d’utilisation :

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 1 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Latence maximale du service de détection	≤ 500 ms
Taux de rafraîchissement	≤ 0,1 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’utilisation 5.12 : Détection assistée par le réseau pour éviter les collisions de drones (UAV)

Description :
Avec l’aide des réseaux 5G actuels, la commercialisation des drones (UAV) à basse altitude a atteint un nouveau stade. Les UAV peuvent effectuer des missions de surveillance, d’alerte précoce et de livraison dans l’espace aérien à basse altitude. Le secteur de la livraison par drone se développe rapidement et pourrait devenir un marché de près de 10 milliards d’euros, avec des applications dans la distribution alimentaire, la livraison de biens de consommation, la fourniture d’aide médicale, l’agriculture de précision, la logistique industrielle, etc.

Cependant, éviter les collisions et gérer efficacement le trafic des UAV sont des défis clés. En général, un drone fournit des informations sur ses mouvements et son environnement détectées par ses propres capteurs au système de gestion du trafic des drones (UTM). Mais la portée de détection d’un drone unique est limitée, ce qui peut entraîner des écarts de trajectoire ou des collisions si l’environnement change brusquement.

Grâce à la couverture étendue du réseau 5G, un équipement utilisateur (UE) embarqué sur un drone peut être abonné au réseau 5G et se connecter à l’UTM (UAS Traffic Management) via le réseau.

Fonctionnement :

Les stations de base 5G envoient des signaux de détection dans une direction, un angle ou une zone spécifique pour suivre la trajectoire de vol du drone.
L’UE collecte les signaux réfléchis par l’environnement et transmet ces données au réseau 5G.
Le réseau analyse les informations recueillies, comme la présence de bâtiments élevés, d’obstacles et d’autres drones à proximité, et les transmet au système UTM.
Le service de détection est continu pendant le vol du drone, et le réseau peut suivre plusieurs drones en même temps dans une même zone.

Performance requise pour le cas d’utilisation :

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 1 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Résolution de détection	< 1 m
Latence maximale du service de détection	≤ 500 ms
Taux de rafraîchissement	≤ 0,5 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’utilisation 5.13 : Détection d’intrusion de drones (UAV)

Description :
L’industrie des UAV (drones) se développe avec une utilisation croissante dans des scénarios variés tels que la photographie aérienne, les forces de l’ordre, la gestion urbaine, l’agriculture, la météorologie, la fourniture d’électricité, le secours d’urgence, etc. Dans les villes intelligentes du futur, un grand nombre de drones seront utilisés pour améliorer la qualité de vie quotidienne, notamment pour l’inspection industrielle, les patrouilles de sécurité publique, le transport de marchandises et les diffusions en direct.

Cependant, cette prolifération pose des défis importants pour la supervision des UAV, notamment :

Le grand nombre de drones de petite taille, leur vaste zone de vol et leurs missions diversifiées rendent la supervision difficile en utilisant uniquement des systèmes de radar traditionnels.
Les drones non coopératifs peuvent pénétrer dans des zones d’interdiction de vol (par exemple, aéroports, bases militaires), ce qui peut entraîner de graves conséquences, telles que l’exposition d’informations privées ou la perturbation du trafic d’autres UAV sur les routes de vol.

Fonctionnement :
Les signaux radio 5G peuvent être utilisés pour détecter la présence ou la proximité de drones volant illégalement dans une zone spécifique. Ce service est particulièrement utile pour détecter les intrusions illégales dans des zones restreintes telles que les gares ferroviaires, les aéroports, les installations gouvernementales, les instituts de recherche, les sites de performance temporaires, etc.

Scénario de service :

Le système 5G détecte en continu les UAV volant dans ou à proximité d’une zone restreinte.
Lorsqu’un UAV est détecté à proximité d’une zone interdite, le système de gestion du trafic des drones (UTM) est informé en temps réel.
L’UTM peut prendre des mesures pour avertir le contrôleur de l’UAV ou activer des contre-mesures pour empêcher le drone de continuer à voler dans la zone interdite.

Performance requise pour le cas d’utilisation :

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 10 m
Précision de l’estimation de positionnement vertical	≤ 10 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Résolution de détection	< 10 m
Latence maximale du service de détection	≤ 1000 ms
Taux de rafraîchissement	≤ 1 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’utilisation 5.14 : Gestion du trafic dans les sites touristiques

Description :
Ce cas d’utilisation concerne la gestion du trafic dans les sites touristiques afin d’assurer un développement durable de ces lieux. La gestion du flux de visiteurs prend en compte la capacité d’accueil, la capacité des installations, la capacité écologique et d’autres facteurs susceptibles d’engendrer des désastres dans la zone.

Les sites touristiques contrôlent le flux de visiteurs grâce à la surveillance en temps réel, à la gestion des flux et aux systèmes d’alerte et de rapport. La gestion du trafic se divise en deux volets : la gestion du flux de passagers et la gestion du flux de véhicules. La collecte de données sur le trafic est une partie importante de cette gestion. Les stations de base situées dans les zones touristiques peuvent fournir des services de communication 5G et collecter des données sur les passagers et les véhicules qui passent à travers les points d’accès ou par unité de surface.

Pour les sites touristiques de grande superficie, il est plus pratique d’utiliser les stations de base pour collecter des données sur le trafic lorsque le déploiement d’équipements comme des caméras et d’autres capteurs est difficile.

Performance requise pour le cas d’utilisation :

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 2 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Résolution de détection	< 1 m
Latence maximale du service de détection	≤ 5000 ms
Taux de rafraîchissement	≤ 0.2 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’utilisation 5.15 : Surveillance du sommeil sans contact

Description :
Ce cas d’utilisation consiste à surveiller la situation de sommeil d’une personne sans avoir recours à un dispositif portable. Les technologies de détection sans contact, utilisant les signaux sans fil 3GPP, offrent de nombreux avantages pour la détection de l’état de santé par rapport aux dispositifs portables traditionnels.

L’application de surveillance du sommeil réutilise les signaux sans fil omniprésents pour réaliser la détection. La présence, le mouvement et même la respiration d’une personne influencent la propagation du signal sans fil, ce qui se traduit par des fluctuations de l’intensité de la forme d’onde et du décalage de phase.

Performance requise pour le cas d’utilisation :

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision du taux de mouvement humain (fréquence)	≤ 0,033Hz
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Résolution de détection	< 1 m
Latence maximale du service de détection	≤ 60 s
Taux de rafraîchissement	≤ 60 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Ces performances garantissent que le système de surveillance du sommeil sans contact est capable de détecter et de signaler des événements respiratoires anormaux, tels que les arrêts respiratoires, afin d’aider les utilisateurs à surveiller leur santé et à identifier les problèmes potentiels liés au sommeil

Intégration de la détection et de la communication : ISAC Cas d’usage 6 à 10

Posté le 27 février 2025 by flaunay - 82 vues

Répondre

Ce document est issu de la TR 22.827 et à pour objectif de résumer les cas d’usages

Résumé du cas d’usage 5.6 : Détection d’intrus aux abords d’une maison intelligente

Ce cas d’usage porte sur l’utilisation de la 5G pour détecter les intrus à l’extérieur d’une maison intelligente, en exploitant des équipements connectés et les signaux radio pour surveiller les alentours d’une propriété.

Contrairement à la détection d’intrusion à l’intérieur d’une maison (cas d’usage 5.1), ici, l’objectif est de repérer tout mouvement suspect aux abords de la maison.
Des appareils 5G (CPE, caméras intelligentes, capteurs IoT) peuvent collecter et analyser les variations des signaux radio réfléchis, permettant d’identifier une présence inhabituelle.

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Latence maximale du service de détection	≤ 5000 ms
Taux de rafraîchissement	≤ 10 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’usage 5.7 : Détection d’intrusion sur les voies ferrées

Ce cas d’usage explore l’utilisation de la 5G pour détecter les intrusions sur les voies ferrées, en exploitant des stations de base et des capteurs connectés pour surveiller en temps réel la présence de personnes, d’animaux ou d’objets sur les rails.

Actuellement, la surveillance ferroviaire repose sur des caméras, radars et capteurs traditionnels, mais ceux-ci ont une couverture limitée et nécessitent une maintenance coûteuse.
La 5G permet une couverture plus large et une détection en continu grâce à l’analyse des signaux radio réfléchis par les obstacles sur la voie.

Surveillance en temps réel :
- Les stations de base 5G et les capteurs IoT surveillent en continu l’état des voies en mesurant les signaux radio réfléchis par l’environnement.
Détection d’une intrusion :
- Si une personne, un animal ou un objet est détecté sur les rails, le système analyse l’information et détermine la nature et la position de l’obstacle.
Alerte et intervention :
- Une alerte est envoyée aux conducteurs de train, aux centres de contrôle ferroviaires, et aux services d’urgence.
- Si nécessaire, des messages d’alerte sont diffusés sur des panneaux intelligents près des voies pour avertir les personnes présentes.
- Un train approchant peut être ralenti ou arrêté à distance en cas de danger.

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Latence maximale du service de détection	≤ 5000 ms
Taux de rafraîchissement	≤ 10 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’usage 5.8 : Manœuvre et navigation automobile assistées par détection

Ce cas d’usage explore comment la 5G et les technologies de détection peuvent améliorer la manœuvre et la navigation des véhicules, notamment pour la conduite autonome et assistée.

Actuellement, les véhicules utilisent des capteurs embarqués (caméras, radars, LiDAR) pour percevoir leur environnement.
La 5G permet d’enrichir ces données en utilisant des stations de base et des capteurs routiers connectés, qui peuvent fournir une vision plus large et plus précise du trafic et des obstacles environnants.

Déroulement du service

Collecte des données :
- Les stations de base scannent en continu l’environnement en analysant les réflexions des signaux 5G.
- Les véhicules partagent leurs propres données de capteurs avec le réseau.
Analyse et prédiction :
- Le système 5G fusionne les données des capteurs embarqués et externes pour créer une cartographie dynamique de l’environnement.
- Il prévoit les mouvements des autres véhicules, piétons et obstacles en temps réel.
Assistance à la conduite :
- Si un véhicule s’apprête à changer de voie, tourner ou freiner, il reçoit une recommandation optimisée basée sur l’analyse des capteurs.
- En cas de danger (piéton traversant, véhicule caché dans l’angle mort), le système déclenche une alerte et peut corriger automatiquement la trajectoire.

Exigences et améliorations potentielles du réseau 5G

Faible latence (<10 ms) pour un traitement en temps réel.
Précision de localisation inférieure à 1 mètre pour assurer une navigation fiable.
Fusion des données des capteurs embarqués et des infrastructures routières pour une perception plus complète.
Compatibilité avec les véhicules autonomes et les systèmes ADAS (Advanced Driver Assistance Systems).

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 1 m
Précision de l’estimation de positionnement vertical	≤ 1 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Précision de l’estimation de vitesse verticale	≤ 1 m/s
Latence maximale du service de détection	≤ 500 ms
Taux de rafraîchissement	≤ 1 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’usage 5.9 : Détection et suivi des AGV (véhicules à guidage automatique) dans les usines

Description

Ce cas d’usage explore l’utilisation de la 5G pour améliorer la détection et le suivi des AGV (Automated Guided Vehicles) dans les usines intelligentes.

Actuellement, ces véhicules (AVG) reposent sur des capteurs embarqués (LiDAR, caméras, RFID), mais ces technologies ont une portée et une précision limitées.
La 5G permet une détection plus large et en temps réel en combinant les signaux radio des stations de base avec les capteurs existants.

Déroulement du service

Surveillance en temps réel :
- Les stations de base analysent en continu la position et les mouvements des AGV via la réflexion des signaux 5G.
- Les AGV partagent leurs propres données de navigation avec le réseau.
Analyse et gestion du trafic :
- Le réseau fusionne les données des AGV et des capteurs externes pour créer une cartographie dynamique de l’usine.
- Il détecte les risques de collision et optimise les itinéraires des AGV.
Optimisation et intervention :
- En cas d’obstacle ou de retard, le système peut rediriger un AGV vers un autre chemin.
- Les opérateurs peuvent suivre les AGV en temps réel via une plateforme cloud et recevoir des alertes en cas d’anomalie.

Exigences et améliorations potentielles du réseau 5G

Précision de positionnement inférieure à 10 cm pour éviter les collisions.
Latence ultra-faible (<10 ms) pour assurer une détection et une réponse immédiates.
Intégration des capteurs embarqués et des infrastructures 5G pour une vision globale.

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 1 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Latence maximale du service de détection	≤ 500 ms
Taux de rafraîchissement	≤ 1 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Résumé du cas d’usage 5.10 : Suivi de la trajectoire de vol des UAV (drones)

Ce cas d’usage explore l’utilisation de la 5G pour surveiller et tracer en temps réel la trajectoire des UAV (drones).

Actuellement, les UAV dépendent du GPS et de capteurs embarqués, mais ces systèmes peuvent être limités en milieu urbain ou par de mauvaises conditions météorologiques.
La 5G permet un suivi plus précis et en temps réel en exploitant les stations de base et les signaux radio pour tracer les mouvements des drones.
Les opérateurs ont besoin d’un suivi précis pour éviter les collisions, optimiser les trajets et garantir la conformité aux règles aériennes.

Déroulement du service

Collecte des données de vol :
- Les stations de base détectent la position des drones grâce à l’analyse des signaux 5G réfléchis et émis.
- Les drones transmettent en temps réel leurs informations de vol au réseau.
Suivi et optimisation de la trajectoire :
- Le système 5G fusionne ces données pour offrir une cartographie dynamique des drones en vol.
- Il ajuste les trajectoires pour éviter les obstacles et les autres drones.
Alertes et intervention :
- En cas de déviation, de panne ou d’intrusion dans une zone interdite, une alerte est envoyée aux opérateurs.
- Des ajustements automatiques peuvent être faits pour ramener le drone sur la bonne trajectoire.

Exigences et améliorations potentielles du réseau 5G

Précision de localisation inférieure à 1 mètre pour assurer un suivi fiable.
Latence ultra-faible (<10 ms) pour un ajustement instantané des trajectoires.
Interopérabilité avec les systèmes de contrôle aérien pour garantir la sécurité et la réglementation.

Critère de performance	Valeur requise
Niveau de confiance	≥ 95 %
Précision de l’estimation de positionnement horizontal	≤ 1 m
Précision de l’estimation de positionnement vertical	≤ 1 m
Précision de l’estimation de vitesse horizontal	≤ 1 m/s
Précision de l’estimation de vitesse verticale	≤ 1 m/s
Latence maximale du service de détection	≤ 500 ms
Taux de rafraîchissement	≤ 1 s
Taux de détection manquée	≤ 5 %
Taux de fausse alarme	≤ 5 %

Ces performances permettent au système de suivre la trajectoire des drones de manière précise et rapide, garantissant ainsi une navigation sécurisée et évitant les collisions avec d’autres objets ou obstacles. Ce suivi en temps réel est essentiel pour des applications telles que la logistique, la surveillance ou la livraison par drones.

CHO : Conditionnal Handover, DAPS HO et H.O Traditionnel

Posté le 23 février 2025 by flaunay - 154 vues

Répondre

La procédure de HandOver a pour objectif de maintenir une session de données ou un échange de signalisation lorsque l’UE bascule d’une cellule vers une autre. La station de base source informe la station de base cible d’une demande de handover par le message Handover Request. Ce message est porté par l’application XnAp. La station de base cible vérifie les conditions d’admission et répond à la station de base source par le message Handover Request Acknowledge. Si la demande est acceptée, la station de base source demande au mobile d’exécuter le handover. Pour guider le mobile, la station de base cible transmet à la station de base source les informations de configuration dans le message Handover Request Acknowledge. Ensuite, la station de base source transfère le contenu de la configuration de Handover dans le message RRC Reconfiguration (figure 1).

Les informations de configuration contiennent au minima l’identité de la cellule cible (Cell ID) et toutes les informations requises pour accéder à la station de base cible (préambule, C-RNTI de la cible gNB…). Ces informations sont transmises dans un containeur transparent d’un message RRC.

Figure 1 : La procédure de Handover inter-gNb [1]

Dès que la station de base source reçoit le message Handover Request Acknowledge, un tunnel de données est établi de manière temporaire de la station de base source vers la station de base cible. Cela permettra aux paquets à destination de l’UE (paquet descendant) d’être transférés vers la station de base cible pour les transmettre au mobile après exécution du handover.

L’exécution du Handover se passe en deux étapes : L’UE reçoit un ordre pour couper le lien radio avec la station de base source et il établit un lien avec la station de base cible.

Pour ce faire, l’UE démarre la procédure d’accès aléatoire (cf article précédent) avec la station de base cible et une fois connecté, l’UE transmet le message RRC Reconfiguration Complete à la station de base cible.

Le relâchement du flux entre la station de base source et le cœur de réseau est déclenché par la station de base cible.

A travers cet article, nous allons étudier trois méthodes de Handover :

Handover traditionnel
DAPS Handover
Handover Conditionnel

Les méthodes de Handover CHO et DAPS ne peuvent pas être configurés simultanément. La demande de Handover est déclenchée par une réception radio mauvaise. Nous allons démarrer l’article par les évènements de mesure du lien radio.

Les évènements de mesure

La demande de Handover est déclenchée par le mobile lorsque la puissance du signal radio reçue par le mobile correspond à un évènement connu par le mobile. Les évènements de déclenchement sont transmis par la station de base au mobile dans le message RRC Reconfiguration.

Les différents évènements de mesure sont :

A1 : Cet évènement est déclenché lorsque la puissance RSRP reçue par l’UE et issue de la cellule de service est supérieure à un seuil. Cette condition permet d’annuler la demande d’un Handover

A2 : Cet évènement est déclenché lorsque la puissance RSRP reçue par l’UE du signal issu de la cellule de service est inférieure à un seuil. Cette condition permet à l’UE de déclencher d’autres mesures inter-fréquences ou inter-systèmes ou de réaliser une mobilité à l’aveugle.

A3 : Cet évènement est déclenché lorsque la puissance RSRP reçue de l’UE et issue d’une cellule voisine est supérieure aux mesures des cellules SpCell c’est-à-dire la cellule maître et secondaire (Double connectivité : https://blogs.univ-poitiers.fr/f-launay/2022/07/20/pcell-scell-pscell-et-spcell/)

A4 : Cet évènement est déclenché lorsque la puissance RSRP reçue par l’UE d’une cellule voisine est supérieure à un seuil. Cet évènement permet de faire de l’équilibrage de cellule d’un UE à cause du nombre d’UE et non des conditions radio. Dans ce cas, il est juste nécessaire de vérifier que la couverture radio de la cellule voisine est suffisante pour une couverture radio convenable.

A5 : Cet évènement est déclenché lorsque la puissance RSRP reçue de l’UE par une cellule est inférieure à un seuil alors que la puissance reçue par une autre cellule est supérieure à un autre seuil. Cette mesure permet un Handover intra-fréquence ou inter-fréquence.

A6 : Cet évènement est déclenché lorsque la puissance RSRP reçue par l’UE d’une cellule voisine est supérieure ou inférieure à une cellule secondaire utilisé lors de l’agrégation de cellule. La puissance reçue par la cellule secondaire est affecté d’un offset positif ou négatif.

B1 : Cet évènement est déclenché lorsque la puissance RSRP reçue par l’UE d’une cellule voisine d’un autre RAR est supérieur à un seuil. Cet évènement peut être utilisé pour réaliser un Handover afin d’équilibrer la charge de la cellule tant que la réception radio est suffisante.

B2 : Cet évènement est déclenché lorsque la puissance RSRP reçue par l’UE de la cellule primaire est inférieure à un seuil alors que la puissance radio reçue par l’UE d’une autre technologie RAT est supérieure à un autre seuil. Cela permet de définir quelle station de base cible prendra le relais radio lors du Handover.

Les mesures A1 à A6 concernent des mesures radio de la même technologie radio

Les mesures B1 et B2 concernent des mesures radios de technologies différentes (autre RAT)

Le Handover traditionnel HO

La procédure de H.O traditionnelle s’effectue en trois étapes :

Préparation du HandOver
Exécution
Achèvement

Figure 2 : La procédure de Handover BHO

Phase de préparation :

A partir du rapport de mesure, la décision du Handover revient à la station de base source. C’est elle qui décide quelle station de base cible assurera la reprise de la session. En fonction des mesures, le mobile fait une demande de HO et attend la réponse de la station de base ciblée par la station de base source.

Phase d’exécution :

La figure 2 complète les premiers messages de la figure 1.

Avant que l’UE se connecte à la station de base cible (procédure RACH et message RRC Reconfiguration Complete), la station de base source envoie le numéro de séquence de l’entité PDCP pour le lien montant et pour le lien descendant (SN Status Transfer). Le numéro SN permet de vérifier qu’aucun paquet n’est perdu au niveau de l’entité PDCP pour les paquets en mode acquitté (RLC AM) lors du HandOver (source/cible). L’entité de la couche RLC remet à 0 le compteur de paquet entre l’UE et la station de base cible, la séquence numéroté PDCP est là pour garantir que tous les paquets ont bien été reçus par le récepteur.

Au niveau du plan utilisateur :

1) lors de la phase d’exécution du HO, après l’envoi du numéro SN, la station de base source établit un tunnel temporaire vers la station de base cible. Le plan utilisateur (trafic) utilise ce tunnel temporaire pour envoyer les flux vers la station de base cible. Ainsi les données entrantes, du réseau DN vers le mobile sont transmis de l’UPF vers le gNB source et du gNB source vers le gNB cible. Les paquets sont bufferisés au niveau du gNB cible. En même temps, la station de base cible recopie la table d’acheminement de la station de base source ce qui lui permet de connaitre l’adresse IP du la fonction UPF et l’identifiant de tunnel TEID associé au flux : le tunnel montant est ainsi ré-établi au niveau de la gNB cible.

Entre temps, le mobile fait une demande d’attachement avec la station de base cible. Une fois connecté, le mobile communique de manière bidirectionnelle avec la station de base cible. Ainsi, les données bufferisées au niveau du gNB cible peuvent être transmises vers le mobile. Pour le lien montant, l’UE envoie les données vers le gNB cible qui les transfère vers l’UPF (@IP UPF et TEID connu).

2) La phase d’achèvement permet de modifier la table d’acheminement de l’UPF pour que les données soient acheminées vers la station de base cible. Cette phase permet aussi de vérifier que toutes les données ont bien été réacheminées (End Marker). Lorsque le dernier paquet reçu par la gNB source a été transmis au gNB cible, le gNB cible demande à la fonction AMF de modifier la table d’acheminement de l’UPF. La fonction AMF envoie la requête PATH SWITCH REQUEST à la fonction SMF afin que cette fonction commute le trafic descendant du gNB source vers le gNB cible.

La figure 3 représente le plan utilisateur lors du H.O :

Figure 3 : Le plan utilisateur lors du Handover

DAPS HO

Dans le cas de la procédure du H.O, il y a une interruption radio de 30 ms à une centaine de ms, ce qui n’est pas compatible avec les services de type URLLC ou la latence est de 1 ms.

La méthode de Handover DAPS (Dual Active Protocol Stack) permet au mobile de conserver le lien radio de données DRB (Data Radio Bearer) avec la station de base source après la commande de Handover, mais l’UE suspend sa signalisation radio SRB avec la station de base source.

Ainsi, l’UE continue à recevoir et à émettre du trafic avec la station de base source en attendant d’être connecté avec la station de base cible.

Préparation du HO.

Le mobile envoie son rapport de mesure à la station de base. La station de base source déclenche le Handover et envoie la commande Handover Request à la station de base cible. La station de base gNB cible prépare le Handover et envoie le message Handover Request Acknowledgement à la station de base source.

La station de base source envoie ensuite le message RRC_Reconfiguration à l’UE pour lui fournir les informations du HO.

Au moment de la demande de HandOver, un tunnel temporaire est établi entre la station de base source et la station de base cible permettant de router le trafic Uplink/Downlink lorsque le mobile se connecte avec la station de base cible. C’est la station de base source qui décide à quel moment elle arrête de transmettre le trafic DL.

Exécution du H.O.

La station de base source envoie ensuite le message SN Uplink Early Status Transfer à la station de base cible. La station de base cible envoie le message SN Downlink Early Status Transfer à la station de base source.

L’information Early Status Transfer (procédure de transfert anticipé) permet de connaitre le numéro de séquence de la première liaison SDU PDCP descendante que la station de base source doit transmettre à la cible.

L’UE se synchronise sur la station de base cible et finalise le Handover par le message RRC Reconfiguration Complete à la station de base cible (suite à la procédure d’accès aléatoire).

La station de base source maintient la transmission DL jusqu’à réception du message HandOver Success émis par la station de base cible. Ce message est transmis lorsque l’UE est connecté sur la station de base cible. Le message HandOver Success permet à la station de base cible d’informer la station de base source que le H.O s’est bien déroulé.

Achevènement du H.O

La station de base source envoie le message SN Status Transfer à la station de base cible. Le cœur de réseau modifie le tunnel entre la fonction UPF et la station de base source.

Ainsi, pour le DAPS HO, le mobile se connecte avec la station de base cible avant de libérer sa connexion avec la station de base source.

Même si le trafic DL a commuté vers la station de base cible, le trafic UL est toujours émis de l’UE vers la station de base source. L’UE continue a émettre les informations CSI, HARQ vers la station de base source.

Puis, le mobile libère les ressources radios avec la station de base source. En cas d’échec, l’UE se repli (fallback) sur la station de base source en ré-établissant les bearers de signalisation SRB suspendus.

Deux piles protocolaires au niveau de l’UE sont nécessaires pour maintenir la session avec la station de base source et pour établir une nouvelle session avec la station de base cible ce qui suppose :

Création d’une nouvelle entité MAC et RLC pour chaque DRB
Etablissement d’une entité RLC associé au canal logique DTCH pour la station de base cible pour chaque DRB concerné

Figure 4 : La couche protocolaire pour la méthode DAPS HO

Les couches PHY/MAC/RLC sont dupliquées, l’une pour la station de base source, l’autre pour la station de base cible. L’unique entité PDCP gère les bearers vers les deux stations de base. La signalisation SRB est émise vers la station de base cible.

Lors de la procédure DAPS, le mobile maintient donc sa connexion avec la station de base source après avoir reçu la commande de HandOver, à la différence du HO traditionnel.

Figure 5 : La procédure de Handover DAPS

Le Handover Inter-RAT DAPS n’est pas supporté dans la R.17, ni même le DAPS HO de la bande FR2 vers la bande FR2.

Le Handover Conditionnel CHO

Le Handover Conditionnel CHO est apparu dans la spécification R.16. Lorsqu’un évènement de mesure est satisfait, l’UE envoi un rapport de mesure vers la station de base source, et celle-ci démarre la procédure de HO Conditionnelle.

La nouveauté est que l’exécution du Handover est faite au niveau de l’UE à partir des conditions de HO des stations de base voisines.

Ainsi, lors de la phase de préparation, gérée par la station de base source, la gNB source demande à un ensemble de stations de base voisines de transmettre les conditions de Handover. Dans le cas du H.O traditionnel, la station de base source choisissait la station de base cible. Chaque station de base voisine transmet à la station de base source les conditions de déclenchement de Handover.

Lors de la phase de préparation, la station de base source fournit les conditions d’exécution à l’UE à travers un message de Commande de HandOver (HO Command) dans le message RRC Reconfiguration.

La sélection de la station de base cible est gérée au niveau de l’UE à partir des conditions reçues. En cas d’échec de HO, le mobile recherche une nouvelle cellule et si celle-ci est candidate, le mobile fait une nouvelle tentative. En cas de deuxième chec, le mobile revient sur la cellule initiale.

Le choix de la station de base cible par l’UE s’appuie sur une ou plusieurs conditions est/sont atteinte(s). La condition peut porter sur le RSRP ou RSRQ. L’UE indique le choix de la station de base cible via le message RRC Reconfiguration Complete envoyé à la station de base source.

L’UE initie la demande d’accès aléatoire selon les conditions de HO reçue dans la commande de HO vers la station de base cible. Si, les conditions sont atteintes mais avant de déclencher le HO l’UE reçoit une nouvelle commande de HO, il ne poursuit pas la procédure de HandOVer initiale.

Le CHO a pour objectif d’améliorer le taux de réussite du Handover et s’effectue toujours en trois étapes.

Etape de préparation : Le mobile fait une demande de Handover et reçoit un acquittement avec les conditions de HO.
Etape d’exécution : Le mobile analyse les conditions de HO et se synchronise sur la cellule candidate. La station de base source envoie le message EARLY STATUS TRANSFER contenant le numéro SN de reprise de séquence. Un tunnel DATA temporaire est créé entre la station de base source et la station de base cible pour le trafic descendant. Les données sont bufferisées au niveau de la station de base cible.

Figure 6 : La procédure de Handover CHO

L’UE réalise des mesures du lien radio. Lorsqu’un évènement de mesure (A1/A6) se déclenche, l’UE transmet un rapport de mesure à la station de base, indiquant à celle-ci qu’un handover sera nécessaire.

Phase de préparation

La station de base source envoie la requête Handover Request via l’application XnAP vers toutes les stations de bases voisines candidates. Chaque station de base candidate transmet à l’UE le préambule d’accès aléatoire et se prépare à recevoir une demande d’accès aléatoire de la part de l’UE. La station de base source récupère les informations de HO. Chaque condition contient le préambule à utiliser spécifique à la station de base et des options de mesures d’évènement à réaliser pour la station de base. Chaque condition est regroupée dans la payload du message RRC Reconfiguration. La commande de Handover Condtionnelle est transmise au mobile via le message RRC Reconfiguration.

Phase d’exécution

A partir des conditions reçues, et des mesures complémentaires à réaliser, l’UE choisit la station de base cible et en informe la station de base source via le message RRC Reconfiguration Complete de la station de base cible choisit. La station de base source initie la procédure de modification du plan d’acheminement NGAP Path Switch Procedure. Via le message Early Status Transfert, la station de base source transmet à la station de base cible les informations d’acheminement du l’UPF (@IP de l’UPF et l’identifiant TEID concernant la session de l’UE et réalise la création d’un tunnel temporaire entre la station de base source et la station de base cible.

L’UE exécute la procédure d’accès aléatoire vers la station de base cible.

Références

[1] TS38.300 R.17 : Figure 9.2.3.1-1

https://www.etsi.org/deliver/etsi_ts/138300_138399/138300/17.00.00_60/ts_138300v170000p.pdf

Annexe DAPS

La modulation 6G : De l’OFDM à l’OTFS – Article 2

Posté le 11 février 2025 by flaunay - 271 vues

Répondre

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

Merci à Christophe BAILLOT, enseignant Télécom à l’IUT R&T du Pays de l’ADOUR pour sa relecture et ses commentaires.

III) L’orthogonalité : la base de la transmission

Principe fondamental : Bande de base/transmission autour d’une porteuse

Lorsqu’on souhaite transmettre une information binaire, on utilise un code en ligne pour transmettre la valeur du bit en bande de base. Ce code peut éventuellement transmettre l’horloge d’émission. Les types de codes classiques sont les codes RZ, NRZ, Manchester, Miller qui sont des codes antipodaux.

Figure 8 : Codes en ligne

La figure précédente représente des codes en ligne pour la transmission en bande de base.

Si l’on souhaite transmettre le signal autour d’une fréquence porteuse, le signal binaire est le modulant car il vient moduler la porteuse. Le récepteur démodule le signal autour de la fréquence porteuse.

Le signal binaire est un signal orthogonal, puisque le produit scalaire des deux informations binaires sur la durée du bit est nul.

Si l’on prend un signal carré, périodique (par exemple le signal d’horloge) alors le spectre du signal binaire, c’est-à-dire la distribution de la puissance sur les harmoniques, est théoriquement infinie.

Figure 9 : Signal carré et sa transformée de Fourier

Sur la figure 9, le signal est un signal carré périodique.

Transmettre une information binaire consiste à émettre un signal rectangulaire, appelé signal porte :

Figure 10 : Représentation du signal porte et de sa transformée de Fourier

La transformée de Fourier d’un signal porte est un sinus cardinal, dont le lobe principal à pour largeur de bande B=2/T. On retrouve donc le principe évoqué précédemment, plus le débit est rapide, plus la durée du signal porte est courte et plus la bande est importante.

Par exemple :

Pour un débit de 1000 bits par secondes, la durée de la porte est de 1 ms.
Pour un débit de 1 Mbits par seconde, la durée de la porte est de 1 µs.

Dans le cas d’une transmission d’information, le signal binaire est une séquence binaire aléatoire (0100111101101). Le spectre en dB à la forme suivante :

Figure 11 : Le spectre d’un signal QPSK

Le signal apporte de la puissance sur les bandes voisines, on parle d’interférence. Pour limiter cette interférence, la solution consiste à filtrer le signal.

Par exemple, voici la fonction de transfert d’un filtre passe-bas appelé filtre en cosinus surélevé (figure 12).

La fonction de transfert en bleu est sélective. Sur la figure 4 cela reviendrait à ne conserver que le demi-lobe principal : on multiplie le spectre du signal par la fonction de transfert du filtre : Y(f)=H(f).X(f), X(f) est le spectre de la figure 4 et H(f) la fonction de transfert de la figure 5.

Figure 12 : Fonction de transfert du filtre en cosinus surélevé

Toutefois, le fait de filtrer déforme le signal dans le domaine temporel. Comme on souhaite conserver la condition d’orthogonalité dans le domaine temporel, on utilise un filtre de Nyquist. Cela va éviter l’interférence en temps, nommée interférence inter-symbole ou IES ou IIS : l’échantillon à la période T en sortie du filtre n’est pas interféré par les bits filtrés et émis précédemment.

On s’aperçoit sur la figure 13 que la forme temporelle d’un signal porte après filtrage de Nyquist s’étale dans le temps mais aux instants kT, k entier, l’amplitude du signal filtrée est nulle. Sur la figure 13, on modifie la valeur du roll-off (sélectivité du filtre)

Figure 13 : La représentation du signal de la porte après filtrage

Ainsi, l’application du filtre sur la séquence binaire suivante 01011001011 donne le signal temporel représenté sur la figure 14 (il s’agit de la convolution du signal précédent aux instants d’échantillonnage de la séquence binaire +1/-1):

Figure 14 : La représentation d’une séquence binaire filtrée

L’orthogonalité permet de préserver qu’au moment de l’échantillonnage, la valeur de l’amplitude est +1 ou -1

Figure 15 : L’orthogonalité dans le domaine temporel

En général, on représente la forme temporelle par le diagramme de l’œil. Cela consiste à superposer 3 bits sur une figure. Pour comprendre facilement, supposez prendre en photo les 3 premiers bits, puis prendre en photo du bit 2 au bit 5 et vous superposez (calque) les deux photos et continuez ainsi. On obtient ainsi la figure 16 dite diagramme de l’œil montrant l’orthogonalité du signal filtré.

Figure 16 : L’orthogonalité dans le domaine temporel – Diagramme de l’oeil

Pour les réseaux mobiles 3G, le spectre opérateur est de 5 MHz. Il s’agit de l’occupation spectral d’un chip à 3,84 Mbps par un filtre en cosinus surélevé de coefficient 0,22. La bande occupée est donc de 3,84*1,22= 4,69 MHz.

Le signal reçu est donc déformé : Le retard apporte de l’interférence inter-symbole qu’il est nécessaire de compenser. En réception, un égaliseur a pour rôle de s’affranchir des perturbations du canal. En 3G, on utilise un récepteur rake pour contrer les phénomènes de multi-trajets. Afin que plusieurs utilisateurs puissent émettre dans la même bande radio, la 3G s’appuie de plus sur un multiplexage par code Orthogonal (Direct Spread Code Division Multiple Access). Les codes orthogonaux sont générés par des séquences de Walsh Hadamard. Ce sont des séquences orthogonales à condition d’être synchronisées. La synchronisation est réalisée par des codes de Gold en 3G, qui ont de bonnes propriétés d’intercorrélation et d’autocorrélation.

La 3G utilise donc, dans le domaine temporel, un vecteur d’étalement orthogonal nommé OSVF (Orthogonal Spreading Variable Factor) en plus du filtrage par un filtre de Nyquist.

L’un des soucis de la 3G est la complexité du récepteur rake, le signal étant déformé sur une large bande, la 4G propose d’utiliser un découpage en fréquence et non plus en temps appelé modulation OFDM.

L’OFDM divise le canal de transmission en plusieurs sous-porteuses orthogonales, permettant la transmission parallèle de données sur différentes fréquences. Le principal avantage est la simplicité d’implémentation avec la FFT/IFFT.

L’orthogonalité se calcule cette fois-ci sur les sous-porteuses : soit deux sous porteuses v1(t) et v2(t), le produit scalaire est calculé par l’intégrale du produit des porteuses sur la durée d’un symbole. L’intégrale est nulle si la durée d’un symbole est inversement proportionnelle à l’espacement entre sous porteuses. En 4G et 5G, la durée d’un symbole est donc l’inverse de l’écart entre fréquence (SCS ; SubCarrier Spacing).

La Transformée de Fourier, en réception, revient à un produit scalaire entre le signal reçu y(t) et l’exponentielle à la fréquence fp. Cela représente donc la quantité de signal reçu dans la fréquence porteuse.

Ainsi, de manière similaire aux figures 15/16, on peut représenter l’orthogonalité dans le domaine fréquentiel par la figure 17.

Figure 17 : L’orthogonalité dans le domaine fréquentiel

L’axe des abscisses est en noir. On remarque que l’amplitude des ondes est soit maximale soit nulle à la fréquence de réception, ce qui prouve l’orthogonalité en fréquence.

Malgré ses avantages, l’OFDM présente certaines limitations :

Sensibilité à l’effet Doppler
Perte d’orthogonalité en cas de décalage fréquentiel
Performance limitée dans les canaux à forte mobilité
Nécessité d’un préfixe cyclique réduisant l’efficacité spectrale

En effet, l’OFDM a pour objectif de moduler différentes sous porteuses espacées par un écart en fréquence SCS (15 kHz en 4G).

En reprenant la figure 17, le signal qui est transmis est une modulation de chaque sous porteuse :

avec X(k) le symbole qui est transmis sur la k-ième sous porteuse. Cette représentation n’est rien d’autre que la transformée de Fourier inverse et par conséquent la transformée de Fourier est vue comme un filtre adaptatif qui pourra reconstruite les symbole X(k).

Le synoptique a fait l’objet de quelques articles dont celui du 13 septembre 2013 (article OFDM)

Figure 18 : Synoptique émission/réception OFDM [3]

On définit en 4G un bloc de ressource qui représente le symbole OFDM à transmettre. Le bloc de ressource à une composante en temps et en fréquence :

Ainsi, le signal reçu aura une caractéristique dans le domaine temporel n et fréquentiel m :

Avec k l’indice du symbole, l l’indice de la sous-porteuse, H le canal de propagation.

La technique d’égalisation a pour objectif de calculer l’inverse de H afin d’estimer au mieux le signal émis à partir de la séquence reçue . Pour mesurer la distorsion du canal en temps et en fréquence, on insère des signaux de références. Il s’agit de séquence d’apprentissage, le récepteur sait ce qu’il doit recevoir et compare le signal reçu de la séquence d’apprentissage qu’il aurait du recevoir. Cette déformation permet d’estimer le canal au prix d’une estimation répétitive en temps et en fréquence.

En 4G, le signaux de références sont distribués sur toute la bande en fréquence et sur le temps.

Figure 19 : Séquence d’apprentissage en 4G

Le canal de propagation est donc estimé dans le domaine temporel et fréquentiel. Les échos vont apporter un délai dans la réception, la vitesse va apporter un décalage en fréquence.

On va représenter l’estimation du canal de propagation en temps et en fréquence mais il serait plus efficace d’estimer les retards et le décalage (figure 19 [5])

Figure 20 : Représentation temps/fréquence et délai/doppler

Le principe de l’OTFS est de calculer le canal de propagation dans sa dimension délai/doppler.

[5] propose une figure illustrative (figure 21): Le véhicule RX s’approche de la station de base, le signal direct est affecté d’un Doppler qui est calculé à partir de la vitesse du véhicule. Le même signal est réfléchi par le véhicule O1 qui roule devant lui à la même vitesse. On constate donc un délai dans la réception mais pas de Doppler, contrairement au véhicule 02 qui roule dans l’autre direction pour lequel le Doppler est important sur le retard de réception.

Figure 21 : Représentation du délai et du Doppler (Figure extraite du [5])

La fonction BSF

Posté le 13 octobre 2024 by flaunay - 331 vues

Répondre

Introduction

Le réseau 5G est un réseau natif Cloud. L’avantage est de permettre un déploiement rapide des fonctions réseaux et une mise à l’échelle pour des services dédiés (Network Slicing). La mise à l’échelle automatique (Horizontal Scaling) autorise la multiplication d’instances d’une fonction réseau pour répondre à la charge demandée.

La fonction BSF (Binding Support Function) a été introduite dans l’architecture du réseau 5G (23.501 R.15) afin de maintenir l’association entre l’UE et une fonction PCF. Ainsi, si plusieurs fonctions PCF sont déployées par l’opérateur, la fonction BSF permet d’associer la fonction PCF qui gère la QoS d’une session PDU d’un UE. Dans le cas de la VoNR, pour un appel entrant, le réseau IMS (fonction AF) contacte le PCF, via l’interface N5/Rx, pour l’établissement d’un flux RTP pour le transport de la session. L’association au niveau du BSF permettra à l’AF de contacter le PCF correspondant à l’UE.

La fonction BSF va stocker l’identifiant du PCF et des informations concernant l’UE afin de pouvoir faire la correspondance entre l’UE et la fonction PCF.

Les informations stockées au niveau du BSF peuvent être :

@IP ou @MAC de l’UE
L’identifiant S-NSSAI
L’identifiant DNN
L’@ du PCF choisi (instance PCF)

Figure 1 : Contexte de la fonction BSF et interrogation de l’AF

Chaque flux d’une session PDU est identifié par une valeur de flux QFI. Le flux est défini par le type de QoS (5QI), le type de bearer (GBR ou non GBR) et le débit (AMBR) qui sont gérés entièrement par la fonction SMF pour une session PDU traditionnelle (Accès Internet, une session SIP,…) ou négociés avec la fonction PCF.

SMF (Session Management Function) : Lorsque le SMF reçoit une demande de session PDU, il peut consulter une fonction PCF pour définir la politique de QoS. La fonction PCF interagit avec la fonction BSF car la fonction SMF ne communique pas directement avec la fonction BSF.

PCF (Policy Control Function) : Les fonctions BSF et PCF s’échangent des informations pour appliquer des politiques spécifiques à chaque session, telles que les règles de QoS et les autorisations d’accès.

La session demandée par la fonction AF doit être liée (Session Binding) à une seule session PDU. Ces informations d’association sont donc transmises à la fonction AF.

II) Les services de la fonction BSF

II-1) Gestion des informations de liaison (binding information)

Le BSF maintient et gère les informations de liaison entre les différentes entités de réseau et les sessions utilisateurs. Cela inclut l’association entre les identifiants des utilisateurs, les sessions actives, et les adresses IP utilisées.

Le BSF maintient une base de données des identifiants d’utilisateur et des contextes de session correspondants. Cela inclut des informations telles que :

L’identifiant unique de l’utilisateur (IMSI – International Mobile Subscriber Identity).
Les identifiants des sessions PDU actives.
Les adresses IP attribuées pour chaque session.
Les paramètres de qualité de service (QoS) pour chaque session.

II2) Support de la mobilité et proxy

La fonction BSF a un rôle comparable aux routeurs DIAMETER DRA (Diameter Routing Agent) utilisés en 4G. La fonction BSF est mis en œuvre lorsque les réseaux 4G et 5G doivent coexister.

Le rôle de la fonction BSF est alors de définir le prochain nœud de destination du paquet à transporter.

III) Les services de la fonction BSF (TS 29.521)

La fonction BSF assure l’association entre une session PDU et une fonction PCF. La fonction BSF propose des services de gestion pour enregistrer les associations entre l’UE, la session PDU et le PCF et les fournir aux fonctions concernées.

La fonction BSF peut jouer le rôle de proxy DIAMETER ou de serveur de redirection. Dans le cas du Proxy BSF, il transmet une requête DIAMETER d’une entité source vers une entité cible.

Dans le cas d’un serveur de redirection, la fonction BSF traduit une requête DIAMETER en un message http2 et inversement.

La fonction BSF dialogue avec les entités suivantes :

III-1) Service de Gestion

Le service de Gestion Service Management permet :

D’enregistrer/de désenregistrer ou de mettre à jour les informations d’associations pour un UE ou une session PDU
De faire une découverte de la fonction PCF pour une session PDU ou un UE
De souscrire, se désinscrire à des évènements et de transmettre des notifications

Le service Nbsf Management Register permet au PCF d’enregistrer les informations de liaison de session pour un UE au niveau de la fonction BSF. La fonction BSF conserve et fournit l’identité de l’utilisateur, le nom du réseau de données (DNN), les adresses UE et l’adresse PCF pour la session PDU. Ainsi, la fonction SMF déclenche un enregistrement du PCF vers le BSF lorsque le SMF demande le service de création d’un profil de QoS au PCF.

La fonction SMF envoie la requête d’enregistrement au BSF à la réception du message Npcf_SMFPolicyControl_Create requets émis par la fonction SMF.

Le déclencheur est donc le message Npcf_SMFPolicyControm_Create requet, émis par le SMF vers le PCF et ce dernier répond au SMF Npcf_SMFPolicyControl_Create Answer avec la valeur transmise par la fonction BSF au PCF.

Figure 2 : Procédure d’enregistrement

Lorsqu’une fonction AF ou NEF a besoin de communiquer avec une fonction PCF, alors cette fonction invoque le service de découverte pour obtenir l’adresse du PCF concerné

Figure 3: Procédure de découverte

III-2) Proxy BSF

Lorsque le BSF reçoit une requête d’un AF, il doit vérifier s’il a déjà sélectionné un PCF pour la session Rx ; s’il dispose d’un PCF déjà sélectionné pour la session Rx, il transmettra la demande au PCF correspondant. Si le BSF n’a pas de PCF déjà sélectionné, il doit sélectionner un PCF pour gérer la session Rx, puis envoyer la demande par proxy au PCF sélectionné.

La création de la liaison est réalisée lorsque la fonction AF démarre une procédure d’enregistrement.

Figure 4 : BSF en tant que proxy

La requête DIAMETER Authorization Authentication Request (AAR) est transmise par la fonction AF vers la fonction BSF. Cette requête à pour objectif d’autoriser et d’authentifier une demande d’établissement d’une session entrante vers le terminal. En 4G, cette demande était transmise à la fonction PCRF via l’interface Rx.
La fonction BSF sélectionne le PCF s’il est déjà défini, sinon la fonction BSF sélectionne un PCF et fait l’association du PCF avec l’AF (liaison ou Binding).
La fonction BSF transmet la requête AAR au PCF cible avec la même valeur d’AVP Session-Id.
Le PCF renvoie la réponse DIAMETER AAA au BSF.
BSF transmet la réponse DIAMETER AAA à l’AF avec la même valeur d’AVP Session-Id.

III-2) Serveur de redirection BSF

La fonction BSF peut jouer le rôle d’un agent de redirection DIAMETER. Il doit être en mesure de récupérer les informations AVP pour récupérer l’identité de la fonction PCF.

L’AF contacte la fonction BSF lors de l’établissement de la session Rx pour récupérer l’adresse PCF. La fonction de redirection du BSF n’a pas besoin de maintenir des sessions DIAMETER pour transmettre les messages DIAMETER vers le PCF sous le format http2

Ce rôle de redirection permet la coexistence de la fonction BSF et des agents de routage DIAMETER (DRA).

Figure 5: BSF en tant que serveur de redirection

La fonction applicative AF envoie un message DIAMETER AAR au DRA pour établir une nouvelle session de diamètre Rx.
Lors de la réception de la demande à l’étape 1, si le DRA n’a aucune information de liaison stockée dérivée d’une session Gx en cours pour l’abonné, le DRA invoque l’opération de service Nbsf_Management_Discovery au BSF pour obtenir l’ID PCF sélectionné pour une certaine session PDU.
Le BSF répond au DRA avec l’ID PCF.

REMARQUE 2 : Si le DRA n’a stocké aucune information de liaison dérivée d’une session Gx en cours pour un abonné, le DRA doit demander de nouvelles informations de liaison pour chaque établissement de session Rx, car les informations du BSF pourraient avoir changé par rapport à toute information de liaison précédente. » a demandé la DRA.

IV) Exemple avec la VoNR

Lorsqu’un utilisateur se connecte au réseau 5G et initie une session de données, le BSF enregistre les informations de liaison, telles que l’adresse IP assignée et les identifiants de session. Si l’utilisateur se déplace et se connecte à une nouvelle cellule, le BSF met à jour les informations de liaison et assure que la session de données est maintenue sans interruption, en coordonnant les actions avec le SMF et le UPF.

Voici un exemple pour la VoNR ou l’UE contacte le Proxy P-CSCF du réseau IMS pour une demande d’appel. Le PCF concerné doit être connu du P-CSCF. Si le réseau IMS est déployé comme une architecture SBA et peut demander des services en utilisant le protocole HTTP2 alors voici la procédure attendue (Figure : ).

Dans le cas d’une coexistence DIAMETER/Http2, on imagine les rôles de la fonction BSF.

Figure 6 : Exemple de la VoNR

Réferences

23.501 : System architecture for the 5G System (5GS) – (3GPP TS 23.501 version 17.5.0 Release 17)

23.503 : Policy and charging control framework for the 5G System (5GS);
Stage 2 (3GPP TS 23.503 version 16.5.0 Release 16)

29.513 : 5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3, R.16 – V16.6

Les identifiants radios

Posté le 6 mars 2024 by flaunay - 782 vues

Répondre

Les articles précédents traitaient de la procédure de sélection et de re-sélection et le dernier article a permis de présenter les SIBs.

Nous allons maintenant nous intéresser aux identifiants de la cellule et de la station de base

Cellules radioélectriques et identifiants

On appelle cellule radio ou secteur, la zone de couverture radio d’une station de base sur une bande de fréquences (carrier).

Une station de base 4G, nommée eNB, qui supportent plusieurs porteuses couvrent plusieurs cellules (au moins une cellule par porteuses et dans la limite de 256 cellules). Dans le cas général, une station de base 4G propose 5 bandes (bandes B1, B3, B7, B20 et B28) et 3 secteurs par bandes, aura donc 15 cellules.

Une station de base eNB est composée de deux unités : L’unité de bande de base BBU et une tête radio dépotée RRU ou RRH. Par conséquent, il est théoriquement possible que la station de base propose des points d’accès radioélectrique (Multi Transmission Point) et couvrent ainsi plus que 3 secteurs.

Une station de base gNB est décomposée de 3 unités : L’unité centralisée CU, l’unité distribuée DU et une tête radio déportée. Si les unités CU et DU sont centralisées, le nombre de cellules sera limités à 16 mais dans le cas ou le CU et DU sont délocalisées, et qu’un CU contrôle plusieurs DU, 14 bits sont réservés pour l’identification des cellules. Un CU peut contrôler jusqu’à 250 DU et un DU peut avoir 12 cellules, soit 3000 cellules En réservant 14 bits pour l’allocation des cellules, on peut ainsi identifier 16384 cellules.

Les identifiants radio

II-1) PCI

En mode de veille, le mobile est sous la couverture d’une cellule : le mobile est sous un secteur de la station de base et est accroché sur une bande de la station de base. En étant synchronisé sur cette bande, le terminal récupère l’identifiant PCI de la cellule partir du signal de synchronisation primaire et secondaire (1 à 504). L’identifiant PCI est l’identifiant physique de la cellule, et dans la planification des cellules, il faut éviter la collision des PCI [2] entre les secteurs de même bande, de deux stations de base voisines.

On parle de collision quand deux cellules voisines avec le même PCI et de confusion pour le mobile pour lequel deux cellules de la même bande ont le même PCI.

La station de base qui dispose de plusieurs bandes émet le même PCI par bande.

L’identifiant PCI permet donc d’identifier une station de base

Figure 2 : Capture NEMO sur Paris

Note de M Lagrange : L’identifiant PCI permet donc d’identifier une station de base dans une zone géographique donnée. S’il y a une zone où un terminal peut détecter 2 stations de bases différentes, les PCI doivent être différents. En revanche, il n’y aucun problème pour qu’une cellule à Rennes et une cellule à Châtellerault utilisent le même PCI (ex PCI = 218 chez SFR)

Figure 3 : Les cellules dont la valeur PCI = 218 (SFR) [4]

II-2) Identifiant de la station de base et des cellules 4G (5G NSA) : eNB ID (en-gNB ID) , GeNBID, ECGI

Un petit rappel sur le réseau d’accès radio 2G/3G

L’identifiant CGI (Cell Global Identification) est utilisé sur les réseaux d’accès 2G/3G pour identifier de manière unique la cellule. Une cellule est identifié par l’identifiant CI, celui-ci doit être unique dans un LAC donné. Ainsi le CGI est obtenu par le LAI (MCC|MNC|LAC) | CI

Figure 3 : L’identifiant CGI [2]

L’identifiant eNB ID (eNB Identifier) permet d’identifier l’eNB d’un réseau PLMN.

L’identifiant en-gNB ID (en-gNB Identifier) permet d’identifier la station de base en-gNB dans le cas du déploiement 5G NSA

L’identifiant GeNB ID (Global eNB ID) permet d’identifier de manière unique une station de base. Il s’obtient en concaténant l’identifiant réseau PLMN (MCC|MNC) avec l’identifiant eNB ID

L’identifiant eCGI (E-UTRAN CGI) est utilisé sur les réseaux d’accès 2G/3G pour identifier de manière unique la cellule.

Figure 3 : L’identifiant eCGI [2]

Dans le cas des réseaux privés SNPN ( Standalone Non-Public Networks) l’identifiant du réseau NID (Network Identifier) est inclus dans l’identifiant ECGI.

Application

L’identifiant ECGI (E-UTRAN CGI) permet d’identifier la cellule de manière unique. L’ECGI est construit en concaténant le MCC|MNC avec l’identifiant ECI.

L’identifiant ECI est construit par l’identifiant de l’eNB nomme eNB-ID et l’identifiant CI de la cellule. Nous savons qu’un eNB peut avoir au plus 256 cellules. L’identiant de la cellule CI est codé sur 8 bits, donc l’identifiant ECI est égale à 256*l’identifiant eNB + l’identifiant de la cellule CI

Figure 3 : Exemple de trace avec l’application Network Cell Info Lite

Dans l’exemple de la figure 3 (extrait Internet), nous avons les valeurs suivantes :

eNB ID = 87 541

CI (LCID : Long Cell ID) 4

eNB ID | CI = 87541*256+4 = 22 410 500

eCGI = 310 -260 – 22 410 500

II-3) Identifiant de la station de base et des cellules 5G : gNB ID et NCGI

L’identifiant NCGI (NR Cell Global Identifier) est similaire à l’identifiant ECGI en concaténant l’identifiant PLMN du réseau 5G avec l’identifiant de la cellule 5G NCI.

L’identifiant NCI est constitué de 36 bits correspond à la concaténation de l’identifiant gNB ID et de la cellule CI.

L’identifiant gNB est de taille variable entre 22 bits et 32 bits
L’identifiant NCI est donc aussi variable entre 14 bits et 4 bits

Figure 4 : Les identifiants gNB Id et NCGI [3]

A partir de l’identifiant du gNB et de l’identité de la cellule, on peut donc calculer le NCI [3][4]

Références

[1] TS 23.003 Numbering, addressing and identification https://www.etsi.org/deliver/etsi_ts/123000_123099/123003/16.04.00_60/ts_123003v160400p.pdf

[2] Les images sont extraites du site : https://telecommunications4dummies.com/2021/01/31/pci_rules/

[3] https://www.techplayon.com/5g-nr-cell-global-identity-planning/

[4] https://enb-analytics.fr/page_recherche_analyse.html

La re-sélection de cellule : Part 4 (Les SIBs)

Posté le 5 mars 2024 by flaunay - 747 vues

Répondre

Cet article termine la série de sélection et re-sélection de cellules

Nous allons dans cet article reprendre le contenu des informations transportées par les messages RRC SIB1, SIB3, SIB4 et SIB5

SIB1 contient

SIB3 contient

SIB4 contient

SIB5 contient

SIB6 contient

Annexe 1 : SIB1

Exemple de mesure sur Paris – Porte de Versailles (SFR)

RRC SIGNALING MESSAGE

Time: 14:07:44.168

SystemInformationBlockType1 (3GPP TS 36.331 ver 16.6.0 Rel 16)

BCCH-DL-SCH-Message

message

systemInformationBlockType1

cellAccessRelatedInfo

plmn-IdentityList

plmn-IdentityList value 1

plmn-Identity

mcc

mcc value : 2, 0, 8

mnc

mnc value : 1, 0

cellReservedForOperatorUse : notReserved

trackingAreaCode

Bin : ‘B5AA’H (= 46506)

cellIdentity

Bin : ‘976AA07’H (= 158771719)

cellBarred : notBarred

intraFreqReselection : allowed

csg-Indication : false

cellSelectionInfo

q-RxLevMin : -63 (= -126 dBm)

p-Max : 23

freqBandIndicator : 20

schedulingInfoList

schedulingInfoList value 1

si-Periodicity : rf16

sib-MappingInfo

schedulingInfoList value 2

si-Periodicity : rf16

sib-MappingInfo

sib-MappingInfo value : sibType3

schedulingInfoList value 3

si-Periodicity : rf16

sib-MappingInfo

sib-MappingInfo value : sibType4

schedulingInfoList value 4

si-Periodicity : rf32

sib-MappingInfo

sib-MappingInfo value : sibType5

schedulingInfoList value 5

si-Periodicity : rf16

sib-MappingInfo

sib-MappingInfo value : sibType6

si-WindowLength : ms20

systemInfoValueTag : 25

nonCriticalExtension

ims-EmergencySupport-r9 : true

nonCriticalExtension

cellAccessRelatedInfo-v1250

nonCriticalExtension

hyperSFN-r13

Bin : ’20D’H (10 bits)

eDRX-Allowed-r13 : true

Data (hex):

68 48 20 21 B5 AA 97 6A A0 78

1F 54 C8 40 42 02 10 A0 88 84

77 2D 25 88 34 00

Exemple de mesure sur Paris – Parc de Versailles (SFR) :

RRC SIGNALING MESSAGE

Time: 14:07:44.168

SystemInformation (3GPP TS 36.331 ver 16.6.0 Rel 16)

BCCH-DL-SCH-Message

message

systemInformation

criticalExtensions

systemInformation-r8

sib-TypeAndInfo

sib-TypeAndInfo value 1

sib3

cellReselectionInfoCommon

q-Hyst : dB4

speedStateReselectionPars

mobilityStateParameters

t-Evaluation : s60

t-HystNormal : s60

n-CellChangeMedium : 2

n-CellChangeHigh : 4

q-HystSF

sf-Medium : dB0

sf-High : dB0

cellReselectionServingFreqInfo

threshServingLow : 2 (= 4 dB)

cellReselectionPriority : 4

intraFreqCellReselectionInfo

q-RxLevMin : -63 (= -126 dBm)

p-Max : 23

s-IntraSearch : 31 (= 62 dB)

presenceAntennaPort1 : true

neighCellConfig

Bin : ‘0’H (2 bits)

t-ReselectionEUTRA : 2

t-ReselectionEUTRA-SF

sf-Medium : oDot5

sf-High : oDot5

Data (hex):

00 05 42 44 FC 29 A3 EB F8 94

SIB4 :

RRC SIGNALING MESSAGE

Time: 14:07:44.263

SystemInformation (3GPP TS 36.331 ver 16.6.0 Rel 16)

BCCH-DL-SCH-Message

message

systemInformation

criticalExtensions

systemInformation-r8

sib-TypeAndInfo

sib-TypeAndInfo value 1

sib4

intraFreqNeighCellList

intraFreqNeighCellList value 1

physCellId : 483

q-OffsetCell : dB0

Data (hex):

00 09 01 E3 78 00 00

SIB 5 :

RRC SIGNALING MESSAGE

Time: 14:07:44.379

SystemInformation (3GPP TS 36.331 ver 16.6.0 Rel 16)

BCCH-DL-SCH-Message

message

systemInformation

criticalExtensions

systemInformation-r8

sib-TypeAndInfo

sib-TypeAndInfo value 1

sib5

interFreqCarrierFreqList

interFreqCarrierFreqList value 1

dl-CarrierFreq : 2825

q-RxLevMin : -65 (= -130 dBm)

p-Max : 23

t-ReselectionEUTRA : 2

t-ReselectionEUTRA-SF

sf-Medium : oDot5

sf-High : oDot5

threshX-High : 10 (= 20 dB)

threshX-Low : 7 (= 14 dB)

allowedMeasBandwidth : mbw75

presenceAntennaPort1 : true

cellReselectionPriority : 7

neighCellConfig

Bin : ‘0’H (2 bits)

q-OffsetFreq : dB-12

interFreqCarrierFreqList value 2

dl-CarrierFreq : 1501

q-RxLevMin : -65 (= -130 dBm)

p-Max : 23

t-ReselectionEUTRA : 2

t-ReselectionEUTRA-SF

sf-Medium : oDot5

sf-High : oDot5

threshX-High : 7 (= 14 dB)

threshX-Low : 7 (= 14 dB)

allowedMeasBandwidth : mbw50

presenceAntennaPort1 : true

cellReselectionPriority : 6

neighCellConfig

Bin : ‘0’H (2 bits)

q-OffsetFreq : dB-4

Data (hex):

00 0C 5E 05 84 8B AA 55 1E 78

67 80 BB A2 EA 94 E7 7C 2C 00

00 00

SIB 6 :

RRC SIGNALING MESSAGE

Time: 14:07:44.265

SystemInformation (3GPP TS 36.331 ver 16.6.0 Rel 16)

BCCH-DL-SCH-Message

message

systemInformation

criticalExtensions

systemInformation-r8

sib-TypeAndInfo

sib-TypeAndInfo value 1

sib6

carrierFreqListUTRA-FDD

carrierFreqListUTRA-FDD value 1

carrierFreq : 10564

cellReselectionPriority : 3

threshX-High : 16 (= 32 dB)

threshX-Low : 3 (= 6 dB)

q-RxLevMin : -58 (= -115 dBm)

p-MaxUTRA : 24

q-QualMin : -16 (dB)

carrierFreqListUTRA-FDD value 2

carrierFreq : 3075

cellReselectionPriority : 2

threshX-High : 16 (= 32 dB)

threshX-Low : 3 (= 6 dB)

q-RxLevMin : -58 (= -115 dBm)

p-MaxUTRA : 24

q-QualMin : -16 (dB)

t-ReselectionUTRA : 3

Data (hex):

00 11 05 A5 11 C0 61 4A 42 60

1A 80 C2 94 86

La re-sélection de cellule : Part 3

Posté le 4 mars 2024 by flaunay - 718 vues

Répondre

Cet article est la suite de : La re-sélection de cellule : Part 2

II-2-3) Mécanisme de re-sélection

Après avoir étudié les conditions, nous allons maintenant résumer la procédure à partir des critères évoqués précédemment :

Priorité plus haute

La re-sélection vers une cellule de priorité supérieure est réalisée si les 2 conditions suivantes sont remplies :

La puissance du signal Srxlev> Thresh_x,highP pendant la durée de re-sélection Treselection
Plus d’une seconde s’est écoulé depuis le temps ou le mobile campe sur la Serving Cell.

Dans le cas ou l’information ThresServingLowQ est transmis dans le SIB3 alors une 3^ème condition se rajoute :

La qualité du signal Squal > Thresh_x,highQ pendant la durée de re-sélection Treselection

Priorité plus basse

La re-sélection vers une cellule de priorité inférieure est réalisée si les 2 conditions suivantes sont remplies :

La puissance du signal Srxlev> Thresh_{Serving_LowP} pendant la durée de re-sélection Treselection
Plus d’une seconde s’est écoulé depuis le temps ou le mobile campe sur la Serving Cell.

Dans le cas ou l’information ThresServingLowQ est transmis dans le SIB3 alors une 3^ème condition se rajoute :

La qualité du signal Squal > Thresh_x,highQ pendant la durée de re-sélection Treselection

Priorité identique

La re-sélection vers une cellule de même priorité est choisie à partir du classement de la priorité des cellules candidates (équations 5 et 6).

III) Les informations SIB et exemple

Le mobile doit récupérer ces valeurs de priorités qui sont diffusées dans les messages RRC SIB (SIB1, SIB3, SIB4, SIB5, SIB6) ou transmises au mobile lorsqu’il passe de l’état RRC_CONNECTED à l’état RRC_IDLE via la requête RRC Connection Release. On parle alors de priorité dédiée au terminal puisque celles-ci sont définies par l’eNB à partir du profil de l’abonné SPID (Subscriber Profile ID, par exemple, pour un IoT qui ne doit écouter que la bande à 800 MHz en mode de veille).

Lorsque le mobile récupère des priorités dédiées, il ignore les informations portées par le SIB. Les priorités dédiées seront supprimées lorsqu’il passe à l’état RRC_CONNECTED (à l’état connecté, c’est le contrôleur qui gère la mobilité) ou lorsque le temporisateur T320 expire (T320 en 4G, T.322 en 3G et T3230 en 2G).

Concernant les critères de mobilités transmis dans les SIB, les annexes sont des captures réalisées à partir de l’outil NEMO du site de Paris (Porte de Versailles). Nous allons noter les valeurs transmises et détailler ci-dessous les informations des SIBs.

Si on prend l’exemple de la figure 1, et en extrayant des valeurs mesurées par une capture NEMO (cf. annexe), nous avons

RSRP=-94 dBm

Srxlev = Qrxlevmeas – qRxLevMin (SIB1) = -94+126 = 32 dB

S-IntraSearch : 31 (= 62 dB)

S_{nonIntraSearch} n’est pas transmis, la valeur de 0 est donc appliquée.

Srxlev < s-IntraSearch => Il peut y avoir une re-sélection de cellules intrabandes, le mobile doit classer les cellules pour connaitre la cellule candidate.

SIB1

q-RxLev Min = -63 => -126 dBm
q-RxLev Min Offset (Absent)
p-Max = 23 dBm
Freq Band Indicator: B20 (800 MHz)

Les informations SIB suivantes configurent le terminal :

SIB3

Q-hyst : 4 dB
T-evaluation = 60 s
T-Hyst=60 s
n-cell Change Medium : 2
n-cell Change Medium : 4
threshServingLow : 2 (= 4 dB)
cellReselectionPriority : 4
intraFreqCellReselectionInfo
q-RxLevMin : -63 (= -126 dBm)
p-Max : 23 dBl
s-IntraSearch : 31 (= 62 dB)
t-ReselectionEUTRA : 2
t-ReselectionEUTRA-SF
- sf-Medium : oDot5
- sf-High : oDot5

SIB4

PCI Voisine dans la bande : 483
Qoffset = 0 dB

SIB5

dl-Carrier Freq : 2825 => Bande 7 à 2,6 GHz
- q-RxLev Min = -65 => -130 dBm
- p-Max = 23 dBm
- t-ReselectionEUTRA : 2
- t-ReselectionEUTRA-SF
  - sf-Medium : oDot5
  - sf-High : oDot5
- threshX-High : 10 (= 20 dB)
- threshX-Low : 7 (= 14 dB)
- allowedMeasBandwidth : mbw75
- presenceAntennaPort1 : true
- cellReselectionPriority : 7
- q-OffsetFreq : dB-12
dl-Carrier Freq : 1501 => Bande 3 à 1800 MHz
- q-RxLev Min = -65 => -130 dBm
- p-Max = 23 dBm
- t-ReselectionEUTRA : 2
- t-ReselectionEUTRA-SF
  - sf-Medium : oDot5
  - sf-High : oDot5
- threshX-High : 7 (= 14 dB)
- threshX-Low : 7 (= 14 dB)
- allowedMeasBandwidth : mbw75
- presenceAntennaPort1 : true
- cellReselectionPriority : 6
- q-OffsetFreq : dB-12

SIB6 transmet les informations pour une resélection du RAT 3G. Nous ne reprendrons pas les valeurs.

La re-sélection de cellule : Part 2

Posté le 3 mars 2024 by flaunay - 812 vues

Répondre

Cet article est la suite de l’article La re-sélection de cellule : Part 1

Merci à M Le professeur Xavier Lagrange pour la relecture de l’article et ses bons conseils.

2. La re-sélection de cellule

Le terminal continue à rechercher les cellules candidates pour une meilleure qualité radio selon les critères de re-sélection (en excluant les cellules blacklistées). Toutefois,pour réduire les mesures, l’UE ne déclenchera pas de re-sélection si la puissance de réception de la Serving Cell est suffisante (comparativement aux seuils S_intraSearchet S_{nonintraSearch}).

Lorsque la puissance de réception du mobile RSRP est inférieur à l’un des deux seuils (ou au deux), la re-sélection de cellule est guidée par 3 critères :

La priorité de la cellule
La qualité du lien radio
L’accessibilité de la cellule (non blacklistée)

II-1) Le déclenchement de la mesure

La re-sélection de cellule est une procédure permettant au mobile en veille (RRC_IDLE) de sélectionner une nouvelle cellule lorsque le niveau de puissance reçue par la cellule actuelle est inférieur à la condition de re-sélection.

Le mobile connait les valeurs de seuils S_intraSearchet S_{nonintraSearch}, il compare sa puissance de réception au seuil.

La procédure de re-sélection est donc déclenchée lorsque la puissance de réception RSRP de la cellule de service (Serving Cell) est inférieure à un seuil de référence.

On calcule dans un premier temps Srxlev de la Serving Cell (cf. Equation 1 dans le cas du HPLMN)

Srxlev = Qrxlevmeas – qRxLevMin (SIB1)

On sait que si la puissance reçue au niveau du mobile (RSRP nommée Qrxlevmeas) est inférieure à qRxLevMin alors Srxlev<0 et le mobile ne peut plus faire de demande d’accès radio (procédure d’accès aléatoire).

Il est donc nécessaire de faire une re-sélection de cellule avant que le RSRP atteigne la valeur minimale qRxLevMin.

Ainsi, le niveau de déclenchement de re-sélection est défini par l’un des valeurs suivantes contenues dans le SIB3. Il s’agit la marge de puissance avant d’atteindre qRxLevMin :

S_intrasearch pour une re-sélection vers une cellule cible qui utilise la même fréquence
S_{nonintrasearch}pour une cellule cible sur une autre fréquence ou un autre accès radio.

Figure 2 : Seuil de déclenchement de la re-sélection

Une priorité d’accès est associé au type de réseau d’accès radio (RAT). La priorité d’accès 4G est en général supérieure au réseau 3G, lui-même supérieure au réseau 2G (Les types de réseaux d’accès radio RAT ont obligatoirement des priorités différentes).

L’accès radio 4G dispose de plusieurs bandes de fréquences. Une priorité est également associée à chaque bande de fréquences.

Le seuil de déclenchement de la re-sélection (intra bande ou inter-bande/RAT) permet de réduire la consommation du mobile en veille uniquement si nécessaire :

Re-sélection dans la même bande (Intrafréquences) est réalisée lorsque :

Equation 3 : Srxlev < S_IntraSearch

Note de M Lagrange : Ce seuil est en général très élevé 62 dB. Cela signifie que seulement dans le cas où un signal est très fort, le terminal ne fait aucune mesure sur les cellules voisines. C’est très rare en pratique.

Re-sélection d’une autre bande (Interfréquences) ou Inter RAT est réalisée lorsque

2a) Mesures en permanence sur un RAT ou une fréquence de priorité plus élevée

2b) Mesures vers un RAT ou une fréquence de priorité plus faible si la puissance reçue par la Serving Cell est inférieure à un seuil :

Equation 4 : Srxlev < S_{nonIntraSearch}

La cellule cible candidate sera celle de priorité la plus haute parmi toutes les cellules éligibles. Pour être éligible, la puissance mesurée par le mobile doit être supérieure à un seuil d’éligibilité pendant une durée T_reselection.

La re-sélection est donc conditionnée par les deux règles suivantes :

Après l’expiration d’un Timer qui démarre lorsque le mobile re-sélectionne une cellule ce qui empèche la re-sélection immédiate d’une autre cellule.
La puissance mesurée de la cellule candidate est supérieure à un seuil sur une durée de timer

Par conséquent, un terminal qui se déplace très rapidement va parcourir une distance plus importante qu’un terminal à faible vitesse et donc s’éloignera davantage de la Serving Cell. L’atténuation étant au minimum proportionnelle au carrée de la distance le risque de la perte de la couverture radio est importante si la durée de T_reselection est fixe. Le SIB 3 apporte une valeur de timer T_reselection qui dépend de l’état de mobilité du terminal (normal, moyen élevé).

Autre exemple proposé par M Lagrange : imaginons un micro-cellule qui couvre un quai de gare et un train qui la traverse. Le signal reçu par un terminal à bord du train peut être élevé mais pendant un temps très court. Le terminal ne va pas la sélectionner.

Pour connaitre l’état de mobilité, le mobile compte le nombre de re-sélection sur une durée T_evaluation et

si ce nombre est inférieur à un seuil n-cell Change Medium la mobilité est dite normale,
si ce nombre est supérieur à un seuil seuil n-cell Change High la mobilité est dite élevée,
si ce nombre entre les deux, la mobilité est dite moyenne,

II-2) La re-sélection de la cellule

Lorsque la procédure de re-sélection est déclenchée, le mobile fait des mesures de la Serving Cell et des Cellules voisines (Neighbour Cell).

Trois cas sont à étudier :

La cellule candidate est de priorité supérieure
La cellule candidate est de même priorité
La cellule candidate est de priorité plus faible

Si plusieurs cellules candidates sont éligibles, un classement permet de sélectionner la cellule qui a la meilleure qualité radio.

Pour résumer, la re-sélection de cellule est définie par 2 critères (on suppose l’accessibilité de la cellule c’est-à-dire qu’elle n’est pas blacklistée) :

La priorité de la cellule
La qualité du lien radio

II-2-1) La choix de la cellule par priorité

Les opérateurs définissent un niveau de priorité (différents RAT et sur les différentes fréquences), diffusé par les messages SIB (SIB3, SIB4, SIB5, SIB6).

Priorité plus haute : critère Thresh_x,high

L’UE va camper sur la cellule de priorité la plus haute si les conditions radios et la qualité du signal sont suffisantes sur une durée suffisante.

L’opérateur défini un seuil Thresh_high qui permet au mobile de sélectionner la cellule tant que le critère de seuil est atteint sur la durée T_reselection.

Priorité plus basse

L’UE va camper sur la cellule de priorité plus basses si les conditions radios et la qualité du signal sont suffisantes sur une durée suffisante.

L’opérateur défini un seuil Thresh_Low qui permet au mobile de sélectionner la cellule tant que le critère est atteint sur la durée T_reselection

Une valeur faible pour le seuil Thresh favorisera la re-sélection

II-2-2) Le classement des cellules de même priorité

Un classement de cellules de même priorité est basé sur le critère de rang R (Ranking). On compare ainsi R_s la valeur mesurée de la Serving Cell aux valeurs de rang R_n mesurées sur les cellules voisines

Equation 5 : R_s=Q_meas,s+Q_hyst

Equation 6 : R_n= Q_meas,n-Q_offset

Avec Q_meas,sla puissance RSRP de la Serving Cell, Q_meas,nla puissance RSRP de la Neighbour Cell. La valeur Q_hyst est un décalage pour éviter l’effet ping pong. La valeur Q_offsetpermet d’apporter un décalage pour une mesure intra-bande et un décalage inter-bande pour prendre en compte un affaiblissement plus faible lorsque la bande candidate est de plus basse fréquence (la mesure du RSRP de cette bande est donc meilleure).

Si une cellule voisine (Neihbourg Cell) est mieux classée que la Serving Cell (Rn>Rs) pendant la durée T_reslection, alors la ré-selection de cellule s’opère.

La re-sélection de cellule : Part 1

Posté le 2 mars 2024 by flaunay - 931 vues

Répondre

Je remercie lMr e professeur Xavier Lagrange pour sa relecture et ses très bon conseils.

Introduction de M Lagrange :

l’opérateur déploie plusieurs bandes de fréquence. Sur chaque bande, une voie balise. A même puissance de transmission, le signal reçu sera d’autant plus puissant que la fréquence est basse.
pour assurer une bonne couverture à l’intérieur des bâtiments, il y a recouvrement important entre les cellules surtout sur les fréquences basses et en extérieur.
En état de veille, un terminal est positionné (campe) sur une voie baise d’un eNB (et donc sur une bande de fréquence). S’il fait un accès, les premiers échanges UE-réseau se sont font cet eNB sur cette bande. Le réseau peut demander à un UE de changer d’eNB ou de bande (handover) mais cela a un coût de signalisation.
L’enjeu est donc de s’assurer que les terminaux sont harmonieusement répartis en veille sur les fréquences et dans les cellules. Il faut éviter que tous les terminaux sélectionnent le 700 MHz car cela créerait un engorgement sur cette bande.
Par ailleurs, les terminaux sont mobiles et les signaux radios reçus sont fluctuants. Il faut éviter qu’un terminal change très fréquemment de cellules ou de bande (par exemple plusieurs fois par secondes).
on définit donc
- une règle de sélection ou non d’une cellule+bande qui vise à s’assurer que si le terminal l’utilise, le signal reçu de l’eNB est suffisant pour que l’UE décode correctement les messages ou données et le signal émis par l’UE est suffisant pour que l’eNB puisse le décoder. Il ne s’agit pas de sélectionner une cellule mais d’établir une liste (cf. articles précédents)
- une règle de re-sélection. L’objectif est double : d’une part, établir une liste ordonnée en construisant un indicateur intégrant de nombreux paramètres pour déterminer la meilleure cellule, d’autre part, intégrer des mécanismes de stabilisation (via des hystérésis) pour éviter de trop rapides alternances. La cellule choisie n’est pas au final nécessairement la première dans la liste mais celle présentant le meilleur compromis

A la date d’écriture de l’article, le réseau 5G SA n’est pas encore déployé. L’article se concentre sur la sélection de cellule sur le réseau 4G [1].

La sélection ou re-sélection de cellule a lieu lorsque le mobile est à l’état RRC_IDLE. Lorsque le mobile est connecté avec le contrôleur, il est dans l’état RRC_CONNECTED et la re-sélection de cellule est réalisée par l’eNB : il s’agit du HandOver. Le HandOver est déclenché à partir des mesures reportées par le mobile vers l’eNB. Ces valeurs sont transmises lorsqu’un évènement (A1, A2, A3, A4, A5, B1 ; B2) a lieu. La configuration de ces évènements est transmise par l’eNB au mobile dans le message RRC_Reconfiguration. Ces évènements ne seront pas explicités dans cet article.

Sélection de cellule

Lorsque le mobile s’allume, il cherche la meilleure cellule parmi les cellules candidates (cf. article : Sélection de cellules – Principes Généraux). Cette sélection de cellule est également réalisée après une perte de couverture radio et périodiquement lorsque l’UE n’est pas sur son réseau home HPLMN.

On appelle la Serving Cell, la cellule sur laquelle le mobile campe. La cellule est un secteur géographique couvert par une bande radio. Si la station de base exploite plusieurs bandes de fréquence alors le mobile doit sélectionner le réseau opérateur, le type d’accès radio (RAT 2G/3G/4G) et la bande radio la plus prioritaire.

Nous avons vu que la carte UICC contient la liste des PLMN et RAT (4G/3G/2G) avec un ordre de priorité.

La sélection de cellule s’effectue en recherchant d’abord le RAT prioritaire du réseau à partir des informations contenues dans la SIM et par comparaison avec le signal de diffusion SIB1 de la cellule candidate.

Même si la puissance du signal SIB1 est suffisante pour être décodée, le mobile doit vérifier que la cellule n’est pas blacklistée et que les critères de réception Srxlev et de qualité du signal Squal de la cellule candidate sont positifs.

Le calcul du critère Srxlev dépend de la puissance de réception RSRP (cf. article) et des seuils de configuration Qrxlevmin, Qrwlevelminoffset et Pcompensation Ces informations sont transmises dans le SIB1. Si une information est absente, le terminal prend 0 dB comme valeur de référence.

Equation 1: S_rxlev= RSRP – (Q_rxlevmin+Q_{rwlevelminoffset})-P_compensation>0

Le terminal est définie par une puissance de transmission maximale (Ppowerclass). La puissance de compensation est le différence entre la puissance maximale de la cellule et la puissance maximale du mobile. Ainsi, sI la puissance de transmission du mobile (par exemple 17 dBm) est inférieure à la puissance maximale de la cellule (Pmax émis dans le SIB1 par exemple 23 dBm) alors la valeur de compensation est égale à 6 dB ce qui rend la sélection de la cellule plus difficile puisque S_rxlev>0

Le calcul du critère Squal dépend de la qualité de réception et de seuil de configurations Qqualmin, Qqualminoffset

Equation 2 : S_qual= RSRQ – (Q_qualmin+Q_{qualminoffset})>0

Si l’une des deux valeurs est négative, le mobile ne pourra pas déclencher la procédure d’accès aléatoire, et il cherche donc à sélectionner une cellule ou un RAT apportant une meilleure réception.

Q_rxlevmin est le niveau de puissance minimal reçu au niveau du terminal qui lui permet d’accéder à la cellule.

Q_qualmin est le niveau de qualité minimal calculé au niveau du terminal qui lui permet d’accéder à la cellule.

Les offsets Q_{rwlevelminoffset} et Q_{qualminoffset} sont utilisés pour la recherche périodique du HPLMN lorsque le mobile campe sur une cellule du réseau visité VPLMN. Cela permet de réduire la valeur Q_rxlevmin/ Q_qualminet favoriser le critère du réseau home.

La détection d’une cellule est réalisée à partir des signaux de synchronisation PSS et SSS. A partir du PSS/SSS, le mobile récupère la valeur PCI (Physical Cell Identifier) de la station de base pour un RAT donnée. Ainsi, on peut déterminer une station de base à partir de son PCI et les cellules sur chacune des bandes auront le même indicateur PCI.

Pour voir un exemple de mesure, Cf article https://blogs.univ-poitiers.fr/f-launay/2024/03/06/les-identifiants-radios/

Note de M Lagrange : Utiliser le même PCI pour la même cellule et différentes bandes n’est pas obligatoire (Orange ne le faisait pas il y a encore quelques mois). Ce qui compte c’est le couple PCI-EARFNC

Frédéric Launay

Les réseaux de mobiles 4G et 5G

Archives pour la catégorie Non classé

Intégration de la détection et de la communication : ISAC Cas d’usage 11 à 15

Résumé du cas d’utilisation 5.12 : Détection assistée par le réseau pour éviter les collisions de drones (UAV)

Résumé du cas d’utilisation 5.13 : Détection d’intrusion de drones (UAV)

Résumé du cas d’utilisation 5.14 : Gestion du trafic dans les sites touristiques

Intégration de la détection et de la communication : ISAC Cas d’usage 6 à 10

CHO : Conditionnal Handover, DAPS HO et H.O Traditionnel

La modulation 6G : De l’OFDM à l’OTFS – Article 2

La fonction BSF

Les identifiants radios

La re-sélection de cellule : Part 4 (Les SIBs)

La re-sélection de cellule : Part 3

La re-sélection de cellule : Part 2

La re-sélection de cellule : Part 1

Résumé du cas d’utilisation 5.12 : Détection assistée par le réseau pour éviter les collisions de drones (UAV)

Résumé du cas d’utilisation 5.13 : Détection d’intrusion de drones (UAV)

​Résumé du cas d’utilisation 5.14 : Gestion du trafic dans les sites touristiques

Résumé du cas d’utilisation 5.14 : Gestion du trafic dans les sites touristiques