diff --git a/README b/README index c1b8be107..b139b3277 100644 --- a/README +++ b/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. diff --git a/doc/build.txt b/doc/build.txt index 430f5977a..087857980 100644 --- a/doc/build.txt +++ b/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. diff --git a/doc/manual/source/enable-modules.rst b/doc/manual/source/enable-modules.rst index e395acb97..76ff9373a 100644 --- a/doc/manual/source/enable-modules.rst +++ b/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 ***************************************** diff --git a/doc/manual/source/events.rst b/doc/manual/source/events.rst index 763713f82..5baf3b516 100644 --- a/doc/manual/source/events.rst +++ b/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 diff --git a/doc/manual/source/helpers.rst b/doc/manual/source/helpers.rst index ca6980eec..fffcab7e5 100644 --- a/doc/manual/source/helpers.rst +++ b/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 diff --git a/doc/manual/source/python.rst b/doc/manual/source/python.rst index 622f655aa..50d58fdce 100644 --- a/doc/manual/source/python.rst +++ b/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: :: diff --git a/doc/manual/source/random-variables.rst b/doc/manual/source/random-variables.rst index 4b48b96c1..951d089cc 100644 --- a/doc/manual/source/random-variables.rst +++ b/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, diff --git a/doc/manual/source/tracing.rst b/doc/manual/source/tracing.rst index fbced1723..55ca8e5df 100644 --- a/doc/manual/source/tracing.rst +++ b/doc/manual/source/tracing.rst @@ -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 stream, std::string prefix, Ptr 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 nd); void EnableAscii (Ptr stream, Ptr 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 -- 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`` to an ``EnableAscii`` method. The ``Ptr`` 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`` is looked up from the name string. Again, the ```` 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 ```` 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 --.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 --.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 --.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 ``--.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`` instead of a ``Ptr`` 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 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 -n- 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`` and an ``interface`` to an ``EnableAscii`` method. For example,:: @@ -940,12 +940,12 @@ protocol/interface pair by providing a ``Ptr`` 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`` is looked up from the name string. The ```` 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 ```` 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 -n-i.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 --.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 -n-i--.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 diff --git a/doc/tutorial/source/getting-started.rst b/doc/tutorial/source/getting-started.rst index 7eb2170eb..b47ec3828 100644 --- a/doc/tutorial/source/getting-started.rst +++ b/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``, diff --git a/doc/tutorial/source/introduction.rst b/doc/tutorial/source/introduction.rst index ac716a0b8..cab42eea6 100644 --- a/doc/tutorial/source/introduction.rst +++ b/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 diff --git a/doc/tutorial/source/tracing.rst b/doc/tutorial/source/tracing.rst index 86db147b7..2389f3715 100644 --- a/doc/tutorial/source/tracing.rst +++ b/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** diff --git a/src/antenna/doc/source/antenna-design.rst b/src/antenna/doc/source/antenna-design.rst index beda6295c..d93db0d5d 100644 --- a/src/antenna/doc/source/antenna-design.rst +++ b/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 diff --git a/src/antenna/doc/source/antenna-testing.rst b/src/antenna/doc/source/antenna-testing.rst index be93c6238..559885837 100644 --- a/src/antenna/doc/source/antenna-testing.rst +++ b/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. diff --git a/src/antenna/doc/source/antenna-user.rst b/src/antenna/doc/source/antenna-user.rst index 784b469fd..f38326828 100644 --- a/src/antenna/doc/source/antenna-user.rst +++ b/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. diff --git a/src/csma/doc/csma.rst b/src/csma/doc/csma.rst index bf9e5a037..8a6730c05 100644 --- a/src/csma/doc/csma.rst +++ b/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 diff --git a/src/dsr/doc/dsr.rst b/src/dsr/doc/dsr.rst index 5213d5ee1..c7c5790de 100644 --- a/src/dsr/doc/dsr.rst +++ b/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 . 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. diff --git a/src/internet-apps/doc/internet-apps.rst b/src/internet-apps/doc/internet-apps.rst index 722266163..e097fecee 100644 --- a/src/internet-apps/doc/internet-apps.rst +++ b/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 ***** diff --git a/src/internet/doc/routing-overview.rst b/src/internet/doc/routing-overview.rst index 12a32bce5..8c3d6c0b0 100644 --- a/src/internet/doc/routing-overview.rst +++ b/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 diff --git a/src/uan/doc/uan.rst b/src/uan/doc/uan.rst index 8ef7d1c9e..fe91ab848 100644 --- a/src/uan/doc/uan.rst +++ b/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 diff --git a/src/wifi/doc/source/wifi-design.rst b/src/wifi/doc/source/wifi-design.rst index 88cbcccd7..f1d62b5f1 100644 --- a/src/wifi/doc/source/wifi-design.rst +++ b/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 diff --git a/src/wifi/doc/source/wifi-user.rst b/src/wifi/doc/source/wifi-user.rst index 15d80a4c6..6d3e71b48 100644 --- a/src/wifi/doc/source/wifi-user.rst +++ b/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