Page de l'UE de
l'année en cours.
NB : pour accéder aux
digital libraries 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.
|
Num. |
Titre |
Tuteur |
Personnes |
Réunions et soutenances |
|
1 |
Data pipelining |
Thierry Lejkin, Orange |
GUILLAUMAT
Simon SCHUCHARD Nicolas |
Réunion I: 13/3 |
|
Description
générale : l’intégration de
fonctions d’intelligence artificielle dans les réseaux crée de nouvelles
problématiques de collecte de données en temps réel afin de les livrer à des
points de traitement qui puisse les analyser en temps réel ou presque. De
nouveaux systèmes de « telecom data
pipelining » se définissent. Des briques logicielles classiques
existent, issus des centres de données, pour la supervision de machines, mais
sans de fonctions de prétraitement et de partage de charge intégrés. D’autres
avec ces fonctions existent (RabbitMQ, Kafka), mais
avec des performances réseaux (latence, bitrate) à
qualifier, et d’autres fonctions pas prioritaires (stockage, data warehousing). D’autres plus récentes ont fait surface
(ZENOH). L’objectif de ce projet est de comparer au mois 3 solutions à l’état
de l’art (RabbitMQ, Kafka, Zenoh),
voire d’autres qui auraient été identifiées avec l’état de l’art, et en
comparer expérimentalement au moins deux parmi celles-ci. Prérequis :
Travail à réaliser
: Les taches sont : 1)
effectuer un état de l’art détailler sur les plateformes de data pipelining 2)
Comparer qualitativement les alternatives et justifier un choix reduit à 2. 3)
Determiner la parametrisation
nécessaire pour le fonctionnement optimal de chaque système 4)
Monter une maquette et comparer expérimentalement les solutions en fonction
du délai de bout en bout, bitrate, gigues,
ressources de calcul mobilisés. Références : CNSM 2024 paper :
https://dl.ifip.org/db/conf/cnsm/cnsm2024/1571045819.pdf |
||||
|
2 |
RDMA |
Flavien Joly-Pottuz (Orange) |
ONDZE ITOUA Rufin PARROT Eric THOMAS-PEDRO Omonkpe Ricardo |
Réunion I: 27/3 |
|
Description
générale : RDMA
est un protocole qui ajoute des fonctionnalités au niveau des cartes réseaux
Ethernet afin de faciliter des accès à la mémoire de serveurs distants,
notamment serveurs GPU, de manière distante entre clusters de calculés
distribués. L’objectif de ce projet est de démontrer son fonctionnement avec
des simulateurs réseaux à l’état de l’art. Prérequis :
Travail à réaliser
: Les taches sont : 1) Effectuer un état de l’art à jour sur RDMA et ses
implémentations réelles et dans des simulateurs. 2) Comparer les différentes implémentations qualitativement. 3) Choisir au moins un simulateur pour effectuer les simulation 4) Définir un scenario avec un grand nombre de nœuds simulés (100
à 10000) et montrer les performance de RDMA dans
différentes configurations à définir. Références : Papier SIGCOMM 2024 (RDMA over Ethernet for Distributed
AI Training at Meta Scale) : https://dl.acm.org/doi/pdf/10.1145/3651890.3672233?casa_token=Mfky7RFFlA4AAAAA:cXV1g-NirhxMmUKjENSyWl83IsiN5f3w1Cht74SNzwDSqWY64SR3zFtywdI-5AIy7A7dWBbbUWE28w https://github.com/bobzhuyb/ns3-rdma |
||||
|
3 |
Thread |
Yacine Benchaib, Cnam
|
BACAR Mouzamilou Legrand Cédric Nader Haddad |
Réunion I: 27/3 |
|
Description générale : Thread[1][2][3] est un
nouveau protocole de communication basé sur 6LoWPAN[4] pour les objets
connectés. Il permet la création d'un réseau maillé résiliant au sein duquel certains
des périphériques ont un rôle particulier.
Travail à réaliser
: Les taches sont : 1) Faire un état
de l'art des protocoles similaires à Thread Références : [1]: Unwala, Ishaq, Zafar Taqvi, and Jiang
Lu. "Thread: An iot protocol." 2018 IEEE Green Technologies Conference (GreenTech). IEEE,
2018. |
||||
|
4 |
Sécurisation des
échanges dans un cœur 5G SA |
Christian Destré, Orange |
Alexandre MONIOT |
Réunion I: 20/03 |
|
Description
générale : les
échanges entre les différentes fonctions réseaux du plan de contrôle
composant un cœur de réseau 5GSA doivent être
sécurisés avec l’activation du chiffrement/HTTP2 sur TLS. La conséquence est
que l’analyse des flux entre les fonctions réseaux s’en retrouve
complexifiée. Pour ce projet, il est demandé d’analyser l’activation du
chiffrement pour deux cœurs 5G. ·
Programmation linux, administration réseau-systeme
(RSX102, RSX103). ·
Architectures de réseau mobile (RSX116). ·
Architecture SDN et NFV (RSX217). Travail à
réaliser : 1.
Documenter à partir des spécifications 3GPP Release 16/17 les
exigences TLS (version, ciphers, …) qui
s’appliquent au cœur 5G SA. 2.
Analyser les documentations/code des projets Free5GC et OpenGS et conclure sur le respect des exigences TLS du
3GPP. 3.
Installer Free5GC en local sur un PC avec une configuration TLS
activée a.
Type de déploiement docker/kubernetes
laissé libre 4.
Utiliser des outils pour vérifier la configuration TLS de chacune
des fonctions 5GSA du plan de contrôle a.
Vérification des versions TLS/ciphers/…
supportés b.
Choix des outils de test laissé libre c.
Rapport de test et conclusion sur la conformité 5.
Réaliser l’analyse pour Open5GS et faire une comparaison avec
Free5GC. Références : 3GPP : 3GPP – The Mobile Broadband Standard |
||||
|
5 |
SRv6-5G : Utilisation de SRv6 pour remplacer le
protocole GTP |
Thierry Lejkin, Orange |
|
Réunion I: 13/3 |
|
Description générale: Dans les
réseaux 5G traditionnels, le protocole GTP (GPRS Tunneling Protocol) est
utilisé pour encapsuler et transporter le trafic utilisateur entre différents
éléments du réseau, notamment entre la RAN (Radio Access Network) et l’UPF
(User Plane Function). Cependant, GTP présente des
limitations en termes de flexibilité, de programmabilité,
et de sécurité. Le protocole SRv6 (Segment Routing
over IPv6) est une alternative émergente offrant des avantages tels qu'une
gestion simplifiée des flux, une réduction de l’utilisation des tunnels et
une intégration native avec les architectures IPv6. Ce projet consiste à
étudier, déployer, et analyser les performances de SRv6 en remplacement de
GTP pour la communication entre RAN et UPF.. Prérequis:
Travail à réaliser
:
·
Analyse des protocoles
GTP et de leurs usages dans les architectures 5G actuelles (3GPP TS 29.281). ·
Étude des
spécifications SRv6 et de son application potentielle dans les réseaux 5G+/6G
(par exemple, RFC 8986). ·
Comparaison des
deux protocoles en termes de performance, flexibilité, et sécurité.
·
Comprendre comment
SRv6 peut être utilisé pour segmenter et diriger le trafic utilisateur. ·
Identifier les
tendances autour du remplacement de GTP par SRv6 dans la future évolution des
réseaux 5G et 6G.
·
Utiliser Free5GC
ou Open5GS pour implémenter les fonctions réseau telles que AMF, SMF, et UPF. ·
Configurer la RAN
avec un simulateur comme UERANSIM pour générer du trafic utilisateur. ·
Configurer un réseau
IPv6 compatible et activer le support SRv6 côté infrastructure (routeurs et
nœuds réseau).
·
Générer du trafic
utilisateur simulé via la RAN et le transmettre à l’UPF en utilisant SRv6. ·
Evaluer la capacité de
SRv6 à gérer des pannes ou des déviations de chemin, …. ·
Identifier les
avantages pratiques apportés par SRv6 (réduction des overheads,
simplification de l'architecture, etc.). Références: https://www.free5gc.org/
ou https://open5gs.org/ - Implémentations
SRv6 : https://fd.io/ : Plateforme pour
implémenter un support SRv6 dans un environnement réseau. https://frrouting.org/ : Projet open-source
pour configurer des routeurs SRv6. https://www.srv6.net/ : Documentation sur
l’utilisation native de SRv6 dans le noyau Linux. Tests
de performance: Test
de connectivité SRv6: ·
https://man7.org/linux/man-pages/man8/ping6.8.html
: Pour tester la connectivité IPv6/SRv6. |
||||
|
6 |
Analyse de la
fonction Service Communication Proxy (SCP) d’un cœur 5G |
Christian Destré, Orange |
Carlucci Teddy Jouve Guillaume |
Réunion I: 20/03 |
|
Description
générale : Le 3GPP a introduit une fonction réseau SCP au sein du cœur
5G afin d’optimiser les échanges entre les fonctions réseaux d’un cœur 5G SA.
Pour ce projet, il est demandé d’analyser le rôle de cette fonction SCP selon
les normes 3GPP et d’analyser son fonctionnement pour le réseau cœur opensource Open5GS déployé sur Kubernetes. ·
Programmation linux, administration réseau-systeme
(RSX102, RSX103). ·
Architectures de réseau mobile (RSX116). ·
Architecture SDN et NFV (RSX217). Travail à
réaliser : 1.
Documenter le rôle de la fonctionnalité SCP selon les normes 3GPP
et expliquer son fonctionnement/intérêt pour la communication entre les
fonctions d’un cœur 5G SA. 2.
Installer un Cluster Kubernetes en
local (type minikube ou Kind),
y installer la dernière release du cœur Open5GS + le simulateur UERANSIM. a.
Déploiement simplifié avec Helm b.
Vérifier que l’enregistrement d’un UE et
son établissement de session PDU fonctionne bien avec la configuration par
défaut sans SCP 3.
Analyser le trafic entre les différentes fonctions réseaux du
cœur 5G SA avec ou sans activation du SCP a.
Utilisation de Wireshark b.
Analyse des flux/messages entre les fonctions dans le cadre de
l’enregistrement d’un UE et de l’établissement de
session pdu c.
Demo 4.
Discussion sur les avantages/inconvénients de la fonction SCP et
de son impact sur la fonction NRF Références Open5GS : open5gs.org |
||||
|
7 |
NRF (Network Repository Function) |
ANDRIEUX Andry |
Réunion I: 13/3 |
|
|
Description générale: Les
interfaces des fonctions réseaux 5G SA utilisent les protocoles HTTP/2 et
sont exposées à des risques, notamment celui d'usurpation d'identité. Ce
risque touche particulièrement la fonction NRF (Network Repository
Function), qui centralise les identités et
adressages des fonctions réseaux (NFs) du plan de
contrôle. Avec l’évolution future des architectures 5G+ ou 6G, il est
envisagé d’intégrer également les RAN et les UPFs
au sein de l’architecture SBA (Service-Based
Architecture), augmentant ainsi l’exposition aux risques. Ce projet consiste
à analyser les risques liés à cet environnement, spécifiquement dans le cadre
de l’usurpation d’identité. Prérequis:
Travail à réaliser
:
Références: 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 OAuth 2.0: https://oauth.net/ |
||||
|
8 |
FastSwan |
Flavien Joly-Pottuz
(Orange) |
BENZAZA Abdelaziz DJOKI DJOKI Paul JABY Christophe |
Réunion I: 27/3 |
|
Description
générale : fastSwan est un logiciel de
routage écrit en C. L'objectif principal de ce projet est de fournir un
chemin de données rapide pour la couche XFRM du noyau Linux. Certains
fabricants de cartes réseau (NIC) offrent une accélération IPSEC via un mode
Crypto ou un mode Packet. En mode Packet, toutes les opérations IPSEC ESP sont effectuées
par le matériel, permettant ainsi de décharger le noyau des traitements liés
au chiffrement et à la gestion des paquets. Pour augmenter encore les performances, fastSwan
met en œuvre une décharge de routage au niveau du noyau grâce à XDP. Un
réflecteur netlink pour la couche XFRM du noyau
reflète de manière dynamique et transparente les politiques XFRM du noyau
vers la couche XDP, afin de contourner la pile réseau du noyau. Prérequis :
Travail à réaliser
:
Références : |
||||
|
9 |
OAI-3GPP : |
Christian Destré, Orange |
|
Réunion I: 20/03 |
|
Description
générale : Le déploiement
des réseaux 3GPP 5G SA est en cours par les différents opérateurs. La 5G SA
introduit beaucoup d’innovations, notamment en lien avec la gestion à la
demande de réseaux/services 5G. Cela notamment implique une implémentation
virtualisée des fonctions réseaux 5G, notamment avec des containers et une automatisation
qui se base sur la technologie Kubernetes.
L’objectif de ce projet est de déployer sur Kubernetes
un réseau cœur 5G opensource avec un composant de
simulation de la partie réseau d’accès, d’analyser le trafic dans
l’environnement Kubernetes concernant les
procédures d’enregistrement et d’établissement de session et de vérifier la
conformité de ces procédures avec le standard 3GPP. ·
Programmation linux, administration réseau-systeme
(RSX102, RSX103). ·
Architectures de réseau mobile (RSX116). ·
Architecture SDN et NFV (RSX217). Travail à
réaliser : 1.
Identifier la dernière release d’OpenAirInterface
5G Core et ses prérequis pour être déployée dans un
environnement Kubernetes. Identifier la release
3GPP avec laquelle OAI Core est supposé être
conforme et les spécifications 3GPP correspondantes concernant les procédures
d’enregistrement d’un UE et d’établissement de session PDU. 2.
Installer un Cluster Kubernetes en
local sur un PC (type minikube ou Kind) et y installer la
dernière release de OAI Core 5G + le simulateur
UERANSIM. a.
Identifier les paramètres de configuration et de provisionning nécessaires pour qu’un User Equipment (UE)
puisse se connecter au réseau 5G OAI Core+UERANSIM b.
Réaliser le déploiement simplifié avec Helm c.
Vérifier que l’enregistrement de l’UE et l’établissement de
session PDU se réalise bien. 3.
Analyser le trafic entre l’UE et les différents éléments d’OAI Core pour vérifier le respect de la norme 3GPP pour les
procédures d’enregistrement et d’établissement de session PDU. a.
Usage de Wireshark + analyse des
trafics entre UE/GnB et le cœur 5GSA, ainsi
qu’entre les différentes fonctions du cœur 5G SA. b.
Demo c.
Analyse de conformité : les procédures d’OAI Core sont-elles conformes aux spécifications 3GPP ? 4.
Configurer la plateforme pour que 2 UEs
se connectent sur 2 slices 5G différentes, chacune ayant une fonction UPF
dédiée et montrer le trafic du plan de contrôle. 1.
Démo. Références 3GPP : 3GPP – The Mobile Broadband Standard |
||||
|
10 |
Corondum |
Mario Patetta (Cnam) |
Anthony MARTIN |
Réunion I: 20/03 |
|
Description
générale : Description
générale : Corundum est une implémentation
open-source en Verilog d'un NIC à haute performance
basée sur des FPGA et une plateforme pour le calcul en réseau. Les
caractéristiques comprennent un chemin de données haute performance, Ethernet
10G/25G/100G, un moteur DMA personnalisé haute performance et étroitement
intégré à une interface PCIe Gen3, plus de 1000 de
nombreuses files d'attente de transmission, de réception, d'achèvement et
d'événements, DMA de diffusion/récupération, interruptions MSI, multiples
ports et interfaces, planification de transmission par port avec TDMA
haute précision, hachage de flux, RSS, déchargement de somme de contrôle et
horodatage PTP IEEE 1588 natif. Un
pilote Linux est inclus et s'intègre à la pile réseau Linux. Le développement
et le débogage sont facilités par un cadre de simulation étendu qui couvre
l'ensemble du système, depuis un modèle de simulation du pilote et de
l'interface PCI express d'un côté jusqu'aux interfaces Ethernet de l'autre
côté Corundum possède plusieurs caractéristiques architecturales uniques.
Tout d'abord, les états des files d'attente d'émission, de réception,
d'achèvement et d'événements sont stockés efficacement dans des blocs de RAM
ou d'ultra RAM, ce qui permet de prendre en charge des milliers de files
d'attente contrôlables individuellement. Ces files d'attente sont associées à
des interfaces, et chaque interface peut avoir plusieurs ports, chacun avec
son propre planificateur indépendant. Cela permet un contrôle extrêmement fin
de la transmission des paquets. Couplé à la synchronisation temporelle PTP,
cela permet un TDMA de haute précision. Corundum
propose également une section d'application pour la mise en œuvre d'une
logique personnalisée. La section d'application dispose d'une BAR PCIe dédiée pour le contrôle et d'un certain nombre
d'interfaces qui donnent accès au chemin de données central et à
l'infrastructure DMA. Dans
son fonctionnement de base, Corundum est un NIC,
c'est-à-dire que tous les paquets reçus sont envoyés à l'ordinateur hôte via PCIe, et il n'est pas destiné à être utilisé comme un
commutateur. Cependant, dans le passé, la communauté des développeurs s'est
efforcée d'intégrer un commutateur dans l'architecture de la carte
d'interface réseau. L'objectif
de ce projet est d'étudier l'évolution de cette fonctionnalité, d'implémenter
un commutateur dans l'architecture Corundum et
éventuellement d'intégrer une application de scheduling
de paquets fournie par le tuteur. Prérequis :
Travail à réaliser
: Les taches sont : -
Etat de l’art et prise en main des caractéristiques
des dernières versions de Corundum. -
Vérifier l'état d'avancement de la mise en place d'un commutateur au sein de
l'architecture Corundum. -
Réaliser un simple commutateur capable de diffuser des paquets à partir des
ports NIC en contournant la machine hôte. -
(Facultatif) Intégrer un module de scheduler
dynamique de paquets. Références : |
||||
|
11 |
Sécurité des
containers |
Yacine Benchaib, Cnam |
KEFKEF
Ahmed TANIER Daniel CAMARA Salifou |
Réunion I: 27/3 |
|
Description
générale : Prérequis :
Travail à réaliser
: (exclusivement sous environnement Linux): Références : |
||||
|
12 |
NWDAF |
Thierry Lejkin, Orange |
Patrice
TERMOSIRIS |
Réunion I: 13/3 |
|
Description générale: L'architecture 5G
intègre l'architecture NFV pour opérer des fonctions des réseaux du coeur de réseau cellulaire 5G (5GC) comme des "virtualized network functions"
(VNF). Parmi ces fonctions, la NWDAF (Network Data Analytics
Function) n’est pas encore intégrée aux plateformes
5GC open source les plus communes comme FREE5GC et Open5GS. L’objectif de ce
projet est de comparer des implémentations récentes de la NWDAF et en
démontrer le fonctionnement. Prérequis:
Travail à réaliser
:
Références: Implémentation OAI : Implémentation UWO : |
||||