U.E. Projets avancés en réseaux

RSX 218

Page de l'UE de l'année en cours.

Liste des projets 2026

NB : pour accéder aux digital librairies de l'ACM, IEEE, springer, etc, ajouter avant l'extension de domaine TLD (par ex .org) cette partie .proxybib-pp.cnam.fr. Votre login @lecnam.net vous permettra d'accéder à  la ressource.

Pj#

Titre

Tuteur

Personnes

Dates

Description / Prérequis / Travail / Références

1

Gestion des requêtes LLM au niveau plan de contrôle

Thierry Lejkin, Orange

Clément LE GUERN

Jean-Christophe HOUBLON-

Réunion 1 : 26/3

Mi-parcours : 16/4

Réunion 2 : 30/4

Soutenance : 11/6

Description générale

Dans le cadre de la 5G, la gestion du plan de contrôle est essentielle pour garantir la flexibilité, l'évolutivité et la sécurité du réseau. La communication entre l'équipement utilisateur (UE), la fonction de gestion d'accès et de mobilité (AMF) et les autres composants du réseau s'appuie sur des protocoles standards tels que NGAP (Next Generation Application Protocol) et SCTP (Stream Control Transmission Protocol). Avec l'émergence des grands modèles de langage (LLM), l'étude de leur intégration au plan de contrôle devient de plus en plus pertinente afin d'améliorer la gestion, la configuration et la prise de décision automatisée. Ce projet vise à  implémenter une requête LLM dans le plan de contrôle entre une UE simulée (e.g. UERANSIM) et l'AMF, en réutilisant les protocoles NGAP et SCTP existants pour transmettre ces requêtes.

Prérequis

  • programmation linux, administration réseau-systeme (RSX102, RSX103)

  • réseaux mobiles (RSX116)

  • virtualisation des réseaux (RSX217)

Travail à  réaliser

  • Déployer un environnement 5G Core fonctionnel (p. ex. free5GC, Open5GS ou une CNF open source légère).

  • Implémenter une interface permettant d'envoyer des requêtes LLM via NGAP ou SCTP entre un simulateur d'UE (UERANSIM) et l'AMF.

  • Utiliser les protocoles existants afin d'assurer une transmission sécurisée et fiable des requêtes LLM.

  • Permettre à  l'AMF d'acheminer ces requêtes vers une fonction de plan de contrôle LLM (LLM PF) capable de les interpréter et de les traiter pour exécuter des actions ou fournir des réponses intelligentes.

  • à‰valuer les performances, la fiabilité et la latence de cette communication.

Références

  • 3GPP TS 38.413 (NGAP)

  • 3GPP TS 38.321 (SCTP)

  • Documentation de free5GC / Open5GS

  • Articles et publications sur l'intégration des LLMs dans les réseaux 5G

2

Routage de requêtes LLM et plan de transfert

Thierry Lejkin, Orange

-

Réunion 1 : 26/3

Mi-parcours : 16/4

Réunion 2 : 30/4

Soutenance : 11/6

Description générale

Dans le cadre de la 5G, la gestion du plan de contrôle est essentielle pour garantir la flexibilité, l'évolutivité et la sécurité du réseau. La communication entre la fonction de gestion de session (SMF), la fonction de plan utilisateur (UPF) et les autres composants du réseau s'appuie sur des protocoles standards tels que PFCP et HTTP/2. Avec l'émergence des grands modèles de langage (LLM), il devient pertinent d'explorer leur intégration au plan de contrôle afin de gérer des services situés derrière l'UPF (Industrie 4.0, villes intelligentes, etc.). Ce projet vise à  implémenter une requête LLM dans le plan de contrôle entre le SMF et l'UPF, en réutilisant des protocoles existants comme PFCP ou HTTP/2 pour transmettre ces requêtes.

Prérequis

  • programmation linux, administration réseau-systeme (RSX102, RSX103)

  • réseaux mobiles (RSX116)

  • virtualisation des réseaux (RSX217)

