Fix an example dependency problem and fix some paths in the documentation
This commit is contained in:
@@ -149,12 +149,12 @@ alternative way to run distributed examples is shown below:::
|
||||
|
||||
./waf shell
|
||||
cd build/debug
|
||||
mpirun -np 2 examples/mpi/simple-distributed
|
||||
mpirun -np 2 src/mpi/examples/simple-distributed
|
||||
|
||||
Creating custom topologies
|
||||
++++++++++++++++++++++++++
|
||||
|
||||
The example programs in examples/mpi give a good idea of how to create different
|
||||
The example programs in src/mpi/examples give a good idea of how to create different
|
||||
topologies for distributed simulation. The main points are assigning system ids
|
||||
to individual nodes, creating point-to-point links where the simulation should
|
||||
be divided, and installing applications only on the LP associated with the
|
||||
|
||||
@@ -141,8 +141,8 @@ to these other net devices:::
|
||||
|
||||
EmuHelper::EnablePcapAll ("emu-udp-echo-client");
|
||||
|
||||
To see an example of a client script using the ``Emu`` net device, see
|
||||
``examples/emu-udp-echo-client.cc`` and ``examples/emu-udp-echo-server.cc``
|
||||
For examples that use the ``Emu`` net device, see
|
||||
``src/emu/examples/emu-udp-echo.cc`` and ``src/emu/examples/emu-ping.cc``
|
||||
in the repository `<http://code.nsnam.org/craigdo/ns-3-emu/>`_.
|
||||
|
||||
Implementation
|
||||
|
||||
@@ -7,13 +7,13 @@ Energy consumption is a key issue for wireless devices, and wireless network res
|
||||
Model Description
|
||||
=================
|
||||
|
||||
The source code for the Energy Framework is currently at: ``src/contrib/energy``.
|
||||
The source code for the Energy Framework is currently at: ``src/energy``.
|
||||
|
||||
Design
|
||||
******
|
||||
|
||||
The ns-3 Energy Framework is composed of 2 parts: Energy Source and Device Energy Model.
|
||||
The framework will be implemented into the ``src/contrib/energy/models`` folder.
|
||||
The framework will be implemented into the ``src/energy/models`` folder.
|
||||
|
||||
Energy Source
|
||||
#############
|
||||
@@ -59,7 +59,7 @@ References
|
||||
Usage
|
||||
=====
|
||||
|
||||
The main way that ns-3 users will typically interact with the Energy Framework is through the helper API and through the publicly visible attributes of the framework. The helper API is defined in ``src/contrib/energy/helper/*.h``.
|
||||
The main way that ns-3 users will typically interact with the Energy Framework is through the helper API and through the publicly visible attributes of the framework. The helper API is defined in ``src/energy/helper/*.h``.
|
||||
|
||||
In order to use the energy framework, the user must install an Energy Source for the node of interest and the corresponding Device Energy Model for the network devices. Energy Source (objects) are aggregated onto each node by the Energy Source Helper. In order to allow multiple energy sources per node, we aggregate an Energy Source Container rather than directly aggregating a source object.
|
||||
|
||||
@@ -69,7 +69,9 @@ The Energy Source object also keeps a list of Device Energy Model objects using
|
||||
Examples
|
||||
********
|
||||
|
||||
The example ``examples/energy/`` contain some basic code that shows how to set up the framework.
|
||||
The example directories, ``src/examples/energy`` and
|
||||
``examples/energy``, contain some basic code that shows how to set up
|
||||
the framework.
|
||||
|
||||
Helpers
|
||||
*******
|
||||
|
||||
@@ -3,6 +3,7 @@ Flow Monitor
|
||||
|
||||
*Placeholder chapter*
|
||||
|
||||
This feature was added as contributed code (``src/contrib``) in *ns-3.6* and to
|
||||
the main distribution for *ns-3.7*. A paper on this feature is published in the
|
||||
proceedings of NSTools: `<http://www.nstools.org/techprog.shtml>`_.
|
||||
This feature was added as contributed code (``src/contrib``) in
|
||||
*ns-3.6* and to the main distribution (``src/flow-monitor``) for
|
||||
*ns-3.7*. A paper on this feature is published in the proceedings of
|
||||
NSTools: `<http://www.nstools.org/techprog.shtml>`_.
|
||||
|
||||
@@ -21,7 +21,7 @@ Model Description
|
||||
*****************
|
||||
|
||||
The source code for the LTE models lives in the directory
|
||||
``src/devices/lte``.
|
||||
``src/lte``.
|
||||
|
||||
Design
|
||||
======
|
||||
@@ -249,16 +249,16 @@ The main way that users who write simulation scripts will typically
|
||||
interact with the LTE models is through the helper API and through
|
||||
the publicly visible attributes of the model.
|
||||
|
||||
The helper API is defined in ``src/devices/lte/helper/lte-helper.h``.
|
||||
The helper API is defined in ``src/lte/helper/lte-helper.h``.
|
||||
|
||||
The example ``src/devices/lte/examples/`` contain some basic
|
||||
The example ``src/lte/examples/`` contain some basic
|
||||
code that shows how to set up the model in order to simualte an
|
||||
E-UTRAN downlink transmission.
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
``src/devices/lte/examples/lte-device.cc`` shows how it is possible to set up the LTE module::
|
||||
``src/lte/examples/lte-device.cc`` shows how it is possible to set up the LTE module::
|
||||
|
||||
NodeContainer ueNodes;
|
||||
NodeContainer enbNodes;
|
||||
@@ -352,7 +352,7 @@ Caveats
|
||||
Validation
|
||||
**********
|
||||
|
||||
In the ``src/devices/lte/example/lte-amc.cc`` has been developed an important example
|
||||
In the ``src/lte/example/lte-amc.cc`` has been developed an important example
|
||||
that shows the proper functioning of both AMC module and Channel model.
|
||||
The analyzed scenario is composed by two nodes: a eNB and a single UE
|
||||
(registered to the eNB). The UE moves into the cell using the
|
||||
|
||||
@@ -174,7 +174,7 @@ sort, it makes sense to put it into the ``src/`` directory somewhere,
|
||||
particularly for ease of integrating with the build system.
|
||||
|
||||
In the case of the error model, it is very related to the packet class, so it
|
||||
makes sense to implement this in the ``src/common/`` directory where |ns3|
|
||||
makes sense to implement this in the ``src/network/model/`` directory where |ns3|
|
||||
packets are implemented.
|
||||
|
||||
waf and wscript
|
||||
@@ -186,7 +186,7 @@ want to integrate your new source files into this system. This requires that you
|
||||
add your files to the ``wscript`` file found in each directory.
|
||||
|
||||
Let's start with empty files error-model.h and error-model.cc, and add this to
|
||||
``src/common/wscript``. It is really just a matter of adding the .cc file to the
|
||||
``src/network/wscript``. It is really just a matter of adding the .cc file to the
|
||||
rest of the source files, and the .h file to the list of the header files.
|
||||
|
||||
Now, pop up to the top level directory and type "./waf --check". You
|
||||
@@ -304,8 +304,8 @@ from class Object.::
|
||||
A few things to note here. We need to include ``object.h``. The convention in
|
||||
|ns3| is that if the header file is co-located in the same directory, it may be
|
||||
included without any path prefix. Therefore, if we were implementing ErrorModel
|
||||
in ``src/core`` directory, we could have just said "``#include "object.h"``".
|
||||
But we are in ``src/common``, so we must include it as "``#include
|
||||
in ``src/core/model`` directory, we could have just said "``#include "object.h"``".
|
||||
But we are in ``src/network/model``, so we must include it as "``#include
|
||||
"ns3/object.h"``". Note also that this goes outside the namespace declaration.
|
||||
|
||||
Second, each class must implement a static public member function called
|
||||
|
||||
@@ -60,8 +60,8 @@ perspective. Users just need to set the attribute
|
||||
GlobalValue::Bind ("SimulatorImplementationType",
|
||||
StringValue ("ns3::RealtimeSimulatorImpl"));
|
||||
|
||||
There is a script in ``examples/realtime-udp-echo.cc`` that has an example of
|
||||
how to configure the realtime behavior. Try: ::
|
||||
There is a script in ``examples/realtime/realtime-udp-echo.cc`` that
|
||||
has an example of how to configure the realtime behavior. Try: ::
|
||||
|
||||
./waf --run realtime-udp-echo
|
||||
|
||||
|
||||
@@ -267,7 +267,7 @@ Optimized Link State Routing (OLSR)
|
||||
+++++++++++++++++++++++++++++++++++
|
||||
|
||||
This IPv4 routing protocol was originally ported from the OLSR-UM implementation
|
||||
for ns-2. The implementation is found in the src/routing/olsr directory, and an
|
||||
for ns-2. The implementation is found in the src/olsr directory, and an
|
||||
example script is in examples/simple-point-to-point-olsr.cc.
|
||||
|
||||
Typically, OLSR is enabled in a main program by use of an OlsrHelper class that
|
||||
|
||||
@@ -8,4 +8,4 @@ Statistics
|
||||
This wiki page: `This wiki page
|
||||
<http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation>`_
|
||||
contains information about the proposed statistical framework that is located in
|
||||
``src/contrib`` directory.
|
||||
``src/stats`` directory.
|
||||
|
||||
@@ -12,7 +12,7 @@ Model Description
|
||||
*****************
|
||||
|
||||
The source code for the UAN Framework lives in the directory
|
||||
``src/devices/uan``, ``src/devices/uan/auv`` and in ``src/contrib/energy`` for the contribution on
|
||||
``src/uan`` and in ``src/energy`` for the contribution on
|
||||
the li-ion battery model.
|
||||
|
||||
The UAN Framework is composed of two main parts:
|
||||
@@ -26,7 +26,7 @@ As enabling component for the energy models, a Li-Ion batteries energy source ha
|
||||
Design
|
||||
======
|
||||
|
||||
The development of the UAN Framework for ns-3 is composed by three consecutive steps. The first one is the development of the AUV simulator, the second one is the development of the UAN energy models and the third one is the integration of such components with the existing modules, UAN module and Energy Model. The module is implemented into the ``/src/contrib/uan`` folder for the part regarding acoustic modem energy model and in ``/src/contrib/uan/auv`` for the part regarding the AUV simulator.
|
||||
The development of the UAN Framework for ns-3 is composed by three consecutive steps. The first one is the development of the AUV simulator, the second one is the development of the UAN energy models and the third one is the integration of such components with the existing modules, UAN module and Energy Model. The module is implemented into the ``/src/uan`` folder for the part regarding acoustic modem energy model and the part regarding the AUV simulator.
|
||||
|
||||
|
||||
AUV mobility models
|
||||
@@ -198,10 +198,10 @@ The main way that users who write simulation scripts will typically
|
||||
interact with the UAN Framework is through the helper API and through
|
||||
the publicly visible attributes of the model.
|
||||
|
||||
The helper API is defined in ``src/devices/uan/helper/acoustic-modem-energy-model-helper.{cc,h}`` and in ``/src/devices/uan/auv/helper/...{cc,h}``.
|
||||
The helper API is defined in ``src/uan/helper/acoustic-modem-energy-model-helper.{cc,h}`` and in ``/src/uan/helper/...{cc,h}``.
|
||||
|
||||
The example folder ``src/devices/uan/auv/examples/`` contain some basic code that shows how to set up and use the models.
|
||||
further examples can be found into the Unit tests in ``src/devices/uan/auv/test/...cc``
|
||||
The example folder ``src/uan/examples/`` contain some basic code that shows how to set up and use the models.
|
||||
further examples can be found into the Unit tests in ``src/uan/test/...cc``
|
||||
|
||||
Examples
|
||||
========
|
||||
@@ -363,7 +363,7 @@ Auv Energy Model
|
||||
================
|
||||
|
||||
Includes test cases for single packet energy consumption, energy depletion, Glider and REMUS energy consumption.
|
||||
The unit test can be found in ``src/devices/uan/auv/test/auv-energy-model-test.cc``.
|
||||
The unit test can be found in ``src/uan/test/auv-energy-model-test.cc``.
|
||||
|
||||
The single packet energy consumption test do the following:
|
||||
|
||||
@@ -395,7 +395,7 @@ Auv Mobility
|
||||
============
|
||||
|
||||
Includes test cases for glider and REMUS mobility models.
|
||||
The unit test can be found in ``src/devices/uan/auv/test/auv-mobility-test.cc``.
|
||||
The unit test can be found in ``src/uan/test/auv-mobility-test.cc``.
|
||||
|
||||
* create a node with glider capabilities
|
||||
* set a specified velocity vector and verify if the resulting buoyancy is the one that is supposed to be
|
||||
@@ -415,7 +415,7 @@ Li-Ion Energy Source
|
||||
====================
|
||||
|
||||
Includes test case for Li-Ion energy source.
|
||||
The unit test can be found in ``src/contrib/energy/test/li-ion-energy-source-test.cc``.
|
||||
The unit test can be found in ``src/energy/test/li-ion-energy-source-test.cc``.
|
||||
|
||||
The test case verify that after a well-known discharge time with constant current drain, the cell voltage has followed the datasheet discharge curve [9].
|
||||
|
||||
|
||||
@@ -77,7 +77,7 @@ attributes of the model.
|
||||
|
||||
The helper API is defined in ``src/helper/wimax-helper.{cc,h}``.
|
||||
|
||||
The example ``examples/wimax/wimax-simple.cc`` contains some basic code that
|
||||
The example ``src/wimax/examples/wimax-simple.cc`` contains some basic code that
|
||||
shows how to set up the model:::
|
||||
|
||||
switch (schedType)
|
||||
@@ -116,7 +116,7 @@ created. The helper method ``Install`` allows the user to specify the scheduler
|
||||
type, the physical layer type, and the device type.
|
||||
|
||||
Different variants of ``Install`` are available; for instance, the example
|
||||
``examples/wimax/wimax-multicast.cc`` shows how to specify a non-default channel
|
||||
``src/wimax/examples/wimax-multicast.cc`` shows how to specify a non-default channel
|
||||
or propagation model:::
|
||||
|
||||
channel = CreateObject<SimpleOfdmWimaxChannel> ();
|
||||
@@ -133,13 +133,13 @@ or propagation model:::
|
||||
scheduler);
|
||||
|
||||
Mobility is also supported in the same way as in Wifi models; see the
|
||||
``examples/wimax/wimax-multicast.cc``.
|
||||
``src/wimax/examples/wimax-multicast.cc``.
|
||||
|
||||
Another important concept in WiMAX is that of a service flow. This is a
|
||||
unidirectional flow of packets with a set of QoS parameters such as traffic
|
||||
priority, rate, scheduling type, etc. The base station is responsible for
|
||||
issuing service flow identifiers and mapping them to WiMAX connections. The
|
||||
following code from ``examples/wimax/wimax-multicast.cc`` shows how this is
|
||||
following code from ``src/wimax/examples/wimax-multicast.cc`` shows how this is
|
||||
configured from a helper level:::
|
||||
|
||||
ServiceFlow MulticastServiceFlow = wimax.CreateServiceFlow (ServiceFlow::SF_DIRECTION_DOWN,
|
||||
|
||||
@@ -408,7 +408,7 @@ in the following code,
|
||||
|
||||
::
|
||||
|
||||
int
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
...
|
||||
|
||||
@@ -10,7 +10,7 @@ def build(bld):
|
||||
obj.source = 'tcp-nsc-lfn.cc'
|
||||
|
||||
obj = bld.create_ns3_program('tcp-nsc-zoo',
|
||||
['csma', 'internet'])
|
||||
['csma', 'internet', 'applications'])
|
||||
obj.source = 'tcp-nsc-zoo.cc'
|
||||
|
||||
obj = bld.create_ns3_program('tcp-star-server',
|
||||
|
||||
Reference in New Issue
Block a user