F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation spelling fixes

Browse Source
This commit is contained in:
Alexander Krotov
2017-09-01 11:40:28 +03:00
parent 5fcca3808f
commit 4b66cb5ac5
21 changed files with 72 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README
View File

@@ -52,7 +52,7 @@ type the command
./waf configure --enable-examples
followed by
./waf
in the the directory which contains
in the directory which contains
this README file. The files built will be copied in the
build/ directory.

2
doc/build.txt
View File

@@ -48,7 +48,7 @@ Other waf usages include:
4. ./waf --run "program [args]"
Run a ns3 program, given its target name, with the given
arguments. This takes care of automatically modifying the the
arguments. This takes care of automatically modifying the
path for finding the ns3 dynamic libraries in the environment
before running the program. Note: the "program [args]" string is
parsed using POSIX shell rules.

2
doc/manual/source/enable-modules.rst
View File

@@ -6,7 +6,7 @@ Enabling Subsets of |ns3| Modules
As with most software projects, |ns3| is ever growing larger in terms of number of modules, lines of code, and memory footprint. Users, however, may only use a few of those modules at a time. For this reason, users may want to explicitly enable only the subset of the possible |ns3| modules that they actually need for their research.
This chapter discusses how to enable only the |ns3| modules that you are intersted in using.
This chapter discusses how to enable only the |ns3| modules that you are interested in using.
How to enable a subset of |ns3|'s modules
*****************************************

2
doc/manual/source/events.rst
View File

@@ -168,7 +168,7 @@ network-level events.
Notes:
* Users need to be careful to propagate DoInitialize methods across objects
by calling Initialize explicitely on their member objects
by calling Initialize explicitly on their member objects
* The context id associated with each ScheduleWithContext method has
other uses beyond logging: it is used by an experimental branch of ns-3
to perform parallel simulation on multicore systems using

2
doc/manual/source/helpers.rst
View File

@@ -7,7 +7,7 @@ Helpers
The above chapters introduced you to various |ns3| programming concepts such as
smart pointers for reference-counted memory management, attributes, namespaces,
callbacks, etc. Users who work at this low-level API can interconnect |ns3|
objects with fine granulariy. However, a simulation program written entirely
objects with fine granularity. However, a simulation program written entirely
using the low-level API would be quite long and tedious to code. For this
reason, a separate so-called "helper API" has been overlaid on the core |ns3|
API. If you have read the |ns3| tutorial, you will already be familiar with the

2
doc/manual/source/python.rst
View File

@@ -166,7 +166,7 @@ Callback based tracing is not yet properly supported for Python, as new |ns3| AP
Pcap file writing is supported via the normal API.
Ascii tracing is supported since |ns3|.4 via the normal C++ API translated to Python. However, ascii tracing requires the creation of an ostream object to pass into the ascii tracing methods. In Python, the C++ std::ofstream has been minimally wrapped to allow this. For example:
ASCII tracing is supported since |ns3|.4 via the normal C++ API translated to Python. However, ASCII tracing requires the creation of an ostream object to pass into the ASCII tracing methods. In Python, the C++ std::ofstream has been minimally wrapped to allow this. For example:
::

2
doc/manual/source/random-variables.rst
View File

@@ -355,7 +355,7 @@ Publishing your results
When you publish simulation results, a key piece of configuration
information that you should always state is how you used the
the random number generator.
random number generator.
* what seeds you used,
* what RNG you used if not the default,

76
doc/manual/source/tracing.rst
View File

