TP3 Castalia: Utilisation de différentes couches MAC

1. Comprendre les fichiers de configurations

1. Editer le fichier omnetpp.ini dans Simulations/valueReporting
   
   
2. Repérer les sections qui définissent les différents modules/protocoles qui sont utilisés pour chaque composants/couches du capteur. Notez la méthode de déployment des capteurs (6x6). Le manuel utilisateur de Castalia page 14 et 15 donne les différentes méthodes de déployment possibles: "uniform" par exemple.
   
   [General]
   
   # ==========================================================
   # Always include the main Castalia.ini file
   # ==========================================================
   
   include ../Parameters/Castalia.ini
   
   sim-time-limit = 600s
   
   SN.field_x = 100                    # meters
   SN.field_y = 100                    # meters
   
   SN.numNodes = 36
   SN.deployment = "6x6"
   
   SN.node[*].Communication.Radio.RadioParametersFile = "../Parameters/Radio/CC2420.txt"
   
   SN.node[*].Communication.RoutingProtocolName = "MultipathRingsRouting"
   SN.node[*].Communication.MACProtocolName = "TMAC"
   
   SN.node[*].ApplicationName = "ValueReporting"
   SN.node[*].Communication.Radio.txPowerLevelUsed = 2
   SN.node[*].Communication.Routing.neighbor_RSSIThreshold = -89.3 # in dBm
   SN.node[*].Communication.Routing.collectTraceInfo = true
   
   SN.node[3].Application.isSink = true
   
   Vous pouvez voir que le module MAC utilisé actuellement est le protocole TMAC qui est un dérivé de SMAC pour les réseaux de capteurs. Le principe de ces protocoles MAC, par rapport à un protocole de type CSMA/CA (WiFi) classique est de définir des périodes d'activité et des période de sommeil complet de la couche radio+MAC afin d'économiser l'énergie car dans système sans-fils la réception passive (réception d'un paquet qui n'est pas pour soi) coûte presque aussi cher que l'émission d'un paquet. Ces protocoles rajoute des mécanismes de synchronisation entre les noeuds pour qu'ils puisse se réveiller au bon moment par rapport à leurs voisins.
   
   
3. Nous allons dans un premier temps modifier le fichier omnetpp.ini pour utiliser le protocole CSMA classique en insérant les lignes suivantes:
   
   SN.node[*].Communication.MACProtocolName = "TunableMAC"
   SN.node[*].Communication.MAC.dutyCycle = 1.0
   SN.node[*].Communication.MAC.randomTxOffset = 0
   SN.node[*].Communication.MAC.backoffType = 3
   
   Dans Castalia, le CSMA classique est tout simplement un cas particulier d'une implémentation qui s'appelle TunableMAC et qui est un protocole de type CSMA dans lequel on peut "tuner" un certain nombre de paramètres de fonctionnement pour représenter une instance de protocole CSMA particulier. La liste des paramètres de ce module est disponible dans le manuel utilisateur de Castalia page 67-70 et les paramètres qui sont modifiables sont listés dans le fichier src/node/communiation/mac/tunableMac/TunableMac.ned qui définit la structure de ce module dans Castalia et dont un extrait est mis ci-dessous:
   
   //=============== These are main parameters which can be tuned ================
   
   double dutyCycle = default (1.0);    // listening / (sleeping+listening)
   double listenInterval = default (10);    // how long do we leave the radio in listen mode, in ms
   double beaconIntervalFraction = default (1.0);    // fraction of the sleeping interval that we send beacons
   double probTx = default (1.0);        // the probability of a single try of Transmission to happen
   int numTx = default (1);        // when we have something to Tx, how many times we try
   double randomTxOffset = default (0.0);    // Tx after time chosen randomly from interval [0..randomTxOffset]
   double reTxInterval = default (0.0);    // Interval between retransmissions in ms, (numTx-1) retransmissions
   double backoffType = default (1);    // 0-->(backoff = sleepinterval),
                           // 1-->(backoff = constant value),
                           // 2-->(backoff = multiplying value - e.g. 1*a, 2*a, 3*a, 4*a ...),
                           // 3-->(backoff = exponential value - e.g. 2, 4, 8, 16, 32...)
   int backoffBaseValue = default (16);    // the backoff base value in ms
   double CSMApersistance = default (0);     // value in [0..1], is CSMA non-persistent, p-persistent, or 1-persistent?
   bool txAllPacketsInFreeChannel = default (true); // if you find the channel free, tx all packets in buffer?
   bool sleepDuringBackoff = default (false);    // for no dutyCycle case: sleep when backing off?
   
   //=============== End of tunable parameters ===================================
   
   Un paramètre important est par exemple dutyCycle qui définit la fraction de temp d'activité du capteur. Pour le CSMA classique, nous mettrons donc dutyCycle=1 qui est la valeur par défaut.
   
   

2. Expérimentations avec une couche MAC CSMA classique 

1. Vous pouvez aussi activer le mode debug pour la couche MAC en insérant la ligne
   
   SN.node[*].Communication.MAC.collectTraceInfo = true
   
   dans le fichier omnetpp.ini. Attention, cela peut rendre votre fichier de trace très gros!
   
   En utilisant la configuration par défaut de CSMA, relancer la simulation pour différentes fréquences de capture et d'envoie de messages vers le SINK. Notez la consommation d'énergie des noeuds. Que se passe t-il si la fréquence d'envoi est grande? Comment pouvez vous mettre en évidence ces problèmes?

3. Modifier les paramètres de fonctionnement de TunableMac

