Archives de l’auteur : flaunay

Comprendre le concept du modèle ML/IA – Sur le RAN – Partie 1

Posté le by - 342 vues
Répondre

L’apport de l’IA sur la couche L1

Introduction

 

Le RAN est un système complexe nécessitant la configuration précise de centaines de paramètres. L’optimisation manuelle était historiquement laborieuse et coûteuse surtout en 2G avec l’ingénierie cellulaire.

Les réseaux auto-organisés (SON – Self Optimized Networks) ont émergé pour automatiser la planification, la configuration et l’optimisation. Les premiers SON utilisaient des approches heuristiques avec des règles prédéfinies. Mais ces méthodes sont limitées face à la complexité croissante des réseaux modernes.

L’IA/ML offre une opportunité de dépasser ces limitations grâce à l’apprentissage dynamique. L’architecture 6G sera Native-IA.

L’AI native est définie [2] comme « le concept d’avoir des capacités d’IA intrinsèquement fiables, où l’IA est une partie naturelle de la fonctionnalité, en termes de conception, déploiement, opération et maintenance ».

Une implémentation AI native s’appuie sur un écosystème basé sur les données et la connaissance, où les données et connaissances sont consommées et produites pour réaliser de nouvelles fonctionnalités basées sur l’IA ou pour remplacer des mécanismes statiques basés sur des règles par une IA adaptative et apprenante selon les besoins.

II) IA Native

 

L’architecture AI native comporte quatre aspects principaux:

1. Intelligence partout (Intelligence everywhere)

  • L’IA doit pouvoir être exécutée partout où cela a du sens selon une analyse coût-bénéfice
  • Cela inclut tous les domaines du réseau, toutes les couches de la pile, tous les sites physiques (du central à la périphérie), et potentiellement même sur les appareils mobiles
  • Des environnements d’exécution IA doivent être disponibles partout, et des environnements d’entraînement peuvent être co-localisés si nécessaire.

2. Infrastructure de données distribuée

  • L’exécution et l’entraînement des modèles d’IA nécessitent que les données et ressources de calcul (comme les GPU) soient disponibles partout
  • Les données disponibles partout permettent aux modèles de s’étendre au-delà des frontières actuelles des couches et domaines
  • L’infrastructure doit gérer les contraintes temporelles des données (date de péremption, contraintes légales, volume)
  • Les infrastructures de données et les orchestrateurs de modèles doivent interagir: parfois les données sont transportées vers l’intelligence, et parfois l’intelligence doit être rapprochée des données

3. Zero-touch

  • La gestion de l’intelligence et de l’infrastructure de données doit être automatisée
  • Plutôt que d’introduire de nouvelles opérations manuelles ou automatisées, l’objectif est d’atteindre des opérations entièrement autonomes
  • Les humains restent en contrôle en exprimant des exigences au système et en supervisant leur réalisation, mais sans dicter les actions spécifiques à prendre
  • Cette approche permet un réseau autonome avec des capacités d’auto-configuration, auto-guérison, auto-optimisation et auto-protection

4. IA en tant que service (AIaaS)

  • Les fonctions liées à l’IA et à la gestion des données peuvent être exposées comme services à des parties externes
  • Exemples: gestion du cycle de vie des modèles d’IA (entraînement, environnement d’exécution) ou aspects de manipulation des données (exposition de données)
  • Cette exposition transforme le réseau en plateforme d’innovation
  • Les utilisateurs de ces services peuvent être le fournisseur de services lui-même ou ses clients

Structure de l’architecture AI native

L’architecture AI native peut être représentée comme un système où l’intelligence et l’infrastructure de données traversent toutes les couches traditionnelles du réseau:

  • Applications
  • Gestion, Orchestration, Monétisation
  • Accès, Mobilité, Applications réseau
  • Infrastructure cloud
  • Transport

 

III) IA sur la couche Physique

Les applications clés sont décrites sur la figure 1 [1] : gestion des non-linéarités des émetteurs/récepteurs, adaptation de liaison, estimation de canal (CSF : Channal State Feedback).

 

 

Figure 1 : Cas d’usage de l’IA sur la couche physique RAN [1]

Introduction à l’IA dans la couche physique

Les applications de l’IA dans la couche physique se concentrent principalement sur:

  • La gestion des non-linéarités des émetteurs et récepteurs
  • L’amélioration de l’adaptation de liaison au niveau de la station de base et des équipements utilisateurs
  • L’optimisation de l’estimation de canal et des signaux de référence
  • L’exploration du codage de canal piloté par l’IA

Les travaux des groupes 3GPP dans les Release 18 et 19 ont également exploré la prédiction de canal, la compression pour des retours d’information plus efficaces, et les avancées dans la gestion de faisceau et le positionnement.

Le retour d’information sur l’état du canal (CSF) amélioré par l’IA

Importance et défis du CSI

La technologie TDD (Time Division Duplex) permet d’obtenir, dans le cas d’un canal quasi-stationnaire, une réciprocité parfaite entre la liaison montante et la liaison descendante. Ainsi la connaissnce du canal, via le CSI de la liaison descendante est disponible à la station de base à partir de la mesure du signal de sondage en liaison montante. Cependant, dans un système FDD (Frequency Division Duplex) ou un système TDD avec réciprocité non idéale, le CSI de la liaison descendante est acquis par rapport de l’UE.

Dans ce cas, les défis principaux incluent:

  • La dimensionnalité élevée du CSI dans les systèmes MIMO massifs à large bande (le nombre de CSI étant de 32 du R.15 au R.18 et 128 à partir de la R.19).
  • La surcharge associée à l’acquisition du CSI réduit les ressources radio disponibles
  • Les contraintes liées aux périodes de cohérence de canal limitées

Approches traditionnelles et leurs limites

A partir de la 4G, l’utilisation de mots de codes( codebooks CSI) permet de comprimer le CSI à remonter (dans le domaine spatial MIMO et fréquentiel CA). Le nombre d’informations étant élevée, cela nécéssite :

  • Demandes élevées de bande passante en liaison montante
  • Précision réduite dans la reconstruction de canal à la station de base
  • Structure CSI prédéfinie qui manque d’adaptabilité

Solutions basées sur l’IA/ML

L’IA/ML offre une approche pilotée par les données qui détermine dynamiquement le contenu du message de retour d’information. Cette approche est avantageuse car:

  • Les modèles IA/ML sont entraînés sur des réalisations de canal réelles
  • Ils peuvent s’adapter à différents scénarios
  • Ils permettent une compression plus efficace
  • Ils améliorent l’équilibre entre surcharge de feedback et précision de reconstruction

Un modèle IA/ML à deux faces pour le retour CSI est proposé pour réduire la charge des informations :

  • L’encodeur basé sur un réseau neuronal au niveau de l’émetteur (UE) compresse et quantifie les caractéristiques du canal
  • Le décodeur basé sur un réseau neuronal au niveau du récepteur (station de base) reconstruit les caractéristiques du canal
  • La paire encodeur-décodeur est entraînée ensemble pour une optimisation de bout en bout

Travaux 3GPP et jalons importants pour le CSF

Les cadres à l’étude pour l’amélioration du retour CSI par l’IA incluent:

  • Des modèles à face unique pour la prédiction CSI
  • Des modèles à deux faces pour la compression CSI

Le groupe de travail 3GPP RAN1 a étudié l’évaluation de la compression en fréquence et spatiale dans la Release 18, puis a exploré des sous-cas d’utilisation avec compression temporelle dans la Release 19. Des évaluations approfondies ont été menées sur la généralisation à divers scénarios, l’évolutivité à diverses configurations, et les aspects de collaboration multi-fournisseurs.

Pour les modèles à deux faces, diverses architectures ont été envisagées, comme les réseaux de neurones convolutifs (CNN), les mémoires à court et long terme (LSTM), et les transformers. Les approches d’entraînement incluent:

  • L’entraînement conjoint du modèle à deux faces d’un seul côté
  • L’entraînement conjoint du modèle à deux faces du côté réseau et du côté UE respectivement
  • L’entraînement séparé du côté réseau et du côté UE

Un défi majeur dans le déploiement du modèle à deux faces est la complexité de la collaboration inter-fournisseurs.

Des modèles hyper-locaux ont également été étudiés pour exploiter la cohérence spatiale, permettant une meilleure compression des échantillons de canal collectés dans une région locale par rapport aux données globales.

La gestion de faisceau (BM) améliorée par l’IA

Importance et défis du MIMO massif

Si le MIMO massif est une technique clé dans les systèmes 5G, elle utilise d’un nombre élevé de réseaux d’antennes pour réaliser des gains de formation dans une direction donnée. La gestion de faisceau est cruciale pour établir et maintenir la connexion entre la station de base et l’UE dans des conditions de canal dynamiques.