Travail à  réaliser

  • Déployer un environnement 5G Core fonctionnel (p. ex. free5GC, Open5GS ou une CNF open source légère).

  • Implémenter une interface permettant d'envoyer des requêtes LLM via les protocoles PFCP ou HTTP/2 entre un simulateur de requêtes, le SMF et l'UPF.

  • Utiliser les protocoles existants afin d'assurer une transmission sécurisée et fiable des requêtes LLM.

  • Permettre à  l'UPF d'acheminer ces requêtes vers une fonction de plan de contrôle LLM (LLM PF) capable de les interpréter et de les traiter pour exécuter des actions ou fournir des réponses intelligentes.

  • à‰valuer les performances, la fiabilité et la latence de cette communication.

Références

  • 3GPP TS 38.413 (NGAP)

  • 3GPP TS 38.321 (SCTP)

  • Documentation de free5GC / Open5GS

  • Articles et publications sur l'intégration des LLMs dans les réseaux 5G

3

BATMAN et localisation

Yacine Benchaib, Cnam

GUELLIL Mostafa

-

Réunion 1 : 26/03

Mi-parcours : 9/4

Réunion 2 : 7/5

Soutenance : 11/6

Description générale

Batman-Adv (Better Approach To Mobile Adhoc Networking) [1][2] est un protocole de communication dont l'objectif est d'apporter des améliorations significatives par rapport aux protocoles de routage utilisés dans les réseaux de type MANET (Mobile ad hoc networks) tel que OLSR. Il a été proposé par la communauté Freifunk qui s'intéresse particulièrement aux réseaux communautaires libres. La version 5 de Batman-Adv [3] introduit ELP (Echo Location Protocol). Il s'agit d'un protocole qui fournit une métrique utilisée pour déterminer le meilleur chemin à  utiliser.

Prérequis

  • programmation linux, administration réseau-système (RSX102, RSX103)

  • adressage et routage IP (RSX103)

  • réseaux mobiles (RSX116)

Travail à  réaliser

  1. éat de l'art concernant la problématique à  étudier

  2. Détailler le fonctionnement de Batman-Adv

  3. Mise en place d'un environnement de test virtuel

  4. à‰valuation de la quantité de trafic ELP selon différents niveaux de densité du réseau

  5. Mesure de l'impact d'ELP sur les métriques telles que le débit, la latence, ...

  6. En fonction des résultats trouvés, proposer des améliorations, un travail futur, ...

Références

  • [1] Johnson, David, Ntsibane S. Ntlatlapa, and Corinna Aichele. “Simple pragmatic approach to mesh routing using BATMAN." (2008).

  • [2] Kiran, K., et al. « Experimental evaluation of BATMAN and BATMAN-Adv routing protocols in a mobile testbed." TENCON 2018-2018 IEEE Region 10 Conference. IEEE, 2018.

  • [3] https://docs.kernel.org/networking/batman-adv.html

4

MASQUE

Yacine Benchaib, Cnam

Réunion 1 : 12/03

Mi-parcours : 9/4

Réunion 2 : 7/5

Soutenance : 11/6

Description générale

Utilisation de MASQUE en tant que VPN de nouvelle génération: évaluation des performances et de la furtivité en conditions réelles.

MASQUE (Multiplexed Application Substrate over QUIC Encryption) [1] est un protocole récent, qui est encore au stade de développement et de standardisation [2][3]. Il fonctionne avec le protocole QUIC [4][5] et la version 3 du protocole HTTP [6]. MASQUE permet notamment la création de tunnels, ce qui pourrait être une alternative intéressante aux VPN qui peuvent être identifiés et bloqués. Plusieurs versions open source associées à  MASQUE [7][8][9] sont disponibles mais avec parfois des fonctionnalités restreintes.

Prérequis

  • Programmation linux, administration réseau-systeme (RSX102, RSX103)

  • Architectures de réseau mobile (RSX116)

  • Architecture SDN et NFV (RSX217)

Travail à  réaliser

  1. éat de l'art concernant la problématique à  étudier

  2. Détailler le fonctionnement de MASQUE

  3. Mise en place d'un environnement de test virtuel

  4. à‰valuation des performances de MASQUE par rapport à  d'autres VPN

  5. à‰valuation de la furtivité des flux de données avec des outils de contrôle de flux

  6. En fonction des résultats trouvés, proposer des améliorations, un travail futur, ...

Références

5

VxLAN over QUIC