1. Par rapport à un CSMA WiFi classique où les ordinateurs n'ont pas de problème particulier en énergie, dans les réseaux de capteurs la conservation de l'énergie est un critère important. Certaines couches MAC sont différentes et  permettent par exemple de définir des intervals de temps pendant lesquels les capteurs ont leur radio et couche MAC activées (listening interval). Les capteurs sont essaient donc d'être le plus souvent en mode veille où la radio et la couche MAC sont désactivées pour économiser l'énergie. Mais cela veut dire aussi que pendant la période d'inactivité, les capteurs ne peuvent ni envoyer ni recevoir; ce qui peut poser des problèmes de synchronisation car si un capteur en activité envoie une trame à un capteur en veille, ce dernier ne pourra pas le recevoir.
   
   
2. Dans le module TunableMac les 2 variables dutyCycle et listenInterval permettent de mieux définir le comportement des capteurs. dutyCycle définit le rapport entre le temps d'activité et le temps total par cycle: le capteur est en mode SLEEP durant (1-dutyCycle) fraction du cycle. listenInterval définit le temps d'activité du capteur par cycle en ms. La durée d'un cycle est donc définie comme étant Tcycle=(1/dutyCycle)*listenInterval. Le temps d'inactivité par cycle est donc déduit grâce à ces 2 paramètres dutyCycle et listenInterval: temps d'inactivité= Tcycle-listenInterval. Faites varier dutyCycle entre 0.1 et 1 par pas de 0.1 et regarder l'effet sur la consommation d'énergie des noeuds (exprimée en Joules) lorsque la fréquence de capture est celle par défaut. Tracer pour un capteur de votre choix la consommation d'énergie en fonction de dutyCycle. Vous pouvez vous inspirer du fichier omnetpp.ini de l'exemple BrigeTest pour voir comment on peut faire varier des paramètres pour la simulation en l'indiquant dans le fichier .ini et créer des configurations spécifiques. Le manuel de Castalia à la page 18-19 explique cette possibilité. Vous pouvez aussi utiliser le script Castalia, au lieu de ../../CastaliaBin, dans le répertoire Simulations/valueReporting:
   
   Castalia-3.2$ cd Simulation/valueReporting
   Castalia-3.2/Simulation/valueReporting$ Castalia -c General
   
   pour ensuite utiliser le script CastaliaResults pour afficher les résultats de manière synthétique. Voir le manuel utilisateur de Castalia page 20-28. IMPORTANT: pour pouvoir utiliser les scripts Castalia et CastaliaResults, il faut que vous ayez dans votre variable PATH le chemin vers Castalia-3.2/bin, ajoutez cela à votre fichier .bashrc si besoin:
   
   export PATH=chemin_de_votre_castalia/bin:$PATH
   
   où chemin_de_votre_castalia est à remplacer par le chemin où vous avez installé Castalia (par exemple ~/Castalia-3.2)
   
   
3. Avec dutyCycle=0.1, listenInterval=100 et une fréquence de capture toute les 0.5s (voir TP1) déterminer le nombre de trames correctement recues par le puits par rapport à la configuration initiale (dutyCycle=1, listenInterval=100).
   
   
4. Augmenter dutyCycle de 0.1 à 0.6 par pas de 0.1 et tracer une courbe montrant le nombre de trames non recues en fonction de dutyCycle.

4. Expérimentations avec SMAC et TMAC

1. SMAC et TMAC sont dans Castalia tous les deux implémenté dans le module TMAC. SMAC est donc une instance particulière de TMAC. Le manuel utilisateur de Castalia page 72-74 explique les paramètres de ce module. Tous les 2 utilisent une période d'activité et de sommeil comme TunableMac mais ajoute des aspects synchronisation entre les noeuds très bénéfique pour réduire les problèmes d'émetteur actif alors que le récepteur ne l'est pas. Ces paramètres d'activités/sommeil sont déterminés de manière dynamique par le protocole. Le fichier src/node/communication/mac/tMac/TMAC.ned vous donne tous les paramètres du module TMAC. Le paramètre disableTAextension permet de passer de TMAC (false) à SMAC (true). Le paramètre listenTimeout est par défaut mis à 15ms dans TMAC, ce paramètre correspond au paramètre TA de TMAC qui lui permet, au bout de TA ms d'inactivité radio pendant la période LISTEN de passer de manière anticipée à une période SLEEP.
   
   
2. Test avec SMAC: nous allons remplacer la couche CSMA avec la couche SMAC et utiliser pour la plupart des paramètres les valeurs par défaut. Insérer les lignes suivantes dans le fichier omnetpp.ini, toujours de l'application valueReporting.
   
   SN.node[*].Communication.MACProtocolName = "TMAC"
   SN.node[*].Communication.MAC.listenTimeout = 61   
   SN.node[*].Communication.MAC.disableTAextension = true 
   SN.node[*].Communication.MAC.conservativeTA = false
   SN.node[*].Communication.MAC.collisionResolution = 0
   
   Notez que pour SMAC, nous mettons listenTimeout à 61ms ce qui permet de définir un rapport listen/sleep de 10% puisque la durée d'un cycle est défini comme étant 610ms (voir le paramètre frameTime). Comparer avec les résultats que vous avez obtenus avec CSMA. Qu'est-ce qui a changé?
   
   
3. Test avec TMAC: pour utiliser TMAC, nous allons mettre toutes les paramètres à des valeurs par défaut comme défini dans le fichier src/node/communication/mac/tMac/TMAC.ned. Donc nous ne garderons que la ligne:
   
   SN.node[*].Communication.MACProtocolName = "TMAC"
   
   Comparer avec les résultats que vous avez obtenus avec SMAC. Qu'est-ce qui a changé?
   
   
4. Observez l'impact d'une augmentation du paramètre listenTimeout que vous pouvez faire varier par exemple de 15ms (valeur par défaut) à 40ms par pas de 5ms.