Les défis principaux incluent:

  • Inefficacité du protocole de balayage de faisceau, particulièrement pour les bandes de fréquences plus élevées
  • Surcharge de messagerie
  • Codebooks sous-optimaux avec une approche « taille unique »
  • Nouveaux cas d’utilisation nécessitant des performances ciblées sous conditions de mobilité

Solutions basées sur l’IA/ML

Face aux défis des cadres de gestion de faisceau avec recherche exhaustive, les techniques d’IA/ML sont explorées pour:

  • Réduire le temps de réponse et la charge de calcul
  • Améliorer la sélection de faisceau basée sur des informations contextuelles
  • Optimiser la performance réseau sous différentes conditions

Les solutions de gestion de faisceau basées sur l’IA/ML se répartissent principalement en:

  • Apprentissage supervisé: utilisant des relations préétablies entre entrées et sorties pour prédire les meilleurs faisceaux
  • Apprentissage par renforcement: déployant un apprentissage par essai-erreur et basé sur les récompenses sans nécessiter de connaissances préalables des canaux

Travaux 3GPP et standardisation

L’interface air IA-native supportant des algorithmes IA/ML pour la gestion de faisceau a été étudiée dans la Rel-18 et spécifiée dans la Rel-19. Les objectifs incluent:

  • Réduire la consommation d’énergie de l’UE en mesurant moins
  • Améliorer l’efficacité énergétique du réseau en transmettant moins de signaux de référence

La prédiction de faisceau s’effectue dans les domaines spatial et/ou temporel, avec des prédictions côté UE et côté réseau. Pour la prédiction temporelle de faisceau, les mesures de puissance des signaux de référence (RSRP) passées sont utilisées pour prédire les meilleurs faisceaux à des instances futures, améliorant ainsi la performance sous conditions de mobilité.

Le document discute également de la généralisation des modèles IA/ML à travers différents scénarios et de la surveillance des performances des modèles pendant l’inférence.

Le positionnement amélioré par l’IA

Importance et limitations des méthodes traditionnelles

Le positionnement est présenté comme un facilitateur clé pour diverses applications, notamment la sécurité, la conduite autonome et l’IoT industriel. Les signaux sans fil peuvent être échangés entre un UE et des points de transmission et de réception (TRP) pour estimer la distance et/ou l’angle en ligne de vue (LOS).

Les méthodes de positionnement 5G NR standard incluent:

  • Différence de temps d’arrivée en liaison descendante/montante (TDoA)
  • Méthodes basées sur l’angle comme l’angle de départ en liaison descendante (AoD)
  • Angle d’arrivée en liaison montante (AoA)
  • Temps d’aller-retour multiple

Ces méthodes supposent une condition LOS entre l’UE et le TRP, ce qui peut conduire à des erreurs lorsque l’UE est en condition de non-ligne de vue (NLOS).

Solutions basées sur l’IA/ML

L’IA/ML est présentée comme une solution pour améliorer la précision du positionnement en conditions NLOS en:

  • Analysant les chemins de propagation de l’environnement sans fil
  • Apprenant leur correspondance avec les informations de localisation
  • Créant un modèle qui fait correspondre les mesures de canal dans le domaine temporel à la localisation de l’UE

Travaux 3GPP et résultats

Dans l’étude de la Release 18, le groupe 3GPP RAN1 a démontré:

  • Une précision au niveau sous-métrique du positionnement IA/ML dans des conditions NLOS extrêmes
  • Une amélioration significative par rapport aux approches de positionnement classiques (plus de 10 mètres d’erreur)

Deux cas d’utilisation ont été identifiés:

  • Positionnement IA/ML direct: le modèle produit les coordonnées de localisation de l’UE
  • Positionnement assisté par IA/ML: le modèle produit une information de mesure de positionnement intermédiaire

Des évaluations approfondies ont été menées pour comprendre:

  • La généralisation et la sensibilité des modèles
  • L’impact des erreurs de synchronisation
  • Les variations temporelles du canal
  • Les déploiements avec différents encombrements

Pour le déploiement réseau, cinq cas ont été identifiés selon:

  • Le type de sortie du modèle
  • L’endroit où s’exécute le modèle (UE, LMF, station de base)

Dans la Release 19, 3GPP RAN1, a spécifié le support pour le positionnement IA/ML, priorisant certains cas et se concentrant sur l’identification de mesures améliorées pour l’entrée du modèle et la sortie du modèle.

Conclusion

L’IA transforme la couche physique des réseaux cellulaires en apportant des améliorations significatives dans:

  • Le retour d’information sur l’état du canal, permettant une compression plus efficace et une meilleure reconstruction
  • La gestion de faisceau, optimisant la sélection de faisceau et réduisant la surcharge de signalisation
  • Le positionnement, atteignant une précision sous-métrique même dans des conditions défavorables

La progression vers des réseaux « IA-natifs » où l’intelligence artificielle est intégrée dès la conception promet d’améliorer considérablement les performances, la fiabilité et l’efficacité des systèmes de communication sans fil.

 

 

Références

[1] 5G America : Artificial Intelligence in Cellular Networks – Dec 2024 https://www.5gamericas.org/wp-content/uploads/2024/12/AI-Cell-Networks-Id-.pdf

[2] Ericcson : Defining AI native: A key enabler for advanced intelligent telecom network, https://www.ericsson.com/en/reports-and-papers/white-papers/ai-native

Comprendre le concept du modèle ML/IA – Des cas d’usages TR 28.908

Posté le by - 290 vues
Répondre

Les uses-case IA en 5G

A partir du document 3GPP TR 28.908 version 18.0.0 Release 18 « Study on Artificial Intelligence/Machine Learning (AI/ ML) management », cet article résume les cas d’usages.

Données d’événements pour l’entraînement ML (5.1.1)

Ce cas d’usage concerne la préparation de données prétraitées pour l’entraînement des modèles ML. Plutôt que d’utiliser toutes les données brutes (qui peuvent contenir des informations redondantes ou biaisées), le système identifie et stocke des événements réseau riches en information. Cela permet de réduire les coûts de stockage et de traitement tout en maintenant des données historiques pertinentes pour l’entraînement des modèles ML.

Validation de modèle ML (5.1.2)

Durant le processus d’entraînement ML, le modèle généré doit être validé. L’objectif est d’évaluer la performance du modèle sur des données de validation et d’identifier les écarts de performance entre les données d’entraînement et de validation. Si l’écart n’est pas acceptable, le modèle doit être réajusté avant d’être mis à disposition du consommateur pour l’inférence.

Test de modèle ML (5.1.3)

Après l’entraînement et la validation d’un modèle, il est nécessaire de le tester pour vérifier son fonctionnement correct dans certains contextes d’exécution ou avec des jeux de données spécifiques. Les tests peuvent impliquer des interactions avec des tiers. Le cas d’usage permet au consommateur d’évaluer la performance du modèle via un processus de test avec des données fournies par le consommateur avant de l’appliquer à la fonction d’inférence cible.

Ré-entraînement de modèle ML (5.1.4)

Un modèle ML entraîné peut nécessiter un ré-entraînement lorsque sa performance se dégrade ou lorsque le contexte d’exécution change. Ce cas d’usage décrit le processus de ré-entraînement du modèle avec de nouvelles données sans changer le type d’inférence (entrées/sorties). Le producteur peut initier le ré-entraînement basé sur des seuils de performance ou extraire les échantillons de données les plus pertinents pour optimiser le processus.

Entraînement conjoint de modèles ML (5.1.5)

Une fonction d’inférence AI/ML peut utiliser plusieurs entités ML pour effectuer des inférences. Ces entités peuvent opérer de manière coordonnée (en séquence ou structure plus complexe). Ce cas d’usage permet d’entraîner ou ré-entraîner conjointement ces entités ML coordonnées, afin que l’ensemble puisse accomplir une tâche plus complexe avec une meilleure performance.

Rapports et analyses sur l’efficacité des données d’entraînement (5.1.6)

Pour l’entraînement des modèles ML, une grande quantité de données n’ajoute pas nécessairement de valeur. Ce cas d’usage permet d’évaluer la contribution de chaque instance de données ou type de données d’entrée au processus d’entraînement, d’analyser les modèles de données les plus efficaces, et de corréler les données de mesure pour optimiser l’entraînement ML.

Contexte ML (5.1.7)

Le cas d’usage 5.1.7 traite du contexte ML (MLContext), qui représente l’ensemble des statuts et conditions liés à un modèle ML. Ce contexte peut inclure les caractéristiques du réseau telles que définies dans 3GPP TS 28.104, mais aussi d’autres conditions applicables au modèle ML qui ne font pas partie des caractéristiques réseau, comme l’heure de la journée ou la saison de l’année.

Les différences dans le contexte réseau, c’est-à-dire l’état du réseau sous lequel les données sont collectées pour produire des analyses, affectent significativement les analyses produites. De même, les changements dans le contexte ML, comme les caractéristiques des données liées à l’état du réseau et aux conditions utilisées pour l’entraînement, les tests et le déploiement du modèle ML, peuvent affecter les performances du modèle. Ces changements peuvent représenter un problème pour le modèle ML et nécessitent donc des capacités de gestion spécifiques.