Stefano Secci, Cnam

Holali David GAVI
Fredy Leonard MAGANGA
Adrien RAMILIHARIVELO

Réunion 1 : 19/03

Mi-parcours : 9/4

Réunion 2 : 7/5

Soutenance : 18/6

Description générale

Le protocole QUIC, RFC9000 « QUIC: A UDP-Based Multiplexed and Secure Transport » définit un nouveau protocole de transport. Il est construit au-dessus d’UDP, et hors du système d’exploitation. Initialement lié au Web, et à http/3, on commence à l’utiliser dans d’autres contextes, comme le DNS par exemple. L’intérêt de QUIC est d’intégrer TLS1.3 directement, et d’améliorer les temps de mise en relation entre un navigateur et un serveur Web. Il offre des services presque équivalents à TCP (fiabilité des échanges, contrôle de flux, participation au contrôle de congestion global de l’Internet…) et offre une solution au problème HOL. Il n’est pas orienté flot d’octets mais flot de messages, et il est multi-flots.

A travers les informations fournies dans le références ci-dessous, on voit bien que porter VxLAN au-dessus de QUIC ne manque pas d’intérêt car on gagnerait au passage tous les services de QUIC dont l’intégration de TLS1.3 pour la sécurité. C’est l’objet du présent projet.

Prérequis

  • Administration réseau-système (RSX103)

  • Architectures de réseau mobile (RSX102)

Travail à  réaliser

  • Analyser l'état de l'art et la pertinence de l’approche VxLAN over QUIC.

  • Etudier la faisabilité du portage, recherche de projet open source, peut-être creuser les références suivantes dont la liste n’est pas exhaustive.

  • En fonction de cette recherche proposer l’architecture d’une preuve de concept, choisir les souches logicielles, le système d’exploitation, l’approche composants s’il y a lieu, et le/les langages à utiliser.

  • Mettre en œuvre la preuve de concept. Mesurer ses performances, capturer des traces avec Wireshark. Conclure sur la pertinence de la solution. Quelles perspectives cela offre.

  • Risques éventuels dans la réalisation du travail demandé : Le choix des souches open source, du langage, et du système d’exploitation doit être fait avec précaution et minutie. Prendre des sources où les communautés sont actives et rigoureuses/méthodiques. Pour QUIC comme pour VxLAN ne pas nécessairement s’attacher à la version la plus complète, par exemple le contrôle de congestion de QUIC n’est pas nécessairement à l’état de l’art avec l’usage de BBR ("Bottleneck Bandwidth and Round-trip propagation time").

Références

• A. Shaji George, A.s Hovan George. A Brief Overview of VXLAN EVPN. July 2021. https://www.researchgate.net/publication/352999040_A_Brief_Overview_of_VXLAN_EVPN (12/01/2026)

• Arista, Virtual Extensible LAN (VXLAN) Overview. https://www.arista.com/assets/data/pdf/Whitepapers/Arista_Networks_VXLAN_White_Paper.pdf (12/01/2026)

• QUIC Working Group, https://quicwg.org/ (12/01/2025)

• RFC 8999: Version-Independent Properties of QUIC, 2021.

• RFC 9000 QUIC: A UDP-based multiplexed and secure transport, 2021.

• RFC 9001: Using TLS to secureQUIC, 2021.

• RFC 9002: QUIC Loss Detection and Congestion Control, 2021.

• RFC 9114: HTTP/3, 2022.

• RFC 9204: QPACK: Field Compression for HTTP/3, 2022.

• RFC 9221: An Unreliable Datagram Extension to QUIC, 2022.

• RFC 9287: Greasing the QUIC Bit, 2022.

• RFC 9308: Applicability of the QUIC Transport Protocol, 2022.

• RFC 9312: Manageability of the QUIC Transport Protocol, 2022.

• RFC 9368: Compatible Version Negotiation for QUIC, 2023.

• RFC 9369: QUIC Version 2, 2023.

• D. Saif, A. Matrawy, Demystifying QUIC from the Specifications, https://arxiv.org/abs/2511.08375 (12/01/2026)

J. Singh Sidhu, A. Bentaleb, Video Streaming Over QUIC: A Comprehensive Study, https://arxiv.org/abs/2505.21769 (12/01/2026)

