refactor: Enhance and streamline academic report
- Removed verbose docstrings and excessive explanations - Condensed from 599 to 365 lines while keeping essential content - Emphasized hybrid SimPy approach in introduction - Simplified methodology section - Focused results tables and analysis - Removed redundant figures section (kept references in code) - Updated date to 3 November 2025 - Maintained all key findings and recommendations - Professional, concise, publication-ready format
This commit is contained in:
Alexis Bruneteau
parent
4d3cc0f57d
commit
88e34e4d94
@ -12,42 +12,40 @@
|
||||
parbreak()
|
||||
}
|
||||
|
||||
// Title Page
|
||||
#align(center)[
|
||||
#text(size: 24pt, weight: "bold")[
|
||||
Simulation LEACH vs LEACH-C\
|
||||
pour Réseaux Dynamiques\
|
||||
Simulation LEACH vs LEACH-C
|
||||
pour Réseaux Dynamiques
|
||||
avec Mobilité de Nœuds
|
||||
]
|
||||
|
||||
|
||||
#v(1em)
|
||||
|
||||
|
||||
#text(size: 14pt)[
|
||||
Agriculture de Précision\
|
||||
Agriculture de Précision
|
||||
Suivi en Temps Réel de Bovins
|
||||
]
|
||||
|
||||
|
||||
#v(2em)
|
||||
|
||||
|
||||
#text(size: 12pt)[
|
||||
Projet de Recherche en Réseaux de Capteurs Sans Fil (WSN)
|
||||
]
|
||||
|
||||
|
||||
#v(3em)
|
||||
#text(size: 11pt)[
|
||||
Auteurs : Paul Roost et Alexis Bruneteau
|
||||
]
|
||||
|
||||
|
||||
#v(1em)
|
||||
|
||||
|
||||
#text(size: 11pt)[
|
||||
31 Octobre 2025
|
||||
3 Novembre 2025
|
||||
]
|
||||
]
|
||||
|
||||
#pagebreak()
|
||||
|
||||
// Table of Contents
|
||||
#outline(depth: 2, indent: 1em)
|
||||
|
||||
#pagebreak()
|
||||
@ -56,544 +54,311 @@
|
||||
|
||||
== Motivation
|
||||
|
||||
Les réseaux de capteurs sans fil (Wireless Sensor Networks - WSN) jouent un rôle croissant dans les applications critiques, notamment en agriculture de précision. Le suivi en temps réel du bétail avec des capteurs mobiles offre des avantages significatifs :
|
||||
Les réseaux de capteurs sans fil (WSN) pour l'agriculture de précision nécessitent une gestion énergétique optimale. Le suivi de bétail mobile crée des défis uniques : clusters instables, communications longue portée, et batterie limitée.
|
||||
|
||||
- Détection précoce des problèmes de santé
|
||||
- Optimisation de la gestion du troupeau
|
||||
- Réduction des pertes économiques
|
||||
- Monitoring continu du bien-être animal
|
||||
Ce projet simule deux protocoles de clustering pour évaluer leur performance en réseaux dynamiques avec nœuds mobiles.
|
||||
|
||||
== Défis Énergétiques
|
||||
== Protocoles LEACH et LEACH-C
|
||||
|
||||
Le principal défi des WSN est la *gestion énergétique limitée*. Les capteurs attachés au bétail ont des batteries de faible capacité, ce qui rend la *durée de vie du réseau* critique.
|
||||
*LEACH* (Low-Energy Adaptive Clustering Hierarchy) : protocole décentralisé où chaque nœud a probabilité p de devenir cluster head chaque round.
|
||||
|
||||
== LEACH et LEACH-C
|
||||
*LEACH-C* : variante centralisée où la station de base sélectionne les cluster heads optimaux basés sur l'énergie disponible.
|
||||
|
||||
*LEACH* (Low-Energy Adaptive Clustering Hierarchy) est un protocole de clustering hiérarchique proposé par Heinzelman et al. (2000) pour minimiser la consommation énergétique.
|
||||
== Approche de Simulation
|
||||
|
||||
*LEACH-C* est une variante centralisée où la station de base calcule les clusters optimaux.
|
||||
Ce projet implémente deux approches SimPy complémentaires :
|
||||
|
||||
== Mobilité Dynamique
|
||||
1. *Simulateur Léger* : wrapper simple autour des protocoles existants (120 lignes)
|
||||
2. *Simulateur Hybride* : architecture complète orientée événements discrets (230 lignes)
|
||||
|
||||
*Contexte clé* : Contrairement aux études académiques antérieures (réseaux statiques), ce projet considère des *nœuds mobiles* qui se déplacent continuellement dans le champ d'observation.
|
||||
|
||||
*Impact* : La mobilité crée une instabilité des clusters, augmente les réélections de CH, et complique la gestion de la communication.
|
||||
Les deux approches génèrent résultats identiques. La première priorite la compatibilité, la seconde la pureté événementielle.
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Méthodologie & Conception
|
||||
= Méthodologie
|
||||
|
||||
== Modèle de Simulation
|
||||
== Configuration du Réseau
|
||||
|
||||
=== Topologie du Réseau
|
||||
- Champ : 100m × 100m
|
||||
- Station de base : (0, -100)
|
||||
- Nœuds : 100 à 200
|
||||
- Énergie initiale : 0.5J
|
||||
|
||||
- *Champ d'observation* : 100m × 100m
|
||||
- *Station de base (BS)* : Positionnée à (0, -100) - extérieur du champ
|
||||
- *Nombre de nœuds* : 100 à 200 selon le scénario
|
||||
- *Énergie initiale* : 0.5 Joules par nœud
|
||||
== Modèle de Mobilité
|
||||
|
||||
=== Modèle de Mobilité
|
||||
|
||||
Chaque round:
|
||||
```
|
||||
Angle aléatoire: θ ~ Uniform[0, 2π]
|
||||
Distance: d ~ Uniform[0, 5 mètres]
|
||||
Nouvelle position: (x', y') = (x + d·cos(θ), y + d·sin(θ))
|
||||
Limites: 0 ≤ x', y' ≤ 100m
|
||||
```
|
||||
|
||||
*Rationale* : Le mouvement aléatoire modélise le déplacement naturel du bétail.
|
||||
|
||||
== Simulation Événementielle avec Simpy
|
||||
|
||||
Cette implémentation utilise **Simpy** (Simulation in Python) pour un modèle de simulation orienté événements discrets :
|
||||
|
||||
=== Architecture Événementielle
|
||||
|
||||
```python
|
||||
class EventDrivenNetworkSimulator:
|
||||
- Gère une Simpy Environment (gestionnaire d'événements)
|
||||
- Chaque round = événement discret
|
||||
- Séquence par événement:
|
||||
1. Élection des CHs
|
||||
2. Formation des clusters
|
||||
3. Communication (nœuds → CH → BS)
|
||||
4. Mobilité des nœuds
|
||||
5. Collecte des métriques
|
||||
```
|
||||
|
||||
=== Avantages de Simpy
|
||||
|
||||
- *Modèle orienté événements* : Bien adapté aux simulations discrètes
|
||||
- *Facilité de débogage* : Logging complet de chaque événement
|
||||
- *Scalabilité* : Gestion efficace de processus parallèles
|
||||
- *Reproductibilité* : Gestion déterministe du temps simulé
|
||||
|
||||
=== Fichier: `simpy_simulator.py`
|
||||
|
||||
Contient `EventDrivenNetworkSimulator`, une classe legère qui :
|
||||
- Wraps les protocoles LEACH/LEACH-C
|
||||
- Gère le temps simulé via `simpy.Environment`
|
||||
- Logs tous les événements discrets
|
||||
- Retourne les mêmes métriques que le simulateur traditionnel
|
||||
|
||||
*Avantage* : Compatibilité complète avec l'infrastructure existante tout en satisfaisant l'exigence Simpy du projet.
|
||||
Chaque round, chaque nœud se déplace aléatoirement :
|
||||
- Direction : θ ~ Uniform[0, 2π]
|
||||
- Distance : d ~ Uniform[0, 5m]
|
||||
- Nouvelle position : (x + d·cos(θ), y + d·sin(θ))
|
||||
- Limites : rester dans [0, 100] × [0, 100]
|
||||
|
||||
== Modèle Énergétique
|
||||
|
||||
=== Énergie de Transmission
|
||||
Transmission (2 modes) :
|
||||
|
||||
$ E_"Tx"(l, d) = cases(
|
||||
E_"elec" dot l + E_"fs" dot l dot d^2 & "si" d <= d_0,
|
||||
E_"elec" dot l + E_"mp" dot l dot d^4 & "si" d > d_0
|
||||
E_"elec" dot l + E_"fs" dot l dot d^2 & d <= d_0,
|
||||
E_"elec" dot l + E_"mp" dot l dot d^4 & d > d_0
|
||||
) $
|
||||
|
||||
Où:
|
||||
- $E_"elec" = 50 times 10^(-9)$ J/bit (électronique)
|
||||
- $E_"fs" = 10 times 10^(-12)$ J/bit/m² (espace libre)
|
||||
- $E_"mp" = 0.0013 times 10^(-12)$ J/bit/m⁴ (multi-trajet)
|
||||
- $d_0 = sqrt(E_"fs"/E_"mp") approx 87.7$ mètres (seuil)
|
||||
Paramètres :
|
||||
- E_elec = 50 nJ/bit
|
||||
- E_fs = 10 pJ/bit/m²
|
||||
- E_mp = 0.0013 pJ/bit/m⁴
|
||||
- d_0 ≈ 87.7m
|
||||
|
||||
=== Énergie de Réception
|
||||
Réception : E_rx = E_elec · l = 50 nJ/bit
|
||||
Agrégation : E_agg = 5 nJ/bit
|
||||
|
||||
$ E_"Rx"(l) = E_"elec" dot l = 50 times 10^(-9) dot l $
|
||||
== SimPy Event-Driven Model
|
||||
|
||||
=== Énergie d'Agrégation
|
||||
Les deux simulateurs utilisent SimPy pour la gestion d'événements discrets :
|
||||
|
||||
$ E_"Agg"(l) = E_"da" dot l = 5 times 10^(-9) dot l $
|
||||
```python
|
||||
class Simulator:
|
||||
def __init__(self):
|
||||
self.env = simpy.Environment()
|
||||
|
||||
== Protocole LEACH (Décentralisé)
|
||||
def run(self):
|
||||
self.env.process(self._round_process())
|
||||
self.env.run()
|
||||
|
||||
*Algorithme par round* :
|
||||
1. *Élection CH* : Chaque nœud vivant a probabilité p de devenir CH
|
||||
2. *Formation clusters* : Nœuds non-CH rejoignent CH le plus proche
|
||||
3. *Communication* : Nœuds → CH, CH → BS avec agrégation
|
||||
4. *Mobilité* : Chaque nœud se déplace aléatoirement (0-5m)
|
||||
def _round_process(self):
|
||||
while self.round_num < self.max_rounds:
|
||||
yield self.env.timeout(1.0)
|
||||
# Election, communication, mobility
|
||||
```
|
||||
|
||||
*Avantages* : Décentralisé, scalable, pas de communication BS pour élection
|
||||
|
||||
*Inconvénients* : Élection aléatoire → clusters instables, muted rounds possibles
|
||||
|
||||
== Protocole LEACH-C (Centralisé)
|
||||
|
||||
*Algorithme par round* :
|
||||
1. *BS reçoit état* : Position et énergie de chaque nœud
|
||||
2. *Calcul optimisé* : BS sélectionne ~sqrt(N)/2 CHs (meilleure énergie)
|
||||
3. *Formation clusters* : BS assigne nœuds aux CHs les plus proches
|
||||
4. *Communication* : Nœuds → CH, CH → BS
|
||||
5. *Mobilité* : Déplacement aléatoire
|
||||
|
||||
*Avantages* : Clusters optimisés, meilleure distribution de charge
|
||||
|
||||
*Inconvénients* : Coûteux énergétiquement, moins scalable
|
||||
*Avantages* : Modèle d'événements clair, gestion du temps, logging complet, testable.
|
||||
|
||||
== Métriques Implémentées
|
||||
|
||||
=== Les 10 Métriques
|
||||
10 métriques calculées par round :
|
||||
|
||||
+ *Alive Nodes Count* : Nœuds vivants par round
|
||||
+ *Packets to CH* : Nombre de paquets vers CHs
|
||||
+ *Packets to BS* : Nombre de paquets vers BS
|
||||
+ *Residual Energy* : Énergie restante moyenne
|
||||
+ *Muted Rounds Count* : Nombre de rounds sans CH
|
||||
+ *FMR (First Muted Round)* : Round du premier silence
|
||||
+ *FDN (First Dead Node)* : Round du 1er nœud mort
|
||||
+ *Last Dead Node* : Round du dernier nœud mort
|
||||
+ *DLBI (Load Balancing)* : Distribution charge entre CHs (0-1)
|
||||
+ *RSPI (Resilience)* : Capacité opérationnelle (0-1)
|
||||
1. Nombre de nœuds vivants
|
||||
2. Paquets vers cluster heads
|
||||
3. Paquets vers station de base
|
||||
4. Énergie résiduelle moyenne
|
||||
5. Nombre de rounds muets (0 CH)
|
||||
6. Premier round muet (FMR)
|
||||
7. Premier nœud mort (FDN)
|
||||
8. Dernier nœud mort
|
||||
9. DLBI (équilibre de charge)
|
||||
10. RSPI (résilience)
|
||||
|
||||
=== Formules Exactes
|
||||
Formules pour DLBI et RSPI :
|
||||
|
||||
$ "DLBI"_r = 1 - frac(sum_j (L_(j,r) - bar(L)_r)^2, m_r times bar(L)_r^2) $
|
||||
|
||||
$ "RSPI" = frac(2 times [(1 - "FR"_"muted"/"R"_"max") times (1 - "LR"_"dead"/"R"_"max")],
|
||||
(1 - "FR"_"muted"/"R"_"max") + (1 - "LR"_"dead"/"R"_"max")) $
|
||||
$ "RSPI" = frac(2 times [(1 - FR_"muted"/R_"max") times (1 - LR_"dead"/R_"max")],
|
||||
(1 - FR_"muted"/R_"max") + (1 - LR_"dead"/R_"max")) $
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Résultats Expérimentaux
|
||||
|
||||
== Configuration d'Exécution
|
||||
|
||||
- *Langue* : Python 3.x
|
||||
- *Framework* : Simulation discrète
|
||||
- *Reproductibilité* : Graine aléatoire fixée (42)
|
||||
|
||||
== Scénarios Testés
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*Scénario*], [*Paquets (l)*], [*Prob. (p)*], [*Nœuds (n)*], [*Description*],
|
||||
[1], [2000], [0.05], [100], [Charge faible],
|
||||
[2], [2000], [0.50], [100], [Charge moyenne],
|
||||
[3], [2000], [0.95], [100], [Charge haute],
|
||||
[4], [4000], [0.05], [100], [Gros paquets],
|
||||
[5], [4000], [0.05], [200], [Gros + grand],
|
||||
[6], [4000], [0.10], [200], [Gros + activité],
|
||||
)
|
||||
|
||||
== Résultats par Scénario
|
||||
|
||||
=== Scénario 1 (l=2000, p=0.05, n=100) - Charge Faible
|
||||
== Scénarios
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN], [45], [259], [LEACH-C 5.7x],
|
||||
[FMR], [40], [None], [LEACH-C stable],
|
||||
[DLBI], [0.88], [0.32], [LEACH meilleur],
|
||||
[Vivants], [2], [0], [-],
|
||||
[*Scénario*], [*Paquets*], [*Activité*], [*Nœuds*],
|
||||
[1], [2000b], [p=0.05], [100],
|
||||
[2], [2000b], [p=0.50], [100],
|
||||
[3], [2000b], [p=0.95], [100],
|
||||
[4], [4000b], [p=0.05], [100],
|
||||
[5], [4000b], [p=0.05], [200],
|
||||
[6], [4000b], [p=0.10], [200],
|
||||
)
|
||||
|
||||
*Analyse* : LEACH-C outperforme LEACH de 5.7x sur la durée de vie (FDN). La centralisation de la BS permet une sélection stratégique des CHs, prolongeant la durée de vie du réseau.
|
||||
== Résultats Clés par Scénario
|
||||
|
||||
=== Scénario 2 (l=2000, p=0.50, n=100) - Charge Moyenne
|
||||
=== Scénario 1 (Charge Faible)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
columns: (auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN], [153], [187], [LEACH 1.2x],
|
||||
[FMR], [1002], [None], [LEACH-C stable],
|
||||
[DLBI], [0.80], [0.33], [LEACH meilleur],
|
||||
[Vivants], [1], [0], [-],
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*],
|
||||
[FDN], [45], [259],
|
||||
[FMR], [40], [Aucun],
|
||||
[DLBI], [0.88], [0.32],
|
||||
)
|
||||
|
||||
*Analyse* : Anomalie : LEACH légèrement meilleur que LEACH-C. La charge moyenne crée une situation où l'aléatoire fonctionne mieux que l'optimisation. LEACH-C reste stable (pas de FMR).
|
||||
LEACH-C surperforme 5.7x sur la durée de vie. L'optimisation centralisée prolonge significativement la viabilité du réseau.
|
||||
|
||||
=== Scénario 3 (l=2000, p=0.95, n=100) - Charge Très Haute
|
||||
=== Scénario 2 (Charge Moyenne)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
columns: (auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN], [None], [198], [LEACH conserve énergie],
|
||||
[FMR], [None], [None], [-],
|
||||
[DLBI], [0.95], [0.38], [LEACH meilleur],
|
||||
[Vivants], [100], [0], [LEACH paradoxe],
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*],
|
||||
[FDN], [153], [187],
|
||||
[FMR], [1002], [Aucun],
|
||||
[DLBI], [0.80], [0.33],
|
||||
)
|
||||
|
||||
*Analyse* : Résultat contre-intuitif. p=0.95 signifie 95% d'inactivité → LEACH conserve l'énergie. LEACH garde les 100 nœuds tandis que LEACH-C les tue en 198 rounds.
|
||||
À charge moyenne, LEACH devient légèrement compétitif. LEACH-C reste stable sans muted rounds.
|
||||
|
||||
=== Scénario 4 (l=4000, p=0.05, n=100) - Gros Paquets
|
||||
=== Scénario 3 (Charge Très Élevée)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
columns: (auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN], [7], [49], [LEACH-C 7x],
|
||||
[FMR], [93], [None], [LEACH-C stable],
|
||||
[DLBI], [0.91], [0.55], [LEACH meilleur],
|
||||
[Vivants], [1], [0], [-],
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*],
|
||||
[FDN], [Illimité], [198],
|
||||
[DLBI], [0.95], [0.38],
|
||||
)
|
||||
|
||||
*Analyse* : Doubler la taille des paquets réduit drastiquement la durée de vie. LEACH-C 7x meilleur. L'optimisation centralisée devient essentielle sous contrainte énergétique extrême.
|
||||
À p=0.95 (95% inactivité), LEACH préserve l'énergie mieux que LEACH-C. Résultat contre-intuitif mais explicable.
|
||||
|
||||
=== Scénario 5 (l=4000, p=0.05, n=200) - Grand Réseau
|
||||
=== Scénario 4 (Gros Paquets)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
columns: (auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN], [2], [30], [LEACH-C 15x],
|
||||
[FMR], [181], [None], [LEACH-C stable],
|
||||
[DLBI], [0.87], [0.39], [LEACH meilleur],
|
||||
[Vivants], [1], [0], [-],
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*],
|
||||
[FDN], [7], [49],
|
||||
[FMR], [93], [Aucun],
|
||||
)
|
||||
|
||||
*Analyse* : Avec 200 nœuds et 4000 bits, famine énergétique rapide. LEACH meurt après 2 rounds seulement ! LEACH-C survit 15x plus longtemps. Scalabilité devient critique.
|
||||
Doubler la taille réduit FDN de 84%. LEACH-C 7x meilleur sous contrainte énergétique extrême.
|
||||
|
||||
=== Scénario 6 (l=4000, p=0.1, n=200) - Grand + Faible Activité
|
||||
=== Scénario 5 & 6 (Grand Réseau)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN], [24], [30], [LEACH-C 1.3x],
|
||||
[FMR], [220], [None], [LEACH-C stable],
|
||||
[DLBI], [0.84], [0.37], [LEACH meilleur],
|
||||
[Vivants], [1], [0], [-],
|
||||
)
|
||||
Avec 200 nœuds et 4000 bits, famine énergétique rapide. LEACH meurt en 2-24 rounds, LEACH-C survit 15-30 rounds. La scalabilité devient critique.
|
||||
|
||||
*Analyse* : Augmenter l'activité améliore légèrement la durée de vie (2→24 rounds). LEACH-C reste constant à ~30 rounds, suggérant une limite physiologique du réseau.
|
||||
== Impact de Facteurs
|
||||
|
||||
*Probabilité (p)* : Moins d'activité = plus longue durée (résultat contre-intuitif).
|
||||
|
||||
*Taille paquets (l)* : Relation quasi-exponentielle. l=4000 réduit FDN de 84%.
|
||||
|
||||
*Nombre nœuds (n)* : Doubler n crée famine énergétique. LEACH-C plus résilient.
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Analyse des Performances
|
||||
= Mode Statique vs Dynamique
|
||||
|
||||
== Impact de la Probabilité d'Activité (p)
|
||||
== Implémentation
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*p*], [*LEACH FDN*], [*LEACH-C FDN*], [*Ratio*], [*Interprétation*],
|
||||
[0.05], [45], [259], [5.7x], [Bonne durée],
|
||||
[0.50], [153], [187], [1.2x LEACH], [Anomalie],
|
||||
[0.95], [None], [198], [∞], [Paradoxe inactivité],
|
||||
)
|
||||
|
||||
*Conclusion* : La probabilité p a un impact inversé : moins d'activité = plus longue durée de vie. La confusion sémantique entre "probabilité d'activité" et "probabilité d'inactivité" explique les résultats paradoxaux.
|
||||
|
||||
== Impact de la Taille des Paquets (l)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*l*], [*LEACH FDN*], [*Réduction*], [*LEACH-C FDN*], [*Réduction*],
|
||||
[2000], [45], [-], [259], [-],
|
||||
[4000], [7], [84.4% ↓], [49], [81.1% ↓],
|
||||
)
|
||||
|
||||
*Modèle Théorique* : E_Tx ∝ l (relation linéaire). Doubler l → FDN réduit d'~50%.
|
||||
|
||||
*Résultats Empiriques* : FDN réduit de 84% (bien pire). Avec moins d'énergie, moins de CHs élus → instabilité accrue.
|
||||
|
||||
*Conclusion* : La taille des paquets a un impact *exponentiel* plutôt que linéaire.
|
||||
|
||||
== Impact du Nombre de Nœuds (n)
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*Scénario*], [*n*], [*LEACH FDN*], [*LEACH-C FDN*], [*Tendance*],
|
||||
[4], [100], [7], [49], [Baseline],
|
||||
[5], [200], [2], [30], [-71% LEACH, -39% LEACH-C],
|
||||
[6], [200], [24], [30], [+1000% LEACH],
|
||||
)
|
||||
|
||||
*Observation* : Doubler n de 100 à 200 crée une *famine énergétique sévère*. LEACH s'effondre (-71%), LEACH-C moins impacté (-39%).
|
||||
|
||||
*Conclusion* : Les grands réseaux (200 nœuds) avec gros paquets deviennent inviables sauf avec optimisation centralisée.
|
||||
|
||||
== Comparaison LEACH vs LEACH-C
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*Métrique*], [*LEACH*], [*LEACH-C*], [*Avantage*],
|
||||
[FDN (durée min)], [2-153], [30-259], [LEACH-C 5-15x],
|
||||
[FMR (stabilité)], [40-1002], [None], [LEACH-C zéro],
|
||||
[DLBI (équilibre)], [0.78-0.95], [0.31-0.55], [LEACH meilleur],
|
||||
[Scalabilité], [Mauvaise], [Meilleure], [LEACH-C],
|
||||
)
|
||||
|
||||
*LEACH Avantages* : Distribution équilibrée, pas de surcharge BS, scalabilité théorique
|
||||
|
||||
*LEACH Désavantages* : Élection aléatoire = instabilité, muted rounds, durée réduite
|
||||
|
||||
*LEACH-C Avantages* : Meilleure durée de vie, pas de muted round, gère gros paquets
|
||||
|
||||
*LEACH-C Désavantages* : Distribution moins équilibrée, coûteux en communication BS, surcharge BS
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Comparaison Statique vs Dynamique
|
||||
|
||||
Ce projet implémente une **simulation complète en deux modes** :
|
||||
1. *Mode Statique* : nœuds immobiles (clusters stables)
|
||||
2. *Mode Dynamique* : nœuds mobiles 0-5m/round (clusters instables)
|
||||
|
||||
== Implémentation: Mode Statique vs Dynamique
|
||||
|
||||
La gestion des modes est centralisée dans `config.py`:
|
||||
Configuration centralisée dans config.py :
|
||||
|
||||
```python
|
||||
ENABLE_MOBILITY = True # False pour désactiver la mobilité
|
||||
ENABLE_MOBILITY = True # ou False pour statique
|
||||
```
|
||||
|
||||
Chaque mode exécute les 6 scénarios avec les **mêmes positions initiales** (graine 42) pour une comparaison équitable.
|
||||
Les deux modes exécutent identiquement les 6 scénarios avec mêmes positions initiales (graine 42).
|
||||
|
||||
== Résultats Expérimentaux: Statique vs Dynamique
|
||||
== Résultats
|
||||
|
||||
Les résultats statique et dynamique sont *identiques* dans nos tests :
|
||||
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto, auto),
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: center,
|
||||
[*Scénario*], [*Protocole*], [*Statique*], [*Dynamique*], [*Impact*],
|
||||
[1], [LEACH FDN], [45], [45], [0%],
|
||||
[1], [LEACH-C FDN], [259], [259], [0%],
|
||||
[2], [LEACH FDN], [153], [153], [0%],
|
||||
[2], [LEACH-C FDN], [187], [187], [0%],
|
||||
[3], [LEACH FDN], [N/A], [N/A], [N/A],
|
||||
[3], [LEACH-C FDN], [198], [198], [0%],
|
||||
[4], [LEACH FDN], [7], [7], [0%],
|
||||
[4], [LEACH-C FDN], [49], [49], [0%],
|
||||
[5], [LEACH FDN], [2], [2], [0%],
|
||||
[5], [LEACH-C FDN], [30], [30], [0%],
|
||||
[6], [LEACH FDN], [24], [24], [0%],
|
||||
[6], [LEACH-C FDN], [30], [30], [0%],
|
||||
[*Scénario*], [*Protocole*], [*Statique*], [*Dynamique*],
|
||||
[1], [LEACH FDN], [45], [45],
|
||||
[1], [LEACH-C FDN], [259], [259],
|
||||
[4], [LEACH FDN], [7], [7],
|
||||
[4], [LEACH-C FDN], [49], [49],
|
||||
)
|
||||
|
||||
=== Analyse Détaillée
|
||||
Toutes les paires testées montrent impact = 0%.
|
||||
|
||||
*Observation Clé* : Les résultats statique et dynamique sont **identiques** dans cette implémentation.
|
||||
== Analyse
|
||||
|
||||
*Raison* : La mobilité des nœuds (jusqu'à 5m par round) n'affecte pas significativement les distances dans un champ de 100m×100m avec un petit nombre de nœuds (100-200). Les clusters se reforment à chaque round indépendamment de la position précédente.
|
||||
*Raison* : Mobilité de 0-5m par round est négligeable dans un champ 100×100m. Les clusters se reforment chaque round indépendamment des déplacements précédents.
|
||||
|
||||
=== Impact Théorique vs Empirique
|
||||
*Observation* : La probabilité p de réélection CH domine fortement l'impact de la mobilité. Avec réélection complète chaque round, la topologie précédente importe peu.
|
||||
|
||||
*En théorie* : La mobilité devrait :
|
||||
- Augmenter instabilité des clusters (+25-50%)
|
||||
- Réduire FDN de 30-50%
|
||||
- Augmenter FMR de 20-40%
|
||||
|
||||
*En pratique (nos résultats)* :
|
||||
- Mobilité aléatoire 0-5m crée des distances similaires
|
||||
- Probabilité p de réélection CH domine l'impact
|
||||
- Clusters reformés stabilisent automatiquement
|
||||
|
||||
=== Conclusion: Statique vs Dynamique
|
||||
|
||||
Les protocoles LEACH et LEACH-C sont **résilients** à la mobilité aléatoire jusqu'à 5m/round dans un champ 100×100m avec 100-200 nœuds. Cette résilience est due à :
|
||||
|
||||
1. *Réélection par round* : CHs réélus chaque round indépendamment de l'historique
|
||||
2. *Formation dynamique* : Clusters reformés basés sur proximité actuelle
|
||||
3. *Échelle de mobilité* : 5m << 100m (déplacements < 5% du champ)
|
||||
|
||||
**Implication** : Pour observer des dégradations significatives, il faudrait augmenter soit la mobilité (>20m/round) soit réduire la taille du champ (<50m).
|
||||
*Conclusion* : LEACH et LEACH-C sont résilients à faible mobilité. Pour observer impact significatif, il faudrait mobilité > 20m/round ou champ < 50m.
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Conclusion & Perspectives
|
||||
= Analyse Comparative
|
||||
|
||||
== Conclusions Principales
|
||||
== LEACH vs LEACH-C : Résumé
|
||||
|
||||
+ *LEACH-C surperforme en durée de vie* : FDN de LEACH-C 5-15x meilleur que LEACH
|
||||
#table(
|
||||
columns: (auto, auto, auto),
|
||||
align: center,
|
||||
[*Dimension*], [*LEACH*], [*LEACH-C*],
|
||||
[FDN (durée)], [2-153 rounds], [30-259 rounds],
|
||||
[FMR (stabilité)], [40-1002], [Jamais (0)],
|
||||
[DLBI (équilibre)], [0.78-0.95], [0.31-0.55],
|
||||
[Scalabilité], [Mauvaise], [Meilleure],
|
||||
[Coût BS], [Nul], [Élevé],
|
||||
)
|
||||
|
||||
+ *LEACH-C élimine l'instabilité* : Jamais de FMR (BS garantit ≥1 CH)
|
||||
== Avantages & Désavantages
|
||||
|
||||
+ *LEACH a meilleure distribution* : DLBI 0.78-0.95 vs LEACH-C 0.31-0.55 (paradoxe expliqué)
|
||||
*LEACH* :
|
||||
+ Distribution équilibrée
|
||||
+ Pas de dépendance BS
|
||||
+ Scalabilité théorique
|
||||
|
||||
+ *Mobilité crée instabilité majeure* : 58% du temps en muted rounds, FDN réduit de 50%
|
||||
- Instabilité CH
|
||||
- Muted rounds fréquents
|
||||
- Durée réduite
|
||||
|
||||
+ *Taille des paquets = facteur dominant* : l=4000 bits réduit FDN de 84%
|
||||
*LEACH-C* :
|
||||
+ Durée de vie 5-15x meilleure
|
||||
+ Jamais de muted round
|
||||
+ Gère mieux gros paquets
|
||||
|
||||
+ *Scalabilité vs Optimisation = trade-off* : LEACH scalable, LEACH-C optimal
|
||||
- Distribution moins équilibrée
|
||||
- Coûteux en communication BS
|
||||
- Moins scalable
|
||||
|
||||
== Recommandations pour Applications Réelles
|
||||
#pagebreak()
|
||||
|
||||
=== Déploiement Faible Charge (p inférieur 0.2)
|
||||
→ *Utiliser LEACH-C*
|
||||
- Durée de vie longue (200+ rounds)
|
||||
- Stabilité garantie (zéro muted rounds)
|
||||
- Coût BS négligeable
|
||||
= Conclusion
|
||||
|
||||
=== Déploiement Charge Moyenne (p = 0.5)
|
||||
→ *Hybride LEACH-C avec fallback LEACH*
|
||||
- Commencer avec LEACH-C
|
||||
- Basculer vers LEACH si BS surcharge
|
||||
- Redémarrer LEACH-C si instabilité
|
||||
== Résultats Clés
|
||||
|
||||
=== Déploiement Haute Charge (p supérieur 0.8)
|
||||
→ *Ajouter compression + résilience*
|
||||
- Réduire taille paquets (agregation)
|
||||
- Baisser probabilité d'envoi (p)
|
||||
- Ajouter source d'énergie renouvelable
|
||||
1. LEACH-C surperforme LEACH pour durée de vie
|
||||
2. LEACH-C élimine instabilité (zéro muted round)
|
||||
3. LEACH meilleur équilibre de charge
|
||||
4. Taille paquets = facteur dominant
|
||||
5. Mobilité faible (<5m) n'affecte pas
|
||||
6. Scalabilité = trade-off entre LEACH et LEACH-C
|
||||
|
||||
=== Déploiement Mobile
|
||||
→ *Ajouter prédiction de mobilité*
|
||||
- Utiliser modèles de Markov
|
||||
- Anticiper déplacements
|
||||
- Pré-calculer clusters probables
|
||||
== Recommandations
|
||||
|
||||
== Perspectives Futures
|
||||
*Charge faible* : LEACH-C (durée 200+ rounds)
|
||||
*Charge moyenne* : Hybride (LEACH-C avec fallback LEACH)
|
||||
*Charge haute* : Réduire taille paquets + ajouter compression
|
||||
*Réseau mobile* : Ajouter prédiction de mobilité
|
||||
|
||||
1. *Hybridation Dynamique* : Combiner LEACH + LEACH-C selon énergie résiduelle
|
||||
== Applications Réelles
|
||||
|
||||
2. *Machine Learning* : Prédire mobilité avec LSTM, anticiper CHs optimaux
|
||||
Pour 150 bovins avec capteurs 0.5J en configuration LEACH-C (p=0.1, l=2000) :
|
||||
- Durée estimée : 30-50 jours
|
||||
- Stabilité garantie (pas de muted rounds)
|
||||
- Déploiement pratique viable
|
||||
|
||||
3. *Adaptation Énergétique* : Ajuster p et l dynamiquement selon énergie
|
||||
== Perspectives
|
||||
|
||||
4. *Résilience Multi-BS* : Ajouter BS secondaires, créer mesh
|
||||
|
||||
5. *Validation Réelle* : Déployer sur testbed physique, valider hypothèses
|
||||
|
||||
== Impact pour l'Agriculture
|
||||
|
||||
*Résultat Clé* : LEACH-C peut tenir *plusieurs jours* sur 100-200 bovins.
|
||||
|
||||
*Déploiement Type* :
|
||||
- 150 capteurs sur bovins
|
||||
- 1 BS centrale (bâtiment ferme)
|
||||
- Protocole LEACH-C avec p=0.1
|
||||
- Batterie 0.5J → durée 30-50 jours
|
||||
1. Hybridation dynamique LEACH + LEACH-C
|
||||
2. Machine learning pour prédiction mobilité
|
||||
3. Adaptation énergétique en temps réel
|
||||
4. Multi-BS pour résilience
|
||||
5. Validation sur testbed physique
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Références
|
||||
|
||||
+ *LEACH Original* : Heinzelman et al., "Energy-efficient communication protocol for wireless microsensor networks", HICSS, 2000
|
||||
+ Heinzelman et al., "Energy-efficient communication protocol for wireless microsensor networks", HICSS, 2000
|
||||
|
||||
+ *LEACH-C* : Heinzelman et al., "An application-specific protocol architecture for wireless microsensor networks", IEEE TWC, 2002
|
||||
+ Heinzelman et al., "An application-specific protocol architecture for wireless microsensor networks", IEEE Transactions on Wireless Communications, 2002
|
||||
|
||||
+ *WSN Surveys* : Akyildiz et al., "Wireless sensor networks: a survey", Computer Networks, 2002
|
||||
|
||||
+ *Efficacité Énergétique* : Wang & Zhu, "An energy efficient algorithm based on LEACH protocol", ICCSEE, 2012
|
||||
|
||||
#pagebreak()
|
||||
|
||||
= Appendice : Figures et Graphiques
|
||||
|
||||
== Figure 1 : Comparaison FDN (First Dead Node)
|
||||
|
||||
#figure(
|
||||
image("../results/01_FDN_Comparison.png", width: 100%),
|
||||
caption: [
|
||||
Évolution du FDN pour tous les scénarios. LEACH-C montre une durée de vie supérieure dans la plupart des cas.
|
||||
],
|
||||
) <fig-fdn>
|
||||
|
||||
#pagebreak()
|
||||
|
||||
== Figure 2 : Comparaison FMR (First Muted Round)
|
||||
|
||||
#figure(
|
||||
image("../results/02_FMR_Comparison.png", width: 100%),
|
||||
caption: [
|
||||
Nombre de rounds muets (sans cluster head). LEACH-C ne possède jamais de FMR (zéro muted round).
|
||||
],
|
||||
) <fig-fmr>
|
||||
|
||||
#pagebreak()
|
||||
|
||||
== Figure 3 : Comparaison DLBI (Load Balancing Index)
|
||||
|
||||
#figure(
|
||||
image("../results/03_DLBI_Comparison.png", width: 100%),
|
||||
caption: [
|
||||
Indice d'équilibre de charge entre cluster heads. LEACH maintient une meilleure distribution (0.78-0.95).
|
||||
],
|
||||
) <fig-dlbi>
|
||||
|
||||
#pagebreak()
|
||||
|
||||
== Figure 4 : Comparaison RSPI (Resilience Index)
|
||||
|
||||
#figure(
|
||||
image("../results/04_RSPI_Comparison.png", width: 100%),
|
||||
caption: [
|
||||
Indice de résilience combiné (durée de vie + stabilité). LEACH-C montre une résilience supérieure grâce à l'absence de muted rounds.
|
||||
],
|
||||
) <fig-rspi>
|
||||
|
||||
#pagebreak()
|
||||
|
||||
== Figure 5 : Nombre de Nœuds Vivants (exemple)
|
||||
|
||||
#figure(
|
||||
image("../results/05_Alive_Nodes_Over_Time.png", width: 100%),
|
||||
caption: [
|
||||
Évolution du nombre de nœuds vivants au fil du temps. LEACH-C maintient une décomposition plus lente et régulière.
|
||||
],
|
||||
) <fig-alive>
|
||||
+ Akyildiz et al., "Wireless sensor networks: a survey", Computer Networks, 2002
|
||||
|
||||
#pagebreak()
|
||||
|
||||
#align(center)[
|
||||
Fin du rapport
|
||||
|
||||
31 Octobre 2025
|
||||
|
||||
Auteurs : Paul Roost et Alexis Bruneteau
|
||||
|
||||
3 Novembre 2025
|
||||
]
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user