@@ -521,32 +521,32 @@ tells the helper to interpret the ``prefix`` parameter as a complete filename.
Ascii Tracing Device Helpers
++++++++++++++++++++++++++++
The behavior of the ascii trace helper ``mixin`` is substantially similar to
The behavior of the ASCII trace helper ``mixin`` is substantially similar to
the pcap version. Take a look at ``src/network/helper/trace-helper.h`` if you want to
follow the discussion while looking at real code.
The class ``AsciiTraceHelperForDevice`` adds the high level functionality for
using ascii tracing to a device helper class. As in the pcap case, every device
must implement a single virtual method inherited from the ascii trace
using ASCII tracing to a device helper class. As in the pcap case, every device
must implement a single virtual method inherited from the ASCII trace
``mixin``.::
virtual void EnableAsciiInternal (Ptr<OutputStreamWrapper> stream, std::string prefix, Ptr<NetDevice> nd) = 0;
The signature of this method reflects the device-centric view of the situation
at this level; and also the fact that the helper may be writing to a shared
output stream. All of the public ascii-trace-related methods inherited from
output stream. All of the public ASCII-trace-related methods inherited from
class ``AsciiTraceHelperForDevice`` reduce to calling this single device-
dependent implementation method. For example, the lowest level ascii trace
dependent implementation method. For example, the lowest level ASCII trace
methods,::
void EnableAscii (std::string prefix, Ptr<NetDevice> nd);
void EnableAscii (Ptr<OutputStreamWrapper> stream, Ptr<NetDevice> nd);
will call the device implementation of ``EnableAsciiInternal`` directly,
providing either a valid prefix or stream. All other public ascii tracing
providing either a valid prefix or stream. All other public ASCII tracing
methods will build on these low-level functions to provide additional user-level
functionality. What this means to the user is that all device helpers in the
system will have all of the ascii trace methods available; and these methods
system will have all of the ASCII trace methods available; and these methods
will all work in the same way across devices if the devices implement
``EnablAsciiInternal`` correctly.
@@ -576,7 +576,7 @@ Ascii Tracing Device Helper Methods
You are encouraged to peruse the Doxygen for class ``TraceHelperForDevice`` to
find the details of these methods; but to summarize ...
There are twice as many methods available for ascii tracing as there were for
There are twice as many methods available for ASCII tracing as there were for
pcap tracing. This is because, in addition to the pcap-style model where traces
from each unique node/device pair are written to a unique file, we support a
model in which trace information for many node/device pairs is written to a
@@ -584,7 +584,7 @@ common file. This means that the <prefix>-<node>-<device> file name generation
mechanism is replaced by a mechanism to refer to a common file; and the number
of API methods is doubled to allow all combinations.
Just as in pcap tracing, you can enable ascii tracing on a particular
Just as in pcap tracing, you can enable ASCII tracing on a particular
node/net-device pair by providing a ``Ptr<NetDevice>`` to an ``EnableAscii``
method. The ``Ptr<Node>`` is implicit since the net device must belong to
exactly one ``Node``. For example,::
@@ -593,12 +593,12 @@ exactly one ``Node``. For example,::
...
helper.EnableAscii ("prefix", nd);
In this case, no trace contexts are written to the ascii trace file since they
In this case, no trace contexts are written to the ASCII trace file since they
would be redundant. The system will pick the file name to be created using the
same rules as described in the pcap section, except that the file will have the
suffix ".tr" instead of ".pcap".
If you want to enable ascii tracing on more than one net device and have all
If you want to enable ASCII tracing on more than one net device and have all
traces sent to a single file, you can do that as well by using an object to
refer to a single file::
@@ -610,12 +610,12 @@ refer to a single file::
helper.EnableAscii (stream, nd1);
helper.EnableAscii (stream, nd2);
In this case, trace contexts are written to the ascii trace file since they
In this case, trace contexts are written to the ASCII trace file since they
are required to disambiguate traces from the two devices. Note that since the
user is completely specifying the file name, the string should include the ".tr"
for consistency.
You can enable ascii tracing on a particular node/net-device pair by providing a
You can enable ASCII tracing on a particular node/net-device pair by providing a
``std::string`` representing an object name service string to an
``EnablePcap`` method. The ``Ptr<NetDevice>`` is looked up from the name
string. Again, the ``<Node>`` is implicit since the named net device must
@@ -648,7 +648,7 @@ This would result in a single trace file called ``trace-file-name.tr`` that
contains all of the trace events for both devices. The events would be
disambiguated by trace context strings.
You can enable ascii tracing on a collection of node/net-device pairs by
You can enable ASCII tracing on a collection of node/net-device pairs by
providing a ``NetDeviceContainer``. For each ``NetDevice`` in the container the
type is checked. For each device of the proper type (the same type as is managed
by the device helper), tracing is enabled. Again, the ``<Node>`` is implicit
@@ -658,7 +658,7 @@ since the found net device must belong to exactly one ``Node``. For example,::
...
helper.EnableAscii ("prefix", d);
This would result in a number of ascii trace files being created, each of which
This would result in a number of ASCII trace files being created, each of which
follows the <prefix>-<node id>-<device id>.tr convention. Combining all of the
traces into a single file is accomplished similarly to the examples above::
@@ -679,7 +679,7 @@ enabled.::
...
helper.EnableAscii ("prefix", n);
This would result in a number of ascii trace files being created, each of which
This would result in a number of ASCII trace files being created, each of which
follows the <prefix>-<node id>-<device id>.tr convention. Combining all of the
traces into a single file is accomplished similarly to the examples above:
@@ -696,7 +696,7 @@ same type as that managed by the device helper.::
helper.EnableAsciiAll ("prefix");
This would result in a number of ascii trace files being created, one for
This would result in a number of ASCII trace files being created, one for
every device in the system of the type managed by the helper. All of these
files will follow the <prefix>-<node id>-<device id>.tr convention. Combining
all of the traces into a single file is accomplished similarly to the examples
@@ -706,20 +706,20 @@ Ascii Tracing Device Helper Filename Selection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Implicit in the prefix-style method descriptions above is the construction of
the complete filenames by the implementation method. By convention, ascii traces
the complete filenames by the implementation method. By convention, ASCII traces
in the |ns3| system are of the form ``<prefix>-<node id>-<device id>.tr``.
As previously mentioned, every node in the system will have a system-assigned
node id; and every device will have an interface index (also called a device id)
relative to its node. By default, then, an ascii trace file created as a result
relative to its node. By default, then, an ASCII trace file created as a result
of enabling tracing on the first device of node 21, using the prefix "prefix",
would be ``prefix-21-1.tr``.
You can always use the |ns3| object name service to make this more clear. For
example, if you use the object name service to assign the name "server" to node
21, the resulting ascii trace file name will automatically become,
21, the resulting ASCII trace file name will automatically become,
``prefix-server-1.tr`` and if you also assign the name "eth0" to the device,
your ascii trace file name will automatically pick this up and be called
your ASCII trace file name will automatically pick this up and be called
``prefix-server-eth0.tr``.
Pcap Tracing Protocol Helpers
@@ -864,7 +864,7 @@ automatically become, "prefix-nserverIpv4-i1.pcap".
Ascii Tracing Protocol Helpers
++++++++++++++++++++++++++++++
The behavior of the ascii trace helpers is substantially similar to the pcap
The behavior of the ASCII trace helpers is substantially similar to the pcap
case. Take a look at ``src/network/helper/trace-helper.h`` if you want to follow the
discussion while looking at real code.
@@ -874,7 +874,7 @@ appropriate type. For example, use a ``Ptr<Ipv6>`` instead of a ``Ptr<Ipv4>``
and call ``EnableAsciiIpv6`` instead of ``EnableAsciiIpv4``.
The class ``AsciiTraceHelperForIpv4`` adds the high level functionality for
using ascii tracing to a protocol helper. Each protocol that enables these
using ASCII tracing to a protocol helper. Each protocol that enables these
methods must implement a single virtual method inherited from this class.::
virtual void EnableAsciiIpv4Internal (Ptr<OutputStreamWrapper> stream, std::string prefix,
@@ -924,7 +924,7 @@ Ascii Tracing Device Helper Methods
You are encouraged to peruse the Doxygen for class ``PcapAndAsciiHelperForIpv4``
to find the details of these methods; but to summarize ...
There are twice as many methods available for ascii tracing as there were for
There are twice as many methods available for ASCII tracing as there were for
pcap tracing. This is because, in addition to the pcap-style model where traces
from each unique protocol/interface pair are written to a unique file, we
support a model in which trace information for many protocol/interface pairs is
@@ -932,7 +932,7 @@ written to a common file. This means that the <prefix>-n<node id>-<interface>
file name generation mechanism is replaced by a mechanism to refer to a common
file; and the number of API methods is doubled to allow all combinations.
Just as in pcap tracing, you can enable ascii tracing on a particular
Just as in pcap tracing, you can enable ASCII tracing on a particular
protocol/interface pair by providing a ``Ptr<Ipv4>`` and an ``interface`` to an
``EnableAscii`` method. For example,::
@@ -940,12 +940,12 @@ protocol/interface pair by providing a ``Ptr<Ipv4>`` and an ``interface`` to an
...
helper.EnableAsciiIpv4 ("prefix", ipv4, 1);
In this case, no trace contexts are written to the ascii trace file since they
In this case, no trace contexts are written to the ASCII trace file since they
would be redundant. The system will pick the file name to be created using the
same rules as described in the pcap section, except that the file will have the
suffix ".tr" instead of ".pcap".
If you want to enable ascii tracing on more than one interface and have all
If you want to enable ASCII tracing on more than one interface and have all
traces sent to a single file, you can do that as well by using an object to
refer to a single file. We have already something similar to this in the "cwnd"
example above::
@@ -958,12 +958,12 @@ example above::
helper.EnableAsciiIpv4 (stream, protocol1, 1);
helper.EnableAsciiIpv4 (stream, protocol2, 1);
In this case, trace contexts are written to the ascii trace file since they are
In this case, trace contexts are written to the ASCII trace file since they are
required to disambiguate traces from the two interfaces. Note that since the
user is completely specifying the file name, the string should include the ".tr"
for consistency.
You can enable ascii tracing on a particular protocol by providing a
You can enable ASCII tracing on a particular protocol by providing a
``std::string`` representing an object name service string to an ``EnablePcap``
method. The ``Ptr<Ipv4>`` is looked up from the name string. The ``<Node>`` in
the resulting filenames is implicit since there is a one-to-one correspondence
@@ -992,7 +992,7 @@ This would result in a single trace file called "trace-file-name.tr" that
contains all of the trace events for both interfaces. The events would be
disambiguated by trace context strings.
You can enable ascii tracing on a collection of protocol/interface pairs by
You can enable ASCII tracing on a collection of protocol/interface pairs by
providing an ``Ipv4InterfaceContainer``. For each protocol of the proper type
(the same type as is managed by the device helper), tracing is enabled for the
corresponding interface. Again, the ``<Node>`` is implicit since there is a
@@ -1009,7 +1009,7 @@ one-to-one correspondence between each protocol and its node. For example,::
...
helper.EnableAsciiIpv4 ("prefix", interfaces);
This would result in a number of ascii trace files being created, each of which
This would result in a number of ASCII trace files being created, each of which
follows the <prefix>-n<node id>-i<interface>.tr convention. Combining all of the
traces into a single file is accomplished similarly to the examples above::
@@ -1025,7 +1025,7 @@ traces into a single file is accomplished similarly to the examples above::
...
helper.EnableAsciiIpv4 (stream, interfaces);
You can enable ascii tracing on a collection of protocol/interface pairs by
You can enable ASCII tracing on a collection of protocol/interface pairs by
providing a ``NodeContainer``. For each ``Node`` in the ``NodeContainer`` the
appropriate protocol is found. For each protocol, its interfaces are enumerated
and tracing is enabled on the resulting pairs. For example,::
@@ -1034,7 +1034,7 @@ and tracing is enabled on the resulting pairs. For example,::
...
helper.EnableAsciiIpv4 ("prefix", n);
This would result in a number of ascii trace files being created, each of which
This would result in a number of ASCII trace files being created, each of which
follows the <prefix>-<node id>-<device id>.tr convention. Combining all of the
traces into a single file is accomplished similarly to the examples above:
@@ -1047,12 +1047,12 @@ used to specify the resulting trace source.::
Of course, the traces can be combined into a single file as shown above.
Finally, you can enable ascii tracing for all interfaces in the system, with
Finally, you can enable ASCII tracing for all interfaces in the system, with
associated protocol being the same type as that managed by the device helper.::
helper.EnableAsciiIpv4All ("prefix");
This would result in a number of ascii trace files being created, one for
This would result in a number of ASCII trace files being created, one for
every interface in the system related to a protocol of the type managed by the
helper. All of these files will follow the <prefix>-n<node id>-i<interface.tr
convention. Combining all of the traces into a single file is accomplished
@@ -1062,21 +1062,21 @@ Ascii Tracing Device Helper Filename Selection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Implicit in the prefix-style method descriptions above is the construction of
the complete filenames by the implementation method. By convention, ascii traces
the complete filenames by the implementation method. By convention, ASCII traces
in the |ns3| system are of the form "<prefix>-<node id>-<device id>.tr."
As previously mentioned, every node in the system will have a system-assigned
node id. Since there is a one-to-one correspondence between protocols and nodes
we use to node-id to identify the protocol identity. Every interface on a given
protocol will have an interface index (also called simply an interface) relative
to its protocol. By default, then, an ascii trace file created as a result of
to its protocol. By default, then, an ASCII trace file created as a result of
enabling tracing on the first device of node 21, using the prefix "prefix",
would be "prefix-n21-i1.tr". Use the prefix to disambiguate multiple protocols
per node.
You can always use the |ns3| object name service to make this more clear.
For example, if you use the object name service to assign the name "serverIpv4"
to the protocol on node 21, and also specify interface one, the resulting ascii
to the protocol on node 21, and also specify interface one, the resulting ASCII
trace file name will automatically become, "prefix-nserverIpv4-1.tr".
Tracing implementation details

2
doc/tutorial/source/getting-started.rst
View File

@@ -883,7 +883,7 @@ For example, to run your |ns3| program ``hello-simulator`` with the arguments
Notice that the |ns3| program name goes with the ``--run`` argument,
and the control utility (here ``gdb``) is the first token
in the ``--commmand-template`` argument. The ``--args`` tells ``gdb``
in the ``--command-template`` argument. The ``--args`` tells ``gdb``
that the remainder of the command line belongs to the "inferior" program.
(Some ``gdb``'s don't understand the ``--args`` feature. In this case,
omit the program arguments from the ``--command-template``,

2
doc/tutorial/source/introduction.rst
View File

@@ -41,7 +41,7 @@ models of how packet data networks work and perform, and provides a
simulation engine for users to conduct simulation experiments. Some of the
reasons to use |ns3| include to perform studies that are more difficult
or not possible to perform with real systems, to study system behavior in
a highly controllled, reproducible environment, and to learn about how
a highly controlled, reproducible environment, and to learn about how
networks work. Users will note that the available model set in |ns3|
focuses on modeling how Internet protocols and networks work, but
|ns3| is not limited to Internet systems; several users are using

2
doc/tutorial/source/tracing.rst
View File

@@ -1272,7 +1272,7 @@ the list of TraceSources you will find
**TraceSources**
* **CongestionWindow**: The TCP connnection's congestion window
* **CongestionWindow**: The TCP connection's congestion window
Callback signature: **ns3::TracedValueCallback::Uint32**

4
src/antenna/doc/source/antenna-design.rst
View File

@@ -21,10 +21,10 @@ AntennaModel
The AntennaModel uses the coordinate system adopted in [Balanis]_ and
depicted in Figure :ref:`fig-antenna-coordinate-system`. This system
is obtained by traslating the cartesian coordinate system used by the
is obtained by translating the Cartesian coordinate system used by the
ns-3 MobilityModel into the new origin :math:`o` which is the location
of the antenna, and then transforming the coordinates of every generic
point :math:`p` of the space from cartesian coordinates
point :math:`p` of the space from Cartesian coordinates
:math:`(x,y,z)` into spherical coordinates
:math:`(r, \theta,\phi)`.
The antenna model neglects the radial component :math:`r`, and

4
src/antenna/doc/source/antenna-testing.rst
View File

@@ -10,11 +10,11 @@ Angles
------
The unit test suite ``angles`` verifies that the Angles class is
constructed properly by correct conversion from 3D cartesian
constructed properly by correct conversion from 3D Cartesian
coordinates according to the available methods (construction from a
single vector and from a pair of vectors). For each method, several
test cases are provided that compare the values :math:`(\phi, \theta)`
determied by the constructor to known reference values. The test
determined by the constructor to known reference values. The test
passes if for each case the values are equal to the reference up to a
tolerance of :math:`10^{-10}` which accounts for numerical errors.

2
src/antenna/doc/source/antenna-user.rst
View File

@@ -5,7 +5,7 @@
User Documentation
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The antenna moduled can be used with all the wireless technologies and
The antenna modeled can be used with all the wireless technologies and
physical layer models that support it. Currently, this includes
the physical layer models based on the SpectrumPhy. Please refer to
the documentation of each of these models for details.

2
src/csma/doc/csma.rst
View File

@@ -4,7 +4,7 @@
CSMA NetDevice
--------------
This is the introduction to CSMA NetDevice chapter, to complement the Csma model
This is the introduction to CSMA NetDevice chapter, to complement the CSMA model
doxygen.
Overview of the CSMA model

10
src/dsr/doc/dsr.rst
View File

@@ -62,7 +62,7 @@ saves the whole path in the cache. The paths are sorted based on the
hop count, and whenever one path is not able to be used, we change to the
next path. The link cache is a slightly better design in the sense that it
uses different subpaths and uses Implemented Link Cache using
Dijsktra algorithm, and this part is implemented by
Dijkstra algorithm, and this part is implemented by
Song Luan <lsuper@mail.ustc.edu.cn>.
The following optional protocol optimizations aren't implemented:
@@ -126,7 +126,7 @@ Implementation modification
* The DsrFsHeader has added 3 fields: message type, source id, destination id, and these changes only for post-processing
1. Message type is used to identify the data packet from control packet
2. source id is used to identify the real source of the data packet since we have to deliver the packet hop-by-hop and the ipv4header is not carrying the real source and destination ip address as needed
2. source id is used to identify the real source of the data packet since we have to deliver the packet hop-by-hop and the Ipv4Header is not carrying the real source and destination ip address as needed
3. destination id is for same reason of above
* Route Reply header is not word-aligned in DSR RFC, change it to word-aligned in implementation
* DSR works as a shim header between transport and network protocol, it needs its own forwarding mechanism, we are changing the packet transmission to hop-by-hop delivery, so we added two fields in dsr fixed header to notify packet delivery
@@ -140,7 +140,7 @@ This implementation used "path cache", which is simple to implement and ensures
* the path cache has automatic expire policy
* the cache saves multiple route entries for a certain destination and sort the entries based on hop counts
* the MaxEntriesEachDst can be tuned to change the maximum entries saved for a single destination
* when adding mulitiple routes for one destination, the route is compared based on hop-count and expire time, the one with less hop count or relatively new route is favored
* when adding multiple routes for one destination, the route is compared based on hop-count and expire time, the one with less hop count or relatively new route is favored
* Future implementation may include "link cache" as another possibility
DSR Instructions
@@ -164,7 +164,7 @@ and DsrMainHelpers in your simulation script. For instance:
DsrMainHelper dsrMain;
dsrMain.Install (dsr, adhocNodes);
The example scripts inside ``src/dsr/examples/`` demonstrate the use of DSR based nodesin different scenarios.
The example scripts inside ``src/dsr/examples/`` demonstrate the use of DSR based nodes in different scenarios.
The helper source can be found inside ``src/dsr/helper/dsr-main-helper.{h,cc}``
and ``src/dsr/helper/dsr-helper.{h,cc}``
@@ -194,7 +194,7 @@ Limitations
***********
The model is not fully compliant with :rfc:`4728`. As an example, Dsr fixed size header
has been extended and it is four octects longer then the RFC specification.
has been extended and it is four octets longer then the RFC specification.
As a consequence, the DSR headers can not be correctly decoded by Wireshark.
The model full compliance with the RFC is planned for the future.

2
src/internet-apps/doc/internet-apps.rst
View File

@@ -35,7 +35,7 @@ following attributes to be set:
* Packet size (default 56 bytes)
* Packet interval (default 1 second)
Moreover, the user can access the measured rtt value (as a Traced Source).
Moreover, the user can access the measured RTT value (as a Traced Source).
Ping6
*****

4
src/internet/doc/routing-overview.rst
View File

@@ -316,7 +316,7 @@ are the number of vertices (routers) and edges (links) respectively.
It should be stressed that the convergence time is the number of steps in
the algorithm, and each step is triggered by a message.
Since Triggered Updates (i.e., when a route is changed) have a 1-5 seconds
cooldown, the toplogy can require some time to be stabilized.
cooldown, the topology can require some time to be stabilized.
Users should be aware that, during routing tables construction, the routers
might drop packets. Data traffic should be sent only after a time long
@@ -351,7 +351,7 @@ Poison Reverse will advertise the route on the interface from which it
was learned, but with a metric of 16 (infinity).
For a full analysis of the three techniques, see :rfc:`1058`, section 2.2.
The examples are based on the network toplogy
The examples are based on the network topology
described in the RFC, but it does not show the effect described there.
The reason are the Triggered Updates, together with the fact that when a

14
src/uan/doc/uan.rst
View File

@@ -80,7 +80,7 @@ Acoustic Ray Tracing software (http://oalib.hlsresearch.com/).
The create-dat utility requires a Bellhop installation to run. Bellhop takes
environment information about the channel, such as sound speed profile, surface height
bottom type, water depth, and uses a gaussian ray tracing algorithm to determine
bottom type, water depth, and uses a Gaussian ray tracing algorithm to determine
propagation information. Arrivals from Bellhop are grouped together into equal length
taps (the arrivals in a tap duration are coherently summed). The maximum taps are then
aligned to take the same position in the PDP. The create-dat utility averages together
@@ -229,7 +229,7 @@ The user will be able to:
* use a specific power profile for the acoustic modem
* use a specific energy model for the AUV
* trace the power consumption of AUV navigation, through AUV's energy model
* trace the power consumprion underwater acoustic communications, through acoustic modem power profile
* trace the power consumption underwater acoustic communications, through acoustic modem power profile
We have integrated the Energy Model with the UAN module, to implement energy handling. We have implemented a specific energy model for the two AUV classes and, an energy source for Lithium batteries. This will be really useful for researchers to keep trace of the AUV operational life.
We have implemented also an acoustic modem power profile, to keep trace of its power consumption. This can be used to compare protocols specific power performance. In order to use such power profile, the acoustic transducer physical layer has been modified to use the modem power profile. We have decoupled the physical layer from the transducer specific energy model, to let the users change the different energy models without changing the physical layer.
@@ -259,7 +259,7 @@ AUV energy sources
Acoustic modem energy model
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Basing on the Device Energy Model interface, has been implemented a generic energy model for acoustic modem. The model allows to trace four modem's power-states: Sleep, Idle, Receiving, Transmitting. The default parameters for the energy model are set to fit those of the WHOI μmodem. The class follows pretty closely the RadioEnergyModel class as the transducer behaviour is pretty close to that of a wifi radio.
Basing on the Device Energy Model interface, has been implemented a generic energy model for acoustic modem. The model allows to trace four modem's power-states: Sleep, Idle, Receiving, Transmitting. The default parameters for the energy model are set to fit those of the WHOI μmodem. The class follows pretty closely the RadioEnergyModel class as the transducer behaviour is pretty close to that of a Wi-Fi radio.
The default power consumption values implemented into the model are as follows [6]:
@@ -281,7 +281,7 @@ UAN module energy modifications
The UAN module has been modified in order to utilize the implemented energy classes. Specifically, it has been modified the physical layer of the UAN module. It Has been implemented an UpdatePowerConsumption method that takes the modem's state as parameter. It checks if an energy source is installed into the node and, in case, it then use the AcousticModemEnergyModel to update the power consumption with the current modem's state. The modem power consumption's update takes place whenever the modem changes its state.
A user should take into account that, if the the power consumption handling is enabled (if the node has an energy source installed), all the communications processes will terminate whether the node depletes all the energy source.
A user should take into account that, if the power consumption handling is enabled (if the node has an energy source installed), all the communications processes will terminate whether the node depletes all the energy source.
Li-Ion batteries model
@@ -315,7 +315,7 @@ Some ideas could be :
* insert a data logging capability
* modify the framework to use sockets (enabling the possibility to use applications)
* introduce some more MAC protocols
* modify the physical layer to let it consider the doppler spread (problematic in underwater environments)
* modify the physical layer to let it consider the Doppler spread (problematic in underwater environments)
* introduce OFDM modulations
References
@@ -355,7 +355,7 @@ further examples can be found into the Unit tests in ``src/uan/test/...cc``
Examples
========
Examples of the Framework's usage can be found into the examples folder. There are mobility related examples and uan related ones.
Examples of the Framework's usage can be found into the examples folder. There are mobility related examples and UAN related ones.
Mobility Model Examples
#######################
@@ -517,7 +517,7 @@ The unit test can be found in ``src/uan/test/auv-energy-model-test.cc``.
The single packet energy consumption test do the following:
* creates a two node network, one surface gateway and one fixed node at -500 m of depth
* install the acoustic communication stack with energy consuption support into the nodes
* install the acoustic communication stack with energy consumption support into the nodes
* a packet is sent from the underwater node to the gateway
* it is verified that both, the gateway and the fixed node, have consumed the expected amount of energy from their sources

4
src/wifi/doc/source/wifi-design.rst
View File

@@ -155,7 +155,7 @@ found in practice.
The physical layer and channel models operate on a per-packet basis, with
no frequency-selective propagation or interference effects when using
the default YansWifiPhy model. Directional antennas are also not
supported at this time. For additive white gaussian noise (AWGN)
supported at this time. For additive white Gaussian noise (AWGN)
scenarios, or wideband interference scenarios, performance is governed
by the application of analytical models (based on modulation and factors
such as channel width) to the received signal-to-noise ratio, where noise
@@ -446,7 +446,7 @@ were adapted to use the Spectrum channel API. This required developing
a few ``SpectrumModel``-related classes. The class
``WifiSpectrumValueHelper`` is used to create Wi-Fi signals with the
spectrum framework and spread their energy across the bands. The
spectrum is sub-divided into 312.5 KHz sub-bands (the width of an OFDM
spectrum is sub-divided into 312.5 kHz sub-bands (the width of an OFDM
subcarrier). The power allocated to a particular channel
is spread across the sub-bands roughly according to how power would
be allocated to sub-carriers using an even distribution of power and

2
src/wifi/doc/source/wifi-user.rst
View File

@@ -36,7 +36,7 @@ To create a WifiNetDevice, users need to follow these steps:
* Decide on which physical layer framework, the ``SpectrumWifiPhy`` or
``YansWifiPhy``, to use. This will affect which Channel and Phy type to use.
* Configure the Channel: Channel takes care of getting signal
from one device to other devices on the same wifi channel.
from one device to other devices on the same Wi-Fi channel.
The main configurations of WifiChannel are propagation loss model and propagation delay model.
* Configure the WifiPhy: WifiPhy takes care of actually sending and receiving wireless
signal from Channel. Here, WifiPhy decides whether each frame will be successfully