https://github.com/martimy/clab_vxlan_frr (12/01/2026)

https://github.com/faysalmehedi/vxlan-ovs-docker-lab (12/01/2026)

https://github.com/upa/vxlan (12/01/2026)

https://github.com/topics/quic (12/01/2026) qui est plutôt un point d’entrée de références

https://github.com/mmmarcos/awesome-quic (12/01/2026)

https://github.com/quicwg (12/01/2026)

6

CAMARA et agents

William Diego, CellNext

Ahmed Zaouali

BITAN Shmuel 

Réunion 1 : 12/03

Mi-parcours : 16/4

Réunion 2 : 23/4

Soutenance : 11/6

Description générale

Le projet CAMARA, porté conjointement par la Linux Foundation et la GSMA Operator Platform Group, vise à standardiser l’exposition des capacités des réseaux télécom (notamment 5G) à travers des APIs ouvertes, interopérables et multi-opérateurs. Ces APIs permettent aux applications d’accéder dynamiquement à des fonctions réseau telles que la localisation des terminaux, leur état, la qualité de service à la demande ou encore la détection de changement de SIM.

Ce projet explore une dimension avancée de CAMARA : L’intégration des Telco APIs avec des agents d’intelligence artificielle via le Model Context Protocol (MCP), afin de transformer le réseau en plateforme programmable pilotée par logiciel.

Deux cas d’usage concrets seront implémentés :

  • Smart Connectivity Boost : activation dynamique d’une QoS prioritaire pour une application critique (e.g. vidéo temps réel) en fonction du contexte du terminal (état, localisation).

  • Telco-Grade Fraud Prevention : corrélation des APIs Device Status, Device Location et SIM Swap pour sécuriser une transaction sensible (paiement, accès bancaire).

Prérequis

  • Programmation linux, administration réseau-systeme (RSX102, RSX103)

  • Architectures de réseau mobile (RSX116)

  • Architecture SDN et NFV (RSX217)

  • APIs REST, Kubernetes, LLM

Travail à  réaliser

  • Étude CAMARA, Telco APIs, MCP et réseaux programmables

  • Déploiement des APIs CAMARA, serveur MCP et agent IA

  • Implémentation de deux cas d’usage : QoS on Demand et détection SIM Swap

  • Démonstration : décisions réseau automatisées, activation dynamique QoS, blocage fraude

  • Analyse critique : comparaison API classique vs IA, scalabilité, sécurité, usages industriels

Références

7

5G control-plane & K8S

Christian Destré, Orange


COULIBALY

Garan

 MOREL Nicolas





Réunion 1 : 12/3

Mi-parcours : 2/4

Réunion 2 : 23/4

Soutenance : 18/6

Description générale

Pour gérer automatiquement le cycle de vie et la configuration des applications déployées sur Kubernetes, l'utilisation des opérateurs Kubernetes est une approche innovante. Elle permet de prendre en charge la gestion basée sur l'intention et les ressources de réconciliation natives. En d'autres termes, les opérateurs Kubernetes comparent l'état cible des ressources donné par une intention (également appelée définition de ressource personnalisée) avec l'état réel des ressources observé dans le cluster. Le rapprochement est l'étape au cours de laquelle les actions sont décidées et mises en œuvre par les opérateurs Kubernetes lorsque les états cible et réel diffèrent. Pour parvenir à un tel comportement, les opérateurs Kubernetes surveillent les ressources Kubernetes et les actions qui s'y rapportent. Le déploiement de plusieurs opérateurs Kubernetes augmentera la charge sur le plan de contrôle Kubernetes. L'objectif du projet est de comprendre comment les mécanismes de surveillance et de réconciliation d'un opérateur Kubernetes donné affectent le plan de contrôle Kubernetes et d'identifier les meilleures pratiques pour atténuer tout problème de performance.


Prérequis

  • Administration réseau-système (RSX103)

  • Architectures de réseau mobile (RSX116)

  • Architectures NFV et SDN (RSX217)

Travail à  réaliser

Les principales tâches du projet sont les suivantes :

- Comprendre comment un opérateur Kubernetes est développé et s'appuie sur le plan de contrôle Kubernetes pour réaliser l'automatisation