Le cas d’usage comporte trois sous-cas principaux:

  1. Surveillance et signalement du contexte ML: Le contexte ML doit être identifié en caractérisant les données d’entrée pour lesquelles le modèle ML est conçu. La surveillance de ce contexte permet de détecter les changements et anomalies qui pourraient dégrader les performances du modèle. Le consommateur du service AI/ML doit être informé de ces changements de contexte observés.
  2. Mobilité du contexte ML: Dans de nombreux cas d’automatisation réseau, une fonction d’inférence AI/ML ne peut pas couvrir l’ensemble du réseau avec une seule instance de modèle ML. Un modèle ML peut être entraîné pour un contexte local spécifique, et de même, un contexte différent peut s’appliquer pour l’inférence. Le contexte des entités ML doit donc distinguer entre le contexte de génération de décisions, le contexte de collecte de mesures ou de données, et le contexte de préparation avant activation pour l’inférence.
  3. Mode veille pour le modèle ML: Lorsque plusieurs instances d’entités ML sont nécessaires pour couvrir différentes parties du réseau, des transferts de contexte d’apprentissage automatique, ou « transferts », entre les entités ML couvrant différentes zones de validité sont nécessaires. Un exemple concret est celui d’un modèle ML prédictif pour le transfert intercellulaire, où le modèle doit être déployé dans l’équipement utilisateur (UE) et mis à jour lorsque l’UE change de cellule. Pour minimiser les délais de déploiement et d’initialisation du nouveau modèle, un « champ de préparation » peut être défini pour chaque modèle ML, indiquant la zone dans laquelle le modèle est déployé et initialisé mais pas encore activé pour l’inférence.

Ce cas d’usage met en évidence l’importance de la gestion du contexte ML pour assurer des performances optimales des modèles ML dans des environnements réseau dynamiques et complexes. Il souligne également la nécessité de définir et gérer différents types de contextes (surveillance, validité, préparation) pour faciliter les transitions fluides entre modèles ML dans des scénarios de mobilité.

Découverte et cartographie des capacités du modèle ML (5.1.8)

Une fonction réseau ou de gestion qui applique l’IA/ML peut avoir une ou plusieurs entités ML, chacune avec des capacités spécifiques. Ce cas d’usage permet d’identifier les capacités des entités ML existantes (capacités de prise de décision ou d’analyse) et de les associer à des logiques d’exécution spécifiques, facilitant leur utilisation pour répondre aux besoins d’automatisation.

Gestion des mises à jour AI/ML (5.1.9)

En raison de la complexité et de la nature changeante du réseau, les entités ML déployées peuvent ne plus être applicables après une période de fonctionnement. Ce cas d’usage permet au producteur de mettre à jour les entités ML et d’informer le consommateur autorisé du statut de mise à jour, assurant ainsi une performance d’inférence optimale dans le réseau ou système.

Évaluation de performance pour l’entraînement ML (5.1.10)

Ce cas d’usage concerne l’évaluation de la performance durant l’entraînement ML, permettant au consommateur de sélectionner les indicateurs de performance appropriés, de comprendre et configurer le comportement du modèle ML, et d’appliquer des politiques basées sur la performance pour l’entraînement et les tests ML.

Gestion de configuration pour la phase d’entraînement ML (5.1.11)

L’entraînement ML peut être initié par le consommateur ou le producteur, et peut consommer des ressources significatives. Ce cas d’usage permet au consommateur de contrôler l’entraînement ML initié par le producteur via des configurations, notamment des politiques pour déclencher l’entraînement et des mécanismes d’activation/désactivation de la fonction d’entraînement ML.

Transfert de connaissances ML (5.1.12)

Ce cas d’usage permet d’utiliser les connaissances contenues dans un ou plusieurs modèles ML existants pour produire ou améliorer une nouvelle capacité ML. Il comprend la découverte des connaissances partageables et le partage de connaissances pour le transfert d’apprentissage, sans nécessairement transférer le modèle ML lui-même.

Historique d’inférence AI/ML (5.2.1)

Pour différents besoins d’automatisation, les fonctions réseau et de gestion peuvent appliquer des fonctionnalités ML pour faire des inférences dans différents contextes. Ce cas d’usage permet de suivre l’historique des décisions d’inférence et du contexte dans lequel elles sont prises, permettant d’évaluer la pertinence des décisions ou de détecter des dégradations dans la capacité de prise de décision du modèle.

Orchestration de l’inférence AI/ML (5.2.2)

Un système d’automatisation réseau peut impliquer plusieurs fonctions d’inférence AI/ML, chacune ayant une vue limitée du réseau. Ce cas d’usage facilite l’orchestration de leur fonctionnement et de l’exécution des actions recommandées, incluant le partage de connaissances sur les actions exécutées et leurs impacts, ainsi que le déclenchement et la coordination des fonctions d’inférence AI/ML.

Coordination entre les capacités ML (5.2.3)

Pour le ML dans le 5GC ou RAN, les capacités ML peuvent nécessiter une coordination avec les analyses de gestion 3GPP pour améliorer la performance globale. Ce cas d’usage permet l’alignement des capacités ML entre 5GC/RAN et le système de gestion 3GPP, combinant leurs résultats d’analyse pour améliorer la précision des prédictions globales.

Chargement de modèle ML (5.2.4)

Ce cas d’usage concerne le processus de mise à disposition d’un modèle ML dans les environnements opérationnels. Après qu’un modèle ML répond aux critères de performance, il peut être chargé dans une fonction d’inférence cible, que ce soit à la demande du consommateur ou sur initiative du producteur selon une politique de chargement prédéfinie.

Émulation d’inférence ML (5.2.5)

Après la validation d’un modèle ML durant son développement, l’émulation d’inférence est nécessaire pour vérifier son fonctionnement correct dans des contextes d’exécution spécifiques. Ce cas d’usage permet au consommateur de demander l’exécution d’une capacité AI/ML dans un environnement d’émulation et de gérer le processus d’émulation, y compris dans différents environnements selon le niveau de confiance.

Évaluation de performance pour l’inférence AI/ML (5.2.6)

En phase d’inférence, la performance de la fonction d’inférence et du modèle ML doit être évaluée par rapport aux attentes du consommateur. Ce cas d’usage permet la sélection et l’application d’indicateurs de performance basés sur les politiques du consommateur, ainsi que l’abstraction des métriques de performance pour faciliter leur interprétation.

Gestion de configuration pour la phase d’inférence AI/ML (5.2.7)

La fonction d’inférence AI/ML doit être configurée pour conduire l’inférence conformément aux attentes du consommateur. Ce cas d’usage permet la configuration de la fonction d’inférence et l’activation/désactivation des modèles ML, y compris l’activation partielle ou progressive des capacités d’inférence AI/ML selon des politiques prédéfinies.

Contrôle de mise à jour AI/ML (5.2.8)

Lorsque les capacités d’un modèle ML se dégradent, le consommateur doit pouvoir déclencher des mises à jour. Ce cas d’usage permet au producteur d’informer le consommateur de la disponibilité de nouvelles capacités et au consommateur de demander la mise à jour des modèles ML avec des exigences de performance spécifiques.

Apprentissage machine fiable (5.3.1)

Ce cas d’usage concerne la gestion de la fiabilité AI/ML pendant l’entraînement, les tests et l’inférence. Il vise à garantir que le modèle est explicable, équitable et robuste à travers la définition d’indicateurs de fiabilité, le prétraitement des données selon des mesures de fiabilité, et l’application de techniques de fiabilité pendant l’entraînement, l’inférence et l’évaluation.

Comprendre le concept du modèle ML/IA – Partie 3

Posté le by - 333 vues
Répondre

Cet article est destiné à présenter un exemple concrent d’ agents IA (agentic AI) dans le contexte de la 6G et un scénario détaillé.

L’IA agentique (ou agentic AI) désigne des systèmes d’intelligence artificielle capables de réaliser des tâches, de prendre des décisions et d’interagir avec d’autres systèmes de façon autonome ou partiellement autonome.

Exemple sur la gestion intelligente d’événements urbains

Contexte

Imaginons une grande ville intelligente équipée d’une infrastructure 6G avancée. Cette ville accueille régulièrement des événements de grande envergure (concerts, événements sportifs, manifestations culturelles) qui créent des défis significatifs pour les réseaux de télécommunications.

Architecture des agents IA

  1. Agent Orchestrateur Central
    • Coordonne l’ensemble du système
    • Prend des décisions de haut niveau
    • Délègue les tâches spécifiques à des agents spécialisés
  2. Agents Spécialisés
    • Agent Trafic Réseau
    • Agent Gestion Énergétique
    • Agent Sécurité
    • Agent Communication d’Urgence
    • Agent Expérience Utilisateur

