Architecture de Simulation

Analyse approfondie des paramètres LR-FHSS et du modèle de trafic Markovien.

Déploiement Physique
1. La Gateway (Stade)
Positionnement : Toit du stade ou mât d'éclairage. Antenne verticale dégagée.
Connexion : Câble Ethernet (PoE) vers la régie technique.
2. Les Capteurs (Joueurs)
Intégration : Poche dorsale dans la brassière GPS (sous le maillot).
Activation : Allumage automatique par mouvement (Accéléromètre).
Le Moteur de Simulation (Python)

Voici la configuration centrale utilisée pour modéliser le comportement du réseau dans le stade. Chaque paramètre ci-dessous correspond à une réalité physique du terrain.

s = Settings(
  simulation_time = 60*60*hours, # Durée d'un match (ou session)
  payload_size = 20, # Taille des données (Bytes)
  number_nodes = n, # Nombre de joueurs (Capteurs)
  traffic_class = Two_State_Markovian_Traffic, # Modèle de comportement
  traffic_param = {'transition_matrix': matrix, 'markov_time': time}
)
Comprendre le Modèle Markovien (Two-State)

Dans le sport, un joueur n'émet pas de données de façon régulière (comme un métronome). Son activité est imprévisible. Nous utilisons une chaîne de Markov à 2 états pour simuler cela.

  • État 0 Jeu Calme / Marche
    Envoi toutes les 60s (Keep-alive)
  • État 1 Action Intense / Sprint
    Envoi toutes les 1s (Rafale de données)
Analogie Sport

C'est comme un joueur qui trottine (État 0). Soudain, il fait un sprint (Transition vers État 1). Il reste en sprint quelques secondes, puis s'arrête (Retour à État 0).

Note Technique

La transition_matrix définit la probabilité de passer d'un état à l'autre à chaque pas de temps (markov_time). C'est ce qui crée l'effet "Burst" qui fait saturer les réseaux classiques.

Impact des Variations (Analyse de Sensibilité)

number_nodes (n)

Simulation de la densité d'émetteurs.

Sport

Un 5 vs 5 (Tennis-Ballon) contre un Marathon (3000 personnes).

Collisions (Standard) Élevé
85%
Collisions (LR-FHSS) Faible
15%

Conclusion : Quand N augmente, LR-FHSS résiste grâce au Frequency Hopping, là où LoRaWAN s'effondre.

payload_size

Quantité d'informations par message (Bytes).

Sport

Envoyer juste "Vitesse" (20B) vs "Vitesse + Cardio + GPS + Accéléromètre" (50B+).

Nombre de Fragments
20 Bytes
80 Bytes

Plus le payload est gros, plus il y a de fragments.

Conclusion : Augmenter le payload augmente le "Time on Air". Plus le message est long, plus le risque qu'un fragment soit perdu est élevé.

Traffic Matrix

Probabilité de passer en mode "Sprint".

Sport

Match Amical (Peu de sprints) vs Finale de Coupe du Monde (Intensité max).

Charge Réseau (Load)
Amical
Finale (Intense)

Conclusion : C'est le paramètre le plus critique. Si tout le monde sprint en même temps, le canal sature. LR-FHSS permet de gérer ces pics ("Bursts").

Pourquoi LR-FHSS ? (Comparatif)

Matrice de Décision

Nous avons évalué les technologies concurrentes selon 4 critères critiques pour le sport pro.

Technologie Portée (Stade) Autonomie Densité (22+ Joueurs) Coût Infra
Wi-Fi Faible (< 100m) Mauvaise Excellente Moyen (Bornes)
4G / 5G Illimitée Moyenne Risque Saturation Élevé (Abonnements)
LoRaWAN (Std) Excellente (>10km) Excellente Échec (Collisions) Faible
LR-FHSS Excellente (>10km) Excellente Validée (Hopping) Faible (1 Gateway)
Conclusion : Seul LR-FHSS coche toutes les cases : couverture totale du stade avec 1 seule antenne, batterie légère pour le joueur, et résistance aux pics de données (Sprints).

Synthèse pour l'Ingénieur

Notre simulation démontre que la technologie LR-FHSS (Long Range - Frequency Hopping Spread Spectrum) est supérieure aux modulations classiques pour les applications sportives à haute densité.

La combinaison de la fragmentation (pour réduire la probabilité de collision par paquet) et de la redondance (Coding Rate) permet de reconstruire les messages même si 30% des fragments sont perdus lors des phases de jeu intenses (Modèle Markovien État 1).