- Développer un opérateur Kubernetes pour une application simple (NGINX, Open5GS) afin d'automatiser la gestion de son cycle de vie et d'évaluer son impact sur le plan de contrôle Kubernetes (via la capture du trafic, les métriques, etc.)

- Proposer des conclusions sur l'utilisation de plusieurs opérateurs Kubernetes dans un cluster pour la gestion de performance, le dimensionnement du plan de contrôle de Kubernetes.



Références et mots clé

  • Coeur de réseau 5G SA: https://www.free5gc.org/ ou https://open5gs.org/

  • Tests de sécurité ciblant HTTP/2: https://owasp.org/www-project-zap/

  • Simuler des attaques MITM et analyser les vulnérabilités dans les échanges: https://mitmproxy.org/

  • Pour pour SSL: https://www.openssl.org/

  • pour OAuth 2.0: https://oauth.net/

  • Operator pattern | Kubernetes

  • OperatorHub.io | The registry for Kubernetes Operators

  • Operator SDK

8

5G data-plane & K8S

Christian Destré, Orange


Réunion 1 : 12/3

Mi-parcours : 2/4

Réunion 2 : 23/4

Soutenance : 18/6

Description générale
Dans l'architecture 5G SA, la fonction UPF (User Plane Function) est chargée d'acheminer le trafic de la couche utilisateur, depuis les équipements utilisateurs vers les réseaux de données, conformément aux règles de nommage des réseaux de données. Ainsi, toute fonction UPF doit être configurée avec des règles permettant de savoir comment acheminer le trafic. Cette tâche est généralement assurée par la fonction SMF (Session Management Function) qui contrôle la fonction UPF à l'aide du protocole PFCP. L'objectif du projet est d'identifier les capacités de routage du trafic (entre l'UPF et l'interface N6) qui sont mises en œuvre dans les systèmes 5G open source (Free5GC, Open5GS, OAI, autres ?) et comment elles sont configurées.


Prérequis

  • Administration réseau-système (RSX103)

  • Programmation réseau et gestion de données (RSX102)

  • Architectures NFV et SDN (RSX217)

Travail à  réaliser

Les principales tâches sont les suivantes :

- Étude des fonctions UPF et des capacités de routage prises en charge

- Étude du fonctionnement du protocole PFCP pour configurer l'UPF conformément aux normes et analyse avec la mise en œuvre de SMF & UPF 5G open source

- Installation de systèmes 5G open source dans un système Kubernetes local et analyse du trafic PFCP en fonction de la configuration

- Comparaison des solutions open source

Mots clé

PFCP - Wikipedia

free5GC

open5gs.org

oai / cn5g / oai-cn5g-upf-vpp ·

9

Switch NetFPGA Plus

Mario Patetta, Cnam


Réunion 1 : 19/3

Mi-parcours : 2/4

Réunion 2 : 23/4

Soutenance : 18/6

Description générale

Au sein de l’équipe ROC du CNAM, nous avons développé un ordonnanceur de paquets programmable basé sur FPGA, intégré au framework open-source Corundum pour cartes réseau (NIC) [1], et implémenté sur des cartes FPGA Alveo AU200.

Comparé à Corundum, le framework NetFPGA-PLUS [2] apparaît plus adapté au prototypage de commutateurs réseau.

L’objectif de ce projet est de porter la conception matérielle de l’ordonnanceur programmable vers le framework NetFPGA-PLUS, en incluant à la fois l’intégration matérielle et l’adaptation du driver Linux associé.

Prérequis

  • Administration réseau-système (RSX103)

  • Conception RTL en Verilog ou VHDL

  • Compréhension des protocoles de communication AXI4-Stream et AXI4-Lite (souhaitée)

  • Familiarité avec l’environnement AMD/Xilinx Vivado



Travail à  réaliser

- Étude de l’architecture du framework NetFPGA-PLUS

- Première prise en main du Reference Router [3] NetFPGA-PLUS

- Intégration de l’ordonnanceur de paquets programmable au sein de l’architecture NetFPGA-PLUS

- Développement et/ou mise à jour du pilote Linux NetFPGA-PLUS afin de : (i) configurer les paramètres de routage et (ii) d’ordonnancement, et (iii) lire les compteurs du routeur.