Fonctionnement détaillé du système

Phase 1: Planification proactive (J-7 avant l’événement)

  1. L’Agent Orchestrateur reçoit l’information qu’un concert majeur aura lieu dans 7 jours, avec 50 000 participants attendus
  2. Il active l’Agent Trafic Réseau qui:
    • Analyse les données historiques d’événements similaires
    • Prédit les besoins en bande passante par zone géographique
    • Identifie les potentiels points de congestion
    • Recommande une topologie de réseau optimisée
  3. L’Agent Gestion Énergétique:
    • Calcule les besoins énergétiques additionnels
    • Programme l’activation/désactivation des antennes supplémentaires
    • Optimise la consommation pour maximiser l’autonomie des batteries de secours
  4. L’Agent Sécurité:
    • Établit des protocoles de détection d’intrusion renforcés
    • Prépare des mécanismes d’isolation rapide en cas d’attaque
    • Configure des canaux sécurisés pour les communications prioritaires

Phase 2: Déploiement (Jour J – 6 heures)

  1. L’Agent Orchestrateur lance le plan de déploiement
  2. L’Agent Communication crée dynamiquement trois « network slices » 6G distincts:
    • Un slice haute priorité pour services d’urgence (police, ambulances)
    • Un slice haute capacité pour médias et streaming
    • Un slice faible latence pour IoT critique
  3. Le système active les ressources additionnelles:
    • Déploiement de small cells temporaires
    • Activation des antennes directionnelles programmables
    • Reconfiguration des paramètres de Quality of Service (QoS)

Phase 3: Opération en temps réel (pendant l’événement)

  1. Les capteurs IoT détectent une concentration inattendue de personnes dans une zone spécifique
  2. L’Agent Trafic analyse la situation et détecte un risque de congestion réseau
  3. L’Agent Orchestrateur prend une décision autonome:
    • Redirection de 30% de capacité supplémentaire vers cette zone
    • Reconfiguration des antennes directionnelles
    • Ajustement des priorités de trafic
  4. L’Agent Expérience Utilisateur:
    • Surveille les indicateurs de qualité perçue (latence, débit)
    • Détecte des problèmes d’expérience utilisateur dans certaines applications
    • Négocie des compromis entre applications pour maintenir la satisfaction globale

Phase 4: Adaptation aux incidents

  1. Les capteurs détectent un incident de sécurité (panne d’électricité locale)
  2. L’Agent Sécurité:
    • Isole la section affectée du réseau
    • Active les protocoles de résilience
    • Redirige le trafic critique
  3. L’Agent Communication d’Urgence:
    • Reconfigure automatiquement les ressources pour services d’urgence
    • Établit des liaisons directes D2D (Device-to-Device) pour communications locales
    • Priorise les messages d’alerte aux participants

Capacités clés démontrées par ce système agentic IA en 6G

  1. Perception contextuelle
    • Intégration de données multi-sources (IoT, réseaux sociaux, capteurs)
    • Compréhension des modèles d’utilisation et de déplacement
    • Détection d’anomalies en temps réel
  2. Raisonnement et planification
    • Prise de décisions autonome basée sur objectifs multiples
    • Planification à court et moyen terme
    • Adaptation dynamique aux changements environnementaux
  3. Action et contrôle
    • Reconfiguration autonome des paramètres réseau
    • Déploiement ciblé de ressources additionnelles
    • Gestion des priorités en fonction du contexte
  4. Apprentissage continu
    • Amélioration itérative des modèles prédictifs
    • Adaptation aux nouveaux cas d’usage
    • Partage de connaissances entre agents

Ce scénario montre que l’outil Agentic.ia fait une pré-étude, analyse la situation, prépare l’évènement et coordonne différents service en passant au stade de l’action.

Ainsi, en exploitant les capacités uniques de la 6G (ultra-faible latence, capacité massive, fiabilité extrême), Agentic.ia transforme la gestion des réseaux de télécommunication en les rendant intelligents, proactifs et adaptables.

Comprendre le concept du modèle ML/IA – Partie 2

Posté le by - 281 vues
Répondre

Dans l’article précédent nous avions présenté 3 d’apprentissages IA. Nous allons maintenant revenir plus particulièrement sur l’apprentissage fédéré horizontal (HFL) et vertical (VLF)

Le fonctionnement du HFL et VFL pour l’IA dans les réseaux de télécommunications

Introduction à l’apprentissage fédéré

L’apprentissage fédéré est une approche d’entraînement de modèles d’IA qui permet de développer des modèles à partir de données distribuées sur différents appareils ou serveurs, sans nécessiter le transfert des données brutes vers un serveur central. Cette approche est particulièrement pertinente dans le contexte des télécommunications où la confidentialité des données, la réduction de la bande passante et la distribution géographique sont des considérations importantes.

Deux principales variantes d’apprentissage fédéré sont mentionnées dans le document de 5G Americas et développées dans la littérature scientifique: l’apprentissage fédéré horizontal (HFL) et l’apprentissage fédéré vertical (VFL).

Figure 1 : HFL (gauche) et VFL (droite)

Apprentissage Fédéré Horizontal (HFL)

Principe fondamental

Selon le document, le HFL (souvent simplement appelé « apprentissage fédéré ») est une technique où le modèle d’apprentissage automatique est entraîné sur différents « clients » (nœuds, appareils ou serveurs) qui possèdent des données avec les mêmes caractéristiques mais concernant des échantillons différents.

En termes plus simples, dans le HFL:

  • Chaque participant dispose du même type de données (mêmes features/variables)
  • Mais chacun a des exemples/échantillons différents (différentes instances)

Fonctionnement détaillé

  1. Initialisation: Un modèle global initial est créé sur le serveur central (NWDAF serveur dans le contexte des télécommunications).
  2. Distribution du modèle: Ce modèle est envoyé à plusieurs clients (par exemple, différents NWDAF locaux dans différentes zones géographiques).
  3. Entraînement local: Chaque client entraîne le modèle sur ses données locales pendant plusieurs itérations.
  4. Agrégation des paramètres: Les clients renvoient uniquement les paramètres du modèle mis à jour (pas les données) au serveur central.
  5. Mise à jour du modèle global: Le serveur central agrège ces paramètres (typiquement par une forme de moyenne pondérée) pour créer une version améliorée du modèle global.
  6. Itération: Les étapes 2-5 sont répétées à travers plusieurs cycles jusqu’à ce que le modèle converge ou atteigne des performances satisfaisantes.

Avantages dans le contexte des télécommunications

  • Confidentialité: Les données sensibles restent sur leurs appareils/serveurs d’origine.
  • Efficacité de communication: Seuls les paramètres du modèle sont transmis, pas les données brutes, réduisant considérablement la charge du réseau.
  • Adaptation locale: Le modèle peut capturer les spécificités locales tout en bénéficiant de l’apprentissage collectif.

Application dans le NWDAF (3GPP)

Dans les réseaux 5G, comme mentionné dans le document, le HFL a été introduit dans la Release 17 du 3GPP pour le NWDAF. Il permet:

  • L’entraînement collaboratif entre différentes zones d’intérêt (parties du réseau)
  • Chaque zone utilise le NWDAF le plus proche pour entraîner localement
  • L’apprentissage collectif est agrégé par une fonction centrale sur le NWDAF serveur
  • Des protocoles préservant la confidentialité comme l’agrégation sécurisée peuvent être appliqués

Apprentissage Fédéré Vertical (VFL)

Principe fondamental

Le VFL, introduit dans la Release 19 pour le NWDAF selon le document, est conçu pour des scénarios où différents participants possèdent différentes caractéristiques/features pour les mêmes échantillons (ou un chevauchement significatif des échantillons).

En termes simplifiés, dans le VFL:

  • Chaque participant a des types de données différents (features différentes)
  • Mais ils concernent le même ensemble d’utilisateurs ou d’entités (mêmes échantillons)

Fonctionnement détaillé

  1. Division du modèle: Dans le VFL, le modèle d’apprentissage est divisé en « modèle de tête » et « modèle de queue »:
    • Les modèles de tête sont déployés chez les participants (par exemple, Client A et Client B)
    • Le modèle de queue est hébergé sur un serveur central
  2. Processus d’entraînement:
    • Propagation avant: Les clients traitent leurs données locales à travers leurs modèles de tête
    • Transfert d’activations: Les résultats intermédiaires (activations) sont envoyés au serveur central
    • Concaténation: Le serveur central concatène ces activations
    • Calcul de perte: Le modèle de queue calcule une perte en utilisant les étiquettes disponibles sur le serveur
    • Rétropropagation: Les gradients sont calculés et les dérivées partielles correspondantes sont renvoyées aux clients
    • Mise à jour locale: Chaque client met à jour son modèle de tête en fonction des gradients reçus
  3. Alignement des échantillons: Pour que le VFL fonctionne, il est crucial d’aligner les échantillons entre les participants, généralement à l’aide d’identifiants uniques comme des horodatages ou des identifiants d’utilisateur (SUPI dans le contexte 5G).

