• View
• Edit
• History
• Print

MACSimulator

This page discusses installation issues, usage, bugs and other topics related to the Consensus MACSimulator. If you are new to this model, see the Consensus project page.

• How should I run the MAC simulator?
  • Linux: First run the "build" script to build the Makefile, then run 'make' to create the program. Then execute "./omneteyes -f MAC.ini -f OPT.ini -f omnetpp.ini" where MAC is "tmac","tmacp","lmac","smac","csma" or "csmaack" depending on which MAC you want to run, and OPT is either "lpl" or "nolpl" depending on whether you to try running with Low-Power Listening or not.
  • Windows: The omneteyes.dsp/dsw may help, but Windows is not a supported platform.

• What do the different mac1..mac4 parameters do?
  • TMAC/TMACp: mac1 is the listen timeout, mac2 is the frame time, mac3 switches various flags on/off using a bitfield(1 = overhearing avoidance, 2 = use FRTS, 4 = ignore RTS) as per the T-MAC paper.
  • SMAC: mac1 is the listen timeout, mac2 is the frame time.
  • LMAC: mac1 is the max slot, mac2 is the data length
  • CSMA/CSMAACK: the parameters do nothing

• What does tests.py do?
  tests.py is a testsuite program intended to stress the MAC simulator and to help us track down any regression bugs caused by new code. As such, it should not in general be used by end users (unless they are helping us track down a bug in the MAC simulator).

• What is the modulation used?
  Technically, none. However, times are calculated assuming a 2 bytes => 3 bytes modulation by default (see eyes.h and the MODULATION_FACTOR #define)

• Is the byte_time in seconds or ticks?
  Seconds.

• Is the propagation time considered anywhere?
  The model assumes that there is no delay between a node starting to send and it's neighbours starting to receive that first byte of data. There is however a delay regarding the actual reception of data (i.e. f(packet length) seconds pass before a packet is received)

• Are collisions the only mechanism of loss?
  That, and nodes having their radios switched off at the recieve side.

Message generation scenario questions

• Where does the application layer start?
  Each node has an AppSelector module in it, which is a subclass of the Pattern class. The scenario module reads a scenario file (test.scen by default) which lists the application to be loaded for each node and executed.

• How do I alter the message generation scenario?
  By editing the scenario file (test.scen by default). A scenario file specifies a message generator module, along with parameters for that module. The combination of a message generator, plus a particular set of parameters is referred to as a scenario. All of the lines in test.scen starting with a '#' are example scenarios, but only the scenario that does not start with a '#' is the scenario that is actually being run at this time. See for example the "LocalBC" examples. These mention a pair of parameters "replyprob" and "replydelay", which are then used in the the LocalBC module (see localbc.cc and specifically LocalBC::init()) to alter the behaviour of the module.

• What do the lines in test.scen mean?
  The format of the lines in test.scen is specified in the top line of test.scen - "#active/idle class msglength msg/s p=x p2=x2". These mean:
  • active/idle: whether this is an "idle" or "active" pattern
  • class: The name of the C++ class (a subclass of Pattern) that will be created to generate messages and process incoming messages
  • msglength: The size of the messages that get sent
  • msg/s: Rate of messages to be sent out in messages/second i.e. .1 = 1 message every 10 seconds
  • p=x, p2=x2: Various module specific parameters (see next question)

• What do the different message generator parameters do?
  • replydelay : doesn't currently do anything. It's a remnant from earlier code, that will be fixed at a later date. We're currently in the middle of a massive rewrite of the MAC Simulator in combination with various other frameworks, and during that process we will be cleaning up things like that.
  • replyprob : a probability value (0.0-1.0) determining how likely it is that a particular node will reply to a message. See the ::rx() routines in LocalUC, LocalBC and LocalGossip for more information
  • ttl : max time to live i.e. maximum number of source->sink hops.
  • aggmode : aggregation mode. Data can be aggregated in this pattern
    • 0: no aggregation
    • 1: concatenate messages together into one big message
    • 2: average the data values from different messages into one message

• What is an 'idle' or 'active' pattern?
  The idle and active names are a bit deceptive. An idle pattern is one that is simply turned on for the complete simulation. This can be used like a background load generator (from which the name derives). Active patterns are patterns that occur at random times (which is also where the area manager comes in to play). Internally the names ACTIVE and IDLE are used for the states of an active pattern (just to confuse things a bit). An IDLE active pattern does not send any messages, while an ACTIVE active pattern does. Active patterns start out IDLE, so this is what the initialisation does.