Menu
▾
▴
[Shox-cvs] SF.net SVN: shox:[2091] trunk/conf/examples/configuration-Intro.txt
|
From: <dir...@us...> - 2009-07-03 11:09:14
|
Revision: 2091
http://shox.svn.sourceforge.net/shox/?rev=2091&view=rev
Author: dirk_held
Date: 2009-07-03 11:09:05 +0000 (Fri, 03 Jul 2009)
Log Message:
-----------
some clarifications.
Modified Paths:
--------------
trunk/conf/examples/configuration-Intro.txt
Modified: trunk/conf/examples/configuration-Intro.txt
===================================================================
--- trunk/conf/examples/configuration-Intro.txt 2009-07-02 14:51:40 UTC (rev 2090)
+++ trunk/conf/examples/configuration-Intro.txt 2009-07-03 11:09:05 UTC (rev 2091)
@@ -3,15 +3,15 @@
1 locating and using sample configurations
-If you've downloaded ShoX, you can find several sample configurations in the
-"shox/conf" directory. Have a look at "shox/conf/examples/OSRdynamic.xml",
-which is used as example in this documentation. To start a simulation, you
-have to add a new run-configuration to Eclipse (open menu "Run/Run
-Configurations..." and add a new Java Application). On the main-tab, you add
-the project shox (depending on your choice, when creating the shox project).
-The main class is "net.sf.shox.simulator.kernel.Simulator". In the Arguments-
-tab, you add the configuration, you want to run, use "conf/examples/OSRdynamic.xml".
-To start the gui, use the main-class "net.sf.shox.visual.ShoX" with no arguments.
+You can find several sample configurations in the "shox/conf" directory. Have a
+look at "shox/conf/examples/OSRdynamic.xml", which is used as example in this
+documentation. To start a simulation, you have to add a new run-configuration to
+Eclipse (open menu "Run/Run Configurations..." and add a new Java Application).
+On the main-tab, you add the project shox (depending on your choice, when creating
+the shox project). The main class is "net.sf.shox.simulator.kernel.Simulator". In
+the Arguments-tab, you add the configuration, you want to run. For this example,
+use "conf/examples/OSRdynamic.xml". To start the gui, use the main-class
+"net.sf.shox.visual.ShoX" with no arguments.
2 sections of a configuration file
@@ -24,72 +24,78 @@
2.1 pseudo random number generator
-Although each class can create its own pseudo random number generator (PRNG),
-shox offers a central instance, which can be defined in the randomgenerator-
-section (lines 4-9). The example generator is currently the best choice. It
-will generate a random seed for each simulation run, which is dumped on several
-occasions. If you only use the standard random number generator, you can
-reproduce a run to a large extend by specifying the dumped seed. Just uncomment
-the seed parameter in line 7 and enter the value. The PRNG offers several
-distributions you can choose from. The class AppRandomVoiceData in the
-directory shox/conf/examples offers some examples, how to create a special
-distribution. It was taken from another project, but can be easily adapted to
-your needs.
+Although each class can create its own pseudo random number generator (PRNG), shox
+offers a central instance, which can be defined in the randomgenerator-section
+(lines 4-9). The example generator, which is the Mersenne-Twister, is currently the
+best choice. It will generate a random seed for each simulation run, which is written
+to the console on several occasions (at the beginning of a simulation, at the end and
+if the simulation is stopped due to a user exception). If you only use the standard
+random number generator, you can reproduce a run to a large extend by specifying this
+seed. Just uncomment the seed parameter in line 7 and enter the value. The PRNG offers
+several distributions you can choose from. The class AppRandomVoiceData in the directory
+shox/conf/examples offers some examples, how to create a special distribution. It was
+taken from another project, but can be easily adapted to your needs.
2.2 size of the field, node positioning and movement
-The field-section (l. 10-12) defines the size of the used field, where the nodes
-are placed in. The used unit is the same as the unit used for the radio-model.
-The positions-section (l. 13-21) defines the class, which is used to generate
-the initial placement of all nodes. Alternatives are GridPositionGenerator and
-UniformStartPositions. Or add your own descendant of the StartPositionGenerator
-class. If you activate the nodefile section, you can specify a file, where the
-generated positions will be written to. If you omit the generated-section
-but supply the nodefile section, the positions from the nodefile will be used.
+The field-section (l. 10-12) defines the size of the used field, where the nodes are
+placed in. The used unit is the same as the unit used for the radio-model. The positions-
+section (l. 13-21) defines the class, which is used to generate the initial placement of
+all nodes. Alternatives to the used RandomStartPositions class are the GridPositionGenerator
+and the UniformStartPositions class. The first one positions the nodes on a grid and uses a
+tunable minimal distance, to set all nodes apart. Each line is filled before the next line
+is started. The second tries to position the nodes uniformly positioned in both directions,
+where the grid dimensions are as close as possible to sqrt(#Nodes) (for ex. are 100 nodes
+placed in a 10 times 10 grid). If this does not suit your needs, you can implement your own
+position generator by implementing a subclass of the StartPositionGenerator class. You can
+do this of course for all referenced classes too. Open the an example implementation and
+find its super-class and which methods to implement. Most aspects of the ShoX framework can
+be replaced this way.
-The movementmanager-section (l. 22-30) defines if and how nodes move.
-The activated RandomWaypoint class is a good choice for moving nodes.
-The used parameters are described directly within the class. In general, this
-is done at the very beginning of each class, which has parameters.
-If you do not need/want moving nodes, just use the NoMovement-class.
+If you activate the nodefile section, you can specify a file, where the generated positions
+will be written to. If you omit the generated-section but supply the nodefile section, the
+positions from the nodefile will be used.
+The movementmanager-section (l. 22-30) defines if and how nodes move. The activated
+RandomWaypoint class is a good choice for moving nodes. The used parameters are described
+directly within the class. In general, this is done at the very beginning of each class,
+which has parameters. If you do not need/want moving nodes, just use the NoMovement-class.
+
2.3 physical model and bit mangling
-The physicalmodel-section (l. 31-37) define the used physical model. This
-describes, how the propagation of the radio waves in the field is simulated.
-The bitmanglingmodel-section (l. 38-40) describes, what happens, if two or
-more radio-transmissions arrive at a receiver at the same time, or in other
-words determines, if a packet was received correct or not.
+The physicalmodel-section (l. 31-37) define the used physical model. This describes, how
+the propagation of the radio waves in the field is simulated. The bitmanglingmodel-section
+(l. 38-40) describes, what happens, if two or more radio-transmissions arrive at a receiver
+at the same time, or in other words determines, if a packet was received correct or not.
-bitmanglers:
+ShoX offers currently the following bitmanglers:
-1.) NoBitMangling: As the name suggests, no packets are dropped. The use is
-not recommended in conjunction with a nontrivial MAC or PHY (like 802.11bg).
+1.) NoBitMangling: As the name suggests, no packets are dropped. The use is not recommended
+in conjunction with a nontrivial MAC or PHY (like 802.11bg).
-2.) CollisionPacketMangler: Drops a packet, if at least one interference collides
-with it, no matter how weak this interference is. This means that the second
-parameter of a physical model, which describes the interference distance or
-threshold should be better set to the value of the first parameter, if a
-physical model is used, where no attenuation of the signal is determined.
+2.) CollisionPacketMangler: Drops a packet, if at least one interference collides with it,
+no matter how weak this interference is. This means that the second parameter of a physical
+model, which describes the interference distance or threshold, should be better set to the
+value of the first parameter, if a physical model is used, where no attenuation of the signal
+is determined.
-3.) PeakNoiseMangler: Drops a packet, if a colliding interference is found, where
-the signal to noise ratio (SNR) is below a tunable level, for example 2.
-If at a time multiple interferences collide with the transmission, where each
-interference is too insignificant, but the sum would be significant, the result
-is not accurate. This simplification drastically reduces the needed effort,
-to handle the reception of a transmission.
-(Depends on a physical model, where the attenuation is somehow determined)
+3.) PeakNoiseMangler: Drops a packet, if a colliding interference is found, where the signal
+to noise ratio (SNR) is below a tunable level, for example 2. Thus if at a time multiple
+interferences collide with the transmission, where each interference is too insignificant,
+but the sum would be significant, the result is not accurate. This simplification drastically
+reduces the needed effort, to handle the reception of a transmission. (Depends on a physical
+model, where the attenuation is somehow determined)
-4.) AddedNoiseMangler: Adds all current interferences up and drops the packet,
-if the SNR drops at any time below a tunable level.
-(Depends on a physical model, where the attenuation is somehow determined)
+4.) AddedNoiseMangler: Adds all current interferences up and drops the packet, if the SNR
+drops at any time below a tunable level. (Depends on a physical model, where the attenuation
+is somehow determined)
-useful combinations of a physical model with a bit mangler:
+Useful combinations of a physical model with a bit mangler:
a.) SimplePhysics + NoBitMangling
All nodes can reach each other and are in the same collision set.
-Probably useless, when used with a nontrivial MAC.
+This combination is not recommended, when used with a nontrivial MAC.
b.) UnitDisk + CollisionPacketMangler
This is probably the most basic model. The UnitDisc model describes a disc with the
@@ -106,8 +112,8 @@
e.) IndoorAttenuationFactor + PeakNoiseMangler|AddedNoiseMangler
-Uses a map to calculate the attenuation of the transmission for each
-passed obstacle.
+The IndoorAttenuationFactor class uses a map to calculate the attenuation of the
+transmission for each passed obstacle.
f.) VariableDisc + PeakNoiseMangler|AddedNoiseMangler
@@ -120,42 +126,43 @@
2.4 nodes and layers
-It is possible, to exchange several layers for all nodes. There are the
-physical layer, the MAC layer, the logical link layer, the network layer,
-the operating system layer and the application layer. The example
-specifies only the physical, the MAC, the network and the application
-layer. The remaining layers are set to dummy implementations, which
-only forward all received packets along the direction of the packet.
+It is possible, to exchange several layers for all nodes. There are the physical layer,
+the MAC layer, the logical link layer, the network layer, the operating system layer
+and the application layer. The example specifies only the physical, the MAC, the
+network and the application layer. The remaining layers are set to dummy implementations,
+which only forwards all received packets up or down the layer-stack, along the direction
+of the packet.
The count section in line 36 specifies the number of nodes for the simulation.
2.4.1 physical layers
-Currently only the dummy and the 802.11bg implementation are available.
-Which are the PhysicalDebug and the PHY_802_11bg class. If you do not
-care about a MAC or a physical layer and thus do not specify them, the
-PhysicalDebug class is used. If you wand to implement a new (for ex. TDMA)
-MAC on top of the 802.11bg hardware, specify the PHY_802_11bg class.
-This class is of course needed, if the 802.11bg MAC is used.
+Currently only the dummy and the 802.11bg implementation are available. Which are the
+PhysicalDebug and the PHY_802_11bg class. If you do not care about a MAC or a physical
+layer and thus do not specify them, the PhysicalDebug class is used. If you wand to
+implement a new (for example TDMA) MAC on top of the 802.11bg hardware, specify the
+PHY_802_11bg class. This class is of course needed, if the 802.11bg MAC is used.
2.4.2 MAC layers
-Likewise to the physical layer, only the dummy and the 802.11bg implementation
-are currently available. The 802.11bg MAC of course needs the 802.11bg physical
-layer and the MACdebug class works with the PhysicalDebug class.
+Likewise to the physical layer, only the dummy and the 802.11bg implementation are
+currently available. The 802.11bg MAC of course needs the 802.11bg physical layer and
+the MACdebug class works with the PhysicalDebug class.
2.4.3 logical link layers
There are several descendants of the LogLinkLayer class, like OBMStatisticLayer,
-StaticGridBackboneLogLinkLayer class, LogLinkDebug class and the
-LogLinkPosition class. The LogLinkDebug class is again the dummy implementation,
-which is used, if nothing else was specified. For the remaining classes, not much
-information is available. See the shox/conf/examples/ll directory for an example
-implementation of a layer, which aggregates multiple packets to the same receiver
-to a larger one, to reduce the overhead, when many packets are sent. To do so,
-small packets are delayed for some time and combined with other small packets
-for the same receiver, until they are sent. Although this is not a logical link
-task, this class can be used as an example, how to implement a layer and how to
+StaticGridBackboneLogLinkLayer class, LogLinkDebug class and the LogLinkPosition class.
+The LogLinkDebug class is again the dummy implementation, which is used, if nothing else
+was specified. For the remaining classes, not much information is available. The the source
+of each class, where a short comment at the beginning and the comment of the parameters may
+give you a hint about the function.
+
+See the shox/conf/examples/ll directory for an example implementation of a layer, which
+aggregates multiple packets to the same receiver to a larger one, to reduce the overhead,
+when many packets are sent. To do so, small packets are delayed for some time and combined
+with other small packets for the same receiver, until they are sent. Although this is not a
+logical link task, this class can be used as an example, how to implement a layer and how to
do logging and statistics.
2.4.4 network layers
@@ -197,13 +204,13 @@
The whole simulation can be recorded and replayed within the gui. During each run
arbitrary statistics can be created and later on visualized within the gui. To do so,
set logging to true (line 59) and add a file-name for the parts, you need in line 60
-and 61, where history refers to the simulation-replay file and statistics to the
-file, where all statistics are dumped to. The first implementation, which stores
-the data, used XML, which has lead to LARGE files. The current compact file
-logger is much more economical. To reduce the number of entries to the history
-even more, you can add filters (see lines 67 to 77).
+and 61, where history refers to the simulation-replay file and statistics to the file,
+where all statistics are written to. The first implementation, which stores the data,
+used XML, which has lead to LARGE files. The current compact file logger is much more
+economical. To reduce the number of entries to the history even more, you can add
+filters (see lines 67 to 77).
The last section simulationtime (line 81) is used, to specify the granularity of the
-simulation time and the total duration in seconds. There may be unexpected
-side effects, when changing stepspersecond, thus just keep it as is.
+simulation time and the total duration in seconds. There may be unexpected side effects,
+when changing stepspersecond, thus just keep it as is.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