Avantages spécifiques au VFL

  • Enrichissement des caractéristiques : Permet de combiner différentes perspectives ou types de données sans les partager directement
  • Architecture personnalisée: Chaque participant peut avoir sa propre architecture de réseau neural
  • Complémentarité des données: Permet d’exploiter des données complémentaires détenues par différentes entités

Application dans les réseaux 5G (NWDAF)

Selon le document, dans la Release 19 du 3GPP, le VFL est introduit pour permettre la collaboration entre:

  • Les NWDAF dans le réseau cœur
  • Les fonctions d’application (AF) qui peuvent détenir d’autres types de données

Cette approche permet notamment:

  • La prédiction de QoS en utilisant à la fois des données réseau et des données applicatives
  • Une meilleure adaptation aux besoins spécifiques grâce à des architectures de modèle personnalisées
  • L’extension des fonctionnalités existantes développées pour le HFL

Différences clés entre HFL et VFL

En synthétisant les informations du document et la littérature sur le sujet:

Aspect HFL (Horizontal) VFL (Vertical)
Partitionnement des données Même espace de features, échantillons différents Features différentes, mêmes échantillons
Architecture du modèle Modèles identiques sur tous les clients Division tête/queue avec architectures potentiellement différentes
Communication Paramètres du modèle complet Activations et gradients partiels
Confidentialité Protège la confidentialité des échantillons Protège la confidentialité des features
Cas d’usage typique dans 5G Apprentissage entre différentes zones géographiques Collaboration entre réseau cœur et applications
Complexité d’implémentation Plus simple (agrégation directe des modèles) Plus complexe (coordination entre sous-modèles)

Protection de la confidentialité dans HFL et VFL

Les deux approches intègrent des mécanismes pour renforcer la confidentialité:

Dans le HFL:

  • Agrégation sécurisée: Techniques cryptographiques pour agréger les mises à jour de modèle sans révéler les contributions individuelles
  • Distillation de connaissances: Transfert de connaissances sans partager les paramètres exacts du modèle
  • Quantification et élagage: Réduction de la précision ou de la taille des modèles pour limiter les fuites d’information

Dans le VFL:

  • Calcul multi-parties: Techniques permettant des calculs conjoints sans partager les données sous-jacentes
  • Chiffrement homomorphe: Opérations sur des données chiffrées sans les déchiffrer
  • Perturbation différentielle: Ajout de bruit aux activations partagées pour protéger la confidentialité

Implémentation dans un réseau de télécommunications

Dans le contexte spécifique des réseaux de télécommunications, le document de 5G Americas décrit l’implémentation de ces approches:

Pour le HFL:

  • Déployé entre différentes zones géographiques du réseau
  • Les NWDAF clients sont situés près des zones qu’ils desservent
  • Un NWDAF serveur central coordonne l’agrégation
  • Les modèles peuvent prédire des comportements comme la charge du réseau ou la mobilité des utilisateurs

Pour le VFL:

  • Permet la collaboration entre le réseau cœur et les applications externes
  • Les prédictions peuvent combiner des données réseau (comme les conditions du signal) avec des données applicatives (comme les exigences des applications)
  • Permet de préserver la séparation entre domaines administratifs tout en bénéficiant du partage de connaissances

Conclusion: évolution et tendances futures

L’évolution de l’apprentissage fédéré dans les réseaux de télécommunications, comme le montre le document 5G Americas, suit une progression naturelle:

  1. D’abord introduction du HFL dans la Release 17, permettant la collaboration entre différentes parties du réseau
  2. Extension au transfert de modèles entre domaines administratifs dans la Release 18
  3. Introduction du VFL dans la Release 19, permettant la collaboration entre le réseau et les applications

Cette évolution reflète une tendance plus large vers:

  • Des réseaux de plus en plus intelligents et adaptatifs
  • Une intégration plus profonde entre les réseaux et les applications qu’ils supportent
  • Une attention croissante à la confidentialité et à l’efficacité des communications

Le HFL et le VFL représentent deux approches complémentaires d’apprentissage fédéré qui, ensemble, permettent une collaboration plus riche et plus flexible entre les différentes entités d’un écosystème de télécommunications, tout en respectant les contraintes de confidentialité et d’efficacité.

Comprendre le concept du modèle ML/IA – Partie 1

Posté le by - 760 vues
Répondre

Comment fonctionne le modèle ? ML/IA : Principes fondamentaux et cycle de vie des modèles

I) Introduction

L’intelligence artificielle (IA) et l’apprentissage automatique (machine learning ou ML) transforment notre façon d’aborder les problèmes complexes dans de nombreux domaines. Ce document explique les principes de base du fonctionnement de ces technologies et détaille leur cycle de vie, de la conception à l’exploitation.

Le cycle de vie est défini dans le document TR28.105 et sera réexpliqué dans un autre article.

Des cas d’usages sont proposés dans le document TR28.908 et seront listés dans un autre article.

L’objectif de l’IA est de pouvoir répondre au plus juste à la question posée. A chaque question, on évalue la réponse. Cela suppose donc une phase d’apprentissage et une une phase d’examen. Les phases d’apprentissage et d’inférence sont, par analogie, comme étudier pour un examen (entraînement) puis passer l’examen réel (inférence).

L’inférence traduit simplement la réponse de l’IA à de nouvelles situations en appliquant ce qu’elle a appris.

Dans le monde réel, l’inférence, c’est quand votre téléphone reconnaît votre visage, quand un assistant vocal comprend vos paroles, ou quand une application de traduction convertit un texte d’une langue à une autre. Le système utilise ce qu’il a appris pendant l’entraînement pour traiter la nouvelle entrée que vous lui donnez.

Dans le cas des réseaux mobiles, l’IA est un assistant pour détecter des pannes. Il doit donc faire une analyse, récupérer des rapports, mais surtout réaliser des actions. Les actions peuvent être rédiger un tocketing vers un prestataire (supposons que la station de base défaillante est sur un TELCO d’un autre opérateur), ou un ticketing vers une équipe spécialisée. L’IA doit ensuite suivre l’intervention de bout en bout.

A ce jour, je liste que deux solutions IA intéressantes pour automatiser (détecter, analyser et réaliser une/des actions) qui sont :

  • Agentic AI
  • Manus MI

Je parlerais des ces deux IA dans un autre articles.

II)Comprendre le ML et l’IA

L’intelligence artificielle désigne les systèmes capables d’accomplir des tâches qui nécessiteraient normalement l’intelligence humaine. Le machine learning est une sous-discipline de l’IA qui permet aux systèmes d’apprendre à partir de données sans être explicitement programmés pour chaque tâche.

Principes fondamentaux

Le ML repose sur trois approches principales :

  1. Apprentissage supervisé : le modèle apprend à partir d’exemples étiquetés (données d’entrée associées aux sorties attendues).
  2.  Apprentissage non supervisé : le modèle découvre des structures ou des motifs cachés dans des données non étiquetées.
  3. Apprentissage par renforcement : le modèle apprend par essais et erreurs, recevant des récompenses ou des pénalités selon ses actions.

Comment les modèles « apprennent »

Au cœur du ML se trouve le concept de modèle : une représentation mathématique qui transforme des entrées en sorties. L’apprentissage consiste à ajuster les paramètres de ce modèle pour minimiser l’erreur entre ses prédictions et les résultats attendus.

Ce processus s’appuie sur :

  • Des données représentatives du problème
  • Des algorithmes qui déterminent comment ajuster les paramètres.
  • Des fonctions d’objectif qui mesurent la performance
  • Des techniques d’optimisation pour améliorer progressivement les résultats.

L’entrainement peut être sur un serveur centralisé ou  sur des serveurs distribués. On parle alors d‘apprentissage fédéré.

L’apprentissage fédéré est une approche distribuée où le modèle est entraîné sur plusieurs appareils ou serveurs sans échanger les données brutes.

L’apprentissage fédéré est une décentralisation des données et permet la protection de la vie privée, quelle que soit la méthode d’apprentissage utilisée (supervisée ou non supervisée).

Le cycle de vie d’un modèle ML/IA

