Documentation spelling fixes

README

@@ -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.
 

doc/build.txt

@@ -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.

doc/manual/source/enable-modules.rst

@@ -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
 *****************************************

doc/manual/source/events.rst

@@ -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

doc/manual/source/helpers.rst

@@ -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

doc/manual/source/python.rst

@@ -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:
 
 ::
 

doc/manual/source/random-variables.rst

@@ -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,

doc/tutorial/source/getting-started.rst

@@ -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``,

doc/tutorial/source/introduction.rst

@@ -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

doc/tutorial/source/tracing.rst

@@ -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**
 

src/antenna/doc/source/antenna-design.rst

@@ -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

src/antenna/doc/source/antenna-testing.rst

@@ -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.
 

src/antenna/doc/source/antenna-user.rst

@@ -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.

src/csma/doc/csma.rst

@@ -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

src/dsr/doc/dsr.rst

@@ -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.

src/internet-apps/doc/internet-apps.rst

@@ -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
 *****

src/internet/doc/routing-overview.rst

@@ -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 

src/uan/doc/uan.rst

@@ -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
 

src/wifi/doc/source/wifi-design.rst

@@ -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

src/wifi/doc/source/wifi-user.rst

@@ -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