- Comparer l'utilisation des ressources FPGA et le débit maximal par rapport au framework Corundum.

Références

[1] https://github.com/corundum/corundum

[2] https://github.com/NetFPGA/NetFPGA-PLUS

[3] https://github.com/NetFPGA/NetFPGA-PLUS/wiki/Reference-Router

10

NEPHIO GitOps

William Diego, CellNext


Réunion 1 : 12/03

Mi-parcours : 2/4

Réunion 2 : 23/4

Soutenance : 11/6

Description générale

Nephio est une plateforme open-source portée par la Linux Foundation visant à automatiser entièrement le cycle de vie des réseaux cloud-natifs (Day-0 à Day-2) à l’aide de Kubernetes et du paradigme GitOps. Contrairement aux approches classiques NFV, Nephio introduit une orchestration déclarative et pilotée par intention (intent-based networking) permettant le provisionnement Zero-Touch de fonctions réseau distribuées sur plusieurs clusters Edge et Cloud. Ce projet vise à explorer une capacité avancée de Nephio : l'orchestration GitOps.

L’orchestration GitOps multi-sites du cœur 5G avec propagation automatique de configuration, validation continue et gestion du cycle de vie. Un cas d’usage concret sera implémenté autour d’un 5G Standalone Core (Open5GS) couplé à UERANSIM, déployé sur Kubernetes via Nephio, en mettant l’accent sur :

  • la génération automatique de configuration depuis une intention réseau,

  • la distribution GitOps vers plusieurs clusters,

  • la gestion du lifecycle (scale, update, redeploy),

  • et l’observabilité opérationnelle.

L’objectif n’est pas seulement de déployer un 5G Core, mais de démontrer comment Nephio transforme un déploiement télécom complexe en pipeline CI/CD réseau puis le comparer avec une approche Helm classique.

Prérequis

  • Administration réseau-système (RSX103)

  • Architectures de réseau mobile (RSX116)

  • Bases GitOps / CI-CD, Kubernetes



Travail à  réaliser

Automatisation complète du cycle de vie d’un cœur 5G (Day-0 → Day-2) via Nephio

Déploiement Open5GS + UERANSIM piloté par intention réseau (intent-based networking)

Orchestration multi-clusters avec propagation automatique de configuration

Mise en œuvre du Zero-Touch Provisioning (déploiement sans intervention manuelle)

Démonstration Day-2 : scaling, ajout UE ou modification slicing via Git

Comparaison avec approche Helm classique (apports Nephio : CI/CD réseau, lifecycle, validation continue).

Références

https://nephio.org
https://wiki.nephio.org
https://docs.nephio.org/docs/guides/user-guides/usecase-user-guides/
https://drive.google.com/file/d/1OANqnh9hTiep8Vr3yFLep0qhMOpGb9jE/view

11

5G3E

Masoud Baharlouei, Naresh Modina, Cnam

NYOBE Cliton Stéphane


Réunion 1 : 19/3

Mi-parcours : 2/4

Réunion 2 : 23/4

Soutenance : 18/6

Description générale

Pour les systèmes 5G et Beyond 5G, le développement de bancs d’essai réalistes est essentiel afin de tester différentes fonctionnalités, collecter des données prêtes pour l’IA et développer des preuves de concept. Ce projet offre l’opportunité de travailler sur des plateformes de pointe : le banc d’essai 5G3E du Cnam et le simulateur ns-O-RAN-flexric d’Orange Innovation. ns-O-RAN-flexric est une plateforme open source de simulation et de test 5G O-RAN, conçue pour valider des xApps/rApps et des cas d’optimisation du RAN au sein de l’écosystème RIC-TaaP. 5G3E est une plateforme émulée permettant la reproduction réaliste d’une pile 5G de bout en bout. L’identification des axes d’amélioration et le développement de nouvelles fonctionnalités permettront de renforcer la fiabilité de ces simulateurs et émulateurs.

Prérequis

  • Administration réseau-système (RSX103)

  • Architectures de réseau mobile (RSX116)

  • Virtualisation des fonctions de réseau (RSX217)



Travail à  réaliser