Un modèle d’IA/ML suit généralement un cycle de vie structuré, composé des étapes suivantes :

  1. Entraînement du modèle ML
    L’entraînement constitue la phase où le modèle « apprend » à partir des données. Cette étape comprend :
    • L’entraînement initial : exposition du modèle aux données d’entraînement pour qu’il ajuste ses paramètres.
    • La validation continue : évaluation des performances du modèle sur des données de validation distinctes.
    • Le réentraînement : ajustement du modèle si les résultats de validation ne sont pas satisfaisants
    L’objectif est d’obtenir un modèle qui capture efficacement les relations dans les données tout en évitant le surapprentissage (mémorisation des données d’entraînement sans capacité de généralisation).
  2. Test du modèle ML
    Une fois le modèle validé, il est soumis à une phase de test rigoureuse :
    • Le modèle est évalué sur un ensemble de données de test totalement nouvelles.
    • Les performances sont mesurées selon des métriques spécifiques au problème (précision, rappel, F1-score, etc.).
    • Si les performances ne répondent pas aux attentes, un retour à l’étape d’entraînement est nécessaire.
    Cette étape est cruciale pour déterminer si le modèle est capable de généraliser ses apprentissages à des données inédites.
  3. Émulation d’inférence AI/ML (optionnelle)
    Avant le déploiement en environnement réel, le modèle peut être testé dans un environnement d’émulation pour :
    • Évaluer les performances d’inférence (vitesse, latence, ressources consommées)
    • Vérifier la compatibilité avec l’infrastructure cible.
    • Identifier les potentiels impacts négatifs sur d’autres systèmes
    Cette étape, bien qu’optionnelle, permet d’anticiper les problèmes techniques qui pourraient survenir en production.
  4. Déploiement du modèle ML
    le déploiement consiste à rendre le modèle opérationnel dans son environnement cible :
    • Processus de chargement du modèle dans l’infrastructure d’inférence
    • Intégration avec les systèmes existants
    • Configuration des paramètres d’exécution
    Dans certains cas, cette étape peut être simplifiée, notamment lorsque les environnements d’entraînement et d’inférence sont co-localisés.
  5. Inférence AI/ML
    L’inférence représente l’utilisation effective du modèle en production.
    • Le modèle traite les nouvelles données entrantes et génère des prédictions.
    • Un système de surveillance évalue continuellement les performances.
    • Des mécanismes peuvent déclencher automatiquement un réentraînement si les performances se dégradent.
    Cette phase correspond à la « vie active » du modèle, où il crée de la valeur en résolvant les problèmes pour lesquels il a été conçu.

Considérations pratiques et avancées

Maintenir un système d’IA/ML en production performant implique de relever plusieurs défis :
1. Dérive des données : les caractéristiques des données réelles évoluent avec le temps, rendant progressivement le modèle moins précis.
2. Besoins computationnels : L’entraînement et l’inférence peuvent nécessiter d’importantes ressources de calcul, particulièrement pour les modèles complexes.
3. Explicabilité : comprendre pourquoi un modèle a pris une décision particulière devient crucial dans de nombreux contextes réglementaires.
4. Biais et équité : les modèles peuvent perpétuer ou amplifier les biais présents dans les données d’entraînement.

Pour maximiser les chances de succès d’un projet ML/IA :

  • Surveillance continue : mettre en place des mécanismes pour détecter les dégradations de performance
  • Réentraînement périodique : actualiser régulièrement le modèle avec des données récentes.
  • Tests A/B : comparer les performances de différentes versions du modèle
  • Documentation exhaustive : Maintenir une traçabilité complète du développement et des choix effectués

L’évolution du domaine ML/IA se caractérise par plusieurs tendances :

  • MLOps : automatisation et standardisation des processus de déploiement et de maintenance des modèles
  • Apprentissage fédéré : entraînement distribué préservant la confidentialité des données
  • Modèles auto-supervisés : réduction de la dépendance aux données étiquetées
  • ML embarqué : exécution de modèles directement sur des appareils en périphérie (edge computing)

MLOps et DevOps

MLOps est un ensemble de pratiques visant à automatiser et rationaliser le cycle de vie des modèles d’IA de leur déploiement à leur production et opération:

Surveillance et gestion de la performance

  • Surveillance en temps réel: Surveillance continue de la performance des modèles d’IA en production pour assurer qu’ils opèrent comme prévu, impliquant le suivi de métriques comme la précision, la latence et l’utilisation des ressources.
  • Boucles de feedback: Implémentation de boucles de feedback pour collecter des données de performance et le feedback utilisateur, qui peuvent être utilisés pour affiner et améliorer les modèles d’IA au fil du temps.

Automatisation

  • Réentraînement du modèle: Automatisation du processus de réentraînement pour incorporer de nouvelles données et s’adapter aux conditions changeantes, assurant que les modèles d’IA restent pertinents et efficaces à mesure que les environnements réseau évoluent.
  • Mise à l’échelle: Utilisation de la mise à l’échelle automatisée pour ajuster les ressources de calcul basées sur les demandes des tâches d’inférence et d’entraînement du modèle d’IA.
  • Pipelines CI/CD: Implémentation de pipelines CI/CD pour l’intégration continue et le déploiement des modèles d’IA, incluant l’automatisation du processus de mise à jour des modèles avec de nouvelles données, testant leur performance et les déployant dans des environnements de production.

Pratiques DevOps

Les pratiques DevOps sont essentielles pour intégrer les modèles d’IA dans le cadre plus large de gestion et d’opérations réseau:

  • Collaboration et intégration:
    • Équipes interfonctionnelles: Promouvoir la collaboration entre les data scientists, les ingénieurs réseau et les équipes opérationnelles pour assurer que les modèles d’IA sont efficacement intégrés dans les opérations réseau.
    • Flux de travail unifiés: Développer des flux de travail unifiés qui combinent la gestion réseau et les opérations du modèle d’IA, permettant une intégration et une coordination transparentes entre différents aspects de la gestion réseau.
  • Infrastructure as Code (IaC):
    • Gestion d’infrastructure automatisée: Utiliser IaC pour automatiser le provisionnement et la gestion de l’infrastructure requise pour l’entraînement et le déploiement du modèle d’IA, incluant la définition et la gestion des ressources réseau à travers le code pour assurer cohérence et efficacité.
  • Surveillance et journalisation:
    • Journalisation complète: Implémenter des pratiques de journalisation complètes pour suivre la performance du modèle d’IA et les métriques opérationnelles, aidant à identifier les problèmes, déboguer les problèmes et assurer que les modèles répondent aux standards de performance.

 

Conclusion

Le ML et l’IA représentent des technologies puissantes dont l’efficacité dépend largement de la rigueur avec laquelle leur cycle de vie est géré. De l’entraînement à l’inférence, chaque étape présente des défis spécifiques et requiert une attention particulière.
La compréhension de ce cycle de vie est essentielle pour toute organisation souhaitant tirer profit de ces technologies de manière durable et responsable. Les systèmes ML/IA ne sont pas statiques : ils nécessitent une maintenance et une amélioration continues pour rester performants face à l’évolution constante des données et des besoins.

Le service XRM : réalité étendue et média (RXRM : Real-Time XRM)

Posté le by - 326 vues
Répondre

Introduction

Le XRM, ou service de réalité étendue et média, représente une convergence de technologies immersives que la 5G permet de déployer à grande échelle grâce à ses caractéristiques techniques avancées.

Le XRM englobe principalement:

1. La réalité virtuelle (VR) – immersion complète dans un environnement numérique
2. La réalité augmentée (AR) – superposition d’éléments numériques sur le monde réel
3. La réalité mixte (MR) – fusion interactive des mondes réel et virtuel
4. Les médias immersifs – contenus multimédia à forte composante d’immersion

Les avantages offerts par la 5G pour le XRM sont multiples:
– Faible latence (temps de réponse inférieur à 10ms) permettant des expériences immersives fluides
– Bande passante élevée pour transmettre des contenus haute définition
– Edge computing (traitement des données au plus près des utilisateurs)
– Fiabilité accrue des connexions

Ces services XRM trouvent des applications dans de nombreux domaines comme:
– L’éducation et la formation professionnelle
– La santé (chirurgie à distance, visualisation médicale avancée)
– L’industrie (maintenance assistée, jumeaux numériques)
– Le divertissement et les médias
– Le commerce (shopping immersif)

II) Déploiement technique

Du point de vue technique, la 5G propose le service XRM grâce à plusieurs mécanismes spécifiques :

1. Network Slicing : C’est effectivement une technologie clé pour le XRM. La 5G permet de créer des « tranches réseau » dédiées avec des caractéristiques adaptées aux besoins des applications XR :
– Une tranche URLLC (Ultra-Reliable Low-Latency Communications) pour minimiser la latence
– Une tranche eMBB (enhanced Mobile Broadband) pour garantir la bande passante nécessaire aux contenus haute définition.

2. Architecture Service-Based (SBA) :
– L’AMF (Access and Mobility Management Function) joue un rôle important en gérant les connexions des terminaux XR avec une priorité adaptée
– Le PCF (Policy Control Function) définit des règles QoS spécifiques aux flux XR
– L’UPF (User Plane Function) peut être déployé au plus près des utilisateurs (edge) pour minimiser la latence

3. Edge Computing :
– Déploiement des MEC (Multi-access Edge Computing) en bordure de réseau
– APIs ouvertes pour les développeurs XR (via ETSI MEC)
– Traitement local des données sensibles au temps (rendu, tracking, etc.)

4. QoS spécifique :
– Utilisation de 5QI (5G QoS Identifier) dédiés pour les flux XR
– Garantie de SLA (Service Level Agreement) adaptés aux besoins immersifs
– Mécanismes d’adaptation du débit selon les mouvements de tête (viewport-adaptive streaming)

5. Technologies radio avancées :
– Beamforming pour diriger l’énergie vers les terminaux XR
– Utilisation des bandes millimétriques (mmWave) pour les environnements à haute densité
– Duplexage flexible pour optimiser les flux montants/descendants

6. API réseau XR spécifiques :
– NEF (Network Exposure Function) exposant des API pour les applications XR
– Interfaces permettant aux applications de négocier dynamiquement les ressources

Ces différents mécanismes sont nécessaires pour apporter les caractéristiques essentielles du XRM :
– Latence ultra-faible (1-10ms)
– Bande passante garantie (jusqu’à plusieurs Gbps)
– Fiabilité élevée (99,999%)

5G-Advanced R.19 : AIoT – Partie 5

Posté le by - 151 vues
Répondre

Tableau Comparatif des Caractéristiques Principales

Use Case Contexte d’application Latence maximale Disponibilité du service Taille du message Densité des dispositifs Portée de communication Vitesse des dispositifs Précision de positionnement
5.1 – Entreposage automatisé Logistique, gestion d’inventaire 1s 99% 96/128 bits 1-2/m² 30m (intérieur) 5-10 km/h 2-3m
5.2 – Instruments médicaux Santé, gestion d’inventaire Quelques secondes 99% 176 bits ≥1000/km² 50m (intérieur), 200m (extérieur) <6 km/h 3-5m (intérieur)
5.3 – Sous-stations électriques Énergie, réseaux intelligents 1s 99% <100 octets <10,000/km² 50-200m (extérieur) Stationnaire Dizaines de mètres
5.4 – Logistique en réseau non public Logistique, gestion d’inventaire – – – – – – –
5.5 – Intralogistique automobile Fabrication, gestion de matériaux 10s 99% 96 bits <1,5 million/km² 30m (intérieur) 5 km/h 3m
5.6 – Maisons intelligentes Domotique, surveillance 20s 99,9% 8-96 bits <5 pour 100m² 10-30m (intérieur) Stationnaire –
5.7 – Terminaux d’aéroport/port Gestion d’actifs, logistique 1-10s 99% 256 bits 100 dispositifs/km² 50m (intérieur) 3-10 km/h Niveau cellulaire
5.8 – Recherche d’objets perdus Localisation, suivi 5s 99% 256 bits 250/100m² (intérieur), 10/100m² (extérieur) 10m (intérieur), 100m (extérieur) – ~3m (intérieur), ~10m (extérieur)
5.9 – Services de localisation Localisation, suivi – – – – 500m 10 km/h (extérieur) Niveau cellulaire (horizontal)
5.10 – Positionnement relatif Localisation, suivi – – – 20/100m² 10m <1m/s 1-3m
5.11 – Modification d’instruments médicaux Santé, gestion d’inventaire Quelques secondes 99% 176 bits ≥1000/km² 50m (intérieur), 200m (extérieur) <6 km/h 3-5m (intérieur)
5.12 – Recherche d’objets personnels Localisation, suivi 1s 99,9% <1 kbits <5 pour 100m² (intérieur), <10 pour 100m² (extérieur) 10m (intérieur), 100m (extérieur) Statique 1-3m (intérieur), dizaines de mètres (extérieur)
5.13 – Supervision environnementale Télécommunications, surveillance 30s 99% 96 bits 1,5/m² 30m (intérieur) Stationnaire –
5.14 – Positionnement intérieur Commerce, navigation 0,5s 99,9% 96 bits 2500/10000m² 10m – 3m
5.15 – Lessive intelligente Domotique, électroménager >10s – <100 bits 20/100m² – 6 km/h (extérieur) –
5.16 – Distribution automatisée Logistique, suivi >10s 99% <100 octets <1,5 million/km² 30m (intérieur), 400m (extérieur) – 3m (intérieur), niveau cellulaire (extérieur)
5.17 – Activation/désactivation Gestion des dispositifs – – – – – – –
5.18 – Aliments frais Logistique, surveillance >1 minute – <100 bits 1,5 million/km² – 1 m/s –
5.19 – Incendies de forêt Surveillance environnementale >10s 99,9% – 100 par km² 15-200m Stationnaire –
5.20 – Agriculture intelligente Agriculture, contrôle >1s 99,9% <1000 bits 1 par m² 30-100m Stationnaire –
5.21 – Guide de musée Culture, information 2s 99,9% 96 bits <10,000/km² 30m 3 km/h 3m
5.22 – Élevage laitier Agriculture, surveillance >1s 99% <100 octets <5200/km² 300-500m (extérieur) 3 km/h –
5.23 – Élevage porcin Agriculture, surveillance >10s – <100 octets 850 000/km² 250m (intérieur) Quasi-stationnaire –
5.24 – Bouches d’égout Infrastructure urbaine 10-30s 99% <100 octets <1000/km² 300-500m (extérieur) Stationnaire –
5.25 – Santé des ponts Infrastructure urbaine 10s 99% <100 octets <1000/km² 300-500m (extérieur) Stationnaire –
5.26 – Soins aux personnes âgées Santé, assistance 1s – <100 bits <20 pour 100m² 20m (intérieur), 200m (extérieur) Statique –
5.27 – Logistique de bout en bout Logistique, suivi – – – – – – –
5.28 – Interrupteur à pression Interface utilisateur – – – – – – –
5.29 – Désactivation permanente Gestion des dispositifs – – – – – – –
5.30 – Contrôleur agricole Agriculture, contrôle Plusieurs secondes 99% 128 bit (DL) – 500m (extérieur) Statique –

5G-Advanced R.19 : AIoT – Partie 4

Posté le by - 214 vues
Répondre

Nous allons nous intéresser maintenant aux cas d’usages présentés dans le TR 22.840

Cas d’usage de 21 à 30

5.21 Use case sur l’IoT Ambiant pour le guide de musée

Objectif :  Ces dispositifs IoT Ambiant permettent, dans les musées, de fournir des informations sur les expositions. Les dispositifs sont attachés aux vitrines d’exposition ou placés à proximité, et les visiteurs peuvent obtenir des informations en utilisant leur téléphone portable qui communique avec les dispositifs.

5.22 Use case sur l’élevage laitier en pâturage intelligent rendu possible par l’IoT Ambiant

Objectif : attaché aux vaches laitières, l’IoT Ambient peut surveiller la température corporelle et détecter précocement les signes de maladie. Les données sont collectées périodiquement et analysées par une application de gestion de la santé du bétail.

5.23 Use case sur l’élevage porcin intelligent rendu possible par l’IoT Ambiant

Objectif : Idem que le cas d’usage précédent mais pour l’élevage porcin

5.24 Use case sur la surveillance de la sécurité des bouches d’égout utilisant l’IoT Ambiant

Objectif : surveiller les bouches d’égout et prévenir les accidents. Les dispositifs sont équipés de capteurs (niveau d’eau, inclinaison, vibration) qui détectent les anomalies et alertent les autorités en cas de problème.

5.25 Use case sur la surveillance de la santé des ponts utilisant l’IoT Ambiant

Objectif : surveiller l’état des ponts et prévenir les accidents. Les dispositifs sont équipés de capteurs (inclinaison, vibration) qui détectent les anomalies structurelles et alertent les autorités locales en cas de problème.

5.26 Use case sur les soins de santé pour personnes âgées

Utilisation de dispositifs IoT Ambiant pour aider les personnes âgées à localiser rapidement leurs médicaments, tant à l’intérieur qu’à l’extérieur. Les dispositifs sont attachés aux boîtes de médicaments et peuvent être activés à distance pour allumer une LED, facilitant leur localisation.

5.27 Use case sur la logistique de bout en bout

Objectif : suivre des produits spécifiques (par exemple, des téléviseurs) depuis l’usine de fabrication jusqu’à la livraison au client final. Les dispositifs peuvent fonctionner dans différents réseaux (NPN, PLMN) et pays, s’adaptant aux différentes réglementations et licences de fréquence.

5.28 Use case sur l’optimisation de la signalisation 5G

Objectif : Réduire la signalisation entre le dispositif IoT et le cœur de réseau 5G

Les interrupteurs existants, non 3GPP, peuvent se connecter sans fil sur de courtes distances (environ 25 m en intérieur et 150 m en extérieur). Intégrer ce type d’interrupteur au réseau 3GPP nécessite suffisamment d’énergie pour s’attacher et émettre des données pour ne pas être en échec. Mais l’énergie nécessaire peut être supérieure à l’énergie disponible (l’énergie cinétique lorsqu’on appuie dessus).

5.29 Use case sur la désactivation permanente des dispositifs