Le projet comprend les tâches suivantes :

  • Déployer ns-O-RAN-flexric d’Orange

  • Étudier l’utilisation de SUMO et du ray tracing avec Sionna

  • Tester différentes allocations de cellules et positions des UE

  • Explorer la possibilité d’envoyer le trafic généré par NS3-RT (temps réel) sur un canal créé par Sionna RT (ray tracing)

  • Observer les résultats des simulations via la plateforme Grafana

  • Intégration possible de la configuration UE provenant du banc d’essai 5G3E

Références

  1. https://github.com/Orange-OpenSource/ns-O-RAN-flexric/?tab=readme-ov-file

  2. https://github.com/robpegurri/ns3-rt

  3. https://github.com/cedric-cnam/5G3E-dataset

  4. Dung Chi Phung, Nour-El-Houda Yellas, Salah Bin Ruba, Stefano Secci. An Open Dataset for Beyond-5G Data-driven Network Automation Experiments. 2022 1st International Conference on 6G Networking (6GNet), Jul 2022, Paris, France. ⟨10.1109/6GNet54646.2022.9830292⟩. ⟨hal-03698732v2⟩

12

MCP découverte et démonstration

Pierre Sweid, Cnam

VITRANT Sébastien

ANDRIEUX Andry

Réunion 1 : 19/03

Mi-parcours : 9/4

Réunion 2 : 7/5

Soutenance : 18/6

Description générale

Les agents d’Intelligence artificielle, pour répondre aux différentes demandes des utilisateurs sont amenés à solliciter différentes sources de données (autres IA, Bases de données spécialisées, Web…) pour fragmenter leurs tâches pour élaborer un contexte d’analyse et de réponse. C’est particulièrement nécessaire avec les LLM (Large Language Models), et l’IA générative. Le contexte est très important pour qu'une IA génère des réponses utiles et logiques. Plus une IA est performante pour gérer un contexte, plus justes et cohérentes sont ses réponses.

Les sources de données peuvent être de natures très différentes par leur contenu, leur technologie d’accès ainsi que par les règles d’utilisation comme le prompt. L’hétérogénéité règne à tous les étages. C’est là que le protocole de communication MCP, Model Context Protocol, un nouveau standard entre en jeu pour tenter d’apporter une solution à l’homogénéisation des échanges de données pour l’IA agentique. MCP est porté principalement par Anthropic.

Le protocole MCP se veut une norme ouverte pour connecter des systèmes d'IA avec des sources de données et des outils (dépôts, outils métier, environnements de développement), en remplaçant les intégrations fragmentées par un seul protocole. Il remplace les connexions désordonnées par une seule méthode de connexion. Ainsi il permet aux clients et aux serveurs d'IA de fonctionner ensemble de manière plus fluide. Certains développeurs d’application voient MCP comme la brique de base d’un intergiciel pour les applications du futur.

Prérequis

  • Administration réseau-système (RSX103)

  • RPC, pub-sub et protocoles applicatifs (RSX102)

Travail à  réaliser

  • Etude d'état de la et des besoins : Le travail devra analyser pourquoi le besoin d’un tel protocole a émergé, quels sont les éléments constitutif du protocole, en particulier JSON-RPC 2.0, et donner des cas d’usages. Quelles technologies d’IA l’utilisent et comment. C’est une première partie qui peut rentrer dans un état de l’art. Il y a d’autres protocoles qui ont le même objectif comme A2A (Agent-to-Agent). Quelles sont les entreprises qui utilisent MCP pour fournir des solutions d’IA distribuée ? Comment elles l’utilisent, pour quelles applications. Lesquelles l’utilisent comme un middleware ? Cette seconde partie poursuit l’état de l’art. 3. Quelles sont les versions open source de MCP ? Il y a un GitHub : https://github.com/modelcontextprotocol (02/01/2026), y en a-t-il d’autres ? En choisir une.

  • Développer une application prototype, à définir avec l’encadrant puis la tester. C’est certainement la partie cliente qu’il faudra réaliser.

  • Capturer des échanges via Wireshark pour examiner toute la partie communication et vérifier la conformité avec les spécifications officielles.

  • Comparer d'éventuelles implémentations concurrentes.

Références