Objectif : désactivation permanente d’un dispositif IoT Ambiant lorsque celui-ci n’a plus d’utilité de surveillance. Le scénario décrit un responsable de production qui supervise la fabrication de plaquettes de circuits intégrés et utilise des dispositifs IoT Ambiant pour enregistrer les conditions environnementales. LAIoT sont désactivées lorsque la chaîne de fabrication est au repos.

5.30 Use case sur le dispositif IoT Ambiant agissant comme contrôleur dans l’agriculture intelligente

Objectif : Utiliser comme contrôleurs dans l’agriculture intelligente pour gérer les équipements (système d’irrigation, pulvérisation de pesticides). Les dispositifs sont activés périodiquement pour recevoir des informations d’opération et contrôler les équipements en conséquence, économisant l’énergie pendant les périodes d’inactivité.

 

5G-Advanced R.19 : AIoT – Partie 3

Posté le by - 248 vues
Répondre

Nous allons nous intéresser maintenant aux cas d’usages présentés dans le TR 22.840

Cas d’usage de 11 à 20

5.11 Use case sur la modification en ligne du statut des instruments médicaux

Objectif : Un gestionnaire d’inventaire peut à distance lire, modifier et écrire des informations sur les instruments médicaux via la plateforme de gestion et le réseau 5G, facilitant la maintenance et le suivi de l’état des instruments.

5.12 Use case sur le service IoT Ambiant pour retrouver des objets personnels

Objectif : Localiser des objets personnels perdus, tant à l’intérieur qu’à l’extérieur. L’utilisateur peut utiliser son téléphone portable pour rechercher les dispositifs IoT Ambiant attachés à ses objets, et obtenir leur position précise grâce au système 5G.

5.13 Use case sur l’IoT Ambiant pour la supervision environnementale des salles de machines des stations de base

Objectif : surveiller les paramètres environnementaux (température, humidité, infiltration d’eau) dans les salles de machines des stations de base. Ces dispositifs aident à prévenir les pannes réseau et les problèmes électriques en détectant les anomalies.

5.14 Use case sur le positionnement intérieur dans un centre commercial utilisant l’IoT Ambiant

Objectif : guider les clients dans un centre commercial, Les utilisateurs peuvent trouver facilement les magasins ou objets cibles grâce à leur téléphone portable qui communique avec les dispositifs IoT Ambiant.

5.15 Use case sur l’IoT Ambiant pour la lessive intelligente

Objectif : pour surveiller les conditions de lavage (température, humidité) et stocker des informations sur le vêtement (couleur, tissu, matériau, forme), le dispositif Ambiant IoT est placé sur les vêtements. Ces informations sont utilisées pour recommander un mode de lavage approprié et optimiser le processus de lavage.

5.16 Use case sur le service IoT Ambiant pour la distribution automatisée de la chaîne d’approvisionnement

Objectif : suivre les produits depuis la fabrication jusqu’à la livraison dans la chaîne d’approvisionnement d’appareils électroménagers pour. Le système permet de surveiller et de localiser les produits pendant le transport, garantissant qu’ils sont livrés au bon client via l’itinéraire correct.

5.17 Use case sur l’activation et la désactivation des dispositifs

Objectif : Activer ou désactiver un dispositif. Le scénario décrit un utilisateur d’entreprise qui utilise des dispositifs IoT Ambiant avec des capteurs environnementaux pour surveiller les conditions de croissance des plantes d’orchidées. Lorsque l’orchidée est sous serre, le dispositif est activé. A partir du moment ou la croissance est terminée, on désactive l’IoT

5.18 Use case sur la chaîne d’approvisionnement des aliments frais

Objectif : surveiller la chaîne d’approvisionnement des aliments frais. Les dispositifs sont attachés aux RTI (Reusable Transport Items) utilisés pour stocker et transporter les aliments, permettant un suivi de la température et des conditions environnementales pour garantir la sécurité alimentaire et réduire le gaspillage.

5.19 Use case sur la surveillance des incendies de forêt utilisant des dispositifs IoT Ambiant

Objectif : le dispositifs IoT Ambiant est équipé de détecteurs de fumée pour surveiller les incendies de forêt. Le système permet une détection précoce des incendies et une communication fiable avec le système 5G, même dans des conditions difficiles (mauvaise couverture de signal, alimentation intermittente).

5.20 Use case sur l’agriculture intelligente

Objectif : surveiller l’environnement et contrôler les installations (système d’irrigation, contrôle de la température) dans l’agriculture intelligente. Les dispositifs récupèrent l’énergie de l’environnement et communiquent avec le réseau 5G pour fournir des données environnementales et recevoir des commandes de contrôle.

5G-Advanced R.19 : AIoT – Partie 2

Posté le by - 440 vues
Répondre

Nous allons nous intéresser maintenant aux cas d’usages présentés dans le TR 22.840

Cas d’usage de 1 à 10

5.1 Use case sur l’IoT Ambiant pour l’entreposage automatisé

Objectif : suivre et inventorier automatiquement les marchandises dans un entrepôt. Les dispositifs sont attachés aux articles, palettes ou conteneurs et communiquent avec le réseau 5G pour permettre un inventaire précis et rapide lors des différentes étapes (entrée, stockage, sortie). Le système peut opérer en mode déclenché manuellement ou automatiquement, et transmettre les données à la plateforme de gestion d’entrepôt.

5.2 Use case sur la gestion d’inventaire et le positionnement des instruments médicaux

Objectif : Faciliter l’inventaire et la localisation des instruments médicaux dans un hôpital. Ces dispositifs fonctionnent sans batterie ou avec un stockage d’énergie limité, et peuvent résister à des conditions difficiles (température élevée, pression, humidité) afin de vérifier que l’instrument médical est bien stérilisé. Le système permet au personnel hospitalier de localiser rapidement des instruments spécifiques et d’obtenir des informations sur leur statut.

5.3 Use case sur les dispositifs IoT Ambiant dans les stations de réseaux électriques intelligents (smart-grid)

Objectif : Déploiement de capteurs dans les sous-stations électriques extérieures pour surveiller différents paramètres (température, humidité, pression, vibrations) afin de détecter les dysfonctionnements. Ces capteurs aident à la maintenance prédictive et permettent d’éviter les pannes. Les données sont collectées périodiquement et analysées pour identifier les anomalies potentielles et faire de l’analyse prédictive.

5.4 Use case sur la prise en charge de l’IoT Ambiant dans un réseau non public pour la logistique

Objectif : Les dispositifs IoT sont attachés aux marchandises et communiquent avec le réseau privé NPN pour permettre un inventaire efficace et un suivi du fret lors de son transport.

5.5 Use case sur l’intralogistique dans la fabrication automobile

Objectif :  les dispositifs sont attachés aux conteneurs de charge et communiquent avec le réseau 5G pour faciliter l’inventaire automatisé, le positionnement et le suivi des matériaux dans l’usine, depuis leur réception jusqu’à leur utilisation sur les lignes de production. Ce cas d’usage permet d’améliorer l’efficacité de la gestion des matériaux et des pièces.

5.6 Use case sur les capteurs IoT Ambiant dans les maisons intelligentes

Objectif : surveillance de l’environnement domestique (température, humidité) et détection de situations d’urgence (gaz, fumée). Ces capteurs fonctionnent à partir d’énergie ambiante récupérée et peuvent alerter les résidents via leurs téléphones portables en cas de dépassement de seuils critiques.

5.7 Use case sur l’IoT Ambiant pour les terminaux d’aéroport/ports maritimes

Objectif : suivi et gestion des actifs dans les aéroports ou ports maritimes (chariots élévateurs, chariots, fauteuils roulants, etc.). Le système permet une gestion en temps réel et un déploiement efficace des ressources en fonction de la demande variable, améliorant la sécurité et l’expérience des voyageurs.

5.8 Use case sur la recherche d’objets perdus à distance

Objectif : Les dispositifs IoT Ambiant sont attachés aux objets personnels, permettant ainsi de les localiser en cas de perte, même à grande distance. Le système permet à l’utilisateur de localiser ses objets perdus grâce à l’aide d’appareils UE/entités RAN environnants qui peuvent communiquer avec le dispositif IoT Ambiant et transmettre les informations de localisation.

5.9 Use case sur les services de localisation (LCS) pour l’IoT Ambiant

Objectif : Le système permet à l’utilisateur de demander la position du dispositif via son téléphone portable, et le réseau localise le dispositif lorsqu’il dispose de suffisamment d’énergie. Exemple : dispositif attaché au collier d’un animal de compagnie

5.10 Use case sur le positionnement relatif pour l’IoT Ambiant

Objectif : Localiser de dispositifs IoT par rapport à d’autres éléments du réseau ou à d’autres UE. L’exemple illustre la recherche d’une clé équipée d’un dispositif IoT Ambiant dans une maison, où l’UE de l’utilisateur communique avec le dispositif pour déterminer sa position relative.