diff --git a/README.md b/README.md
index ff9b22bd3..f8220d3db 100644
--- a/README.md
+++ b/README.md
@@ -41,19 +41,19 @@ use of these ns-3 libraries.
 
 To build the set of default libraries and the example
 programs included in this package, you need to use the
-tool 'waf'. Detailed information on how to use waf is
+tool 'ns3'. Detailed information on how to use ns3 is
 included in the file doc/build.txt
 
 However, the real quick and dirty way to get started is to
 type the command
 ```shell
-./waf configure --enable-examples
+./ns3 configure --enable-examples
 ```
 
 followed by
 
 ```shell
-./waf
+./ns3
 ```
 
 in the directory which contains this README file. The files
@@ -73,7 +73,7 @@ enabled), it should be easy to run the sample programs with the
 following command, such as:
 
 ```shell
-./waf --run simple-global-routing
+./ns3 --run simple-global-routing
 ```
 
 That program should generate a `simple-global-routing.tr` text
diff --git a/doc/build.txt b/doc/build.txt
index 087857980..1614ab121 100644
--- a/doc/build.txt
+++ b/doc/build.txt
@@ -1,107 +1,110 @@
-The Waf build system is used to build ns-3.  Waf is a Python-based
-build system (http://www.freehackers.org/~tnagy/waf.html)
+The CMake build system is used to build ns-3.  CMake is a
+meta-build system (https://cmake.org/)
 
 Note:  We've added a wiki page with more complete build instructions
 than the quick ones you find below:
 http://www.nsnam.org/wiki/Installation
 
-=== Installing Waf ===
+=== Installing CMake ===
 
-The top-level ns-3 directory should contain a current waf script, so
-there is no need to have WAF installed in the system.  We are using
-some extensions to WAF, which can be found in the 'waf-tools'
-directory. The upstream location for these WAF extensions is:
+To use CMake, you need to download it and install it. This can be done
+ via package managers available for your operating system, or directly
+ from the CMake page: https://cmake.org/download/.
 
-    https://code.launchpad.net/~gjc/waf/cmd
+CMake is a meta-build system that relies on an underlying build system.
+This build system is referred to as Generators by CMake
+(https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html),
+and include Makefiles, Ninja, XCode, Eclipse CDT4 and others.
+
+One of these must be installed for CMake to work.
 
 
-=== Building with Waf ===
+=== Building with ns3 ===
 
-To build ns-3 with waf type the commands from the top-level directory:
- 1. ./waf configure [options]
- 2. ./waf
+To build ns-3 with the ns3 CMake wrapper type the commands from the top-level directory:
+ 1. ./ns3 configure [options]
+ 2. ./ns3 build
 
-To see valid configure options, type ./waf --help.  The most important
+To see valid configure options, type ./ns3 --help.  The most important
 option is -d <debug level>.  Valid debug levels (which are listed in
-waf --help) are: "debug" or "optimized", with debug being default.  It is
+ns3 --help) are: "debug" or "optimized", with debug being default.  It is
 also possible to change the flags used for compilation with (e.g.):
-CXXFLAGS="-O3" ./waf configure.  By default, ns-3 is built as debug code, 
+CXXFLAGS="-O3" ./ns3 configure.  By default, ns-3 is built as debug code,
 with examples and tests disabled, and with python bindings enabled.  
 
 [ Note:  Unlike some other build tools, to change the build target,
 the option must be supplied during the configure stage rather than
-the build stage (i.e., "./waf -d optimized" will not work; instead, do
-"./waf -d optimized configure; ./waf" ]
+the build stage (i.e., "./ns3 build -d optimized" will not work; instead, do
+"./ns3 configure -d optimized; ./ns3 build" ]
 
 The resulting executables and libraries are placed in build/.
 
-Other waf usages include:
+Other ns3 usages include:
 
- 1. ./waf configure --enable-examples --enable-tests
+ 1. ./ns3 configure --enable-examples --enable-tests
     Turn on examples and tests.
 
- 2. ./waf configure --disable-python
+ 2. ./ns3 configure --disable-python
     Disable python bindings.
 
- 3. ./waf --doxygen
+ 3. ./ns3 --doxygen
     Run doxygen to generate documentation
 
- 4. ./waf --run "program [args]"
+ 4. ./ns3 --run "program [args]"
     Run a ns3 program, given its target name, with the given
     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.
 
- 4.1 ./waf --run programname --command-template "... %s ..."
+ 4.1 ./ns3 --run programname --command-template "... %s ..."
 
     Same as --run, but uses a command template with %s replaced by the
     actual program (whose name is given by --run).  This can be use to
     run ns-3 programs with helper tools.  For example, to run unit
     tests with valgrind, use the command:
 
-         ./waf --run run-tests --command-template "valgrind %s"
+         ./ns3 --run run-tests --command-template "valgrind %s"
 
- 5. ./waf --shell
+ 5. ./ns3 --shell
     Starts a nested system shell with modified environment to run ns3 programs.
 
- 6. ./waf distclean
+ 6. ./ns3 clean
     Cleans out the entire build/ directory
 
- 7. ./waf dist
-    The command 'waf dist' can be used to create a distribution tarball.
-    It includes all files in the source directory, except some particular
-    extensions that are blacklisted, such as back files (ending in ~).
 
 === Extending ns-3 ===
 
 To add new modules:
   1. Create the module directory under src;
   2. Add the source files to it;
-  3. Add a 'wscript' describing it;
+  3. Add a 'CMakeLists.txt' describing it;
 
 A convenience program to auto-generate the template of a new module can
 be found in src/create-module.py.
 
-A module's wscript file is basically a regular Waf script.  A ns-3
-module is created as a cpp/shlib object, like this:
+A ns-3 module is created as a cpp/shlib object, like this:
 
-def build(bld):
-    module = bld.create_ns3_module('ns3-mymodule', ['core'])
-    module.source = [
-        'model/ns3-mymodule.cc',
-        'helper/ns3-mymodule-helper.cc',
-        ]
+    set(name ns3-mymodule)
 
-    headers = bld.new_task_gen(features=['ns3header'])
-    headers.module = 'ns3-mymodule'
-    headers.source = [
-        'model/ns3-mymodule.h',
-        'helper/ns3-mymodule-helper.h',
-        ]
+    set(source_files
+        model/ns3-mymodule.cc
+        helper/ns3-mymodule-helper.cc
+        )
 
-    if bld.env.ENABLE_EXAMPLES:
-        bld.add_subdirs('examples')
+    set(header_files
+        model/ns3-mymodule.h
+        helper/ns3-mymodule-helper.h
+        )
+
+    set(libraries_to_link
+        libcore # lib prefix + module name
+        )
+
+    set(test_sources
+        test/test-mymodule.cc
+        )
+
+    build_lib("${name}" "${source_files}" "${header_files}" "${libraries_to_link}" "${test_sources}")
 
-    # bld.ns3_python_bindings()
 
diff --git a/doc/contributing/source/models.rst b/doc/contributing/source/models.rst
index 5254ad17b..14a3f11d2 100644
--- a/doc/contributing/source/models.rst
+++ b/doc/contributing/source/models.rst
@@ -25,7 +25,7 @@ Options for new models
 
 |ns3| is organized into modules, each of which is compiled and linked into
 a separate library.  Users can selectively enable and disable the inclusion
-of modules (via the `--enable-modules` argument to Waf configure, or via
+of modules (via the `--enable-modules` argument to ns3 configure, or via
 the selective inclusion of contributed modules).
 
 When proposing new models to |ns3|, please keep in mind that not all models
diff --git a/doc/doxygen.conf b/doc/doxygen.conf
index 465a9193e..83848f5f4 100644
--- a/doc/doxygen.conf
+++ b/doc/doxygen.conf
@@ -2196,7 +2196,7 @@ INCLUDE_FILE_PATTERNS  =
 ## ns-3:
 ##
 ## We predefine NS3_ASSERT_ENABLE and NS3_LOG_ENABLE so doxygen sees
-## the working definitions.  (These are normally defined by waf
+## the working definitions.  (These are normally defined by ns3
 ## in ns3/core-config.h)
 ##
 ## Function like macros at file global scope typically need to be here,
diff --git a/doc/main.h b/doc/main.h
index f6759955f..10e171db2 100644
--- a/doc/main.h
+++ b/doc/main.h
@@ -19,7 +19,7 @@
  * 
  * ns-3 requires Doxygen version 1.8.3.1 or greater.
  * 
- * Type "./waf --doxygen" or "./waf --doxygen-no-build" to build the 
+ * Type "./ns3 --doxygen" or "./ns3 --doxygen-no-build" to build the
  *  documentation.  The doc/ directory contains
  * configuration for Doxygen (doxygen.conf) and main.h.  The Doxygen 
  * build process puts html files into the doc/html/ directory, and latex 
@@ -91,7 +91,7 @@
  *
  * Enable asserts at compile time.
  *
- * This is normally set by `./waf configure --build-profile=debug`.
+ * This is normally set by `./ns3 configure --build-profile=debug`.
  */
 #define NS3_ASSERT_ENABLE
 
@@ -102,7 +102,7 @@
  *
  * Enable logging at compile time.
  *
- * This is normally set by `./waf configure --build-profile=debug`.
+ * This is normally set by `./ns3 configure --build-profile=debug`.
  */
 #define NS3_LOG_ENABLE
 
diff --git a/doc/manual/source/attributes.rst b/doc/manual/source/attributes.rst
index dacffb881..f916b0d04 100644
--- a/doc/manual/source/attributes.rst
+++ b/doc/manual/source/attributes.rst
@@ -617,7 +617,7 @@ output corresponding to the steps we took above:
 
 .. sourcecode:: bash
 
-    $ ./waf --run main-attribute-value
+    $ ./ns3 --run main-attribute-value
     1.  dtq limit: 80p
     2.  txQueue limit: 80p
     3.  txQueue limit changed: 60p
@@ -1218,7 +1218,7 @@ To check whether it is configured or not, check the output of the step:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
+  $ ./ns3 configure --enable-examples --enable-tests
 
   ---- Summary of optional NS-3 features:
   Python Bindings               : enabled
@@ -1231,8 +1231,8 @@ version is installed and:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3
 
 is rerun.
 
diff --git a/doc/manual/source/documentation.rst b/doc/manual/source/documentation.rst
index 28f44e941..c63e84085 100644
--- a/doc/manual/source/documentation.rst
+++ b/doc/manual/source/documentation.rst
@@ -23,7 +23,7 @@ To build all the standard documentation:
 
 .. sourcecode:: bash
 
-   $ ./waf docs
+   $ ./ns3 docs
 
 For more specialized options, read on.
 
@@ -132,7 +132,7 @@ To build all the Sphinx documentation:
 
 .. sourcecode:: bash
 
-   $ ./waf sphinx
+   $ ./ns3 sphinx
 
 To build just the Models documentation:
 
@@ -371,7 +371,7 @@ Building the Doxygen documentation is pretty simple:
 
 .. sourcecode:: bash
 
-   $ ./waf doxygen
+   $ ./ns3 doxygen
 
 This builds using the default configuration, which generates
 documentation sections for *all* items, even if they do not have
diff --git a/doc/manual/source/enable-modules.rst b/doc/manual/source/enable-modules.rst
index 76ff9373a..39b4a758d 100644
--- a/doc/manual/source/enable-modules.rst
+++ b/doc/manual/source/enable-modules.rst
@@ -27,29 +27,29 @@ will be built, too.  Other modules that the module depends on and their test lib
 
 By default, all modules are built in |ns3|.  There are two ways to enable a subset of these modules:
 
-#. Using waf's --enable-modules option
+#. Using ns3's --enable-modules option
 #. Using the |ns3| configuration file
 
-Enable modules using waf's --enable-modules option
+Enable modules using ns3's --enable-modules option
 ++++++++++++++++++++++++++++++++++++++++++++++++++
 
 To enable only the core module with example and tests, for example,
 try these commands: ::
 
-  $ ./waf clean
-  $ ./waf configure --enable-examples --enable-tests --enable-modules=core
-  $ ./waf build
-  $ cd build/debug/
+  $ ./ns3 clean
+  $ ./ns3 configure --enable-examples --enable-tests --enable-modules=core
+  $ ./ns3 build
+  $ cd build/lib
   $ ls
 
 and the following libraries should be present:
 
 .. sourcecode:: text
 
-  bindings  libns3-core.so       ns3      scratch  utils
-  examples  libns3-core-test.so  samples  src
+  libns3-core.so
+  libns3-core-test.so
 
-Note the ``./waf clean`` step is done here only to make it more obvious which module libraries were built.  You don't have to do ``./waf clean`` in order to enable subsets of modules.
+Note the ``./ns3 clean`` step is done here only to make it more obvious which module libraries were built.  You don't have to do ``./ns3 clean`` in order to enable subsets of modules.
 
 Running test.py will cause only those tests that depend on module core to be run:
  
@@ -61,8 +61,8 @@ Repeat the above steps for the "network" module instead of the "core" module, an
 
 .. sourcecode:: text
 
-  bindings  libns3-core.so       libns3-network.so       ns3      scratch  utils
-  examples  libns3-core-test.so  libns3-network-test.so  samples  src
+  libns3-core.so       libns3-network.so
+  libns3-core-test.so  libns3-network-test.so
 
 Running test.py will cause those tests that depend on only the core and network modules to be run:
 
@@ -81,7 +81,7 @@ When enabling a subset of |ns3| modules, the precedence rules are as follows:
 #. the .ns3rc file in the top level |ns3| directory is next consulted, if present
 #. the system searches for ~/.ns3rc if the above two are unspecified
 
-If none of the above limits the modules to be built, all modules that waf knows about will be built.
+If none of the above limits the modules to be built, all modules that CMake knows about will be built.
 
 The maintained version of the .ns3rc file in the |ns3| source code repository resides in the ``utils`` directory.  The reason for this is if it were in the top-level directory of the repository, it would be prone to accidental checkins from maintainers that enable the modules they want to use.  Therefore, users need to manually copy the .ns3rc from the ``utils`` directory to their preferred place (top level directory or their home directory) to enable persistent modular build configuration.
 
@@ -127,20 +127,20 @@ Use your favorite editor to modify the .ns3rc file to only enable the core modul
 
 Only the core module will be enabled now if you try these commands: ::
 
-  $ ./waf clean
-  $ ./waf configure
-  $ ./waf build
-  $ cd build/debug/
+  $ ./ns3 clean
+  $ ./ns3 configure
+  $ ./ns3 build
+  $ cd build/lib/
   $ ls
 
 and the following libraries should be present:
 
 .. sourcecode:: text
 
-  bindings  libns3-core.so       ns3      scratch  utils
-  examples  libns3-core-test.so  samples  src
+  libns3-core.so
+  libns3-core-test.so
 
-Note the ``./waf clean`` step is done here only to make it more obvious which module libraries were built.  You don't have to do ``./waf clean`` in order to enable subsets of modules.
+Note the ``./ns3 clean`` step is done here only to make it more obvious which module libraries were built.  You don't have to do ``./ns3 clean`` in order to enable subsets of modules.
 
 Running test.py will cause only those tests that depend on module core to be run:
  
@@ -152,8 +152,8 @@ Repeat the above steps for the "network" module instead of the "core" module, an
 
 .. sourcecode:: text
 
-  bindings  libns3-core.so       libns3-network.so       ns3      scratch  utils
-  examples  libns3-core-test.so  libns3-network-test.so  samples  src
+  libns3-core.so       libns3-network.so
+  libns3-core-test.so  libns3-network-test.so
 
 Running test.py will cause those tests that depend on only the core and network modules to be run:
 
diff --git a/doc/manual/source/enable-tests.rst b/doc/manual/source/enable-tests.rst
index 3325836a9..b17661c0e 100644
--- a/doc/manual/source/enable-tests.rst
+++ b/doc/manual/source/enable-tests.rst
@@ -15,7 +15,7 @@ How to enable/disable examples and tests in |ns3|
 There are 3 ways to enable/disable examples and tests in |ns3|:
 
 #. Using build.py when |ns3| is built for the first time
-#. Using waf once |ns3| has been built
+#. Using ns3 once |ns3| has been built
 #. Using the |ns3| configuration file once |ns3| has been built
 
 Enable/disable examples and tests using build.py
@@ -46,18 +46,18 @@ Running test.py in the top level |ns3| directory will cause all of the examples
 
   170 of 170 tests passed (170 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
 
-Enable/disable examples and tests using waf
+Enable/disable examples and tests using ns3
 +++++++++++++++++++++++++++++++++++++++++++
 
-You can use waf to enable/disable examples and tests once |ns3| has been built.
+You can use ns3 to enable/disable examples and tests once |ns3| has been built.
 
 By default, examples and tests are not built in |ns3|.  
 
 From the top level |ns3| directory, you can build |ns3| without any
 examples or tests simply by doing: ::
 
-  $ ./waf configure
-  $ ./waf build
+  $ ./ns3 configure
+  $ ./ns3 build
 
 Running test.py now will cause no examples or tests to be run:
  
@@ -67,8 +67,8 @@ Running test.py now will cause no examples or tests to be run:
 
 If you would like build |ns3| with examples and tests, then do the following from the top level |ns3| directory: ::
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
 
 Running test.py will cause all of the examples and tests to be run:
  
@@ -117,8 +117,8 @@ The .ns3rc file should now be in your top level |ns3| directory, and it contains
 From the top level |ns3| directory, you can build |ns3| without any
 examples or tests simply by doing: ::
 
-  $ ./waf configure
-  $ ./waf build
+  $ ./ns3 configure
+  $ ./ns3 build
 
 Running test.py now will cause no examples or tests to be run:
  
@@ -149,8 +149,8 @@ examples_enabled and tests_enabled file to be True:
 From the top level |ns3| directory, you can build |ns3| with examples
 and tests simply by doing: ::
 
-  $ ./waf configure
-  $ ./waf build
+  $ ./ns3 configure
+  $ ./ns3 build
 
 Running test.py will cause all of the examples and tests to be run:
  
diff --git a/doc/manual/source/gnuplot.rst b/doc/manual/source/gnuplot.rst
index 78dc77037..f8da4f899 100644
--- a/doc/manual/source/gnuplot.rst
+++ b/doc/manual/source/gnuplot.rst
@@ -36,7 +36,7 @@ In order to run this example, do the following:
 
 .. sourcecode:: bash
 
-  $ ./waf --run src/stats/examples/gnuplot-example
+  $ ./ns3 --run src/stats/examples/gnuplot-example
 
 This should produce the following gnuplot control files:
 
diff --git a/doc/manual/source/logging.rst b/doc/manual/source/logging.rst
index 3a5a1afe2..0ff691249 100644
--- a/doc/manual/source/logging.rst
+++ b/doc/manual/source/logging.rst
@@ -49,7 +49,7 @@ first is by setting the ``NS_LOG`` environment variable; e.g.:
 
 .. sourcecode:: bash
 
-   $ NS_LOG="*" ./waf --run first
+   $ NS_LOG="*" ./ns3 --run first
 
 will run the ``first`` tutorial program with all logging output.  (The
 specifics of the ``NS_LOG`` format will be discussed below.)
@@ -58,7 +58,7 @@ This can be made more granular by selecting individual components:
 
 .. sourcecode:: bash
 
-   $ NS_LOG="Ipv4L3Protocol" ./waf --run first
+   $ NS_LOG="Ipv4L3Protocol" ./ns3 --run first
 
 The output can be further tailored with prefix options.
   
@@ -115,7 +115,7 @@ To see what log components are defined, any of these will work:
 
 .. sourcecode:: bash
 
-   $ NS_LOG="print-list" ./waf --run ...
+   $ NS_LOG="print-list" ./ns3 --run ...
 
    $ NS_LOG="foo"  # a token not matching any log-component
 
@@ -253,7 +253,7 @@ class (``|prefix_level``).
 
 .. sourcecode:: bash
 
-   $ NS_LOG="*=all|prefix_level" ./waf --run scratch-simulator
+   $ NS_LOG="*=all|prefix_level" ./ns3 --run scratch-simulator
    Scratch Simulator
    [ERROR] error message
    [WARN] warn message
diff --git a/doc/manual/source/new-models.rst b/doc/manual/source/new-models.rst
index cb53ee78e..982644cf8 100644
--- a/doc/manual/source/new-models.rst
+++ b/doc/manual/source/new-models.rst
@@ -187,16 +187,16 @@ In the case of the error model, it is very related to the packet class, so it
 makes sense to implement this in the ``src/network/`` module where |ns3|
 packets are implemented.  
 
-`waf` and `wscript`
+`cmake` and `CMakeLists.txt`
 +++++++++++++++++++
 
-|ns3| uses the `Waf <http://www.freehackers.org/~tnagy/waf.html>`_ build system.
-You will want to integrate your new |ns3| uses the Waf build system. You will
+|ns3| uses the `CMake <https://cmake.org/>`_ build system.
+You will want to integrate your new |ns3| uses the CMake build system. You will
 want to integrate your new source files into this system. This requires that you
-add your files to the ``wscript`` file found in each directory.  
+add your files to the ``CMakeLists.txt`` file found in each directory.
 
 Let's start with empty files error-model.h and error-model.cc, and add this to
-``src/network/wscript``. It is really just a matter of adding the .cc file to the
+``src/network/CMakeLists.txt``. It is really just a matter of adding the .cc file to the
 rest of the source files, and the .h file to the list of the header files. 
 
 Now, pop up to the top level directory and type "./test.py".  You
diff --git a/doc/manual/source/new-modules.rst b/doc/manual/source/new-modules.rst
index ace02c6cb..710cfaf6d 100644
--- a/doc/manual/source/new-modules.rst
+++ b/doc/manual/source/new-modules.rst
@@ -96,7 +96,7 @@ and ``.rst`` files.  The complete module with skeleton files looks like this:
 :ref:`Step-0 <Step-0>` will be created automatically during
 the build.)
 
-We next walk through how to customize this module.  Informing ``waf``
+We next walk through how to customize this module.  Informing ``ns3``
 about the files which make up your module is done by editing the two
 ``wscript`` files.  We will walk through the main steps in this chapter.
 
@@ -104,7 +104,7 @@ All |ns3| modules depend on the ``core`` module and usually on
 other modules.  This dependency is specified in the ``wscript`` file
 (at the top level of the module, not the separate ``wscript`` file
 in the ``examples`` directory!).  In the skeleton ``wscript``
-the call that will declare your new module to ``waf`` will look
+the call that will declare your new module to ``ns3`` will look
 like this (before editing):
 
 .. sourcecode:: python
@@ -192,7 +192,7 @@ also should be specified in the ``wscript`` file.
 Continuing with the ``spectrum`` model illustration,
 the public header files are specified with the following stanza.
 (Note that the argument to the ``bld`` function tells
-``waf`` to install this module's headers with the other |ns3| headers):
+``ns3`` to install this module's headers with the other |ns3| headers):
 
 .. sourcecode:: python
 
@@ -269,7 +269,7 @@ The ``spectrum`` model defines it's first example in
 Note that the second argument to the function ``create_ns3_program()``
 is the list of modules that the program being created depends on; again,
 don't forget to include ``new-module`` in the list.  It's best practice
-to list only the direct module dependencies, and let ``waf`` deduce
+to list only the direct module dependencies, and let ``ns3`` deduce
 the full dependency tree.
 
 Occasionally, for clarity, you may want to split the implementation
@@ -337,7 +337,7 @@ contains the tuple ``(example_name, do_run, do_valgrind_run)``, where
     crashes with some tests when they are run under valgrind.)
 
 Note that the two conditions are Python statements that
-can depend on ``waf`` configuration variables.  For example,
+can depend on ``ns3`` configuration variables.  For example,
 
 .. sourcecode:: python
 
@@ -350,7 +350,7 @@ Each entry in the Python list of examples to run contains the tuple
   * ``do_run`` is a condition under which to run the example.
 
 Again, the condition is a Python statement that can
-depend on ``waf`` configuration variables.  For example,
+depend on ``ns3`` configuration variables.  For example,
 
 .. sourcecode:: python
 
@@ -361,14 +361,14 @@ Step 8 - Configure and Build
 ****************************
 
 You can now configure, build and test your module as normal.
-You must reconfigure the project as a first step so that ``waf``
+You must reconfigure the project as a first step so that ``ns3``
 caches the new information in your ``wscript`` files,
 or else your new module will not be included in the build.
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py
 
 Look for your new module's test suite (and example programs,
diff --git a/doc/manual/source/python.rst b/doc/manual/source/python.rst
index 890c69d6f..597ee9c57 100644
--- a/doc/manual/source/python.rst
+++ b/doc/manual/source/python.rst
@@ -25,15 +25,15 @@ Python, to allow integration of |ns3| with other Python tools and workflows.
 The intent is not to provide a different language choice to author new
 |ns3| models implemented in Python.
 
-Python bindings for |ns3| use a tool called PyBindGen (https://github.com/gjcarneiro/pybindgen) to create Python modules from the C++ libraries built by
-Waf.  The Python bindings that PyBindGen uses are maintained in a 
-``bindings`` directory in each module, and must be maintained to match the 
+Python bindings for |ns3| use a tool called PyBindGen (https://github.com/gjcarneiro/pybindgen)
+to create Python modules from the C++ libraries built by CMake.  The Python bindings that PyBindGen
+uses are maintained in a ``bindings`` directory in each module, and must be maintained to match the
 C++ API of that ns-3 module.  If the C++ API changes, the Python bindings file
 must either be modified by hand accordingly, or the bindings must be
 regenerated by an automated scanning process.
 
 If a user is not interested in Python, he or she may disable the use of
-Python bindings at Waf configure time.  In this case, changes to the C++
+Python bindings at CMake configure time.  In this case, changes to the C++
 API of a provided module will not cause the module to fail to compile. 
 
 The process for automatically generating Python bindings relies on a toolchain
@@ -96,18 +96,18 @@ Here is some example code that is written in Python and that runs |ns3|, which i
 Running Python Scripts
 **********************
 
-waf contains some options that automatically update the python path to find the ns3 module.  To run example programs, there are two ways to use waf to take care of this.  One is to run a waf shell; e.g.:
+ns3 contains some options that automatically update the python path to find the ns3 module.  To run example programs, there are two ways to use ns3 to take care of this.  One is to run a ns3 shell; e.g.:
 
 .. sourcecode:: bash
 
-  $ ./waf shell
+  $ ./ns3 shell
   $ python examples/wireless/mixed-wireless.py
 
-and the other is to use the --pyrun option to waf:
+and the other is to use the --pyrun option to ns3:
 
 .. sourcecode:: bash
 
-  $ ./waf --pyrun examples/wireless/mixed-wireless.py
+  $ ./ns3 --pyrun examples/wireless/mixed-wireless.py
 
 As of ns-3.30, a --pyrun-no-build option was added to allow the running of
 a program without invoking a project rebuild.  This option may be useful
@@ -117,20 +117,20 @@ different arguments, such as from scripts. It can be used in place of
 
 .. sourcecode:: bash
 
-  $ ./waf --pyrun-no-build examples/wireless/mixed-wireless.py
+  $ ./ns3 --pyrun-no-build examples/wireless/mixed-wireless.py
 
 To run a python script under the C debugger:
 
 .. sourcecode:: bash
 
-  $ ./waf shell
+  $ ./ns3 shell
   $ gdb --args python examples/wireless/mixed-wireless.py
 
 To run your own Python script that calls |ns3| and that has this path, ``/path/to/your/example/my-script.py``, do the following:
 
 .. sourcecode:: bash
 
-  $ ./waf shell
+  $ ./ns3 shell
   $ python /path/to/your/example/my-script.py
 
 Caveats
@@ -251,7 +251,7 @@ If something goes wrong with compiling Python bindings and you just want to igno
 
 .. sourcecode:: bash
 
-  $ ./waf configure --disable-python ...
+  $ ./ns3 configure --disable-python ...
 
 To add support for modular bindings to an existing or new |ns3| module, simply add the following line to its wscript build() function:
 
@@ -451,7 +451,7 @@ C++ code), it will report a failure instead:
 At this point, it is recommended to change into the ns-3-dev directory and
 work further from there, because the API scanning dependencies have been
 built and installed successfully into the `build` directory.
-The output of './waf configure' can be inspected to see if Python API scanning
+The output of './ns3 configure' can be inspected to see if Python API scanning
 support is enabled:
 
 .. sourcecode:: text
@@ -484,7 +484,7 @@ a 'long' (LP64) or 'long long' (ILP32).
 
 The process (only supported on Linux at present) generates the LP64
 bindings using the toolchain and then copies the LP64 bindings to the
-ILP32 bindings with some type substitutions automated by Waf scripts.
+ILP32 bindings with some type substitutions automated by CMake scripts.
   
 Rescanning a module
 ###################
@@ -494,14 +494,14 @@ To re-scan a module:
 .. sourcecode:: bash
 
     $ cd source/ns-3-dev
-    $ ./waf --apiscan=wifi
+    $ ./ns3 --apiscan=wifi
 
 To re-scan all modules:
 
 .. sourcecode:: bash
 
     $ cd source/ns-3-dev
-    $ ./waf --apiscan=all
+    $ ./ns3 --apiscan=all
 
 Generating bindings on MacOS
 ############################
diff --git a/doc/manual/source/random-variables.rst b/doc/manual/source/random-variables.rst
index 951d089cc..368479cfc 100644
--- a/doc/manual/source/random-variables.rst
+++ b/doc/manual/source/random-variables.rst
@@ -183,16 +183,16 @@ variable as follows:
 
 .. sourcecode:: bash
 
-  $ NS_GLOBAL_VALUE="RngRun=3" ./waf --run program-name
+  $ NS_GLOBAL_VALUE="RngRun=3" ./ns3 --run program-name
 
 Another way to control this is by passing a command-line argument; since this is
 an |ns3| GlobalValue instance, it is equivalently done such as follows:
 
 .. sourcecode:: bash
 
-  $ ./waf --command-template="%s --RngRun=3" --run program-name
+  $ ./ns3 --command-template="%s --RngRun=3" --run program-name
 
-or, if you are running programs directly outside of waf:
+or, if you are running programs directly outside of ns3:
 
 .. sourcecode:: bash
 
diff --git a/doc/manual/source/realtime.rst b/doc/manual/source/realtime.rst
index 0d22982e0..7ac0ee792 100644
--- a/doc/manual/source/realtime.rst
+++ b/doc/manual/source/realtime.rst
@@ -66,7 +66,7 @@ has an example of how to configure the realtime behavior.  Try:
 
 .. sourcecode:: bash
 
-    $ ./waf --run realtime-udp-echo
+    $ ./ns3 --run realtime-udp-echo
 
 Whether the simulator will work in a best effort or hard limit policy fashion is
 governed by the attributes explained in the previous section.
diff --git a/doc/manual/source/test-framework.rst b/doc/manual/source/test-framework.rst
index d2dc67f3d..8d5b73a8d 100644
--- a/doc/manual/source/test-framework.rst
+++ b/doc/manual/source/test-framework.rst
@@ -65,8 +65,8 @@ have been built by doing the following
 
 ::
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
 
 By default, ``test.py`` will run all available tests and report status
 back in a very concise form.  Running the command
@@ -129,7 +129,7 @@ if you run ``test.py --help`` you should see a command summary like:
     -l, --list            print the list of known tests
     -m, --multiple        report multiple failures from test suites and test
                           cases
-    -n, --nowaf           do not run waf before starting testing
+    -n, --nobuild           do not run ns3 before starting testing
     -p PYEXAMPLE, --pyexample=PYEXAMPLE
                           specify a single python example to run (with relative
                           path)
@@ -377,12 +377,12 @@ if the example has been configured or not, it will just try to run it and
 report the result of the attempt.
 
 When ``test.py`` runs, by default it will first ensure that the system has
-been completely built.  This can be defeated by selecting the ``--nowaf``
+been completely built.  This can be defeated by selecting the ``--nobuild``
 option.
 
 ::
 
-  $ ./test.py --list --nowaf
+  $ ./test.py --list --nobuild
 
 will result in a list of the currently built test suites being displayed, similar to:
 
@@ -395,7 +395,7 @@ will result in a list of the currently built test suites being displayed, simila
   object-name-service
   random-variable-stream-generators
 
-Note the absence of the ``Waf`` build messages.
+Note the absence of the ``ns3`` build messages.
 
 ``test.py`` also supports running the test suites and examples under valgrind.
 Valgrind is a flexible program for debugging and profiling Linux executables.  By
@@ -529,7 +529,7 @@ stage, and also (optionally) examples if examples are to be checked:
 
 ::
 
-   $ ./waf --configure --enable-examples --enable-tests
+   $ ./ns3 --configure --enable-examples --enable-tests
 
 Then, build |ns3|, and after it is built, just run ``test.py``.  ``test.py -h``
 will show a number of configuration options that modify the behavior
@@ -555,9 +555,9 @@ executable. Hence, if you want to see logging output from your tests, you
 have to run them using the test-runner directly.
 
 In order to execute the test-runner, you run it like any other |ns3| executable
--- using ``waf``.  To get a list of available options, you can type::
+-- using ``ns3``.  To get a list of available options, you can type::
 
-  $ ./waf --run "test-runner --help"
+  $ ./ns3 --run "test-runner --help"
 
 You should see something like the following
 
@@ -611,7 +611,7 @@ option something like,
 
 ::
 
-  $ ./waf shell
+  $ ./ns3 shell
   $ cd build/utils
   $ gdb ns3-dev-test-runner-debug
   $ run --suite=global-value --assert-on-failure
@@ -621,14 +621,14 @@ generated and the (source level) debugger would stop at the ``NS_TEST_ASSERT_MSG
 that detected the error.
 
 To run one of the tests directly from the test-runner
-using ``waf``, you will need to specify the test suite to run.
+using ``ns3``, you will need to specify the test suite to run.
 So you could use the shell and do::
 
-  $ ./waf --run "test-runner --suite=pcap-file"
+  $ ./ns3 --run "test-runner --suite=pcap-file"
 
 |ns3| logging is available when you run it this way, such as:
 
-  $ NS_LOG="Packet" ./waf --run "test-runner --suite=pcap-file"
+  $ NS_LOG="Packet" ./ns3 --run "test-runner --suite=pcap-file"
 
 Test output
 +++++++++++
@@ -676,7 +676,7 @@ Try,
 
 ::
 
-  $ ./waf --run "test-runner --suite=pcap-file --out=myfile.txt"
+  $ ./ns3 --run "test-runner --suite=pcap-file --out=myfile.txt"
 
 
 Debugging test suite failures
@@ -692,7 +692,7 @@ You can access the underlying test-runner program via gdb as follows, and
 then pass the "--basedir=`pwd`" argument to run (you can also pass other
 arguments as needed, but basedir is the minimum needed)::
 
-  $ ./waf --command-template="gdb %s" --run "test-runner"
+  $ ./ns3 --command-template="gdb %s" --run "test-runner"
   Waf: Entering directory `/home/tomh/hg/sep09/ns-3-allinone/ns-3-dev-678/build'
   Waf: Leaving directory `/home/tomh/hg/sep09/ns-3-allinone/ns-3-dev-678/build'
   'build' finished successfully (0.380s)
@@ -714,7 +714,7 @@ such as::
 
   VALGR: TestSuite devices-mesh-dot11s-regression
 
-  $ ./waf --command-template="valgrind %s --suite=devices-mesh-dot11s-regression" --run test-runner
+  $ ./ns3 --command-template="valgrind %s --suite=devices-mesh-dot11s-regression" --run test-runner
 
 Class TestRunner
 ****************
diff --git a/doc/manual/source/troubleshoot.rst b/doc/manual/source/troubleshoot.rst
index 5e8d24850..7d8b6d78e 100644
--- a/doc/manual/source/troubleshoot.rst
+++ b/doc/manual/source/troubleshoot.rst
@@ -23,7 +23,7 @@ values are unexpectedly null.
 
 Here is an example of what might occur::
 
-    $ ./waf --run tcp-point-to-point
+    $ ./ns3 --run tcp-point-to-point
     Entering directory '/home/tomh/ns-3-nsc/build'
     Compilation finished successfully 
     Command ['/home/tomh/ns-3-nsc/build/debug/examples/tcp-point-to-point'] exited with code -11 
@@ -35,7 +35,7 @@ closely, try running it under the `gdb debugger
 
 .. sourcecode:: bash
 
-    $ ./waf --run tcp-point-to-point --gdb
+    $ ./ns3 --run tcp-point-to-point --gdb
     Entering directory '/home/tomh/ns-3-nsc/build'
     Compilation finished successfully 
     GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
@@ -84,4 +84,4 @@ Sometimes you may need to use the `valgrind memory checker
 <http://valgrind.org>`_ for more subtle errors. Again, you invoke the use of
 valgrind similarly::
 
-    $ ./waf --run tcp-point-to-point --valgrind
+    $ ./ns3 --run tcp-point-to-point --valgrind
diff --git a/doc/manual/source/utilities.rst b/doc/manual/source/utilities.rst
index 6a8eab751..1b12a5708 100644
--- a/doc/manual/source/utilities.rst
+++ b/doc/manual/source/utilities.rst
@@ -35,25 +35,25 @@ To run it, simply open terminal and type
 
 .. sourcecode:: bash
 
-    $ ./waf --run print-introspected-doxygen
+    $ ./ns3 --run print-introspected-doxygen
 
 This will give all the output, formatted for Doxygen, which can be viewed
 in a text editor.
 
 One way to use this is to capture it to a file::
 
-    $ ./waf --run print-introspected-doxygen > doc.html
+    $ ./ns3 --run print-introspected-doxygen > doc.html
 
 Some users might prefer to use tools like grep
 to locate the required piece of information from the documentation
 instead of using an editor. For such uses-cases and more,
 `print-introspected-doxygen` can return plain text::
 
-    $ ./waf --run "print-introspected-doxygen --output-text"
+    $ ./ns3 --run "print-introspected-doxygen --output-text"
 
 (Note the quotes around the inner command and options.)
 
-    $ ./waf --run "print-introspected-doxygen --output-text" | grep "hello" 
+    $ ./ns3 --run "print-introspected-doxygen --output-text" | grep "hello"
 
 This will output the following::
 
@@ -80,7 +80,7 @@ Command-line Arguments
 
 .. sourcecode:: bash
 
-    $ ./waf --run "bench-simulator --help"
+    $ ./ns3 --run "bench-simulator --help"
 
     Program Options:
 	--cal:    use CalendarSheduler [false]
@@ -115,7 +115,7 @@ To run it, simply open the terminal and type
 
 .. sourcecode:: bash
 
-    $ ./waf --run bench-simulator
+    $ ./ns3 --run bench-simulator
     
 It will show something like this depending upon the scheduler being benchmarked::
 
@@ -137,7 +137,7 @@ Suppose we had to benchmark `CalendarScheduler` instead, we would have written
 
 .. sourcecode:: bash
 
-    $ ./waf --run "bench-simulator --cal"
+    $ ./ns3 --run "bench-simulator --cal"
  
 And the output would look something like this::
 
diff --git a/doc/ns3_html_theme/get_version.sh b/doc/ns3_html_theme/get_version.sh
index 7abd925bd..eae7c45e6 100755
--- a/doc/ns3_html_theme/get_version.sh
+++ b/doc/ns3_html_theme/get_version.sh
@@ -27,7 +27,7 @@
 #     run by cron jobs.)
 #
 # If both a and b are true, we're building for public urls.
-# (The newer update-docs script (through waf) sets
+# (The newer update-docs script (through ns3) sets
 # NS3_WWW_URLS=public explicitly.)
 # 
 # The repo version is either a tag name or a commit (short) id.
diff --git a/doc/release_steps.txt b/doc/release_steps.txt
index 86af22d62..75938964a 100644
--- a/doc/release_steps.txt
+++ b/doc/release_steps.txt
@@ -29,15 +29,15 @@ This step presumes that you have a reasonably solid ns-3-dev that you
 and/or the buildbots have been testing
    - building static, optimized, and debug versions
    - try Python visualizer (not tested by buildbots)
-      -- ./waf --pyrun src/flow-monitor/examples/wifi-olsr-flowmon.py --vis
+      -- ./ns3 --pyrun src/flow-monitor/examples/wifi-olsr-flowmon.py --vis
    - ensure that tests pass (./test.py -g) and make sure that the buildbots
      are reporting 'pass' state, based on the tip of the repository
    - revise and check in AUTHORS, RELEASE_NOTES.md, and CHANGES.html
    - required versions for related libraries (netanim, pybindgen)
      are correct
-   - confirm that Doxygen builds cleanly (./waf doxygen), 
+   - confirm that Doxygen builds cleanly (./ns3 doxygen),
    - confirm that the new bake configurations for the release work correctly
-   - confirm all documents build:  './waf docs' and check outputs
+   - confirm all documents build:  './ns3 docs' and check outputs
 
 2.1)  Update the tutorial "Getting Started" and "Quick Start" pages to use the new release number.
 
diff --git a/doc/tutorial/figures/clion/build_targets.png b/doc/tutorial/figures/clion/build_targets.png
new file mode 100644
index 000000000..ae540e587
Binary files /dev/null and b/doc/tutorial/figures/clion/build_targets.png differ
diff --git a/doc/tutorial/figures/clion/cmake_configuration.png b/doc/tutorial/figures/clion/cmake_configuration.png
new file mode 100644
index 000000000..46bbf81e4
Binary files /dev/null and b/doc/tutorial/figures/clion/cmake_configuration.png differ
diff --git a/doc/tutorial/figures/clion/reload_cache.png b/doc/tutorial/figures/clion/reload_cache.png
new file mode 100644
index 000000000..533a721a6
Binary files /dev/null and b/doc/tutorial/figures/clion/reload_cache.png differ
diff --git a/doc/tutorial/figures/clion/run_target.png b/doc/tutorial/figures/clion/run_target.png
new file mode 100644
index 000000000..0598f5a7a
Binary files /dev/null and b/doc/tutorial/figures/clion/run_target.png differ
diff --git a/doc/tutorial/figures/clion/toolchains.png b/doc/tutorial/figures/clion/toolchains.png
new file mode 100644
index 000000000..8dda3a55f
Binary files /dev/null and b/doc/tutorial/figures/clion/toolchains.png differ
diff --git a/doc/tutorial/figures/codeblocks/breakpoint_and_debug.png b/doc/tutorial/figures/codeblocks/breakpoint_and_debug.png
new file mode 100644
index 000000000..6141af634
Binary files /dev/null and b/doc/tutorial/figures/codeblocks/breakpoint_and_debug.png differ
diff --git a/doc/tutorial/figures/codeblocks/build_finished_breakpoint_waiting.png b/doc/tutorial/figures/codeblocks/build_finished_breakpoint_waiting.png
new file mode 100644
index 000000000..44c0c0bb8
Binary files /dev/null and b/doc/tutorial/figures/codeblocks/build_finished_breakpoint_waiting.png differ
diff --git a/doc/tutorial/figures/codeblocks/compiler_detection.png b/doc/tutorial/figures/codeblocks/compiler_detection.png
new file mode 100644
index 000000000..ad7094ba4
Binary files /dev/null and b/doc/tutorial/figures/codeblocks/compiler_detection.png differ
diff --git a/doc/tutorial/figures/codeblocks/debug_watches.png b/doc/tutorial/figures/codeblocks/debug_watches.png
new file mode 100644
index 000000000..ed00463e1
Binary files /dev/null and b/doc/tutorial/figures/codeblocks/debug_watches.png differ
diff --git a/doc/tutorial/figures/codeblocks/landing.png b/doc/tutorial/figures/codeblocks/landing.png
new file mode 100644
index 000000000..896d163a6
Binary files /dev/null and b/doc/tutorial/figures/codeblocks/landing.png differ
diff --git a/doc/tutorial/figures/codeblocks/open_project.png b/doc/tutorial/figures/codeblocks/open_project.png
new file mode 100644
index 000000000..9924ea59e
Binary files /dev/null and b/doc/tutorial/figures/codeblocks/open_project.png differ
diff --git a/doc/tutorial/figures/vscode/configure_ns3.png b/doc/tutorial/figures/vscode/configure_ns3.png
new file mode 100644
index 000000000..49531dad1
Binary files /dev/null and b/doc/tutorial/figures/vscode/configure_ns3.png differ
diff --git a/doc/tutorial/figures/vscode/debugging.png b/doc/tutorial/figures/vscode/debugging.png
new file mode 100644
index 000000000..864aaab3e
Binary files /dev/null and b/doc/tutorial/figures/vscode/debugging.png differ
diff --git a/doc/tutorial/figures/vscode/enable_examples_and_save_to_reload_cache.png b/doc/tutorial/figures/vscode/enable_examples_and_save_to_reload_cache.png
new file mode 100644
index 000000000..ef276a1e7
Binary files /dev/null and b/doc/tutorial/figures/vscode/enable_examples_and_save_to_reload_cache.png differ
diff --git a/doc/tutorial/figures/vscode/install_cmake_tools.png b/doc/tutorial/figures/vscode/install_cmake_tools.png
new file mode 100644
index 000000000..0e9e56983
Binary files /dev/null and b/doc/tutorial/figures/vscode/install_cmake_tools.png differ
diff --git a/doc/tutorial/figures/vscode/install_cpp_tools.png b/doc/tutorial/figures/vscode/install_cpp_tools.png
new file mode 100644
index 000000000..925262fba
Binary files /dev/null and b/doc/tutorial/figures/vscode/install_cpp_tools.png differ
diff --git a/doc/tutorial/figures/vscode/open_cmake_cache.png b/doc/tutorial/figures/vscode/open_cmake_cache.png
new file mode 100644
index 000000000..9115ca53e
Binary files /dev/null and b/doc/tutorial/figures/vscode/open_cmake_cache.png differ
diff --git a/doc/tutorial/figures/vscode/open_project.png b/doc/tutorial/figures/vscode/open_project.png
new file mode 100644
index 000000000..50c24d26d
Binary files /dev/null and b/doc/tutorial/figures/vscode/open_project.png differ
diff --git a/doc/tutorial/figures/vscode/select_target_build_and_debug.png b/doc/tutorial/figures/vscode/select_target_build_and_debug.png
new file mode 100644
index 000000000..a200c6c83
Binary files /dev/null and b/doc/tutorial/figures/vscode/select_target_build_and_debug.png differ
diff --git a/doc/tutorial/figures/xcode/create_schemes.png b/doc/tutorial/figures/xcode/create_schemes.png
new file mode 100644
index 000000000..41ac3ab25
Binary files /dev/null and b/doc/tutorial/figures/xcode/create_schemes.png differ
diff --git a/doc/tutorial/figures/xcode/debug_permission_to_attach.png b/doc/tutorial/figures/xcode/debug_permission_to_attach.png
new file mode 100644
index 000000000..3ad37a813
Binary files /dev/null and b/doc/tutorial/figures/xcode/debug_permission_to_attach.png differ
diff --git a/doc/tutorial/figures/xcode/profiling_stack_watches_output.png b/doc/tutorial/figures/xcode/profiling_stack_watches_output.png
new file mode 100644
index 000000000..68b458e04
Binary files /dev/null and b/doc/tutorial/figures/xcode/profiling_stack_watches_output.png differ
diff --git a/doc/tutorial/figures/xcode/select_command_line.png b/doc/tutorial/figures/xcode/select_command_line.png
new file mode 100644
index 000000000..6eecb6cba
Binary files /dev/null and b/doc/tutorial/figures/xcode/select_command_line.png differ
diff --git a/doc/tutorial/figures/xcode/select_target_and_build.png b/doc/tutorial/figures/xcode/select_target_and_build.png
new file mode 100644
index 000000000..d5601ac24
Binary files /dev/null and b/doc/tutorial/figures/xcode/select_target_and_build.png differ
diff --git a/doc/tutorial/figures/xcode/target_dropdown.png b/doc/tutorial/figures/xcode/target_dropdown.png
new file mode 100644
index 000000000..e909adfca
Binary files /dev/null and b/doc/tutorial/figures/xcode/target_dropdown.png differ
diff --git a/doc/tutorial/source/building-topologies.rst b/doc/tutorial/source/building-topologies.rst
index 584f8b8a0..64001f87c 100644
--- a/doc/tutorial/source/building-topologies.rst
+++ b/doc/tutorial/source/building-topologies.rst
@@ -335,14 +335,14 @@ the ``first.cc`` example.
   }
 
 In order to run this example, copy the ``second.cc`` example script into 
-the scratch directory and use waf to build just as you did with
+the scratch directory and use ns3 to build just as you did with
 the ``first.cc`` example.  If you are in the top-level directory of the
 repository you just type,
 
 .. sourcecode:: bash
 
   $ cp examples/tutorial/second.cc scratch/mysecond.cc
-  $ ./waf
+  $ ./ns3
 
 Warning:  We use the file ``second.cc`` as one of our regression tests to
 verify that it works exactly as we think it should in order to make your
@@ -358,7 +358,7 @@ run the program.
 .. sourcecode:: bash
 
   $ export NS_LOG=
-  $ ./waf --run scratch/mysecond
+  $ ./ns3 --run scratch/mysecond
 
 Since we have set up the UDP echo applications to log just as we did in 
 ``first.cc``, you will see similar output when you run the script.
@@ -540,7 +540,7 @@ devices set to four:
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/mysecond --nCsma=4"
+  $ ./ns3 --run "scratch/mysecond --nCsma=4"
 
 You should now see,
 
@@ -615,7 +615,7 @@ If you build the new script and run the simulation setting ``nCsma`` to 100,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/mysecond --nCsma=100"
+  $ ./ns3 --run "scratch/mysecond --nCsma=100"
 
 you will see the following output:
 
@@ -1180,15 +1180,14 @@ Finally, we actually run the simulation, clean up and then exit the program.
   }
 
 In order to run this example, you have to copy the ``third.cc`` example
-script into the scratch directory and use Waf to build just as you did with
+script into the scratch directory and use CMake to build just as you did with
 the ``second.cc`` example.  If you are in the top-level directory of the
 repository you would type,
 
 .. sourcecode:: bash
 
   $ cp examples/tutorial/third.cc scratch/mythird.cc
-  $ ./waf
-  $ ./waf --run scratch/mythird
+  $ ./ns3 --run scratch/mythird
 
 Again, since we have set up the UDP echo applications just as we did in the 
 ``second.cc`` script, you will see similar output.
diff --git a/doc/tutorial/source/conceptual-overview.rst b/doc/tutorial/source/conceptual-overview.rst
index 4232ff2be..357582d2e 100644
--- a/doc/tutorial/source/conceptual-overview.rst
+++ b/doc/tutorial/source/conceptual-overview.rst
@@ -157,11 +157,11 @@ directory structure something like the following:
 
 .. sourcecode:: bash
 
-  AUTHORS          doc        RELEASE_NOTES.md  utils     waf-tools
-  bindings         examples   scratch           utils.py  wscript
-  CHANGES.html     LICENSE    src               VERSION   wutils.py
-  contrib          Makefile   test.py           waf
-  CONTRIBUTING.md  README.md  testpy.supp       waf.bat
+  AUTHORS          doc        RELEASE_NOTES.md  utils
+  bindings         examples   scratch           utils.py
+  CHANGES.html     LICENSE    src               VERSION
+  contrib          Makefile   test.py           
+  CONTRIBUTING.md  README.md  testpy.supp
 
 Change into the ``examples/tutorial`` directory.  You should see a file named 
 ``first.cc`` located there.  This is a script that will create a simple
@@ -242,10 +242,10 @@ Each of the |ns3| include files is placed in a directory called
 include file name collisions.  The ``ns3/core-module.h`` file corresponds 
 to the ns-3 module you will find in the directory ``src/core`` in your 
 downloaded release distribution.  If you list this directory you will find a
-large number of header files.  When you do a build, Waf will place public 
+large number of header files.  When you do a build, ns3 will place public
 header files in an ``ns3`` directory under the appropriate 
 ``build/debug`` or ``build/optimized`` directory depending on your 
-configuration.  Waf will also automatically generate a module include file to
+configuration.  CMake will also automatically generate a module include file to
 load all of the public header files.
 
 Since you are, of course, following this tutorial religiously, you will 
@@ -253,17 +253,17 @@ already have done a
 
 .. sourcecode:: bash
 
-  $ ./waf -d debug --enable-examples --enable-tests configure
+  $ ./ns3 configure -d debug --enable-examples --enable-tests
 
 in order to configure the project to perform debug builds that include 
 examples and tests.  You will also have done a
 
 .. sourcecode:: bash
 
-  $ ./waf
+  $ ./ns3 build
 
 to build the project.  So now if you look in the directory 
-``../../build/debug/ns3`` you will find the four module include files shown 
+``../../build/include/ns3`` you will find the four module include files shown
 above.  You can take a look at the contents of these files and find that they
 do include all of the public include files in their respective modules.
 
@@ -813,7 +813,7 @@ Building Your Script
 ++++++++++++++++++++
 We have made it trivial to build your simple scripts.  All you have to do is 
 to drop your script into the scratch directory and it will automatically be 
-built if you run Waf.  Let's try it.  Copy ``examples/tutorial/first.cc`` into 
+built if you run ns3.  Let's try it.  Copy ``examples/tutorial/first.cc`` into
 the ``scratch`` directory after changing back into the top level directory.
 
 .. sourcecode:: bash
@@ -821,11 +821,11 @@ the ``scratch`` directory after changing back into the top level directory.
   $ cd ../..
   $ cp examples/tutorial/first.cc scratch/myfirst.cc
 
-Now build your first example script using waf:
+Now build your first example script using ns3:
 
 .. sourcecode:: bash
 
-  $ ./waf
+  $ ./ns3
 
 You should see messages reporting that your ``myfirst`` example was built
 successfully.
@@ -843,7 +843,7 @@ directory you must run it out of the scratch directory):
 
 .. sourcecode:: bash
 
-  $ ./waf --run scratch/myfirst
+  $ ./ns3 --run scratch/myfirst
 
 You should see some output:
 
@@ -884,27 +884,37 @@ most of our *repositories* will look:
 
 .. sourcecode:: text
 
-  drwxr-xr-x                               [up]     
-  drwxr-xr-x                               bindings python  files
-  drwxr-xr-x                               doc              files
-  drwxr-xr-x                               examples         files
-  drwxr-xr-x                               ns3              files
-  drwxr-xr-x                               scratch          files
-  drwxr-xr-x                               src              files
-  drwxr-xr-x                               utils            files
-  -rw-r--r-- 2009-07-01 12:47 +0200 560    .hgignore        file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 1886   .hgtags          file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 1276   AUTHORS          file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 30961  CHANGES.html     file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 17987  LICENSE          file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 3742   README           file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 16171  RELEASE_NOTES.md file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 6      VERSION          file | revisions | annotate
-  -rwxr-xr-x 2009-07-01 12:47 +0200 88110  waf              file | revisions | annotate
-  -rwxr-xr-x 2009-07-01 12:47 +0200 28     waf.bat          file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 35395  wscript          file | revisions | annotate
-  -rw-r--r-- 2009-07-01 12:47 +0200 7673   wutils.py        file | revisions | annotate
-  
+  drwxr-xr-x                               [up]
+  -rwxrwxrwx  12507 nov 23 23:12 AUTHORS
+  drwxrwxrwx      0 dez 30  2020 bindings
+  drwxrwxrwx   4096 nov 28 11:25 buildsupport
+  -rwxrwxrwx 189870 nov 28 10:13 CHANGES.html
+  -rwxrwxrwx   1490 nov 22 10:56 .clang-format
+  -rwxrwxrwx   5079 nov 28 10:50 CMakeLists.txt
+  drwxrwxrwx      0 nov 28 00:56 contrib
+  -rwxrwxrwx  18336 nov 23 23:12 CONTRIBUTING.md
+  drwxrwxrwx   4096 nov 28 11:30 doc
+  -rwxrwxrwx    564 nov 22 10:56 .editorconfig
+  drwxrwxrwx   4096 nov 28 00:28 examples
+  drwxrwxrwx   4096 nov 28 11:15 .git
+  -rwxrwxrwx     42 nov 22 10:56 .gitattributes
+  -rwxrwxrwx    395 nov 28 11:25 .gitignore
+  drwxrwxrwx   4096 nov 28 11:37 .idea
+  -rwxrwxrwx  17987 nov 22 10:56 LICENSE
+  -rwxrwxrwx   6841 nov 22 10:56 .mailmap
+  drwxrwxrwx      0 jul 13 20:15 .nompi
+  -rwxrwxrwx  31942 nov 28 11:16 ns3
+  -rwxrwxrwx   4210 nov 28 11:25 README.md
+  -rwxrwxrwx 185874 nov 28 10:13 RELEASE_NOTES.md
+  drwxrwxrwx   4096 nov 28 00:28 scratch
+  drwxrwxrwx      0 out 21 11:42 .settings
+  drwxrwxrwx   8192 nov 28 00:56 src
+  -rwxrwxrwx  83149 nov 28 11:28 test.py
+  -rwxrwxrwx    131 nov 22 10:56 testpy.supp
+  drwxrwxrwx   4096 nov 28 11:25 utils
+  -rwxrwxrwx   4227 nov 28 11:25 utils.py
+  -rwxrwxrwx      6 nov 22 10:56 VERSION
+
 Our example scripts are in the ``examples`` directory.  If you click on ``examples``
 you will see a list of subdirectories.  One of the files in ``tutorial`` subdirectory is ``first.cc``.  If
 you click on ``first.cc`` you will find the code you just walked through.
diff --git a/doc/tutorial/source/data-collection.rst b/doc/tutorial/source/data-collection.rst
index 09d6670e3..f31ce45a1 100644
--- a/doc/tutorial/source/data-collection.rst
+++ b/doc/tutorial/source/data-collection.rst
@@ -60,7 +60,7 @@ be invoked as follows (please note the use of double quotes):
 
 ::
 
-  ./waf --run "seventh --help"
+  ./ns3 --run "seventh --help"
 
 which produces:
 
@@ -84,7 +84,7 @@ toggling the boolean value as follows:
 
 ::
 
-  ./waf --run "seventh --useIpv6=1"
+  ./ns3 --run "seventh --useIpv6=1"
 
 and have a look at the pcap generated, such as with ``tcpdump``:
 
diff --git a/doc/tutorial/source/getting-started.rst b/doc/tutorial/source/getting-started.rst
index c0c8c970e..8d92284b4 100644
--- a/doc/tutorial/source/getting-started.rst
+++ b/doc/tutorial/source/getting-started.rst
@@ -78,6 +78,8 @@ Prerequisite  Package/version
 ============  ===========================================================
 C++ compiler  ``clang++`` or ``g++`` (g++ version 7 or greater)
 Python        ``python3`` version >=3.6
+CMake         ``cmake`` version >=3.10
+Build system  ``make``, ``ninja``, ``xcodebuild`` (XCode)
 Git           any recent version (to access |ns3| from `GitLab.com <https://gitlab.com/nsnam/ns-3-dev/>`_)
 tar           any recent version (to unpack an `ns-3 release <https://www.nsnam.org/releases/>`_)
 bunzip2       any recent version (to uncompress an |ns3| release)
@@ -91,10 +93,6 @@ From this point forward, we are going to assume that the reader is working in
 Linux, macOS, or a Linux emulation environment, and has at least the above
 prerequisites.
 
-**Note:** The |ns3| build system (`Waf`, introduced below) does not
-tolerate spaces in the installation path.  Make sure that you are downloading
-into a directory that does not contain spaces in the full path name.
-
 For example, do not use a directory path such as the below, because one
 of the parent directories contains a space in the directory name:
 
@@ -382,11 +380,10 @@ Building ns-3
 
 As with downloading |ns3|, there are a few ways to build |ns3|.  The main
 thing that we wish to emphasize is the following.  |ns3| is built with
-a build tool called ``Waf``, described below.  Most users will end up
-working most directly with Waf, but there are some convenience scripts
-to get you started or to orchestrate more complicated builds.  Therefore,
-please have a look at ``build.py`` and building with ``bake``, before
-reading about Waf below.
+a build tool called ``CMake``, described below.  Most users will end up
+working most directly with the ns3 command-line wrapper for CMake, for the sake
+of convenience.  Therefore, please have a look at ``build.py`` and building
+with ``bake``, before reading about CMake and the ns3 wrapper below.
 
 Building with ``build.py``
 ++++++++++++++++++++++++++
@@ -400,7 +397,7 @@ This program is called ``build.py``.  This
 program will get the project configured for you
 in the most commonly useful way.  However, please note that more advanced
 configuration and work with |ns3| will typically involve using the
-native |ns3| build system, Waf, to be introduced later in this tutorial.  
+native |ns3| build system, CMake, to be introduced later in this tutorial.
 
 If you downloaded
 using a tarball you should have a directory called something like 
@@ -502,16 +499,15 @@ command tells you; it may give a hint as to a missing dependency:
 This will list out the various dependencies of the packages you are
 trying to build.
 
-Building with Waf
-+++++++++++++++++
+Building with the ns3 CMake wrapper
++++++++++++++++++++++++++++++++++++
 
 Up to this point, we have used either the `build.py` script, or the
 `bake` tool, to get started with building |ns3|.  These tools are useful
 for building |ns3| and supporting libraries, and they call into
-the |ns3| directory to call the Waf build tool to do the actual building.  
-An installation of Waf is bundled with the |ns3| source code.
-Most users quickly transition to using Waf directly to configure and 
-build |ns3|.  So, to proceed, please change your working directory to 
+the |ns3| directory to call the CMake build tool to do the actual building.
+CMake needs to be installed before building |ns3|.
+So, to proceed, please change your working directory to
 the |ns3| directory that you have initially built.
 
 It's not 
@@ -520,16 +516,19 @@ detour and look at how to make changes to the configuration of the project.
 Probably the most useful configuration change you can make will be to 
 build the optimized version of the code.  By default you have configured
 your project to build the debug version.  Let's tell the project to 
-make an optimized build.  To explain to Waf that it should do optimized
+make an optimized build.
+
+To maintain a similar interface for command-line users, we include a
+wrapper script for CMake, |ns3|. To tell |ns3| that it should do optimized
 builds that include the examples and tests, you will need to execute the 
 following commands:
 
 .. sourcecode:: bash
 
-  $ ./waf clean
-  $ ./waf configure --build-profile=optimized --enable-examples --enable-tests
+  $ ./ns3 clean
+  $ ./ns3 configure --build-profile=optimized --enable-examples --enable-tests
 
-This runs Waf out of the local directory (which is provided as a convenience
+This runs CMake out of the local directory (which is provided as a convenience
 for you).  The first command to clean out the previous build is not 
 typically strictly necessary but is good practice (but see `Build Profiles`_,
 below); it will remove the
@@ -649,21 +648,21 @@ would not be enabled and a message would be displayed.  Note further that there
 a feature to use the program ``sudo`` to set the suid bit of certain programs.
 This is not enabled by default and so this feature is reported as "not enabled."
 Finally, to reprint this summary of which optional features are enabled, use
-the ``--check-config`` option to waf.
+the ``--check-config`` option to ns3.
 
 Now go ahead and switch back to the debug build that includes the examples and tests.
 
 .. sourcecode:: bash
 
-  $ ./waf clean
-  $ ./waf configure --build-profile=debug --enable-examples --enable-tests
+  $ ./ns3 clean
+  $ ./ns3 configure --build-profile=debug --enable-examples --enable-tests
 
 The build system is now configured and you can build the debug versions of 
 the |ns3| programs by simply typing:
 
 .. sourcecode:: bash
 
-  $ ./waf
+  $ ./ns3 build
 
 Although the above steps made you build the |ns3| part of the system twice,
 now you know how to change the configuration and build optimized code.
@@ -673,13 +672,13 @@ for an already configured project:
 
 .. sourcecode:: bash
 
-  $ ./waf --check-profile
+  $ ./ns3 --check-profile
   Waf: Entering directory \`/path/to/ns-allinone-3.35/ns-3.35/build\'
   Build profile: debug
 
 The build.py script discussed above supports also the ``--enable-examples``
 and ``enable-tests`` arguments, but in general, does not directly support
-other waf options; for example, this will not work:
+other ns3 options; for example, this will not work:
 
 .. sourcecode:: bash
 
@@ -692,15 +691,15 @@ will result in:
   build.py: error: no such option: --disable-python
 
 However, the special operator ``--`` can be used to pass additional
-options through to waf, so instead of the above, the following will work:
+options through to ns3, so instead of the above, the following will work:
 
 .. sourcecode:: bash
 
   $ ./build.py -- --disable-python   
 
-as it generates the underlying command ``./waf configure --disable-python``.
+as it generates the underlying command ``./ns3 configure --disable-python``.
 
-Here are a few more introductory tips about Waf.
+Here are a few more introductory tips about CMake.
 
 Handling build errors
 =====================
@@ -720,19 +719,19 @@ on Fedora 28, when Gtk2+ is installed, will result in an error such as::
   /usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: error: unnecessary parentheses in declaration of ‘__gtk_reserved1’ [-Werror=parentheses]
    void (*__gtk_reserved1);
 
-In releases starting with ns-3.28.1, an option is available in Waf to work
+In releases starting with ns-3.28.1, an option is available in CMake to work
 around these issues.  The option disables the inclusion of the '-Werror' 
 flag to g++ and clang++.  The option is '--disable-werror' and must be
 used at configure time; e.g.:
 
 .. sourcecode:: bash
 
-  ./waf configure --disable-werror --enable-examples --enable-tests
+  ./ns3 configure --disable-werror --enable-examples --enable-tests
 
 Configure vs. Build
 ===================
 
-Some Waf commands are only meaningful during the configure phase and some commands are valid
+Some CMake commands are only meaningful during the configure phase and some commands are valid
 in the build phase.  For example, if you wanted to use the emulation 
 features of |ns3|, you might want to enable setting the suid bit using
 sudo as described above.  This turns out to be a configuration-time command, and so 
@@ -740,28 +739,28 @@ you could reconfigure using the following command that also includes the example
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-sudo --enable-examples --enable-tests
+  $ ./ns3 configure --enable-sudo --enable-examples --enable-tests
 
-If you do this, Waf will have run sudo to change the socket creator programs of the
+If you do this, ns3 will have run sudo to change the socket creator programs of the
 emulation code to run as root.
 
 There are many other configure- and build-time options
-available in Waf.  To explore these options, type:
+available in ns3.  To explore these options, type:
 
 .. sourcecode:: bash
 
-  $ ./waf --help
+  $ ./ns3 --help
 
 We'll use some of the testing-related commands in the next section.
 
 Build Profiles
 ==============
 
-We already saw how you can configure Waf for ``debug`` or ``optimized`` builds:
+We already saw how you can configure CMake for ``debug`` or ``optimized`` builds:
 
 .. sourcecode:: bash
 
-  $ ./waf --build-profile=debug
+  $ ./ns3 configure --build-profile=debug
 
 There is also an intermediate build profile, ``release``.  ``-d`` is a
 synonym for ``--build-profile``.
@@ -792,7 +791,7 @@ The build profile controls the use of logging, assertions, and compiler optimiza
 As you can see, logging and assertions are only configured
 by default in debug builds, although they can be selectively enabled
 in other build profiles by using the ``--enable-logs`` and 
-``--enable-asserts`` flags during Waf configuration time.
+``--enable-asserts`` flags during CMake configuration time.
 Recommended practice is to develop your scenario in debug mode, then
 conduct repetitive runs (for statistics or changing parameters) in
 optimized build profile.
@@ -806,28 +805,28 @@ use the indicated Code Wrapper macro:
   DoLongInvolvedComputation ();
   NS_BUILD_DEBUG (timer.Stop (); std::cout << "Done: " << timer << std::endl;)
 
-By default Waf puts the build artifacts in the ``build`` directory.  
+By default ns3 puts the build artifacts in the ``build`` directory.
 You can specify a different output directory with the ``--out``
 option, e.g.
 
 .. sourcecode:: bash
 
-  $ ./waf configure --out=my-build-dir
+  $ ./ns3 configure --out=my-build-dir
 
 Combining this with build profiles lets you switch between the different
 compile options in a clean way:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --build-profile=debug --out=build/debug
-  $ ./waf build
+  $ ./ns3 configure --build-profile=debug --out=build/debug
+  $ ./ns3 build
   ...
-  $ ./waf configure --build-profile=optimized --out=build/optimized
-  $ ./waf build
+  $ ./ns3 configure --build-profile=optimized --out=build/optimized
+  $ ./ns3 build
   ...
 
 This allows you to work with multiple builds rather than always
-overwriting the last build.  When you switch, Waf will only compile
+overwriting the last build.  When you switch, ns3 will only compile
 what it has to, instead of recompiling everything.
 
 When you do switch build profiles like this, you have to be careful
@@ -840,32 +839,32 @@ to define some environment variables to help you avoid mistakes:
   $ export NS3DEBUG="--build-profile=debug --out=build/debug"
   $ export NS3OPT=="--build-profile=optimized --out=build/optimized"
 
-  $ ./waf configure $NS3CONFIG $NS3DEBUG
-  $ ./waf build
+  $ ./ns3 configure $NS3CONFIG $NS3DEBUG
+  $ ./ns3 build
   ...
-  $ ./waf configure $NS3CONFIG $NS3OPT
-  $ ./waf build
+  $ ./ns3 configure $NS3CONFIG $NS3OPT
+  $ ./ns3 build
 
 Compilers and Flags
 ===================
 
-In the examples above, Waf uses the GCC C++ compiler, ``g++``, for
-building |ns3|. However, it's possible to change the C++ compiler used by Waf
+In the examples above, CMake uses the GCC C++ compiler, ``g++``, for
+building |ns3|. However, it's possible to change the C++ compiler used by CMake
 by defining the ``CXX`` environment variable.
 For example, to use the Clang C++ compiler, ``clang++``,
 
 .. sourcecode:: bash
 
-  $ CXX="clang++" ./waf configure
-  $ ./waf build
+  $ CXX="clang++" ./ns3 configure
+  $ ./ns3 build
 
-One can also set up Waf to do distributed compilation with ``distcc`` in
+One can also set up ns3 to do distributed compilation with ``distcc`` in
 a similar way:
 
 .. sourcecode:: bash
 
-  $ CXX="distcc g++" ./waf configure
-  $ ./waf build
+  $ CXX="distcc g++" ./ns3 configure
+  $ ./ns3 build
 
 More info on ``distcc`` and distributed compilation can be found on it's
 `project page
@@ -878,19 +877,19 @@ you configure |ns3|.
 Install
 =======
 
-Waf may be used to install libraries in various places on the system.
+ns3 may be used to install libraries in various places on the system.
 The default location where libraries and executables are built is
-in the ``build`` directory, and because Waf knows the location of these
+in the ``build`` directory, and because ns3 knows the location of these
 libraries and executables, it is not necessary to install the libraries
 elsewhere.
 
 If users choose to install things outside of the build directory, users
-may issue the ``./waf install`` command.  By default, the prefix for
-installation is ``/usr/local``, so ``./waf install`` will install programs
+may issue the ``./ns3 install`` command.  By default, the prefix for
+installation is ``/usr/local``, so ``./ns3 install`` will install programs
 into ``/usr/local/bin``, libraries into ``/usr/local/lib``, and headers
 into ``/usr/local/include``.  Superuser privileges are typically needed
 to install to the default prefix, so the typical command would be
-``sudo ./waf install``.  When running programs with Waf, Waf will
+``sudo ./ns3 install``.  When running programs with ns3, ns3 will
 first prefer to use shared libraries in the build directory, then 
 will look for libraries in the library path configured in the local
 environment.  So when installing libraries to the system, it is good
@@ -899,31 +898,31 @@ practice to check that the intended libraries are being used.
 Users may choose to install to a different prefix by passing the ``--prefix``
 option at configure time, such as::
 
-  ./waf configure --prefix=/opt/local
+  ./ns3 configure --prefix=/opt/local
 
-If later after the build the user issues the ``./waf install`` command, the 
+If later after the build the user issues the ``./ns3 install`` command, the
 prefix ``/opt/local`` will be used.
 
-The ``./waf clean`` command should be used prior to reconfiguring 
-the project if Waf will be used to install things at a different prefix.
+The ``./ns3 clean`` command should be used prior to reconfiguring
+the project if ns3 will be used to install things at a different prefix.
 
-In summary, it is not necessary to call ``./waf install`` to use |ns3|.
-Most users will not need this command since Waf will pick up the
+In summary, it is not necessary to call ``./ns3 install`` to use |ns3|.
+Most users will not need this command since ns3 will pick up the
 current libraries from the ``build`` directory, but some users may find 
 it useful if their use case involves working with programs outside
 of the |ns3| directory.
 
-One Waf
+One ns3
 =======
 
-There is only one Waf script, at the top level of the |ns3| source tree.
+There is only one ns3 script, at the top level of the |ns3| source tree.
 As you work, you may find yourself spending a lot of time in ``scratch/``,
-or deep in ``src/...``, and needing to invoke Waf.  You could just
-remember where you are, and invoke Waf like this:
+or deep in ``src/...``, and needing to invoke ns3.  You could just
+remember where you are, and invoke ns3 like this:
 
 .. sourcecode:: bash
 
-  $ ../../../waf ...
+  $ ../../../ns3 ...
 
 but that gets tedious, and error prone, and there are better solutions.
 
@@ -936,16 +935,281 @@ If you only have the tarball, an environment variable can help:
 .. sourcecode:: bash
 
   $ export NS3DIR="$PWD"
-  $ function waff { cd $NS3DIR && ./waf $* ; }
+  $ function ns3f { cd $NS3DIR && ./ns3 $* ; }
 
   $ cd scratch
-  $ waff build
+  $ ns3f build
 
-It might be tempting in a module directory to add a trivial ``waf``
-script along the lines of ``exec ../../waf``.  Please don't.  It's
+It might be tempting in a module directory to add a trivial ``ns3``
+script along the lines of ``exec ../../ns3``.  Please don't.  It's
 confusing to newcomers, and when done poorly it leads to subtle build
 errors.  The solutions above are the way to go.
 
+Building with CMake
++++++++++++++++++++++++
+
+The ns3 wrapper script calls CMake directly, mapping Waf-like options
+to the verbose settings used by CMake. Calling ``./ns3 --verbose`` shows
+the underlying commands used by the different options.
+
+Here is are a few examples showing why we suggest the use of the ns3 wrapper script.
+
+Configuration command
+=====================
+
+.. sourcecode:: bash
+
+  $ ./ns3 --verbose configure --enable-tests --enable-examples -d optimized
+
+Corresponds to
+
+.. sourcecode:: bash
+
+  $ cd /ns-3-dev/cmake_cache/
+  $ cmake -DCMAKE_BUILD_TYPE=release -DNS3_NATIVE_OPTIMIZATIONS=ON -DNS3_ASSERT=OFF -DNS3_LOG=OFF -DNS3_TESTS=ON -DNS3_EXAMPLES=ON ..
+
+Build command
+=============
+
+To build a specific target such as ``test-runner`` we use the following ns3 command:
+
+.. sourcecode:: bash
+
+  $ ./ns3 --verbose build test-runner
+
+Which corresponds to the following commands:
+
+.. sourcecode:: bash
+
+  $ cd /ns-3-dev/cmake_cache/
+  $ cmake .. # This command refreshes the CMake cache, which detects changes in source file names before building
+  $ cmake --build . -j 16 --target test-runner # This command builds the test-runner target with the underlying build system
+
+
+To build all targets such as modules, examples and tests, we use the following ns3 command:
+
+.. sourcecode:: bash
+
+  $ ./ns3 --verbose build
+
+Which corresponds to:
+
+.. sourcecode:: bash
+
+  $ cd /ns-3-dev/cmake_cache/
+  $ cmake .. # This command refreshes the CMake cache, which detects changes in source file names before building
+  $ cmake --build . -j 16  # This command builds all the targets with the underlying build system
+
+Run command
+===========
+
+.. sourcecode:: bash
+
+  $ ./ns3 --verbose --run test-runner
+
+Corresponds to:
+
+.. sourcecode:: bash
+
+  $ cd /ns-3-dev/cmake_cache/
+  $ cmake .. # This command refreshes the CMake cache, which detects changes in source file names before building
+  $ cmake --build . -j 16 --target test-runner # This command builds the test-runner target calling the underlying build system
+  $ export PATH=$PATH:/ns-3-dev/build/:/ns-3-dev/build/lib:/ns-3-dev/build/bindings/python # export library paths
+  $ export LD_LIBRARY_PATH=/ns-3-dev/build/:/ns-3-dev/build/lib:/ns-3-dev/build/bindings/python
+  $ export PYTHON_PATH=/ns-3-dev/build/:/ns-3-dev/build/lib:/ns-3-dev/build/bindings/python
+  $ /ns-3-dev/build/utils/ns3-dev-test-runner-optimized # call the executable with the real path
+
+Note: the command above would fail if ``./ns3 build`` was not executed first,
+since the examples won't be built by the test-runner target.
+
+Building with IDEs
+++++++++++++++++++
+
+With CMake, IDE integration is much easier. We list the steps on how to use ns-3 with a few IDEs.
+
+Microsoft Visual Code
+=====================
+
+Start by downloading `VS Code <https://code.visualstudio.com/>`_.
+
+Then install it and then install the CMake and C++ plugins.
+
+This can be done accessing the extensions' menu button on the left.
+
+.. figure:: figures/vscode/install_cmake_tools.png
+
+.. figure:: figures/vscode/install_cpp_tools.png
+
+It will take a while, but it will locate the available toolchains for you to use.
+
+After that, open the ns-3-dev folder. It should run CMake automatically and preconfigure it.
+
+.. figure:: figures/vscode/open_project.png
+
+After this happens, you can choose ns-3 features by opening the CMake cache and toggling them on or off.
+
+.. figure:: figures/vscode/open_cmake_cache.png
+
+.. figure:: figures/vscode/configure_ns3.png
+
+Just as an example, here is how to enable examples
+
+.. figure:: figures/vscode/enable_examples_and_save_to_reload_cache.png
+
+After saving the cache, CMake will run, refreshing the cache. Then VsCode will update its
+list of targets on the left side of the screen in the CMake menu.
+
+After selecting a target on the left side menu, there are options to build, run or debug it.
+
+.. figure:: figures/vscode/select_target_build_and_debug.png
+
+Any of them will automatically build the selected target.
+If you choose run or debug, the executable targets will be executed.
+You can open the source files you want, put some breakpoints and then click debug to visually debug programs.
+
+.. figure:: figures/vscode/debugging.png
+
+JetBrains CLion
+===============
+
+Start by downloading `CLion <https://www.jetbrains.com/clion/>`_.
+
+
+The following image contains the toolchain configuration window for
+CLion running on Windows (only WSLv2 is currently supported).
+
+.. figure:: figures/clion/toolchains.png
+
+CLion uses Makefiles for your platform as the default generator.
+Here you can choose a better generator like `ninja` by setting the cmake options flag to `-G Ninja`.
+You can also set options to enable examples (`-DNS3_EXAMPLES=ON`) and tests (`-DNS3_TESTS=ON`).
+
+.. figure:: figures/clion/cmake_configuration.png
+
+To refresh the CMake cache, triggering the discovery of new targets (libraries, executables and/or modules),
+you can either configure to re-run CMake automatically after editing CMake files (pretty slow and easily
+triggered) or reload it manually. The following image shows how to trigger the CMake cache refresh.
+
+.. figure:: figures/clion/reload_cache.png
+
+After configuring the project, the available targets are listed in a drop-down list on the top right corner.
+Select the target you want and then click the hammer symbol to build, as shown in the image below.
+
+.. figure:: figures/clion/build_targets.png
+
+If you have selected and executable target, you can click either the play button to execute the program;
+the bug to debug the program; the play button with a chip, to run Valgrind and analyze memory usage,
+leaks and so on.
+
+.. figure:: figures/clion/run_target.png
+
+Code::Blocks
+============
+
+Start by installing `Code::Blocks <https://www.codeblocks.org/>`_.
+
+Code::Blocks does not support CMake project natively, but we can use the corresponding CMake
+generator to generate a project in order to use it. The generator name depends on the operating
+system and underlying build system. https://cmake.org/cmake/help/latest/generator/CodeBlocks.html
+
+.. sourcecode:: bash
+
+  $ ./ns3 configure -G"CodeBlocks - Ninja" --enable-examples
+
+  ...
+
+  $ -- Build files have been written to: /ns-3-dev/cmake_cache
+
+
+There will be a NS3.cbp file inside the cache folder used during configuration (in this case cmake_cache).
+This is a Code::Blocks project file that can be opened by the IDE.
+
+When you first open the IDE, you will be greeted by a window asking you to select the compiler you want.
+
+.. figure:: figures/codeblocks/compiler_detection.png
+
+After that you will get into the landing page where you can open the project.
+
+.. figure:: figures/codeblocks/landing.png
+
+Loading it will take a while.
+
+.. figure:: figures/codeblocks/open_project.png
+
+After that we can select a target in the top menu (where it says "all") and click to build, run or debug.
+We can also set breakpoints on the source code.
+
+.. figure:: figures/codeblocks/breakpoint_and_debug.png
+
+After clicking to build, the build commands of the underlying build system will be printed in the tab at the bottom.
+If you clicked to debug, the program will start automatically and stop at the first breakpoint.
+
+.. figure:: figures/codeblocks/build_finished_breakpoint_waiting.png
+
+You can inspect memory and the current stack enabling those views in Debug->Debugging Windows->Watches and Call Stack.
+Using the debugging buttons, you can advance line by line, continue until the next breakpoint.
+
+.. figure:: figures/codeblocks/debug_watches.png
+
+Note: as Code::Blocks doesn't natively support CMake projects, it doesn't refresh the CMake cache, which means you
+will need to close the project, run the ``./ns3`` command to refresh the CMake caches after adding/removing
+source files to/from the CMakeLists.txt files, adding a new module or dependencies between modules.
+
+Apple XCode
+============
+
+Start by installing `XCode <https://developer.apple.com/xcode/>`_.
+Then open it for the first time and accept the license.
+Then open Xcode->Preferences->Locations and select the command-line tools location.
+
+.. figure:: figures/xcode/select_command_line.png
+
+XCode does not support CMake project natively, but we can use the corresponding CMake
+generator to generate a project in order to use it. The generator name depends on the operating
+system and underlying build system. https://cmake.org/cmake/help/latest/generator/Xcode.html
+
+.. sourcecode:: bash
+
+  $ ./ns3 configure -GXcode --enable-examples
+
+  ...
+
+  $ -- Build files have been written to: /ns-3-dev/cmake_cache
+
+
+There will be a NS3.xcodeproj file inside the cache folder used during configuration
+(in this case cmake_cache). This is a XCode project file that can be opened by the IDE.
+
+Loading the project will take a while, and you will be greeted with the following prompt.
+Select to automatically create the schemes.
+
+.. figure:: figures/xcode/create_schemes.png
+
+After that we can select a target in the top menu and click to run, which will build and run
+(if executable, or debug if build with debugging symbols).
+
+.. figure:: figures/xcode/target_dropdown.png
+
+After clicking to build, the build will start and progress is shown in the top bar.
+
+.. figure:: figures/xcode/select_target_and_build.png
+
+Before debugging starts, Xcode will request for permissions to attach to the process
+(as an attacker could pretend to be a debugging tool and steal data from other processes).
+
+.. figure:: figures/xcode/debug_permission_to_attach.png
+
+After attaching, we are greeted with profiling information and call stack on the left panel,
+source code, breakpoint and warnings on the central panel. At the bottom there are the memory
+watches panel in the left and the output panel on the right, which is also used to read the command line.
+
+.. figure:: figures/xcode/profiling_stack_watches_output.png
+
+
+Note: as XCode doesn't natively support CMake projects, it doesn't refresh the CMake cache, which means you
+will need to close the project, run the ``./ns3`` command to refresh the CMake caches after adding/removing
+source files to/from the CMakeLists.txt files, adding a new module or dependencies between modules.
+
 
 Testing ns-3
 ************
@@ -957,7 +1221,7 @@ You can run the unit tests of the |ns3| distribution by running the
 
   $ ./test.py
 
-These tests are run in parallel by Waf. You should eventually
+These tests are run in parallel by ns3. You should eventually
 see a report saying that
 
 .. sourcecode:: text
@@ -968,60 +1232,70 @@ This is the important message to check for; failures, crashes, or valgrind
 errors indicate problems with the code or incompatibilities between the
 tools and the code.
 
-You will also see the summary output from Waf and the test runner
-executing each test, which will actually look something like::
+You will also see the summary output from ns3 and the test runner
+executing each test, which will actually look something like:
 
-  Waf: Entering directory `/path/to/workspace/ns-3-allinone/ns-3-dev/build'
-  Waf: Leaving directory `/path/to/workspace/ns-3-allinone/ns-3-dev/build'
-  'build' finished successfully (1.799s)
-  
-  Modules built: 
-  aodv                      applications              bridge
-  click                     config-store              core
-  csma                      csma-layout               dsdv
-  emu                       energy                    flow-monitor
-  internet                  lte                       mesh
-  mobility                  mpi                       netanim
-  network                   nix-vector-routing        ns3tcp
-  ns3wifi                   olsr                      openflow
-  point-to-point            point-to-point-layout     propagation
-  spectrum                  stats                     tap-bridge
-  template                  test                      tools
-  topology-read             uan                       virtual-net-device
-  visualizer                wifi                      wimax
+.. sourcecode:: bash
 
-  PASS: TestSuite wifi-interference
-  PASS: TestSuite histogram
+  -- CCache is enabled
+  -- The CXX compiler identification is GNU 11.2.0
+  -- The C compiler identification is GNU 11.2.0
 
   ...
 
-  PASS: TestSuite object
-  PASS: TestSuite random-number-generators
-  92 of 92 tests passed (92 passed, 0 failed, 0 crashed, 0 valgrind errors)
+  -- Configuring done
+  -- Generating done
+  -- Build files have been written to: /ns-3-dev/cmake_cache
+
+  ...
+  Scanning dependencies of target tap-creator
+  [  1%] Building CXX object src/fd-net-device/CMakeFiles/tap-device-creator.dir/helper/tap-device-creator.cc.o
+  [  1%] Building CXX object src/tap-bridge/CMakeFiles/tap-creator.dir/model/tap-creator.cc.o
+  [  1%] Building CXX object src/fd-net-device/CMakeFiles/raw-sock-creator.dir/helper/creator-utils.cc.o
+  [  1%] Building CXX object src/tap-bridge/CMakeFiles/tap-creator.dir/model/tap-encode-decode.cc.o
+  [  1%] Linking CXX executable ../../../build/src/fd-net-device/ns3-dev-tap-device-creator
+
+   ...
+
+  [100%] Linking CXX executable ../../../build/examples/matrix-topology/ns3-dev-matrix-topology
+  [100%] Built target manet-routing-compare
+  [100%] Built target matrix-topology
+  [1/742] PASS: TestSuite aodv-routing-id-cache
+  [2/742] PASS: TestSuite routing-aodv
+  [3/742] PASS: TestSuite uniform-planar-array-test
+  [4/742] PASS: TestSuite angles
+
+  ...
+
+  [740/742] PASS: Example src/wifi/examples/wifi-manager-example --wifiManager=MinstrelHt --standard=802.11ax-6GHz --serverChannelWidth=160 --clientChannelWidth=160 --serverShortGuardInterval=3200 --clientShortGuardInterval=3200 --serverNss=4 --clientNss=4 --stepTime=0.1
+  [741/742] PASS: Example src/lte/examples/lena-radio-link-failure --numberOfEnbs=2 --useIdealRrc=0 --interSiteDistance=700 --simTime=17
+  [742/742] PASS: Example src/lte/examples/lena-radio-link-failure --numberOfEnbs=2 --interSiteDistance=700 --simTime=17
+  739 of 742 tests passed (739 passed, 3 skipped, 0 failed, 0 crashed, 0 valgrind errors)
+
 
 This command is typically run by users to quickly verify that an 
 |ns3| distribution has built correctly.  (Note the order of the ``PASS: ...``
 lines can vary, which is okay.  What's important is that the summary line at
 the end report that all tests passed; none failed or crashed.)
 
-Both Waf and ``test.py`` will split up the job on the available CPU cores
+Both ns3 and ``test.py`` will split up the job on the available CPU cores
 of the machine, in parallel.
 
 Running a Script
 ****************
 
-We typically run scripts under the control of Waf.  This allows the build 
+We typically run scripts under the control of ns3.  This allows the build
 system to ensure that the shared library paths are set correctly and that
 the libraries are available at run time.  To run a program, simply use the
-``--run`` option in Waf.  Let's run the |ns3| equivalent of the
+``--run`` option in ns3.  Let's run the |ns3| equivalent of the
 ubiquitous hello world program by typing the following:
 
 .. sourcecode:: bash
 
-  $ ./waf --run hello-simulator
+  $ ./ns3 --run hello-simulator
 
-Waf first checks to make sure that the program is built correctly and 
-executes a build if required.  Waf then executes the program, which 
+ns3 first checks to make sure that the program is built correctly and
+executes a build if required.  ns3 then executes the program, which
 produces the following output.
 
 .. sourcecode:: text
@@ -1032,10 +1306,10 @@ Congratulations!  You are now an ns-3 user!
 
 **What do I do if I don't see the output?**
 
-If you see Waf messages indicating that the build was 
+If you see ns3 messages indicating that the build was
 completed successfully, but do not see the "Hello Simulator" output, 
 chances are that you have switched your build mode to ``optimized`` in 
-the `Building with Waf`_ section, but have missed the change back to 
+the `Building with the ns3 CMake wrapper`_ section, but have missed the change back to
 ``debug`` mode.  All of the console output used in this tutorial uses a 
 special |ns3| logging component that is useful for printing 
 user messages to the console.  Output from this component is 
@@ -1045,15 +1319,15 @@ type the following:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --build-profile=debug --enable-examples --enable-tests
+  $ ./ns3 configure --build-profile=debug --enable-examples --enable-tests
 
-to tell Waf to build the debug versions of the |ns3| 
+to tell ns3 to build the debug versions of the |ns3|
 programs that includes the examples and tests.  You must still build 
 the actual debug version of the code by typing
 
 .. sourcecode:: bash
 
-  $ ./waf
+  $ ./ns3
 
 Now, if you run the ``hello-simulator`` program, you should see the 
 expected output.
@@ -1065,12 +1339,12 @@ To feed command line arguments to an |ns3| program use this pattern:
 
 .. sourcecode:: bash
 
-  $ ./waf --run <ns3-program> --command-template="%s <args>"
+  $ ./ns3 --run <ns3-program> --command-template="%s <args>"
 
 Substitute your program name for ``<ns3-program>``, and the arguments
-for ``<args>``.  The ``--command-template`` argument to Waf is
-basically a recipe for constructing the actual command line Waf should use
-to execute the program.  Waf checks that the build is complete,
+for ``<args>``.  The ``--command-template`` argument to ns3 is
+basically a recipe for constructing the actual command line ns3 should use
+to execute the program.  ns3 checks that the build is complete,
 sets the shared library paths, then invokes the executable
 using the provided command line template, 
 inserting the program name for the ``%s`` placeholder.
@@ -1081,7 +1355,7 @@ by single quotes, such as:
 
 .. sourcecode:: bash
 
-  $ ./waf --run '<ns3-program> --arg1=value1 --arg2=value2 ...'
+  $ ./ns3 --run '<ns3-program> --arg1=value1 --arg2=value2 ...'
 
 Another particularly useful example is to run a test suite by itself.
 Let's assume that a ``mytest`` test suite exists (it doesn't).
@@ -1091,7 +1365,7 @@ tests in parallel, by repeatedly invoking the real testing program,
 
 .. sourcecode:: bash
 
-  $ ./waf --run test-runner --command-template="%s --suite=mytest --verbose"
+  $ ./ns3 --run test-runner --command-template="%s --suite=mytest --verbose"
 
 This passes the arguments to the ``test-runner`` program.
 Since ``mytest`` does not exist, an error message will be generated.
@@ -1099,7 +1373,7 @@ To print the available ``test-runner`` options:
 
 .. sourcecode:: bash
 
-  $ ./waf --run test-runner --command-template="%s --help"
+  $ ./ns3 --run test-runner --command-template="%s --help"
 
 Debugging
 +++++++++
@@ -1113,7 +1387,7 @@ For example, to run your |ns3| program ``hello-simulator`` with the arguments
 
 .. sourcecode:: bash
 
-  $ ./waf --run=hello-simulator --command-template="gdb %s --args <args>"
+  $ ./ns3 --run=hello-simulator --command-template="gdb %s --args <args>"
 
 Notice that the |ns3| program name goes with the ``--run`` argument,
 and the control utility (here ``gdb``) is the first token
@@ -1128,44 +1402,44 @@ debugger:
 
 .. sourcecode:: bash
 
-  $ ./waf --run test-runner --command-template="gdb %s --args --suite=mytest --verbose"
+  $ ./ns3 --run test-runner --command-template="gdb %s --args --suite=mytest --verbose"
 
 Working Directory
 +++++++++++++++++
 
-Waf needs to run from its location at the top of the |ns3| tree.
+ns3 needs to run from its location at the top of the |ns3| tree.
 This becomes the working directory where output files will be written.
 But what if you want to keep those files out of the |ns3| source tree?  Use
 the ``--cwd`` argument:
 
 .. sourcecode:: bash
 
-  $ ./waf --cwd=...
+  $ ./ns3 --cwd=...
 
 It may be more convenient to start with your working directory where
 you want the output files, in which case a little indirection can help:
 
 .. sourcecode:: bash
 
-  $ function waff {
+  $ function ns3f {
       CWD="$PWD"
       cd $NS3DIR >/dev/null
-      ./waf --cwd="$CWD" $*
+      ./ns3 --cwd="$CWD" $*
       cd - >/dev/null
     }
 
 This embellishment of the previous version saves the current working directory,
-``cd``'s to the Waf directory, then instructs Waf to change the working
+``cd``'s to the ns3 directory, then instructs ns3 to change the working
 directory *back* to the saved current working directory before running the
 program.
 
 We mention this ``--cwd`` command for completeness; most users will simply
-run Waf from the top-level directory and generate the output data files there.
+run ns3 from the top-level directory and generate the output data files there.
 
 Running without Building
 ++++++++++++++++++++++++
 
-As of the ns-3.30 release, a new Waf option was introduced to allow the
+As of the ns-3.30 release, a new ns3 option was introduced to allow the
 running of programs while skipping the build step.  This can reduce the time
 to run programs when, for example, running the same program repeatedly
 through a shell script, or when demonstrating program execution. 
@@ -1174,12 +1448,12 @@ except that the program and ns-3 libraries will not be rebuilt.
 
 .. sourcecode:: bash
 
-  $ ./waf --run-no-build '<ns3-program> --arg1=value1 --arg2=value2 ...'
+  $ ./ns3 --run-no-build '<ns3-program> --arg1=value1 --arg2=value2 ...'
 
 Build version
 +++++++++++++
 
-As of the ns-3.32 release, a new Waf configure option ``--enable-build-version`` 
+As of the ns-3.32 release, a new ns3 configure option ``--enable-build-version``
 was introduced which inspects the local ns3 git repository during builds and adds 
 version metadata to the core module. 
 
@@ -1196,14 +1470,14 @@ or
 If these prerequisites are not met, the configuration will fail.
 
 When these prerequisites are met and ns-3 is configured with the 
-``--enable-build-version`` option, the waf command ``--check-version`` can be 
+``--enable-build-version`` option, the ns3 command ``--check-version`` can be
 used to query the local git repository and display the current version metadata. 
 
 .. sourcecode:: bash
 
-  $ ./waf --check-version
+  $ ./ns3 --check-version
 
-Waf will collect information about the build and print out something similar
+ns3 will collect information about the build and print out something similar
 to the output below.
 
 .. sourcecode:: text
@@ -1256,7 +1530,7 @@ tree_state
 
 profile
   The build profile specified in the ``--build-profile`` option passed to 
-  ``waf configure``
+  ``ns3 configure``
 
 A new class, named Version, has been added to the core module.  The Version class 
 contains functions to retrieve individual fields of the build version as well 
@@ -1295,7 +1569,7 @@ option which will print the full build version and exit.
 
 .. sourcecode:: text
 
-  ./waf --run-no-build "command-line-example --version"
+  ./ns3 --run-no-build "command-line-example --version"
   Waf: Entering directory `/g/g14/mdb/gitlab/mdb/ns-3-dev/build/debug'
   ns-3.33+249@g80e0dd0-dirty-debug
 
diff --git a/doc/tutorial/source/quick-start.rst b/doc/tutorial/source/quick-start.rst
index b6f00b9a8..ebf41c9a5 100644
--- a/doc/tutorial/source/quick-start.rst
+++ b/doc/tutorial/source/quick-start.rst
@@ -33,10 +33,10 @@ does not cover those aspects.
 Prerequisites
 *************
 |ns3| has various optional extensions, but the main features just require
-a C++ compiler (g++ or clang++) and Python (version 3.6 or above); the
-Python is needed for the build system.  We focus in this chapter only on
-getting |ns3| up and running on a system supported by a recent C++ compiler
-and Python runtime support.
+a C++ compiler (g++ or clang++), Python (version 3.6 or above), CMake and
+a build-system (e.g. make, ninja, Xcode).
+We focus in this chapter only on getting |ns3| up and running on a system
+supported by a recent C++ compiler and Python runtime support.
 
 For Linux, use either g++ or clang++ compilers.  For macOS, use clang++ 
 (available in Xcode or Xcode Command Line Tools).  For Windows, we recommend
@@ -100,20 +100,20 @@ Building and testing ns-3
 
 Once you have obtained the source either by downloading a release or by
 cloning a Git repository, the next step is to
-configure the build using the *Waf* build system that comes with |ns3|.  There
+configure the build using the *CMake* build system.  There
 are several options to control the build, but enabling the example programs
 and the tests, for a default debug build profile (with debugging symbols
 and support for |ns3| logging) is what is usually done at first:
 
 ::
 
-  $ ./waf configure --enable-examples --enable-tests
+  $ ./ns3 configure --enable-examples --enable-tests
 
-Then, use Waf to build |ns3|:
+Then, use ns3 to build |ns3|:
 
 ::
 
-  $ ./waf build
+  $ ./ns3 build
 
 Once complete, you can run the unit tests to check your build:
 
@@ -125,18 +125,18 @@ All tests should either PASS or be SKIPped.  At this point, you have a
 working |ns3| simulator.  From here, you can start to
 run programs (look in the examples directory).  To run the first tutorial
 program, whose source code is located at `examples/tutorial/first.cc`, 
-use Waf to run it (by doing so, the |ns3| shared libraries are found
+use ns3 to run it (by doing so, the |ns3| shared libraries are found
 automatically):
 
 ::
 
-  $ ./waf --run first
+  $ ./ns3 --run first
 
 To view possible command-line options, specify the `--PrintHelp` argument:
 
 ::
 
-  $ ./waf --run 'first --PrintHelp'
+  $ ./ns3 --run 'first --PrintHelp'
 
 To continue reading about the conceptual model and architecture of |ns3|,
 the tutorial chapter :ref:`Conceptual Overview` would be the next natural place
diff --git a/doc/tutorial/source/resources.rst b/doc/tutorial/source/resources.rst
index 3463ae515..c96b9a222 100644
--- a/doc/tutorial/source/resources.rst
+++ b/doc/tutorial/source/resources.rst
@@ -38,8 +38,8 @@ complete this tutorial, we recommend becoming familiar with Git and using it
 to access the source code.  GitLab.com provides resources to get started
 at: https://docs.gitlab.com/ee/gitlab-basics/.
 
-Waf
-***
+CMake
+*****
 
 Once you have source code downloaded to your local system, you will need 
 to compile that source to produce usable programs.  Just as in the case of
@@ -47,15 +47,13 @@ source code management, there are many tools available to perform this
 function.  Probably the most well known of these tools is ``make``.  Along
 with being the most well known, ``make`` is probably the most difficult to
 use in a very large and highly configurable system.  Because of this, many
-alternatives have been developed.  Recently these systems have been developed
-using the Python language.
+alternatives have been developed.
 
-The build system Waf is used on the |ns3| project.  It is one 
-of the new generation of Python-based build systems.  You will not need to 
-understand any Python to build the existing |ns3| system.
+The build system CMake is used on the |ns3| project.
 
-For those interested in the gory details of Waf, the Waf book is available
-at https://waf.io/book/ and the current code at https://gitlab.com/ita1024/waf/.
+For those interested in the details of CMake, the CMake documents are available
+at https://cmake.org/cmake/help/latest/index.html and the current code
+at https://gitlab.kitware.com/cmake/cmake.
 
 Development Environment
 ***********************
@@ -82,7 +80,7 @@ software toolchain is the set of programming tools available in the given
 environment. For a quick review of what is included in the GNU toolchain see,
 http://en.wikipedia.org/wiki/GNU_toolchain.  |ns3| uses gcc, 
 GNU binutils, and gdb.  However, we do not use the GNU build system tools, 
-neither make nor autotools.  We use Waf for these functions.
+neither make directly.  We use CMake for these functions.
 
 On macOS, the toolchain used is Xcode.  |ns3| users on a Mac are strongly
 encouraged to install Xcode and the command-line tools packages from the
diff --git a/doc/tutorial/source/tracing.rst b/doc/tutorial/source/tracing.rst
index f8b7ac5db..eade87b84 100644
--- a/doc/tutorial/source/tracing.rst
+++ b/doc/tutorial/source/tracing.rst
@@ -488,7 +488,7 @@ If you now build and run this example,
 
 .. sourcecode:: bash
 
-  $ ./waf --run fourth
+  $ ./ns3 --run fourth
 
 you will see the output from the ``IntTrace`` function execute as soon
 as the trace source is hit:
@@ -2035,7 +2035,7 @@ to run.
 
 .. sourcecode:: bash
 
-  $ ./waf --run fifth
+  $ ./ns3 --run fifth
   Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
   Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
   'build' finished successfully (0.684s)
@@ -2051,7 +2051,7 @@ to run.
   ...
 
 You can probably see immediately a downside of using prints of any
-kind in your traces.  We get those extraneous waf messages printed all
+kind in your traces.  We get those extraneous ns3 messages printed all
 over our interesting information along with those RxDrop messages.  We
 will remedy that soon, but I'm sure you can't wait to see the results
 of all of this work.  Let's redirect that output to a file called
@@ -2059,9 +2059,9 @@ of all of this work.  Let's redirect that output to a file called
 
 .. sourcecode:: bash
 
-  $ ./waf --run fifth > cwnd.dat 2>&1
+  $ ./ns3 --run fifth > cwnd.dat 2>&1
 
-Now edit up "cwnd.dat" in your favorite editor and remove the waf
+Now edit up "cwnd.dat" in your favorite editor and remove the ns3
 build status and drop lines, leaving only the traced data (you could
 also comment out the ``TraceConnectWithoutContext("PhyRxDrop",
 MakeCallback (&RxDrop));`` in the script to get rid of the drop prints
@@ -2277,7 +2277,7 @@ Now, back to the example.  If you build and run this example,
 
 .. sourcecode:: bash
 
-  $ ./waf --run sixth
+  $ ./ns3 --run sixth
 
 you will see the same messages appear as when you ran "fifth", but two
 new files will appear in the top-level directory of your |ns3|
diff --git a/doc/tutorial/source/tweaking.rst b/doc/tutorial/source/tweaking.rst
index 114245c4b..b8a07d7af 100644
--- a/doc/tutorial/source/tweaking.rst
+++ b/doc/tutorial/source/tweaking.rst
@@ -85,7 +85,7 @@ did previously,
 
 .. sourcecode:: bash
 
-  $ ./waf --run scratch/myfirst
+  $ ./ns3 --run scratch/myfirst
 
 You should see the now familiar output of the first |ns3| example
 program
@@ -329,7 +329,7 @@ and look through it with your favorite editor if you like,
 
 .. sourcecode:: bash
 
-  $ ./waf --run scratch/myfirst > log.out 2>&1
+  $ ./ns3 --run scratch/myfirst > log.out 2>&1
 
 I personally use this extremely verbose version of logging when I am presented 
 with a problem and I have no idea where things are going wrong.  I can follow the 
@@ -374,19 +374,19 @@ right before the lines,
   NodeContainer nodes;
   nodes.Create (2);
 
-Now build the script using waf and clear the ``NS_LOG`` variable to turn 
+Now build the script using ns3 and clear the ``NS_LOG`` variable to turn
 off the torrent of logging we previously enabled:
 
 .. sourcecode:: bash
 
-  $ ./waf
+  $ ./ns3
   $ export NS_LOG=
 
 Now, if you run the script, 
 
 .. sourcecode:: bash
 
-  $ ./waf --run scratch/myfirst
+  $ ./ns3 --run scratch/myfirst
 
 you will ``not`` see your new message since its associated logging 
 component (``FirstScriptExample``) has not been enabled.  In order to see your
@@ -448,9 +448,9 @@ the script for help in the following way,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --PrintHelp"
+  $ ./ns3 --run "scratch/myfirst --PrintHelp"
 
-This will ask Waf to run the ``scratch/myfirst`` script and pass the command
+This will ask ns3 to run the ``scratch/myfirst`` script and pass the command
 line argument ``--PrintHelp`` to the script.  The quotes are required to 
 sort out which program gets which argument.  The command line parser will
 now see the ``--PrintHelp`` argument and respond with,
@@ -488,7 +488,7 @@ will be ``ns3::PointToPointNetDevice``.  Let's go ahead and type in,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"
+  $ ./ns3 --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"
 
 The system will print out all of the ``Attributes`` of this kind of net device.
 Among the ``Attributes`` you will see listed is,
@@ -522,7 +522,7 @@ any ``set`` operations as in the following example,
 
   ...
 
-Go ahead and build the new script with Waf (``./waf``) and let's go back 
+Go ahead and build the new script with ns3 (``./ns3``) and let's go back
 and enable some logging from the UDP echo server application and turn on the 
 time prefix.
 
@@ -564,7 +564,7 @@ the formula implied by the help item:
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"
+  $ ./ns3 --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"
 
 This will set the default value of the ``DataRate`` ``Attribute`` back to 
 five megabits per second.  Are you surprised by the result?  It turns out that
@@ -575,7 +575,7 @@ the net device:
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"
+  $ ./ns3 --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"
 
 We discover the ``Delay`` ``Attribute`` of the channel is set in the following
 way:
@@ -589,7 +589,7 @@ We can then set both of these default values through the command line system,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst
+  $ ./ns3 --run "scratch/myfirst
     --ns3::PointToPointNetDevice::DataRate=5Mbps
     --ns3::PointToPointChannel::Delay=2ms"
 
@@ -627,7 +627,7 @@ end up looking something like,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst 
+  $ ./ns3 --run "scratch/myfirst
     --ns3::PointToPointNetDevice::DataRate=5Mbps 
     --ns3::PointToPointChannel::Delay=2ms 
     --ns3::UdpEchoClient::MaxPackets=2"
@@ -638,7 +638,7 @@ a feature for this.  If we ask for command line help we should see:
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --PrintHelp"
+  $ ./ns3 --run "scratch/myfirst --PrintHelp"
   myfirst [Program Arguments] [General Arguments]
 
   General Arguments:
@@ -658,7 +658,7 @@ again on the point-to-point module:
 
 .. sourcecode:: bash
 
-  ./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
+  ./ns3 --run "scratch/myfirst --PrintGroup=PointToPoint"
   TypeIds in group PointToPoint:
     ns3::PointToPointChannel
     ns3::PointToPointNetDevice
@@ -713,7 +713,7 @@ Try,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --PrintHelp"
+  $ ./ns3 --run "scratch/myfirst --PrintHelp"
 
 .. sourcecode:: bash
 
@@ -734,7 +734,7 @@ setting the ``--nPackets`` argument in the command line,
 
 .. sourcecode:: bash
 
-  $ ./waf --run "scratch/myfirst --nPackets=2"
+  $ ./ns3 --run "scratch/myfirst --nPackets=2"
 
 You should now see
 
@@ -870,17 +870,17 @@ You can now build the script and run it from the command line:
 
 .. sourcecode:: bash
 
-  $ ./waf --run scratch/myfirst
+  $ ./ns3 --run scratch/myfirst
 
-Just as you have seen many times before, you will see some messages from Waf and then
+Just as you have seen many times before, you will see some messages from ns3 and then
 "'build' finished successfully" with some number of messages from 
 the running program.  
 
 When it ran, the program will have created a file named ``myfirst.tr``.  
-Because of the way that Waf works, the file is not created in the local 
+Because of the way that ns3 works, the file is not created in the local
 directory, it is created at the top-level directory of the repository by 
 default.  If you want to control where the traces are saved you can use the 
-``--cwd`` option of Waf to specify this.  We have not done so, thus we 
+``--cwd`` option of ns3 to specify this.  We have not done so, thus we
 need to change into the top level directory of our repo and take a look at 
 the ASCII trace file ``myfirst.tr`` in your favorite editor.
 
@@ -1019,7 +1019,7 @@ script in the usual way:
 
 .. sourcecode:: bash
 
-  $ ./waf --run scratch/myfirst
+  $ ./ns3 --run scratch/myfirst
 
 If you look at the top level directory of your distribution, you should now
 see three log files:  ``myfirst.tr`` is the ASCII trace file we have 
diff --git a/examples/routing/simple-alternate-routing.cc b/examples/routing/simple-alternate-routing.cc
index 4cfed4ce1..6ec9e2162 100644
--- a/examples/routing/simple-alternate-routing.cc
+++ b/examples/routing/simple-alternate-routing.cc
@@ -71,7 +71,7 @@ main (int argc, char *argv[])
   // line argument system as well, for exemplary purposes.  This means 
   // that it can be resettable at the command-line to the program, 
   // rather than recompiling
-  // e.g. waf --run "simple-alternate-routing --AlternateCost=5"
+  // e.g. ns3 --run "simple-alternate-routing --AlternateCost=5"
   uint16_t sampleMetric = 1;
   cmd.AddValue ("AlternateCost",
                 "This metric is used in the example script between n3 and n1 ", 
diff --git a/examples/stats/wifi-example-db.sh b/examples/stats/wifi-example-db.sh
index 4f3e35609..e4932ba4b 100755
--- a/examples/stats/wifi-example-db.sh
+++ b/examples/stats/wifi-example-db.sh
@@ -44,7 +44,7 @@ do
   for distance in $DISTANCES
   do
     echo Trial $trial, distance $distance
-    ../../waf --run "wifi-example-sim --format=db --distance=$distance --run=run-$distance-$trial"
+    ../../ns3 --run "wifi-example-sim --format=db --distance=$distance --run=run-$distance-$trial"
   done
 done
 
diff --git a/examples/tcp/tcp-large-transfer.cc b/examples/tcp/tcp-large-transfer.cc
index 2efcce65b..75a295977 100644
--- a/examples/tcp/tcp-large-transfer.cc
+++ b/examples/tcp/tcp-large-transfer.cc
@@ -27,7 +27,7 @@
 // - pcap traces also generated in the following files
 //   "tcp-large-transfer-$n-$i.pcap" where n and i represent node and interface
 // numbers respectively
-//  Usage (e.g.): ./waf --run tcp-large-transfer
+//  Usage (e.g.): ./ns3 --run tcp-large-transfer
 
 #include <iostream>
 #include <fstream>
diff --git a/examples/tcp/tcp-nsc-lfn.cc b/examples/tcp/tcp-nsc-lfn.cc
index 299cf4100..3bba31746 100644
--- a/examples/tcp/tcp-nsc-lfn.cc
+++ b/examples/tcp/tcp-nsc-lfn.cc
@@ -24,7 +24,7 @@
 // - a 'lossy' network with long delay
 // - TCP flow from n0 to n1 and from n1 to n0
 // - pcap traces generated as tcp-nsc-lfn-0-0.pcap and tcp-nsc-lfn-1-0.pcap
-//  Usage (e.g.): ./waf --run 'tcp-nsc-lfn --TCP_CONGESTION=hybla --runtime=30'
+//  Usage (e.g.): ./ns3 --run 'tcp-nsc-lfn --TCP_CONGESTION=hybla --runtime=30'
 
 #include <iostream>
 #include <fstream>
diff --git a/examples/tcp/tcp-nsc-zoo.cc b/examples/tcp/tcp-nsc-zoo.cc
index 616422ff7..08383e67b 100644
--- a/examples/tcp/tcp-nsc-zoo.cc
+++ b/examples/tcp/tcp-nsc-zoo.cc
@@ -25,7 +25,7 @@
 //
 // - Pcap traces are saved as tcp-nsc-zoo-$n-0.pcap, where $n represents the node number
 // - TCP flows from n0 to n1, n2, n3, from n1 to n0, n2, n3, etc.
-//  Usage (e.g.): ./waf --run 'tcp-nsc-zoo --nodes=5'
+//  Usage (e.g.): ./ns3 --run 'tcp-nsc-zoo --nodes=5'
 
 #include <iostream>
 #include <string>
diff --git a/examples/tcp/tcp-pacing.cc b/examples/tcp/tcp-pacing.cc
index 69a42bfde..38c3c0aad 100644
--- a/examples/tcp/tcp-pacing.cc
+++ b/examples/tcp/tcp-pacing.cc
@@ -62,7 +62,7 @@
 // an RTT. The size of initial congestion window is set to 10, and pacing
 // of the initial window is enabled. The available command-line options and
 // their default values can be observed in the usual way by running the
-// program to print the help info; i.e.: ./waf --run 'tcp-pacing --PrintHelp'
+// program to print the help info; i.e.: ./ns3 --run 'tcp-pacing --PrintHelp'
 //
 // When pacing is disabled, TCP sends eligible packets back-to-back. The
 // differences in behaviour when pacing is disabled can be observed from the
diff --git a/examples/tcp/tcp-star-server.cc b/examples/tcp/tcp-star-server.cc
index 522b4b871..7f38a36a3 100644
--- a/examples/tcp/tcp-star-server.cc
+++ b/examples/tcp/tcp-star-server.cc
@@ -33,10 +33,10 @@
 //   "tcp-star-server-$n-$i.pcap" where n and i represent node and interface
 //   numbers respectively
 // Usage examples for things you might want to tweak:
-//       ./waf --run="tcp-star-server"
-//       ./waf --run="tcp-star-server --nNodes=25"
-//       ./waf --run="tcp-star-server --ns3::OnOffApplication::DataRate=10000"
-//       ./waf --run="tcp-star-server --ns3::OnOffApplication::PacketSize=500"
+//       ./ns3 --run="tcp-star-server"
+//       ./ns3 --run="tcp-star-server --nNodes=25"
+//       ./ns3 --run="tcp-star-server --ns3::OnOffApplication::DataRate=10000"
+//       ./ns3 --run="tcp-star-server --ns3::OnOffApplication::PacketSize=500"
 // See the ns-3 tutorial for more info on the command line: 
 // http://www.nsnam.org/tutorials.html
 
diff --git a/examples/tcp/tcp-validation.cc b/examples/tcp/tcp-validation.cc
index 52ea7fb46..a0c684528 100644
--- a/examples/tcp/tcp-validation.cc
+++ b/examples/tcp/tcp-validation.cc
@@ -113,13 +113,13 @@
 // validation cases (and syntax of how to run):
 // ------------
 // Case 'dctcp-10ms':  DCTCP single flow, 10ms base RTT, 50 Mbps link, ECN enabled, CoDel:
-//     ./waf --run 'tcp-validation --firstTcpType=dctcp --linkRate=50Mbps --baseRtt=10ms --queueUseEcn=1 --stopTime=15s --validate=1 --validation=dctcp-10ms'
+//     ./ns3 --run 'tcp-validation --firstTcpType=dctcp --linkRate=50Mbps --baseRtt=10ms --queueUseEcn=1 --stopTime=15s --validate=1 --validation=dctcp-10ms'
 //    - Throughput between 48 Mbps and 49 Mbps for time greater than 5.6s
 //    - DCTCP alpha below 0.1 for time greater than 5.4s
 //    - DCTCP alpha between 0.06 and 0.085 for time greater than 7s
 //
 // Case 'dctcp-80ms': DCTCP single flow, 80ms base RTT, 50 Mbps link, ECN enabled, CoDel:
-//     ./waf --run 'tcp-validation --firstTcpType=dctcp --linkRate=50Mbps --baseRtt=80ms --queueUseEcn=1 --stopTime=40s --validate=1 --validation=dctcp-80ms'
+//     ./ns3 --run 'tcp-validation --firstTcpType=dctcp --linkRate=50Mbps --baseRtt=80ms --queueUseEcn=1 --stopTime=40s --validate=1 --validation=dctcp-80ms'
 //    - Throughput less than 20 Mbps for time less than 14s
 //    - Throughput less than 48 Mbps for time less than 30s
 //    - Throughput between 47.5 Mbps and 48.5 for time greater than 32s
@@ -128,14 +128,14 @@
 //    - DCTCP alpha between 0.015 and 0.025 for time greater than 34
 //
 // Case 'cubic-50ms-no-ecn': CUBIC single flow, 50ms base RTT, 50 Mbps link, ECN disabled, CoDel:
-//     ./waf --run 'tcp-validation --firstTcpType=cubic --linkRate=50Mbps --baseRtt=50ms --queueUseEcn=0 --stopTime=20s --validate=1 --validation=cubic-50ms-no-ecn'
+//     ./ns3 --run 'tcp-validation --firstTcpType=cubic --linkRate=50Mbps --baseRtt=50ms --queueUseEcn=0 --stopTime=20s --validate=1 --validation=cubic-50ms-no-ecn'
 //    - Maximum value of cwnd is 511 segments at 5.4593 seconds
 //    - cwnd decreases to 173 segments at 5.80304 seconds
 //    - cwnd reaches another local maxima around 14.2815 seconds of 236 segments
 //    - cwnd reaches a second maximum around 18.048 seconds of 234 segments
 //
 // Case 'cubic-50ms-ecn': CUBIC single flow, 50ms base RTT, 50 Mbps link, ECN enabled, CoDel:
-//     ./waf --run 'tcp-validation --firstTcpType=cubic --linkRate=50Mbps --baseRtt=50ms --queueUseEcn=0 --stopTime=20s --validate=1 --validation=cubic-50ms-no-ecn'
+//     ./ns3 --run 'tcp-validation --firstTcpType=cubic --linkRate=50Mbps --baseRtt=50ms --queueUseEcn=0 --stopTime=20s --validate=1 --validation=cubic-50ms-no-ecn'
 //    - Maximum value of cwnd is 511 segments at 5.4593 seconds
 //    - cwnd decreases to 173 segments at 5.7939 seconds
 //    - cwnd reaches another local maxima around 14.3477 seconds of 236 segments
diff --git a/examples/wireless/wifi-80211e-txop.cc b/examples/wireless/wifi-80211e-txop.cc
index 43e0932e8..72eebdadf 100644
--- a/examples/wireless/wifi-80211e-txop.cc
+++ b/examples/wireless/wifi-80211e-txop.cc
@@ -55,7 +55,7 @@
 //
 // The user can select the distance between the stations and the APs, can enable/disable the RTS/CTS mechanism
 // and can choose the payload size and the simulation duration.
-// Example: ./waf --run "wifi-80211e-txop --distance=10 --simulationTime=20 --payloadSize=1000"
+// Example: ./ns3 --run "wifi-80211e-txop --distance=10 --simulationTime=20 --payloadSize=1000"
 //
 // The output prints the throughput measured for the 4 cases/networks described above. When TXOP is enabled, results show
 // increased throughput since the channel is granted for a longer duration. TXOP is enabled by default for AC_VI and AC_VO,
diff --git a/examples/wireless/wifi-aggregation.cc b/examples/wireless/wifi-aggregation.cc
index 8c4c42180..8fe4e6fdb 100644
--- a/examples/wireless/wifi-aggregation.cc
+++ b/examples/wireless/wifi-aggregation.cc
@@ -56,7 +56,7 @@
 //Packets in this simulation belong to BestEffort Access Class (AC_BE).
 //
 // The user can select the distance between the stations and the APs and can enable/disable the RTS/CTS mechanism.
-// Example: ./waf --run "wifi-aggregation --distance=10 --enableRts=0 --simulationTime=20"
+// Example: ./ns3 --run "wifi-aggregation --distance=10 --enableRts=0 --simulationTime=20"
 //
 // The output prints the throughput measured for the 4 cases/networks described above. When default aggregation parameters are enabled, the
 // maximum A-MPDU size is 65 kB and the throughput is maximal. When aggregation is disabled, the throughput is about the half of the physical
diff --git a/examples/wireless/wifi-backward-compatibility.cc b/examples/wireless/wifi-backward-compatibility.cc
index d75e4ab15..987b85beb 100644
--- a/examples/wireless/wifi-backward-compatibility.cc
+++ b/examples/wireless/wifi-backward-compatibility.cc
@@ -42,7 +42,7 @@
 // the AP or both has/have traffic to send.
 //
 // Example for an IEEE 802.11ac station sending traffic to an 802.11a AP using Ideal rate adaptation algorithm:
-// ./waf --run "wifi-backward-compatibility --apVersion=80211a --staVersion=80211ac --staRaa=Ideal"
+// ./ns3 --run "wifi-backward-compatibility --apVersion=80211a --staVersion=80211ac --staRaa=Ideal"
 
 using namespace ns3;
 
diff --git a/examples/wireless/wifi-mixed-network.cc b/examples/wireless/wifi-mixed-network.cc
index 4791f792b..7dd943aa8 100644
--- a/examples/wireless/wifi-mixed-network.cc
+++ b/examples/wireless/wifi-mixed-network.cc
@@ -55,7 +55,7 @@
 // short slot time are only observed in a g only configuration.
 //
 // The user can also select the payload size and can choose either an UDP or a TCP connection.
-// Example: ./waf --run "wifi-mixed-network --isUdp=1"
+// Example: ./ns3 --run "wifi-mixed-network --isUdp=1"
 
 using namespace ns3;
 
diff --git a/examples/wireless/wifi-multirate.cc b/examples/wireless/wifi-multirate.cc
index b021efea1..ea8460600 100644
--- a/examples/wireless/wifi-multirate.cc
+++ b/examples/wireless/wifi-multirate.cc
@@ -23,21 +23,21 @@
  * QUICK INSTRUCTIONS:
  *
  * To optimize build:
- * ./waf -d optimized configure
- * ./waf
+ * ./ns3 -d optimized configure
+ * ./ns3
  *
  * To compile:
- * ./waf --run wifi-multirate
+ * ./ns3 --run wifi-multirate
  *
  * To compile with command line(useful for varying parameters):
- * ./waf --run "wifi-multirate --totalTime=0.3s --rateManager=ns3::MinstrelWifiManager"
+ * ./ns3 --run "wifi-multirate --totalTime=0.3s --rateManager=ns3::MinstrelWifiManager"
  *
  * To turn on NS_LOG:
  * export NS_LOG=multirate=level_all
- * (can only view log if built with ./waf -d debug configure)
+ * (can only view log if built with ./ns3 -d debug configure)
  *
  * To debug:
- * ./waf --shell
+ * ./ns3 --shell
  * gdb ./build/debug/examples/wireless/wifi-multirate
  *
  * To view pcap files:
diff --git a/examples/wireless/wifi-power-adaptation-distance.cc b/examples/wireless/wifi-power-adaptation-distance.cc
index 7b3fc99f7..dd8ae210c 100644
--- a/examples/wireless/wifi-power-adaptation-distance.cc
+++ b/examples/wireless/wifi-power-adaptation-distance.cc
@@ -66,17 +66,17 @@
  *
  * To display all the possible arguments and their defaults:
  * \code{.sh}
- *   ./waf --run "wifi-power-adaptation-distance --help"
+ *   ./ns3 --run "wifi-power-adaptation-distance --help"
  * \endcode
  *
  * Example usage (selecting Aparf rather than Parf):
  * \code{.sh}
- *   ./waf --run "wifi-power-adaptation-distance --manager=ns3::AparfWifiManager --outputFileName=aparf"
+ *   ./ns3 --run "wifi-power-adaptation-distance --manager=ns3::AparfWifiManager --outputFileName=aparf"
  * \endcode
  *
  * Another example (moving towards the AP):
  * \code{.sh}
- *   ./waf --run "wifi-power-adaptation-distance --manager=ns3::AparfWifiManager --outputFileName=aparf --stepsSize=-1 --STA1_x=200"
+ *   ./ns3 --run "wifi-power-adaptation-distance --manager=ns3::AparfWifiManager --outputFileName=aparf --stepsSize=-1 --STA1_x=200"
  * \endcode
  *
  * To enable the log of rate and power changes:
diff --git a/examples/wireless/wifi-power-adaptation-interference.cc b/examples/wireless/wifi-power-adaptation-interference.cc
index 5f6921b80..e25b46eb0 100644
--- a/examples/wireless/wifi-power-adaptation-interference.cc
+++ b/examples/wireless/wifi-power-adaptation-interference.cc
@@ -41,12 +41,12 @@
  *
  * Example usage:
  * \code{.sh}
- *   ./waf --run "wifi-power-adaptation-interference --manager=ns3::AparfWifiManager --outputFileName=aparf"
+ *   ./ns3 --run "wifi-power-adaptation-interference --manager=ns3::AparfWifiManager --outputFileName=aparf"
  * \endcode
  *
  * Another example (changing STAs position):
  * \code{.sh}
- *   ./waf --run "wifi-power-adaptation-interference --manager=ns3::AparfWifiManager --outputFileName=aparf --STA1_x=5 --STA2_x=205"
+ *   ./ns3 --run "wifi-power-adaptation-interference --manager=ns3::AparfWifiManager --outputFileName=aparf --STA1_x=5 --STA2_x=205"
  * \endcode
  *
  * To enable the log of rate and power changes:
diff --git a/examples/wireless/wifi-rate-adaptation-distance.cc b/examples/wireless/wifi-rate-adaptation-distance.cc
index 11d6db4b7..b93d02858 100644
--- a/examples/wireless/wifi-rate-adaptation-distance.cc
+++ b/examples/wireless/wifi-rate-adaptation-distance.cc
@@ -38,13 +38,13 @@
  * - (if logging is enabled) the changes of rate to standard output.
  *
  * Example usage:
- * ./waf --run "wifi-rate-adaptation-distance --standard=802.11a --staManager=ns3::MinstrelWifiManager --apManager=ns3::MinstrelWifiManager --outputFileName=minstrel"
+ * ./ns3 --run "wifi-rate-adaptation-distance --standard=802.11a --staManager=ns3::MinstrelWifiManager --apManager=ns3::MinstrelWifiManager --outputFileName=minstrel"
  *
  * Another example (moving towards the AP):
- * ./waf --run "wifi-rate-adaptation-distance --standard=802.11a --staManager=ns3::MinstrelWifiManager --apManager=ns3::MinstrelWifiManager --outputFileName=minstrel --stepsSize=1 --STA1_x=-200"
+ * ./ns3 --run "wifi-rate-adaptation-distance --standard=802.11a --staManager=ns3::MinstrelWifiManager --apManager=ns3::MinstrelWifiManager --outputFileName=minstrel --stepsSize=1 --STA1_x=-200"
  *
  * Example for HT rates with SGI and channel width of 40MHz:
- * ./waf --run "wifi-rate-adaptation-distance --staManager=ns3::MinstrelHtWifiManager --apManager=ns3::MinstrelHtWifiManager --outputFileName=minstrelHt --shortGuardInterval=true --channelWidth=40"
+ * ./ns3 --run "wifi-rate-adaptation-distance --staManager=ns3::MinstrelHtWifiManager --apManager=ns3::MinstrelHtWifiManager --outputFileName=minstrelHt --shortGuardInterval=true --channelWidth=40"
  *
  * To enable the log of rate changes:
  * export NS_LOG=RateAdaptationDistance=level_info
diff --git a/examples/wireless/wifi-simple-adhoc-grid.cc b/examples/wireless/wifi-simple-adhoc-grid.cc
index c38972952..067ef17da 100644
--- a/examples/wireless/wifi-simple-adhoc-grid.cc
+++ b/examples/wireless/wifi-simple-adhoc-grid.cc
@@ -37,7 +37,7 @@
 // There are a number of command-line options available to control
 // the default behavior.  The list of available command-line options
 // can be listed with the following command:
-// ./waf --run "wifi-simple-adhoc-grid --help"
+// ./ns3 --run "wifi-simple-adhoc-grid --help"
 //
 // Note that all ns-3 attributes (not just the ones exposed in the below
 // script) can be changed at command line; see the ns-3 documentation.
@@ -47,21 +47,21 @@
 // the default of 500m.
 // To see this effect, try running:
 //
-// ./waf --run "wifi-simple-adhoc-grid --distance=500"
-// ./waf --run "wifi-simple-adhoc-grid --distance=1000"
-// ./waf --run "wifi-simple-adhoc-grid --distance=1500"
+// ./ns3 --run "wifi-simple-adhoc-grid --distance=500"
+// ./ns3 --run "wifi-simple-adhoc-grid --distance=1000"
+// ./ns3 --run "wifi-simple-adhoc-grid --distance=1500"
 //
 // The source node and sink node can be changed like this:
 //
-// ./waf --run "wifi-simple-adhoc-grid --sourceNode=20 --sinkNode=10"
+// ./ns3 --run "wifi-simple-adhoc-grid --sourceNode=20 --sinkNode=10"
 //
 // This script can also be helpful to put the Wifi layer into verbose
 // logging mode; this command will turn on all wifi logging:
 //
-// ./waf --run "wifi-simple-adhoc-grid --verbose=1"
+// ./ns3 --run "wifi-simple-adhoc-grid --verbose=1"
 //
 // By default, trace file writing is off-- to enable it, try:
-// ./waf --run "wifi-simple-adhoc-grid --tracing=1"
+// ./ns3 --run "wifi-simple-adhoc-grid --tracing=1"
 //
 // When you are done tracing, you will notice many pcap trace files
 // in your directory.  If you have tcpdump installed, you can try this:
diff --git a/examples/wireless/wifi-simple-adhoc.cc b/examples/wireless/wifi-simple-adhoc.cc
index 7dd19956a..14efcd76f 100644
--- a/examples/wireless/wifi-simple-adhoc.cc
+++ b/examples/wireless/wifi-simple-adhoc.cc
@@ -26,15 +26,15 @@
 // There are a number of command-line options available to control
 // the default behavior.  The list of available command-line options
 // can be listed with the following command:
-// ./waf --run "wifi-simple-adhoc --help"
+// ./ns3 --run "wifi-simple-adhoc --help"
 //
 // For instance, for this configuration, the physical layer will
 // stop successfully receiving packets when rss drops below -97 dBm.
 // To see this effect, try running:
 //
-// ./waf --run "wifi-simple-adhoc --rss=-97 --numPackets=20"
-// ./waf --run "wifi-simple-adhoc --rss=-98 --numPackets=20"
-// ./waf --run "wifi-simple-adhoc --rss=-99 --numPackets=20"
+// ./ns3 --run "wifi-simple-adhoc --rss=-97 --numPackets=20"
+// ./ns3 --run "wifi-simple-adhoc --rss=-98 --numPackets=20"
+// ./ns3 --run "wifi-simple-adhoc --rss=-99 --numPackets=20"
 //
 // Note that all ns-3 attributes (not just the ones exposed in the below
 // script) can be changed at command line; see the documentation.
@@ -42,7 +42,7 @@
 // This script can also be helpful to put the Wifi layer into verbose
 // logging mode; this command will turn on all wifi logging:
 //
-// ./waf --run "wifi-simple-adhoc --verbose=1"
+// ./ns3 --run "wifi-simple-adhoc --verbose=1"
 //
 // When you are done, you will notice two pcap trace files in your directory.
 // If you have tcpdump installed, you can try this:
diff --git a/examples/wireless/wifi-simple-ht-hidden-stations.cc b/examples/wireless/wifi-simple-ht-hidden-stations.cc
index d51634af3..008bfe603 100644
--- a/examples/wireless/wifi-simple-ht-hidden-stations.cc
+++ b/examples/wireless/wifi-simple-ht-hidden-stations.cc
@@ -36,7 +36,7 @@
 // This example considers two hidden stations in an 802.11n network which supports MPDU aggregation.
 // The user can specify whether RTS/CTS is used and can set the number of aggregated MPDUs.
 //
-// Example: ./waf --run "wifi-simple-ht-hidden-stations --enableRts=1 --nMpdus=8"
+// Example: ./ns3 --run "wifi-simple-ht-hidden-stations --enableRts=1 --nMpdus=8"
 //
 // Network topology:
 //
diff --git a/examples/wireless/wifi-simple-infra.cc b/examples/wireless/wifi-simple-infra.cc
index 83f744562..26701355c 100644
--- a/examples/wireless/wifi-simple-infra.cc
+++ b/examples/wireless/wifi-simple-infra.cc
@@ -27,15 +27,15 @@
 // There are a number of command-line options available to control
 // the default behavior.  The list of available command-line options
 // can be listed with the following command:
-// ./waf --run "wifi-simple-infra --help"
+// ./ns3 --run "wifi-simple-infra --help"
 //
 // For instance, for this configuration, the physical layer will
 // stop successfully receiving packets when rss drops below -97 dBm.
 // To see this effect, try running:
 //
-// ./waf --run "wifi-simple-infra --rss=-97 --numPackets=20"
-// ./waf --run "wifi-simple-infra --rss=-98 --numPackets=20"
-// ./waf --run "wifi-simple-infra --rss=-99 --numPackets=20"
+// ./ns3 --run "wifi-simple-infra --rss=-97 --numPackets=20"
+// ./ns3 --run "wifi-simple-infra --rss=-98 --numPackets=20"
+// ./ns3 --run "wifi-simple-infra --rss=-99 --numPackets=20"
 //
 // Note that all ns-3 attributes (not just the ones exposed in the below
 // script) can be changed at command line; see the documentation.
@@ -43,7 +43,7 @@
 // This script can also be helpful to put the Wifi layer into verbose
 // logging mode; this command will turn on all wifi logging:
 //
-// ./waf --run "wifi-simple-infra --verbose=1"
+// ./ns3 --run "wifi-simple-infra --verbose=1"
 //
 // When you are done, you will notice two pcap trace files in your directory.
 // If you have tcpdump installed, you can try this:
diff --git a/examples/wireless/wifi-simple-interference.cc b/examples/wireless/wifi-simple-interference.cc
index 360672a4f..9c73bbdd1 100644
--- a/examples/wireless/wifi-simple-interference.cc
+++ b/examples/wireless/wifi-simple-interference.cc
@@ -58,7 +58,7 @@
 // For instance, for this configuration, the interfering frame arrives
 // at -90 dBm with a time offset of 3.2 microseconds:
 //
-// ./waf --run "wifi-simple-interference --Irss=-90 --delta=3.2"
+// ./ns3 --run "wifi-simple-interference --Irss=-90 --delta=3.2"
 //
 // Note that all ns-3 attributes (not just the ones exposed in the below
 // script) can be changed at command line; see the documentation.
@@ -66,7 +66,7 @@
 // This script can also be helpful to put the Wifi layer into verbose
 // logging mode; this command will turn on all wifi logging:
 //
-// ./waf --run "wifi-simple-interference --verbose=1"
+// ./ns3 --run "wifi-simple-interference --verbose=1"
 //
 // When you are done, you will notice a pcap trace file in your directory.
 // If you have tcpdump installed, you can try this:
@@ -77,7 +77,7 @@
 //
 // Next, try this command and look at the tcpdump-- you should see two packets
 // that are no longer interfering:
-// ./waf --run "wifi-simple-interference --delta=30000"
+// ./ns3 --run "wifi-simple-interference --delta=30000"
 
 #include "ns3/command-line.h"
 #include "ns3/config.h"
diff --git a/examples/wireless/wifi-sleep.cc b/examples/wireless/wifi-sleep.cc
index 4842d309c..98c8bd5da 100644
--- a/examples/wireless/wifi-sleep.cc
+++ b/examples/wireless/wifi-sleep.cc
@@ -31,7 +31,7 @@
 // There are a number of command-line options available to control
 // the default behavior.  The list of available command-line options
 // can be listed with the following command:
-// ./waf --run "wifi-sleep --help"
+// ./ns3 --run "wifi-sleep --help"
 //
 // Note that all ns-3 attributes (not just the ones exposed in the below
 // script) can be changed at command line; see the documentation.
@@ -39,7 +39,7 @@
 // This script can also be helpful to put the Wifi layer into verbose
 // logging mode; this command will turn on all wifi logging:
 //
-// ./waf --run "wifi-sleep --verbose=1"
+// ./ns3 --run "wifi-sleep --verbose=1"
 //
 // When you are done, you will notice four trace files in your directory:
 // two for the remaining energy on each node and two for the state transitions
diff --git a/examples/wireless/wifi-spatial-reuse.cc b/examples/wireless/wifi-spatial-reuse.cc
index cc1bf199a..cfc3a19c6 100644
--- a/examples/wireless/wifi-spatial-reuse.cc
+++ b/examples/wireless/wifi-spatial-reuse.cc
@@ -42,15 +42,15 @@
 //
 //  In general, the program can be configured at run-time by passing command-line arguments.
 //  The following command will display all of the available run-time help options:
-//    ./waf --run "wifi-spatial-reuse --help"
+//    ./ns3 --run "wifi-spatial-reuse --help"
 //
 //  By default, the script shows the benefit of the OBSS_PD spatial reuse script:
-//    ./waf --run wifi-spatial-reuse
+//    ./ns3 --run wifi-spatial-reuse
 //    Throughput for BSS 1: 6.6468 Mbit/s
 //    Throughput for BSS 2: 6.6672 Mbit/s
 //
 // If one disables the OBSS_PD feature, a lower throughput is obtained per BSS:
-//    ./waf --run "wifi-spatial-reuse --enableObssPd=0"
+//    ./ns3 --run "wifi-spatial-reuse --enableObssPd=0"
 //    Throughput for BSS 1: 5.8692 Mbit/s
 //    Throughput for BSS 2: 5.9364 Mbit/
 //
diff --git a/examples/wireless/wifi-timing-attributes.cc b/examples/wireless/wifi-timing-attributes.cc
index 03b232ebe..ee6c0c1cc 100644
--- a/examples/wireless/wifi-timing-attributes.cc
+++ b/examples/wireless/wifi-timing-attributes.cc
@@ -38,7 +38,7 @@
 //
 // Example: set slot time to 20 microseconds, while keeping other values as defined in the simulation script:
 //
-//          ./waf --run "wifi-timing-attributes --slot=20"
+//          ./ns3 --run "wifi-timing-attributes --slot=20"
 //
 // Network topology:
 //
diff --git a/examples/wireless/wifi-txop-aggregation.cc b/examples/wireless/wifi-txop-aggregation.cc
index 6fb160153..6b3abc88f 100644
--- a/examples/wireless/wifi-txop-aggregation.cc
+++ b/examples/wireless/wifi-txop-aggregation.cc
@@ -57,7 +57,7 @@
 //
 // The user can select the distance between the stations and the APs, can enable/disable the RTS/CTS mechanism
 // and can modify the duration of a TXOP.
-// Example: ./waf --run "wifi-txop-aggregation --distance=10 --enableRts=0 --simulationTime=20"
+// Example: ./ns3 --run "wifi-txop-aggregation --distance=10 --enableRts=0 --simulationTime=20"
 //
 // The output prints the throughput and the maximum TXOP duration measured for the 4 cases/networks
 // described above. When default aggregation parameters are enabled, the
diff --git a/src/applications/doc/applications.rst b/src/applications/doc/applications.rst
index 2d51bf928..7b3c5a6bf 100644
--- a/src/applications/doc/applications.rst
+++ b/src/applications/doc/applications.rst
@@ -211,7 +211,7 @@ Examples
 For an example demonstrating HTTP applications
 run::
 
-  $ ./waf --run 'three-gpp-http-example'
+  $ ./ns3 --run 'three-gpp-http-example'
 
 By default, the example will print out the web page requests of the client and responses of the 
 server and client receiving content packets by using LOG_INFO of ``ThreeGppHttpServer`` and ``ThreeGppHttpClient``. 
diff --git a/src/brite/doc/brite.rst b/src/brite/doc/brite.rst
index a1addd6ae..c65c1bda9 100644
--- a/src/brite/doc/brite.rst
+++ b/src/brite/doc/brite.rst
@@ -97,7 +97,7 @@ directory.
 Once BRITE has been built successfully, we proceed to configure ns-3 with 
 BRITE support. Change to your ns-3 directory::
 
-  $ ./waf configure --with-brite=/your/path/to/brite/source --enable-examples
+  $ ./ns3 configure --with-brite=/your/path/to/brite/source --enable-examples
 
 Make sure it says 'enabled' beside 'BRITE Integration'. If it does not, then 
 something has gone wrong. Either you have forgotten to build BRITE first 
@@ -105,14 +105,14 @@ following the steps above, or ns-3 could not find your BRITE directory.
 
 Next, build ns-3::
 
-  $ ./waf
+  $ ./ns3
 
 Examples
 ========
 For an example demonstrating BRITE integration
 run::
 
-  $ ./waf --run 'brite-generic-example'
+  $ ./ns3 --run 'brite-generic-example'
 
 By enabling the verbose parameter, the example will print out the node and 
 edge information in a similar format to standard BRITE output. There are 
@@ -133,13 +133,13 @@ many other command-line parameters including confFile, tracing, and nix, describ
 The generic BRITE example also support visualization using pyviz, assuming
 python bindings in ns-3 are enabled::
 
-  $ ./waf --run brite-generic-example --vis
+  $ ./ns3 --run brite-generic-example --vis
   
 Simulations involving BRITE can also be used with MPI.  The total number of MPI instances is 
 passed to the BRITE topology helper where a modulo divide is used to assign the nodes for each 
 AS to a MPI instance.  An example can be found in src/brite/examples::
 
-  $ mpirun -np 2 ./waf --run brite-MPI-example
+  $ mpirun -np 2 ./ns3 --run brite-MPI-example
 	
 Please see the ns-3 MPI documentation for information on setting up MPI with ns-3.
 
diff --git a/src/buildings/doc/source/buildings-testing.rst b/src/buildings/doc/source/buildings-testing.rst
index 66139e59e..c64fb630b 100644
--- a/src/buildings/doc/source/buildings-testing.rst
+++ b/src/buildings/doc/source/buildings-testing.rst
@@ -10,7 +10,7 @@ Overview
 
 To test and validate the ns-3 Building Pathloss module, some test suites is provided which are integrated with the ns-3 test framework. To run them, you need to have configured the build of the simulator in this way::
 
-    $ ./waf configure --enable-tests --enable-modules=buildings
+    $ ./ns3 configure --enable-tests --enable-modules=buildings
     $ ./test.py
 
 The above will run not only the test suites belonging to the buildings module, but also those belonging to all the other ns-3 modules on which the buildings module depends. See the ns-3 manual for generic information on the testing framework.
diff --git a/src/click/doc/click.rst b/src/click/doc/click.rst
index d454c2a6f..dc48e3dd2 100644
--- a/src/click/doc/click.rst
+++ b/src/click/doc/click.rst
@@ -91,7 +91,7 @@ The --enable-wifi flag may be skipped if you don't intend on using Click with Wi
 Once Click has been built successfully, change into the ns-3 directory and 
 configure ns-3 with Click Integration support::
 
-  $ ./waf configure --enable-examples --enable-tests --with-nsclick=/path/to/click/source
+  $ ./ns3 configure --enable-examples --enable-tests --with-nsclick=/path/to/click/source
 
 Hint:  If you have click installed one directory above ns-3 (such as in the
 ns-3-allinone directory), and the name of the directory is 'click' (or
@@ -103,7 +103,7 @@ If it says 'enabled' beside 'NS-3 Click Integration Support', then you're good t
 
 Next, try running one of the examples::
 
-  $ ./waf --run nsclick-simple-lan
+  $ ./ns3 --run nsclick-simple-lan
 
 You may then view the resulting .pcap traces, which are named nsclick-simple-lan-0-0.pcap and nsclick-simple-lan-0-1.pcap.
 
diff --git a/src/core/examples/hash-example.cc b/src/core/examples/hash-example.cc
index d0e4ccb9d..e87c10288 100644
--- a/src/core/examples/hash-example.cc
+++ b/src/core/examples/hash-example.cc
@@ -40,7 +40,7 @@
  *  Example Output:
  *  \verbatim
 
-./waf --run="hasher-example --time \
+./ns3 --run="hasher-example --time \
   --dict=/usr/share/dict/web2 \
   --dict=/usr/share/dict/web2a \
   --dict=/usr/share/dict/propernames \
diff --git a/src/core/examples/sample-log-time-format.cc b/src/core/examples/sample-log-time-format.cc
index b605bd2d9..8d7d9a7f7 100644
--- a/src/core/examples/sample-log-time-format.cc
+++ b/src/core/examples/sample-log-time-format.cc
@@ -28,7 +28,7 @@
  * occur at future times.  When run with no arguments, it prints out
  * something like this:
  * \code
- * $ ./waf --run sample-log-time-format
+ * $ ./ns3 --run sample-log-time-format
  * RandomVariableStream:RandomVariableStream(0x184e3a0)
  * RandomVariableStream:UniformRandomVariable(0x184e3a0)
  * RandomVariableStream:SetStream(0x184e3a0, -1)
@@ -60,7 +60,7 @@
  * replacement function for printing time.  This can be demonstrated
  * by setting the 'replace-time-printer' parameter to true:
  * \code
- * ./waf --run 'sample-log-time-format --replaceTimePrinter=1'
+ * ./ns3 --run 'sample-log-time-format --replaceTimePrinter=1'
  * RandomVariableStream:RandomVariableStream(0x15fb080)
  * RandomVariableStream:UniformRandomVariable(0x15fb080)
  * RandomVariableStream:SetStream(0x15fb080, -1)
diff --git a/src/core/examples/sample-random-variable-stream.cc b/src/core/examples/sample-random-variable-stream.cc
index c00f1016f..2c5b0ba28 100644
--- a/src/core/examples/sample-random-variable-stream.cc
+++ b/src/core/examples/sample-random-variable-stream.cc
@@ -27,8 +27,8 @@
  * \ingroup randomvariable
  * Example program illustrating use of ns3::RandomVariableStream
  *
- * This program can be run from waf such as
- * `./waf --run sample-random-variable-stream`
+ * This program can be run from ns3 such as
+ * `./ns3 --run sample-random-variable-stream`
  *
  * This program is about as simple as possible to display the use of ns-3
  * to generate random numbers.  By default, the uniform random variate that
@@ -44,9 +44,9 @@
  * 1. Through explicit call of SeedManager::SetSeed () and
  *    SeedManager::SetRun () (commented out below)
  * 2. Through the passing of command line arguments such as:
- *    `./waf --command-template="%s --RngRun=<value>" --run program-name`
+ *    `./ns3 --command-template="%s --RngRun=<value>" --run program-name`
  * 3. Through the use of the NS_GLOBAL_VALUE environment variable, such as:
- *    `$ NS_GLOBAL_VALUE="RngRun=<value>" ./waf --run program-name`
+ *    `$ NS_GLOBAL_VALUE="RngRun=<value>" ./ns3 --run program-name`
  *
  * For instance, setting the run number to 3 will change the program output to
  * 0.775417
diff --git a/src/core/examples/sample-random-variable.cc b/src/core/examples/sample-random-variable.cc
index d38cf63f2..3b2526f24 100644
--- a/src/core/examples/sample-random-variable.cc
+++ b/src/core/examples/sample-random-variable.cc
@@ -29,8 +29,8 @@
 using namespace ns3;
 
 /**
- * This program can be run from waf such as
- * `./waf --run sample-random-variable`
+ * This program can be run from ns3 such as
+ * `./ns3 --run sample-random-variable`
  *
  * This program is about as simple as possible to display the use of ns-3
  * to generate random numbers.  By default, the uniform random variate that
@@ -46,9 +46,9 @@ using namespace ns3;
  * 1. Through explicit call of SeedManager::SetSeed () and
  *    SeedManager::SetRun () (commented out below)
  * 2. Through the passing of command line arguments such as:
- *    ./waf --command-template="%s --RngRun=<value>" --run program-name`
+ *    ./ns3 --command-template="%s --RngRun=<value>" --run program-name`
  * 3. Through the use of the NS_GLOBAL_VALUE environment variable, such as:
- *    `$ NS_GLOBAL_VALUE="RngRun=<value>" ./waf --run program-name`
+ *    `$ NS_GLOBAL_VALUE="RngRun=<value>" ./ns3 --run program-name`
  *
  * For instance, setting the run number to 3 will change the program output to
  * 0.775417
diff --git a/src/core/model/command-line.cc b/src/core/model/command-line.cc
index 2516f1794..e56f66364 100644
--- a/src/core/model/command-line.cc
+++ b/src/core/model/command-line.cc
@@ -385,7 +385,7 @@ CommandLine::PrintDoxygenUsage (void) const
 
   os << "/**\n \\file " << m_shortName << ".cc\n"
      << "<h3>Usage</h3>\n"
-     << "<code>$ ./waf --run \"" << m_shortName
+     << "<code>$ ./ns3 --run \"" << m_shortName
      << (m_options.size ()  ? " [Program Options]" : "")
      << (nonOptions.size () ? " [Program Arguments]" : "")
      << "\"</code>\n";
diff --git a/src/core/model/command-line.h b/src/core/model/command-line.h
index 6263ee70c..c5cc0ec26 100644
--- a/src/core/model/command-line.h
+++ b/src/core/model/command-line.h
@@ -155,19 +155,19 @@ namespace ns3 {
  * Here is the output from a few runs of that program:
  *
  * \verbatim
-   $ ./waf --run="command-line-example"
+   $ ./ns3 --run="command-line-example"
    intArg:   1
    boolArg:  false
    strArg:   "strArg default"
    cbArg:    "cbArg default"
 
-   $ ./waf --run="command-line-example --intArg=2 --boolArg --strArg=Hello --cbArg=World"
+   $ ./ns3 --run="command-line-example --intArg=2 --boolArg --strArg=Hello --cbArg=World"
    intArg:   2
    boolArg:  true
    strArg:   "Hello"
    cbArg:    "World"
 
-   $ ./waf --run="command-line-example --help"
+   $ ./ns3 --run="command-line-example --help"
    ns3-dev-command-line-example-debug [Program Arguments] [General Arguments]
 
    CommandLine example program.
@@ -583,7 +583,7 @@ private:
   std::size_t m_NNonOptions;            /**< The expected number of non-option arguments */
   std::size_t m_nonOptionCount;         /**< The number of actual non-option arguments seen so far. */
   std::string m_usage;                  /**< The Usage string */
-  std::string m_shortName;              /**< The source file name (without `.cc`), as would be given to `waf --run` */
+  std::string m_shortName;              /**< The source file name (without `.cc`), as would be given to `ns3 --run` */
 
 };  // class CommandLine
 
diff --git a/src/core/model/des-metrics.h b/src/core/model/des-metrics.h
index dfbf37f25..abe8d1c03 100644
--- a/src/core/model/des-metrics.h
+++ b/src/core/model/des-metrics.h
@@ -88,14 +88,14 @@ namespace ns3 {
  *
  * Enable DES Metrics at configure time with
  * \verbatim
-   $ waf configure ... --enable-des-metrics \endverbatim
+   $ ns3 configure ... --enable-des-metrics \endverbatim
  *
  * <b> Working with DES Metrics </b>
  *
  * Some useful shell pipelines:
  *
  * \li Run everything, retaining the results directory: <br/>
- *   \code  ./test.py --nowaf --retain \endcode
+ *   \code  ./test.py --nobuild --retain \endcode
  * \li Example traces end up in \c testpy-output/, so move there: <br/>
  *   \code cd testpy-output/$(date +"%F")*_/  \endcode
  *   (Remove the `_', which is to work around a Doxygen limitation.)
diff --git a/src/core/model/example-as-test.cc b/src/core/model/example-as-test.cc
index 105aca4a6..8c32624c0 100644
--- a/src/core/model/example-as-test.cc
+++ b/src/core/model/example-as-test.cc
@@ -100,7 +100,7 @@ ExampleAsTestCase::DoRun (void)
      << GetPostProcessingCommand ()
      << " > " << testFile
 
-    // Get the status of waf
+    // Get the status of ns3
      << "; exit ${PIPESTATUS[0]}'";
 
   int status = std::system (ss.str ().c_str ());
diff --git a/src/core/model/example-as-test.h b/src/core/model/example-as-test.h
index beb610463..1a01b8428 100644
--- a/src/core/model/example-as-test.h
+++ b/src/core/model/example-as-test.h
@@ -78,7 +78,7 @@ public:
    * Customization point for more complicated patterns
    * to invoke the example program.
    *
-   * \returns The string to be given to the `waf --command-template=` argument.
+   * \returns The string to be given to the `ns3 --command-template=` argument.
    */
   virtual std::string GetCommandTemplate (void) const;
 
diff --git a/src/core/model/log.h b/src/core/model/log.h
index 3bb57bc10..daf09ed1d 100644
--- a/src/core/model/log.h
+++ b/src/core/model/log.h
@@ -54,11 +54,11 @@
  * Use the environment variable NS_LOG to define a ':'-separated list of
  * logging components to enable. For example (using bash syntax),
  * \code
- *   $ NS_LOG="OlsrAgent" ./waf --run ...
+ *   $ NS_LOG="OlsrAgent" ./ns3 --run ...
  * \endcode
  * would enable one component at all log levels.
  * \code
- *   $NS_LOG="OlsrAgent:Ipv4L3Protocol" ./waf --run ...
+ *   $NS_LOG="OlsrAgent:Ipv4L3Protocol" ./ns3 --run ...
  * \endcode
  * would enable two components, at all log levels, etc.
  * \c NS_LOG="*" will enable all available log components at all levels.
diff --git a/src/core/model/test.cc b/src/core/model/test.cc
index 6adac4aa5..bbf8e3f12 100644
--- a/src/core/model/test.cc
+++ b/src/core/model/test.cc
@@ -325,7 +325,7 @@ TestCase::AddTestCase (TestCase *testCase, enum TestCase::TestDuration duration)
       /*
         To count the bad test names, use NS_LOG_UNCOND instead
         of NS_FATAL_ERROR, and the command
-        $ ./waf --run "test-runner --list" 2>&1 | grep "^Invalid" | wc
+        $ ./ns3 --run "test-runner --list" 2>&1 | grep "^Invalid" | wc
       */
       NS_LOG_UNCOND ("Invalid test name: cannot contain any of '"
                      << badchars << "': " << testCase->m_name);
diff --git a/src/core/model/version-defines.h.in b/src/core/model/version-defines.h.in
index ad70eeb72..319d75e96 100644
--- a/src/core/model/version-defines.h.in
+++ b/src/core/model/version-defines.h.in
@@ -134,7 +134,7 @@
 
 /**
  * Indicates the build profile that was specified by the --build-profile option
- * of "waf configure"
+ * of "ns3 configure"
  *
  * Type: string literal
  */
diff --git a/src/core/model/version.h b/src/core/model/version.h
index 117e92545..574c767a7 100644
--- a/src/core/model/version.h
+++ b/src/core/model/version.h
@@ -94,7 +94,7 @@ namespace ns3 {
  * | TagDistance        | 1        |       |
  * | CommitHash         | g6ad7f05 | g at front of hash indicates a git hash |
  * | DirtyWorkingTree   | Variable | Depends on status of git working and stage areas |
- * | BuildProfile       | Variable | Depends on the value of --build-profile option of waf configure |
+ * | BuildProfile       | Variable | Depends on the value of --build-profile option of ns3 configure |
  */
 class Version
 {
@@ -207,7 +207,7 @@ public:
   /**
    * Indicates the type of build that was performed (debug/release/optimized).
    *
-   * This information is set by the --build-profile option of waf configure
+   * This information is set by the --build-profile option of ns3 configure
    *
    * \return String containing the type of build
    */
diff --git a/src/core/test/random-variable-stream-test-suite.cc b/src/core/test/random-variable-stream-test-suite.cc
index c24de998a..22b3948f3 100644
--- a/src/core/test/random-variable-stream-test-suite.cc
+++ b/src/core/test/random-variable-stream-test-suite.cc
@@ -301,7 +301,7 @@ public:
    * deterministic value of seed=3 and default run number=1 every time:
    *   NS_GLOBAL_VALUE="RngSeed=3" ./test.py -s random-variable-stream-generators
    * or equivalently (to see log output):
-   *   NS_LOG="RandomVariableStreamGenerators" NS_GLOBAL_VALUE="RngSeed=3" ./waf --run "test-runner --suite=random-variable-stream-generators"
+   *   NS_LOG="RandomVariableStreamGenerators" NS_GLOBAL_VALUE="RngSeed=3" ./ns3 --run "test-runner --suite=random-variable-stream-generators"
    *
    * Conversely, this command will cause this test suite to use a seed
    * based on time-of-day, and run number=0: 
diff --git a/src/fd-net-device/doc/dpdk-net-device.rst b/src/fd-net-device/doc/dpdk-net-device.rst
index f37797ec6..f24c6b96b 100644
--- a/src/fd-net-device/doc/dpdk-net-device.rst
+++ b/src/fd-net-device/doc/dpdk-net-device.rst
@@ -148,7 +148,7 @@ For example:
  export RTE_SDK=/home/username/dpdk/dpdk-stable-19.11.1
  export RTE_TARGET=x86_64-native-linuxapp-gcc
 
-(Note: In case DPDK is moved, ns-3 needs to be reconfigured using ``./waf configure [options]``)
+(Note: In case DPDK is moved, ns-3 needs to be reconfigured using ``./ns3 configure [options]``)
 
 It is advisable that you export these variables in ``.bashrc`` or similar for reusability.
 
@@ -231,7 +231,7 @@ The mount point can be made permanent across reboots, by adding the following li
 Usage
 *****
 
-The status of DPDK support is shown in the output of ``./waf configure``.  If
+The status of DPDK support is shown in the output of ``./ns3 configure``.  If
 it is found, a user should see:
 
 .. sourcecode:: text
diff --git a/src/fd-net-device/doc/fd-net-device.rst b/src/fd-net-device/doc/fd-net-device.rst
index dddac3013..28d420d95 100644
--- a/src/fd-net-device/doc/fd-net-device.rst
+++ b/src/fd-net-device/doc/fd-net-device.rst
@@ -143,7 +143,7 @@ Each individual helper (file descriptor type) may have platform
 limitations.  For instance, threading, real-time simulation mode, and the
 ability to create TUN/TAP devices are prerequisites to using the
 provided helpers.  Support for these modes can be found in the output
-of the ``waf configure`` step, e.g.:
+of the ``ns3 configure`` step, e.g.:
 
 .. sourcecode:: text
 
@@ -196,7 +196,7 @@ permissions. Rather than force the user to execute the entire simulation as
 root, we provide a small "creator" program that runs as root and does any
 required high-permission sockets work. The easiest way to set the right 
 privileges for the "creator" programs, is by enabling the ``--enable-sudo``
-flag when performing ``waf configure``.
+flag when performing ``ns3 configure``.
 
 We do a similar thing for both the ``Emu`` and the ``Tap`` devices.  The
 high-level view is that the ``CreateFileDescriptor`` method creates a local interprocess
diff --git a/src/fd-net-device/doc/netmap-net-device.rst b/src/fd-net-device/doc/netmap-net-device.rst
index 11faaaa83..c333c6fb1 100644
--- a/src/fd-net-device/doc/netmap-net-device.rst
+++ b/src/fd-net-device/doc/netmap-net-device.rst
@@ -127,7 +127,7 @@ If not, it will report:
   Netmap emulation FdNetDevice  : not enabled (needs net/netmap_user.h)
 
 To run FdNetDevice-enabled simulations, one must pass the ``--enable-sudo``
-option to ``./waf configure``, or else run the simulations with root
+option to ``./ns3 configure``, or else run the simulations with root
 privileges.
 
 Helpers
diff --git a/src/fd-net-device/examples/fd-emu-onoff.cc b/src/fd-net-device/examples/fd-emu-onoff.cc
index fecc5ed4c..e83679e21 100644
--- a/src/fd-net-device/examples/fd-emu-onoff.cc
+++ b/src/fd-net-device/examples/fd-emu-onoff.cc
@@ -78,7 +78,7 @@
 //      build netmap/dpdk separately.
 //
 // 4 - Give root suid to the raw or netmap socket creator binary.
-//     If the --enable-sudo option was used to configure ns-3 with waf, then the following
+//     If the --enable-sudo option was used to configure ns-3 with ns3, then the following
 //     step will not be necessary.
 //
 // both hosts: $ sudo chown root.root build/src/fd-net-device/ns3-dev-raw-sock-creator
@@ -96,11 +96,11 @@
 //
 // 6 - Run the server side:
 //
-// server host: $ ./waf --run="fd-emu-onoff --serverMode=1"
+// server host: $ ./ns3 --run="fd-emu-onoff --serverMode=1"
 //
 // 7 - Run the client side:
 //
-// client host: $ ./waf --run="fd-emu-onoff"
+// client host: $ ./ns3 --run="fd-emu-onoff"
 //
 
 #include <iostream>
diff --git a/src/fd-net-device/examples/fd-emu-ping.cc b/src/fd-net-device/examples/fd-emu-ping.cc
index 4fcade51e..089b389d2 100644
--- a/src/fd-net-device/examples/fd-emu-ping.cc
+++ b/src/fd-net-device/examples/fd-emu-ping.cc
@@ -69,7 +69,7 @@
 //     on your host.  Search for "Ipv4Address gateway" and replace the string
 //     "1.2.3.4" string with the gateway IP address.
 //  6) Give root suid to the raw or netmap socket creator binary.
-//     If the --enable-sudo option was used to configure ns-3 with waf, then the following
+//     If the --enable-sudo option was used to configure ns-3 with ns3, then the following
 //     step will not be necessary.
 //
 //     $ sudo chown root.root build/src/fd-net-device/ns3-dev-raw-sock-creator
diff --git a/src/fd-net-device/examples/fd-tap-ping.cc b/src/fd-net-device/examples/fd-tap-ping.cc
index 4ecbf4e09..2ea636de3 100644
--- a/src/fd-net-device/examples/fd-tap-ping.cc
+++ b/src/fd-net-device/examples/fd-tap-ping.cc
@@ -58,15 +58,15 @@
 //     # iptables -t nat -A POSTROUTING -s <TAP-network-address>/<TAP-network-mask> -j MASQUERADE
 //
 //  3) Before running the example make sure that the tap creator binary has root suid.
-//     If the --enable-sudo option was used to configure ns-3 with waf, then the following
+//     If the --enable-sudo option was used to configure ns-3 with ns3, then the following
 //     step will not be necessary.
 //
 //     # chown root.root build/src/fd-net-device/ns3-dev-tap-device-creator
 //     # sudo chmod 4755 build/src/fd-net-device/ns3-dev-tap-device-creator
 //
-//  4)  The example can be executed as follows using waf:
+//  4)  The example can be executed as follows using ns3:
 //
-//     ./waf --run fd-tap-ping --command-template="%s --tapNetwork=<TAP-network-address> --tapMask=<TAP-network-mask>"
+//     ./ns3 --run fd-tap-ping --command-template="%s --tapNetwork=<TAP-network-address> --tapMask=<TAP-network-mask>"
 //
 
 #include "ns3/abort.h"
diff --git a/src/fd-net-device/examples/fd2fd-onoff.cc b/src/fd-net-device/examples/fd2fd-onoff.cc
index f0d839b72..9e2942d7b 100644
--- a/src/fd-net-device/examples/fd2fd-onoff.cc
+++ b/src/fd-net-device/examples/fd2fd-onoff.cc
@@ -37,8 +37,8 @@
 //
 // Steps to run the experiment:
 //
-// $ ./waf --run="fd2fd-onoff"
-// $ ./waf --run="fd2fd-onoff --tcpMode=1"
+// $ ./ns3 --run="fd2fd-onoff"
+// $ ./ns3 --run="fd2fd-onoff --tcpMode=1"
 //
 
 #include <sys/socket.h>
diff --git a/src/fd-net-device/examples/realtime-fd2fd-onoff.cc b/src/fd-net-device/examples/realtime-fd2fd-onoff.cc
index 935f2fe11..0f1f67f8a 100644
--- a/src/fd-net-device/examples/realtime-fd2fd-onoff.cc
+++ b/src/fd-net-device/examples/realtime-fd2fd-onoff.cc
@@ -37,7 +37,7 @@
 //
 // Steps to run the experiment:
 //
-// $ ./waf --run="fd2fd-onoff"
+// $ ./ns3 --run="fd2fd-onoff"
 //
 
 #include <sys/socket.h>
diff --git a/src/internet/doc/tcp.rst b/src/internet/doc/tcp.rst
index fb89f79df..99ee96a3c 100644
--- a/src/internet/doc/tcp.rst
+++ b/src/internet/doc/tcp.rst
@@ -819,7 +819,7 @@ to 20 Mb/s) to create a higher BDP link, such as
 
 ::
 
-  ./waf --run "tcp-variants-comparison --transport_prot=TcpHtcp --bandwidth=20Mbps --duration=10"
+  ./ns3 --run "tcp-variants-comparison --transport_prot=TcpHtcp --bandwidth=20Mbps --duration=10"
 
 More information (paper): http://www.hamilton.ie/net/htcp3.pdf
 
@@ -1965,7 +1965,7 @@ If we run the experiment, enabling the logging, we can see the following:
 
 .. code-block:: bash
 
-   ./waf shell
+   ./ns3 shell
    gdb --args ./build/utils/ns3-dev-test-runner-debug --test-name=tcp-zero-window-test --stop-on-failure --fullness=QUICK --assert-on-failure --verbose
    (gdb) run
 
@@ -2154,12 +2154,12 @@ To run the test, the usual way is
    PASS: TestSuite tcp-zero-window-test
    1 of 1 tests passed (1 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
 
-To see INFO messages, use a combination of ./waf shell and gdb (really useful):
+To see INFO messages, use a combination of ./ns3 shell and gdb (really useful):
 
 .. code-block:: bash
 
 
-    ./waf shell && gdb --args ./build/utils/ns3-dev-test-runner-debug --test-name=tcp-zero-window-test --stop-on-failure --fullness=QUICK --assert-on-failure --verbose
+    ./ns3 shell && gdb --args ./build/utils/ns3-dev-test-runner-debug --test-name=tcp-zero-window-test --stop-on-failure --fullness=QUICK --assert-on-failure --verbose
 
 and then, hit "Run".
 
@@ -2266,9 +2266,9 @@ into the |ns3| source directory and try running the following configuration:
 
 .. sourcecode:: bash
 
-  $ ./waf configure
+  $ ./ns3 configure
 
-If NSC has been previously built and found by waf, then you will see:
+If NSC has been previously built and found by ns3, then you will see:
 
 .. sourcecode:: bash
 
@@ -2285,7 +2285,7 @@ with the "--with-nsc" configure option; e.g.
 
 .. sourcecode:: bash
 
-  $ ./waf configure --with-nsc=/path/to/my/nsc/directory
+  $ ./ns3 configure --with-nsc=/path/to/my/nsc/directory
 
 For |ns3| releases prior to the ns-3.17 release, using the ``build.py`` 
 script in ns-3-allinone directory, NSC will be built by default unless the 
@@ -2294,10 +2294,10 @@ type:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests --disable-nsc
+  $ ./ns3 configure --enable-examples --enable-tests --disable-nsc
 
-If waf detects NSC, then building |ns3| with NSC is performed the same way
-with waf as without it. Once |ns3| is built, try running the following
+If ns3 detects NSC, then building |ns3| with NSC is performed the same way
+with ns3 as without it. Once |ns3| is built, try running the following
 test suite:
 
 .. sourcecode:: bash
@@ -2320,8 +2320,8 @@ There are a few example files. Try:
 
 .. sourcecode:: bash
 
-    $ ./waf --run tcp-nsc-zoo
-    $ ./waf --run tcp-nsc-lfn
+    $ ./ns3 --run tcp-nsc-zoo
+    $ ./ns3 --run tcp-nsc-lfn
 
 These examples will deposit some ``.pcap`` files in your directory,
 which can be examined by tcpdump or wireshark.
diff --git a/src/lte/doc/source/lte-profiling.rst b/src/lte/doc/source/lte-profiling.rst
index b21850dd2..795bec559 100644
--- a/src/lte/doc/source/lte-profiling.rst
+++ b/src/lte/doc/source/lte-profiling.rst
@@ -88,9 +88,9 @@ Reference software and equipment
 
 All timing tests had been run in a Intel Pentium IV 3.00 GHz machine with 512 Mb of RAM memory running Fedora Core 10 with a 2.6.27.41-170.2.117 kernel, storing the traces directly to the hard disk.
 
-Also, as a reference configuration, the build has been configured static and optimized. The exact ``waf`` command issued is:
+Also, as a reference configuration, the build has been configured static and optimized. The exact ``ns3`` command issued is:
 
-``CXXFLAGS="-O3 -w" ./waf -d optimized configure --enable-static --enable-examples --enable-modules=lte``
+``CXXFLAGS="-O3 -w" ./ns3 -d optimized configure --enable-static --enable-examples --enable-modules=lte``
 
 
 Results
diff --git a/src/lte/doc/source/lte-testing.rst b/src/lte/doc/source/lte-testing.rst
index 9f15f5c23..04d237c02 100644
--- a/src/lte/doc/source/lte-testing.rst
+++ b/src/lte/doc/source/lte-testing.rst
@@ -13,7 +13,7 @@ Overview
 To test and validate the ns-3 LTE module, several test suites are provided which are integrated with the ns-3 test framework.
 To run them, you need to have configured the build of the simulator in this way::
 
-    $ ./waf configure --enable-tests --enable-modules=lte --enable-examples
+    $ ./ns3 configure --enable-tests --enable-modules=lte --enable-examples
     $ ./test.py
 
 The above will run not only the test suites belonging to the LTE module, but also those belonging to all the other ns-3 modules on which the LTE module depends. See the ns-3 manual for generic information on the testing framework.
diff --git a/src/lte/doc/source/lte-user.rst b/src/lte/doc/source/lte-user.rst
index baf87b4d7..ff12c38ff 100644
--- a/src/lte/doc/source/lte-user.rst
+++ b/src/lte/doc/source/lte-user.rst
@@ -178,7 +178,7 @@ Supposing your simulation program is called
 ``src/lte/examples/lte-sim-with-input``, you can now pass these
 settings to the simulation program in the following way::
 
-   ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt
+   ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt
    --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText"
    --run src/lte/examples/lte-sim-with-input
 
@@ -186,7 +186,7 @@ settings to the simulation program in the following way::
 Furthermore, you can generate a template input file with the following
 command::
 
-   ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt
+   ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt
    --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText"
    --run src/lte/examples/lte-sim-with-input
 
@@ -258,16 +258,16 @@ print a list of the attributes of a given object together with their
 description and default value passing ``--PrintAttributes=`` to a simulation
 program, like this::
 
-     ./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"
+     ./ns3 --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"
 
 
 You can try also with other LTE and EPC objects, like this::
    
-     ./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
-     ./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
-     ./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
-     ./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
-     ./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"
+     ./ns3 --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
+     ./ns3 --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
+     ./ns3 --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
+     ./ns3 --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
+     ./ns3 --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"
  
 
 
@@ -961,10 +961,10 @@ The attributes ``ns3::EmuEpcHelper::sgwDeviceName`` and ``ns3::EmuEpcHelper::enb
 First of all we build ns-3 appropriately::
 
   # configure
-  ./waf configure --enable-sudo --enable-modules=lte,fd-net-device --enable-examples 
+  ./ns3 configure --enable-sudo --enable-modules=lte,fd-net-device --enable-examples
 
   # build
-  ./waf
+  ./ns3
 
 
 Then we setup two virtual ethernet interfaces, and start wireshark to look at the traffic going through::
@@ -990,7 +990,7 @@ Then we setup two virtual ethernet interfaces, and start wireshark to look at th
 
 We can now run the example program with the simulated clock::
 
-  ./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0
+  ./ns3 --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0
   --ns3::EmuEpcHelper::enbDeviceName=veth1"
 
 
@@ -999,13 +999,13 @@ packets exchanged both in uplink and downlink.
 
 The default setting of the example program is 1 eNB and 1UE. You can change this via command line parameters, e.g.::
 
-  ./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0
+  ./ns3 --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0
   --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb=2"
 
 
 To get a list of the available parameters::
 
-  ./waf --run lena-simple-epc-emu --command="%s --PrintHelp"
+  ./ns3 --run lena-simple-epc-emu --command="%s --PrintHelp"
 
 
 
@@ -1016,13 +1016,13 @@ with the BestEffort mode is not a good idea: something can go wrong
 So you need a decent hardware and the optimized build with statically  
 linked modules::
 
-  ./waf configure -d optimized --enable-static --enable-modules=lte --enable-examples
+  ./ns3 configure -d optimized --enable-static --enable-modules=lte --enable-examples
   --enable-sudo
 
 
 Then run the example program like this::
 
-  ./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0
+  ./ns3 --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0
   --ns3::EmuEpcHelper::enbDeviceName=veth1
   --SimulatorImplementationType=ns3::RealtimeSimulatorImpl
   --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"
@@ -1384,7 +1384,7 @@ cases. However, users may set the eNodeB to "closed" by setting the boolean
 attribute ``LteEnbRrc::AdmitHandoverRequest`` to `false`. As an example, you can
 run the ``lena-x2-handover`` program and setting the attribute in this way::
 
-   NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"
+   NS_LOG=EpcX2:LteEnbRrc ./ns3 --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"
 
 After the above three requirements are fulfilled, the handover procedure can be
 triggered manually or automatically. Each will be presented in the following
@@ -1621,13 +1621,13 @@ The example program ``src/lte/examples/lena-x2-handover.cc``
 illustrates how the all above instructions can be integrated in a
 simulation program. You can run the program like this::
 
-   ./waf --run lena-x2-handover
+   ./ns3 --run lena-x2-handover
 
 and it will output the messages printed by the custom handover trace
 hooks. In order additionally visualize some meaningful logging
 information, you can run the program like this::
 
-    NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --run lena-x2-handover
+    NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./ns3 --run lena-x2-handover
 
 
 Frequency Reuse Algorithms
@@ -2051,7 +2051,7 @@ be found in the literature. Here we list some of them:
    changing the corresponding global variables. To get a list of all these
    global variables, you can run this command::
 
-     ./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"
+     ./ns3 --run lena-dual-stripe --command-template="%s --PrintGlobals"
      
    The following subsection presents an example of running a simulation
    campaign using this example program.
@@ -2184,11 +2184,11 @@ shown in Table :ref:`tab-handover-campaign-default-values` below.
 
 |ns3| provides many ways for passing configuration values into a simulation. In
 this example, we will use the command line arguments. It is basically done by
-appending the parameters and their values to the ``waf`` call when starting each
-individual simulation. So the ``waf`` calls for invoking our 3 simulations would
+appending the parameters and their values to the ``ns3`` call when starting each
+individual simulation. So the ``ns3`` calls for invoking our 3 simulations would
 look as below::
 
-   $ ./waf --run="lena-dual-stripe
+   $ ./ns3 --run="lena-dual-stripe
      --simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
      --epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
      --ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
@@ -2198,7 +2198,7 @@ look as below::
      --ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
      --RngRun=1" > no-op.txt
 
-   $ ./waf --run="lena-dual-stripe
+   $ ./ns3 --run="lena-dual-stripe
      --simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
      --epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
      --ns3::LteHelper::HandoverAlgorithm=ns3::A3RsrpHandoverAlgorithm
@@ -2208,7 +2208,7 @@ look as below::
      --ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
      --RngRun=1" > a3-rsrp.txt
 
-   $ ./waf --run="lena-dual-stripe
+   $ ./ns3 --run="lena-dual-stripe
      --simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
      --epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
      --ns3::LteHelper::HandoverAlgorithm=ns3::A2A4RsrqHandoverAlgorithm
@@ -2365,7 +2365,7 @@ To run ``lena-frequency-reuse`` with different Frequency Reuse algorithms, user
 FR algorithm by overriding the default attribute ``ns3::LteHelper::FfrAlgorithm``.
 Example command to run ``lena-frequency-reuse`` with Soft FR algorithm is presented below::
 
-   $ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"
+   $ ./ns3 --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"
 
 In these examples functionality to generate REM and spectrum analyzer trace was added. 
 User can enable generation of it by setting ``generateRem`` and ``generateSpectrumTrace``
@@ -2374,7 +2374,7 @@ attributes.
 Command to generate REM for RB 1 in data channel from ``lena-frequency-reuse`` scenario 
 with Soft FR algorithm is presented below::
 
-   $ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
+   $ ./ns3 --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
      --generateRem=true --remRbId=1"
 
 Radio Environment Map for Soft FR is presented in Figure :ref:`fig-lte-soft-fr-1-rem`.
@@ -2392,7 +2392,7 @@ Command to generate spectrum trace from ``lena-frequency-reuse`` scenario
 with Soft FFR algorithm is presented below (Spectrum Analyzer position needs to be configured 
 inside script)::
 
-   $ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
+   $ ./ns3 --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
      --generateSpectrumTrace=true"
 
 Example spectrum analyzer trace is presented in figure :ref:`fig-lte-soft-ffr-2-spectrum-trace`.
@@ -2415,7 +2415,7 @@ along entire system bandwidth.
 User needs to specify FR algorithm by overriding the default attribute ``ns3::LteHelper::FfrAlgorithm``.
 Example command to run ``lena-dual-stripe`` with Hard FR algorithm is presented below::
 
-   $ ./waf --run="lena-dual-stripe
+   $ ./ns3 --run="lena-dual-stripe
      --simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
      --epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
      --ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
@@ -2429,7 +2429,7 @@ Example command to run ``lena-dual-stripe`` with Hard FR algorithm is presented
 Example command to generate REM for RB 1 in data channel from ``lena-dual-stripe`` scenario 
 with Hard FR algorithm is presented below::
 
-   $ ./waf --run="lena-dual-stripe
+   $ ./ns3 --run="lena-dual-stripe
      --simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
      --epc=0 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
      --ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
@@ -2488,7 +2488,7 @@ to check the performance. A new column is added to PHY and MAC traces to indicat
 The test suite ``lte-carrier-aggregation`` is also a test program that can be used as an example as it can be run in a mode to write results 
 to output files by setting the ``s_writeResults`` boolean static variable to true. The test can be run by using a `test-runner`:
 
-   ./waf --run 'test-runner --suite=lte-carrier-aggregation'
+   ./ns3 --run 'test-runner --suite=lte-carrier-aggregation'
 
 To plot the test results, a file has to be created in the root folder of the ns-3 repository, and added to it with the following content :
 
@@ -2563,14 +2563,14 @@ writes it into a file for plotting purposes. For example, to simulate the "Scena
 A" with *Ideal* and *Real* RRC protocol a user can use the following commands::
 
   Ideal RRC:
-  ./waf --run "lena-radio-link-failure
+  ./ns3 --run "lena-radio-link-failure
   --numberOfEnbs=1 --useIdealRrc=1
   --interSiteDistance=1200 --n310=1 --n311=1
   --t310=1 --enableCtrlErrorModel=1
   --enableDataErrorModel=1 --simTime=25"
 
   Real RRC:
-  ./waf --run "lena-radio-link-failure
+  ./ns3 --run "lena-radio-link-failure
   --numberOfEnbs=1 --useIdealRrc=0
   --interSiteDistance=1200 --n310=1 --n311=1
   --t310=1 --enableCtrlErrorModel=1
@@ -2632,14 +2632,14 @@ Similarly, to simulate the "Scenario B" with *Ideal* and *Real* RRC protocol
 following commands can be used::
 
   Ideal RRC:
-  ./waf --run "lena-radio-link-failure
+  ./ns3 --run "lena-radio-link-failure
   --numberOfEnbs=2 --useIdealRrc=1
   --interSiteDistance=1200 --n310=1 --n311=1
   --t310=1 --enableCtrlErrorModel=1
   --enableDataErrorModel=1 --simTime=25"
 
   Real RRC:
-  ./waf --run "lena-radio-link-failure
+  ./ns3 --run "lena-radio-link-failure
   --numberOfEnbs=2 --useIdealRrc=0
   --interSiteDistance=1200 --n310=1 --n311=1
   --t310=1 --enableCtrlErrorModel=1
diff --git a/src/lte/examples/lena-cqi-threshold.cc b/src/lte/examples/lena-cqi-threshold.cc
index a328c533c..436f880a1 100644
--- a/src/lte/examples/lena-cqi-threshold.cc
+++ b/src/lte/examples/lena-cqi-threshold.cc
@@ -67,10 +67,10 @@ int main (int argc, char *argv[])
   cmd.Parse (argc, argv);
 	
   // to save a template default attribute file run it like this:
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
   //
   // to load a previously created default attribute file
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
 
   ConfigStore inputConfig;
   inputConfig.ConfigureDefaults ();
diff --git a/src/lte/examples/lena-fading.cc b/src/lte/examples/lena-fading.cc
index 3a6b09c49..e382191dd 100644
--- a/src/lte/examples/lena-fading.cc
+++ b/src/lte/examples/lena-fading.cc
@@ -37,10 +37,10 @@ int main (int argc, char *argv[])
   cmd.Parse (argc, argv);
 	
   // to save a template default attribute file run it like this:
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
   //
   // to load a previously created default attribute file
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
 
   //ConfigStore inputConfig;
   //inputConfig.ConfigureDefaults ();
diff --git a/src/lte/examples/lena-radio-link-failure.cc b/src/lte/examples/lena-radio-link-failure.cc
index 17cb46d33..e2a3bf3bf 100644
--- a/src/lte/examples/lena-radio-link-failure.cc
+++ b/src/lte/examples/lena-radio-link-failure.cc
@@ -266,7 +266,7 @@ Throughput (bool firstWrite, Time binSize, std::string fileName)
  *
  * The example can be run as follows:
  *
- * ./waf --run "lena-radio-link-failure --numberOfEnbs=1 --simTime=25"
+ * ./ns3 --run "lena-radio-link-failure --numberOfEnbs=1 --simTime=25"
  */
 int
 main (int argc, char *argv[])
diff --git a/src/lte/examples/lena-rem.cc b/src/lte/examples/lena-rem.cc
index e3dbcf445..f2b2439f2 100644
--- a/src/lte/examples/lena-rem.cc
+++ b/src/lte/examples/lena-rem.cc
@@ -37,10 +37,10 @@ int main (int argc, char *argv[])
   cmd.Parse (argc, argv);
 	
   // to save a template default attribute file run it like this:
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
   //
   // to load a previously created default attribute file
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-first-sim
 
   ConfigStore inputConfig;
   inputConfig.ConfigureDefaults ();
diff --git a/src/lte/examples/lena-simple.cc b/src/lte/examples/lena-simple.cc
index 2c6d63ea0..8b7a745af 100644
--- a/src/lte/examples/lena-simple.cc
+++ b/src/lte/examples/lena-simple.cc
@@ -39,10 +39,10 @@ int main (int argc, char *argv[])
   cmd.Parse (argc, argv);
 
   // to save a template default attribute file run it like this:
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-simple
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-simple
   //
   // to load a previously created default attribute file
-  // ./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-simple
+  // ./ns3 --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lena-simple
 
   ConfigStore inputConfig;
   inputConfig.ConfigureDefaults ();
diff --git a/src/lte/test/epc-test-run-time.pl b/src/lte/test/epc-test-run-time.pl
index 723f512a3..6bb138a05 100755
--- a/src/lte/test/epc-test-run-time.pl
+++ b/src/lte/test/epc-test-run-time.pl
@@ -14,10 +14,10 @@ my @simTime = (5, 10);
 
 
 # Configure and complite first the program to avoid counting compilation time as running time
-my $launch = "CXXFLAGS=\"-O3 -w\" ./waf -d optimized configure --enable-static --enable-examples --enable-modules=lte";
+my $launch = "CXXFLAGS=\"-O3 -w\" ./ns3 -d optimized configure --enable-static --enable-examples --enable-modules=lte";
 my $out, my $err;
 capture { system($launch ) } \$out, \$err;
-$launch = "./waf --run \'lena-profiling --simTime=0.1 --nUe=1 --nEnb=1 --nFloors=0\'";
+$launch = "./ns3 --run \'lena-profiling --simTime=0.1 --nUe=1 --nEnb=1 --nFloors=0\'";
 
 foreach my $time (@simTime)
 {
@@ -26,7 +26,7 @@ foreach my $time (@simTime)
             my $timeStats = Statistics::Descriptive::Full->new();
             for ( my $iteration = 0 ; $iteration < $nIterations ; $iteration++ )
             {
-               $launch = "time -f \"real%E\" ./waf --run 'lena-simple-epc --simTime=$time --numberOfNodes=$node'";
+               $launch = "time -f \"real%E\" ./ns3 --run 'lena-simple-epc --simTime=$time --numberOfNodes=$node'";
                print "$launch\n";
                capture { system($launch ) } \$out, \$err;
                $err =~ /real(.+):(.+)/;
diff --git a/src/lte/test/lte-test-run-time.pl b/src/lte/test/lte-test-run-time.pl
index 064fa37c5..e15ac2b62 100755
--- a/src/lte/test/lte-test-run-time.pl
+++ b/src/lte/test/lte-test-run-time.pl
@@ -14,11 +14,11 @@ my @nFloors = (0, 1);
 my @simTime = (5, 10);
 
 # Configure and complite first the program to avoid counting compilation time as running time
-my $launch = "CXXFLAGS=\"-O3 -w\" ./waf -d optimized configure --enable-static --enable-examples --enable-modules=lte";
+my $launch = "CXXFLAGS=\"-O3 -w\" ./ns3 -d optimized configure --enable-static --enable-examples --enable-modules=lte";
 my $out;
 my $err;
 capture { system($launch ) } \$out, \$err;
-$launch = "./waf --run \'lena-profiling --simTime=0.1 --nUe=1 --nEnb=1 --nFloors=0\'";
+$launch = "./ns3 --run \'lena-profiling --simTime=0.1 --nUe=1 --nEnb=1 --nFloors=0\'";
 capture { system($launch ) } \$out, \$err;
 
 foreach my $time (@simTime)
@@ -32,7 +32,7 @@ foreach my $time (@simTime)
             my $timeStats = Statistics::Descriptive::Full->new();
             for ( my $iteration = 0 ; $iteration < $nIterations ; $iteration++ )
             {
-               $launch = "time -f \"real%E\" ./waf --run \'lena-profiling --simTime=$time --nUe=$ue --nEnb=$enb --nFloors=$floor\'";
+               $launch = "time -f \"real%E\" ./ns3 --run \'lena-profiling --simTime=$time --nUe=$ue --nEnb=$enb --nFloors=$floor\'";
                print "$launch\n";
                capture { system($launch ) } \$out, \$err;
                $err =~ /real(.+):(.+)/;
diff --git a/src/mobility/doc/mobility.rst b/src/mobility/doc/mobility.rst
index 62ec72f21..5de907dbb 100644
--- a/src/mobility/doc/mobility.rst
+++ b/src/mobility/doc/mobility.rst
@@ -287,7 +287,7 @@ Example usage:
 
 .. sourcecode:: bash
 
-  $ ./waf --run "ns2-mobility-trace \
+  $ ./ns3 --run "ns2-mobility-trace \
   --traceFile=src/mobility/examples/default.ns_movements \
   --nodeNum=2 \
   --duration=100.0 \
diff --git a/src/mobility/examples/bonnmotion-ns2-example.cc b/src/mobility/examples/bonnmotion-ns2-example.cc
index 9828b8894..439c6d272 100644
--- a/src/mobility/examples/bonnmotion-ns2-example.cc
+++ b/src/mobility/examples/bonnmotion-ns2-example.cc
@@ -37,7 +37,7 @@
  *
  * Finally, note that you can visualize this program using the pyviz
  * visualizer:
- *  ./waf --run bonnmotion-ns2-example --vis
+ *  ./ns3 --run bonnmotion-ns2-example --vis
  */
 
 #include "ns3/core-module.h"
diff --git a/src/mobility/examples/ns2-mobility-trace.cc b/src/mobility/examples/ns2-mobility-trace.cc
index eb892e38b..142ceac01 100644
--- a/src/mobility/examples/ns2-mobility-trace.cc
+++ b/src/mobility/examples/ns2-mobility-trace.cc
@@ -36,7 +36,7 @@
  *
  * Usage of ns2-mobility-trace:
  *
- *  ./waf --run "ns2-mobility-trace \
+ *  ./ns3 --run "ns2-mobility-trace \
  *        --traceFile=src/mobility/examples/default.ns_movements
  *        --nodeNum=2  --duration=100.0 --logFile=ns2-mobility-trace.log"
  *
@@ -94,7 +94,7 @@ int main (int argc, char *argv[])
   if (traceFile.empty () || nodeNum <= 0 || duration <= 0 || logFile.empty ())
     {
       std::cout << "Usage of " << argv[0] << " :\n\n"
-      "./waf --run \"ns2-mobility-trace"
+      "./ns3 --run \"ns2-mobility-trace"
       " --traceFile=src/mobility/examples/default.ns_movements"
       " --nodeNum=2 --duration=100.0 --logFile=ns2-mob.log\" \n\n"
       "NOTE: ns2-traces-file could be an absolute or relative path. You could use the file default.ns_movements\n"
diff --git a/src/mpi/doc/distributed.rst b/src/mpi/doc/distributed.rst
index 3e5334f16..4aca6d6bb 100644
--- a/src/mpi/doc/distributed.rst
+++ b/src/mpi/doc/distributed.rst
@@ -184,32 +184,32 @@ Building and Running Examples
 
 If you already built |ns3| without MPI enabled, you must re-build::
 
-    $ ./waf distclean
+    $ ./ns3 distclean
 
 Configure |ns3| with the --enable-mpi option::
 
-    $ ./waf -d debug configure --enable-examples --enable-tests --enable-mpi
+    $ ./ns3 -d debug configure --enable-examples --enable-tests --enable-mpi
 
 Ensure that MPI is enabled by checking the optional features shown from the
 output of configure.
 
 Next, build |ns3|::
 
-    $ ./waf
+    $ ./ns3
 
 After building |ns3| with mpi enabled, the example programs are now
-ready to run with `mpiexec`.  It is advised to avoid running Waf directly
+ready to run with `mpiexec`.  It is advised to avoid running ns3 directly
 with `mpiexec`; two options that should be more robust are to either use
 the `--command-template` way of running the mpiexec program, or to use
-`./waf shell` and run the executables directly on the command line.
+`./ns3 shell` and run the executables directly on the command line.
 Here are a few examples (from the root |ns3| directory)::
 
-    $ ./waf --command-template="mpiexec -np 2 %s" --run simple-distributed
-    $ ./waf --command-template="mpiexec -np 2 -machinefile mpihosts %s --nix=0" --run nms-p2p-nix-distributed
+    $ ./ns3 --command-template="mpiexec -np 2 %s" --run simple-distributed
+    $ ./ns3 --command-template="mpiexec -np 2 -machinefile mpihosts %s --nix=0" --run nms-p2p-nix-distributed
             
 An example using the null message synchronization algorithm::
 
-    $ ./waf --command-template="mpiexec -np 2 %s --nullmsg" --run simple-distributed
+    $ ./ns3 --command-template="mpiexec -np 2 %s --nullmsg" --run simple-distributed
 
 The np switch is the number of logical processors to use. The machinefile switch
 is which machines to use. In order to use machinefile, the target file must
@@ -224,10 +224,10 @@ exist (in this case mpihosts). This can simply contain something like:
 
 Or if you have a cluster of machines, you can name them.
 
-The other alternative to `command-template` is to use `./waf shell`.  Here
+The other alternative to `command-template` is to use `./ns3 shell`.  Here
 are the equivalent examples to the above (assuming optimized build profile)::
 
-    $ ./waf shell
+    $ ./ns3 shell
     $ cd build/src/mpi/examples
     $ mpiexec -np 2 ns3-dev-simple-distributed-optimized
     $ mpiexec -np 2 -machinefile mpihosts ns3-dev-nms-p2p-nix-distributed-optimized --nix=0
diff --git a/src/netanim/doc/animation.rst b/src/netanim/doc/animation.rst
index 0f4bcd428..b0e63cd62 100644
--- a/src/netanim/doc/animation.rst
+++ b/src/netanim/doc/animation.rst
@@ -145,8 +145,8 @@ Example:
 
 .. sourcecode:: bash
 
-  $ ./waf -d debug configure --enable-examples
-  $ ./waf --run "dumbbell-animation"
+  $ ./ns3 -d debug configure --enable-examples
+  $ ./ns3 --run "dumbbell-animation"
 
 The above will create an XML file dumbbell-animation.xml
 
diff --git a/src/nix-vector-routing/doc/nix-vector-routing.rst b/src/nix-vector-routing/doc/nix-vector-routing.rst
index 8b789c9b9..64c991aa4 100644
--- a/src/nix-vector-routing/doc/nix-vector-routing.rst
+++ b/src/nix-vector-routing/doc/nix-vector-routing.rst
@@ -175,14 +175,14 @@ There are examples which use both IPv4 and IPv6 networking.
       .. code-block:: bash
 
          # By default IPv4 network is selected
-         ./waf --run nix-simple
+         ./ns3 --run nix-simple
 
    b. Using IPv6:
 
       .. code-block:: bash
 
          # Use the --useIPv6 flag
-         ./waf --run "nix-simple --useIPv6"
+         ./ns3 --run "nix-simple --useIPv6"
 
 
 
@@ -199,14 +199,14 @@ There are examples which use both IPv4 and IPv6 networking.
       .. code-block:: bash
 
          # By default IPv4 network is selected
-         ./waf --run nms-p2p-nix
+         ./ns3 --run nms-p2p-nix
 
    b. Using IPv6:
 
       .. code-block:: bash
 
          # Use the --useIPv6 flag
-         ./waf --run "nms-p2p-nix --useIPv6"
+         ./ns3 --run "nms-p2p-nix --useIPv6"
 
 3.  nix-simple-multi-address.cc
 
@@ -217,7 +217,7 @@ There are examples which use both IPv4 and IPv6 networking.
    .. code-block:: bash
 
       # By default IPv4 network is selected
-      ./waf --run nix-simple-multi-address
+      ./ns3 --run nix-simple-multi-address
 
 4.  nix-double-wifi.cc
 
@@ -230,15 +230,15 @@ There are examples which use both IPv4 and IPv6 networking.
       .. code-block:: bash
 
          # By default IPv4 network is selected
-         ./waf --run nix-double-wifi
+         ./ns3 --run nix-double-wifi
          # Use the --enableNixLog to enable NixVectorRouting logging.
-         ./waf --run "nix-double-wifi --enableNixLog"
+         ./ns3 --run "nix-double-wifi --enableNixLog"
 
    b. Using IPv6:
 
       .. code-block:: bash
 
          # Use the --useIPv6 flag
-         ./waf --run "nix-double-wifi --useIPv6"
+         ./ns3 --run "nix-double-wifi --useIPv6"
          # Use the --enableNixLog to enable NixVectorRouting logging.
-         ./waf --run "nix-double-wifi --useIPv6 --enableNixLog"
\ No newline at end of file
+         ./ns3 --run "nix-double-wifi --useIPv6 --enableNixLog"
\ No newline at end of file
diff --git a/src/olsr/examples/olsr-hna.cc b/src/olsr/examples/olsr-hna.cc
index f210fd907..d2cdde2be 100644
--- a/src/olsr/examples/olsr-hna.cc
+++ b/src/olsr/examples/olsr-hna.cc
@@ -35,19 +35,19 @@
 // If no HNA message is generated by B, a will not be able to form a route to C.
 // This can be verified as follows:
 //
-// ./waf --run olsr-hna
+// ./ns3 --run olsr-hna
 //
 // There are two ways to make a node to generate HNA messages.
 //
 // One way is to use olsr::RoutingProtocol::SetRoutingTableAssociation ()
 // to use which you may run:
 //
-// ./waf --run "olsr-hna --assocMethod1=1"
+// ./ns3 --run "olsr-hna --assocMethod1=1"
 //
 // The other way is to use olsr::RoutingProtocol::AddHostNetworkAssociation ()
 // to use which you may run:
 //
-// ./waf --run "olsr-hna --assocMethod2=1"
+// ./ns3 --run "olsr-hna --assocMethod2=1"
 //
 
 #include <iostream>
diff --git a/src/openflow/doc/openflow-switch.rst b/src/openflow/doc/openflow-switch.rst
index 06f06ee0c..8efb16491 100644
--- a/src/openflow/doc/openflow-switch.rst
+++ b/src/openflow/doc/openflow-switch.rst
@@ -138,7 +138,7 @@ To do this:
 
 1. Obtain the OFSID code.
    An ns-3 specific OFSID branch is provided to ensure
-   operation with ns-3. Use mercurial to download this branch and waf to build 
+   operation with ns-3. Use mercurial to download this branch and ns3 to build
    the library::
 
      $ hg clone http://code.nsnam.org/openflow
@@ -146,14 +146,14 @@ To do this:
 
    From the "openflow" directory, run::
      
-     $ ./waf configure
-     $ ./waf build
+     $ ./ns3 configure
+     $ ./ns3 build
 
 2. Your OFSID is now built into a libopenflow.a library!
    To link to an ns-3 build with this OpenFlow switch module, run from the ns-3-dev
    (or whatever you have named your distribution)::
 
-     $ ./waf configure --enable-examples --enable-tests --with-openflow=path/to/openflow
+     $ ./ns3 configure --enable-examples --enable-tests --with-openflow=path/to/openflow
 
 3. Under ``---- Summary of optional NS-3 features:`` you should see:
 
@@ -163,7 +163,7 @@ To do this:
 
    indicating the library has been linked to ns-3. Run::
 
-     $ ./waf build
+     $ ./ns3 build
 
 to build ns-3 and activate the OpenFlowSwitch module in ns-3.
 
@@ -172,11 +172,11 @@ Examples
 For an example demonstrating its use in a simple learning controller/switch, 
 run::
 
-  $ ./waf --run openflow-switch
+  $ ./ns3 --run openflow-switch
 
 To see it in detailed logging, run::
 
-  $ ./waf --run "openflow-switch -v"
+  $ ./ns3 --run "openflow-switch -v"
 
 
 Helpers
diff --git a/src/point-to-point-layout/doc/point-to-point-dumbbell.rst b/src/point-to-point-layout/doc/point-to-point-dumbbell.rst
index 5645109f1..ff16f0ec1 100644
--- a/src/point-to-point-layout/doc/point-to-point-dumbbell.rst
+++ b/src/point-to-point-layout/doc/point-to-point-dumbbell.rst
@@ -145,22 +145,22 @@ The example for this helper is `dumbbell-animation.cc` located in
 ``src/netanim/examples``. The following command shows the available command-
 line options for this example::
 
-   $ ./waf --run "dumbbell-animation --PrintHelp"
+   $ ./ns3 --run "dumbbell-animation --PrintHelp"
 
 The following command sets up a dumbbell topology with the default
 configuration::
 
-   $ ./waf --run dumbbell-animation
+   $ ./ns3 --run dumbbell-animation
 
 The following command sets up a dumbbell topology with 6 left leaf nodes and 9
 right leaf nodes::
 
-   $ ./waf --run "dumbbell-animation --nLeftLeaf=6 --nRightLeaf=9"
+   $ ./ns3 --run "dumbbell-animation --nLeftLeaf=6 --nRightLeaf=9"
 
 The following command sets up a dumbbell topology with 10 left leaf nodes and
 10 right leaf nodes::
 
-   $ ./waf --run "dumbbell-animation --nLeaf=10"
+   $ ./ns3 --run "dumbbell-animation --nLeaf=10"
 
 The expected output from the previous commands is a XML file to playback the
 animation using NetAnim.
diff --git a/src/tap-bridge/examples/tap-csma-virtual-machine.cc b/src/tap-bridge/examples/tap-csma-virtual-machine.cc
index 70bff18e2..9602b0c18 100644
--- a/src/tap-bridge/examples/tap-csma-virtual-machine.cc
+++ b/src/tap-bridge/examples/tap-csma-virtual-machine.cc
@@ -97,7 +97,7 @@ main (int argc, char *argv[])
   // devices installed on both of the nodes.  The data rate and delay for the
   // channel can be set through the command-line parser.  For example,
   //
-  // ./waf --run "tap=csma-virtual-machine --ns3::CsmaChannel::DataRate=10000000"
+  // ./ns3 --run "tap=csma-virtual-machine --ns3::CsmaChannel::DataRate=10000000"
   //
   CsmaHelper csma;
   NetDeviceContainer devices = csma.Install (nodes);
diff --git a/src/tap-bridge/examples/tap-csma.cc b/src/tap-bridge/examples/tap-csma.cc
index 744ac6b01..f353a15d4 100644
--- a/src/tap-bridge/examples/tap-csma.cc
+++ b/src/tap-bridge/examples/tap-csma.cc
@@ -51,7 +51,7 @@
 //
 // 1) Ping one of the simulated nodes
 //
-//    ./waf --run tap-csma&
+//    ./ns3 --run tap-csma&
 //    ping 10.1.1.2
 //
 #include <iostream>
diff --git a/src/tap-bridge/examples/tap-wifi-dumbbell.cc b/src/tap-bridge/examples/tap-wifi-dumbbell.cc
index 3c2d578c1..c44aaf441 100644
--- a/src/tap-bridge/examples/tap-wifi-dumbbell.cc
+++ b/src/tap-bridge/examples/tap-wifi-dumbbell.cc
@@ -53,7 +53,7 @@
 //
 // 1) Ping one of the simulated nodes on the left side of the topology.
 //
-//    ./waf --run tap-wifi-dumbbell&
+//    ./ns3 --run tap-wifi-dumbbell&
 //    ping 10.1.1.3
 //
 // 2) Configure a route in the linux host and ping once of the nodes on the 
@@ -61,7 +61,7 @@
 //    delays due to CBR background traffic on the point-to-point (see next
 //    item).
 //
-//    ./waf --run tap-wifi-dumbbell&
+//    ./ns3 --run tap-wifi-dumbbell&
 //    sudo route add -net 10.1.3.0 netmask 255.255.255.0 dev thetap gw 10.1.1.2
 //    ping 10.1.3.4
 //
@@ -77,7 +77,7 @@
 //    reflected in large delays seen by ping.  You can crank down the CBR 
 //    traffic data rate and watch the ping timing change dramatically.
 //
-//    ./waf --run "tap-wifi-dumbbell --ns3::OnOffApplication::DataRate=100kb/s"&
+//    ./ns3 --run "tap-wifi-dumbbell --ns3::OnOffApplication::DataRate=100kb/s"&
 //    sudo route add -net 10.1.3.0 netmask 255.255.255.0 dev thetap gw 10.1.1.2
 //    ping 10.1.3.4
 //
@@ -93,7 +93,7 @@
 //    sudo brctl addif mybridge mytap1
 //    sudo brctl addif mybridge mytap2
 //    sudo ifconfig mybridge 10.1.1.5 netmask 255.255.255.0 up
-//    ./waf --run "tap-wifi-dumbbell --mode=UseBridge --tapName=mytap2"&
+//    ./ns3 --run "tap-wifi-dumbbell --mode=UseBridge --tapName=mytap2"&
 //    ping 10.1.1.3
 
 #include <iostream>
diff --git a/src/test/ns3tcp/plot.gp b/src/test/ns3tcp/plot.gp
index 87d2b03f3..5ec14d58f 100644
--- a/src/test/ns3tcp/plot.gp
+++ b/src/test/ns3tcp/plot.gp
@@ -22,7 +22,7 @@
 # * logging output from Ns3TcpLossTest case must first be enabled 
 # * by manually editing ns3-tcp-loss-test-suite.cc and setting 
 # * WRITE_LOGGING to true. Then, the test suite should be re-run 
-# * with ./waf --run "test-runner --suite='ns3-tcp-loss'"
+# * with ./ns3 --run "test-runner --suite='ns3-tcp-loss'"
 # * This will generate a number of log files which are parsed 
 # * below for eventual plotting to .eps format using gnuplot.
 # * To run this file in gnuplot, simply: gnuplot plot.gp
diff --git a/src/traffic-control/doc/cobalt.rst b/src/traffic-control/doc/cobalt.rst
index ef2c32047..d32498f94 100644
--- a/src/traffic-control/doc/cobalt.rst
+++ b/src/traffic-control/doc/cobalt.rst
@@ -109,7 +109,7 @@ An example program named `cobalt-vs-codel.cc` is located in
 
 ::
 
-   $ ./waf --run cobalt-vs-codel
+   $ ./ns3 --run cobalt-vs-codel
 
 
 Validation
@@ -129,13 +129,13 @@ The test suite can be run using the following commands:
 
 ::
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s cobalt-queue-disc
 
 or
 
 ::
 
-  $ NS_LOG="CobaltQueueDisc" ./waf --run "test-runner --suite=cobalt-queue-disc"
+  $ NS_LOG="CobaltQueueDisc" ./ns3 --run "test-runner --suite=cobalt-queue-disc"
 
diff --git a/src/traffic-control/doc/codel.rst b/src/traffic-control/doc/codel.rst
index 1848b64df..fc2bfabfc 100644
--- a/src/traffic-control/doc/codel.rst
+++ b/src/traffic-control/doc/codel.rst
@@ -82,8 +82,8 @@ command-line options):
 
 .. sourcecode:: bash
 
-   $ ./waf --run "codel-vs-pfifo-basic-test --PrintHelp"
-   $ ./waf --run "codel-vs-pfifo-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr" 
+   $ ./ns3 --run "codel-vs-pfifo-basic-test --PrintHelp"
+   $ ./ns3 --run "codel-vs-pfifo-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"
 
 The expected output from the previous commands are two files: `codel.pcap` file and `cwndCoDel.tr` (ASCII trace) file The .pcap file can be analyzed using 
 wireshark or tcptrace:
@@ -97,8 +97,8 @@ deployment scenario.  To run the file:
 
 .. sourcecode:: bash
 
-   $ ./waf --run "codel-vs-pfifo-asymmetric --PrintHelp"
-   $ ./waf --run codel-vs-pfifo-asymmetric
+   $ ./ns3 --run "codel-vs-pfifo-asymmetric --PrintHelp"
+   $ ./ns3 --run codel-vs-pfifo-asymmetric
 
 The expected output from the previous commands is six pcap files:
 
@@ -137,13 +137,13 @@ The test suite can be run using the following commands:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s codel-queue-disc
 
 or  
 
 .. sourcecode:: bash
 
-  $ NS_LOG="CoDelQueueDisc" ./waf --run "test-runner --suite=codel-queue-disc"
+  $ NS_LOG="CoDelQueueDisc" ./ns3 --run "test-runner --suite=codel-queue-disc"
 
diff --git a/src/traffic-control/doc/fq-cobalt.rst b/src/traffic-control/doc/fq-cobalt.rst
index 89e05edca..2bb39d04c 100644
--- a/src/traffic-control/doc/fq-cobalt.rst
+++ b/src/traffic-control/doc/fq-cobalt.rst
@@ -74,10 +74,10 @@ The FqCobalt model is tested using :cpp:class:`FqCobaltQueueDiscTestSuite` class
 The tests are similar to the ones for FqCoDel queue disc mentioned in first section of this document.
 The test suite can be run using the following commands::
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s fq-cobalt-queue-disc
 
 or::
 
-  $ NS_LOG="FqCobaltQueueDisc" ./waf --run "test-runner --suite=fq-cobalt-queue-disc"
+  $ NS_LOG="FqCobaltQueueDisc" ./ns3 --run "test-runner --suite=fq-cobalt-queue-disc"
diff --git a/src/traffic-control/doc/fq-codel.rst b/src/traffic-control/doc/fq-codel.rst
index a68d590b5..df198105d 100644
--- a/src/traffic-control/doc/fq-codel.rst
+++ b/src/traffic-control/doc/fq-codel.rst
@@ -131,8 +131,8 @@ command-line options):
 
 .. sourcecode:: bash
 
-   $ ./waf --run "FqCoDel-L4S-example --PrintHelp"
-   $ ./waf --run "FqCoDel-L4S-example --scenarioNum=5" 
+   $ ./ns3 --run "FqCoDel-L4S-example --PrintHelp"
+   $ ./ns3 --run "FqCoDel-L4S-example --scenarioNum=5"
 
 The expected output from the previous command are .dat files.
 
@@ -154,15 +154,15 @@ The test suite can be run using the following commands:
 
 .. sourcecode:: bash
 
-   $ ./waf configure --enable-examples --enable-tests
-   $ ./waf build
+   $ ./ns3 configure --enable-examples --enable-tests
+   $ ./ns3 build
    $ ./test.py -s fq-codel-queue-disc
 
 or:
 
 .. sourcecode:: bash
 
-   $ NS_LOG="FqCoDelQueueDisc" ./waf --run "test-runner --suite=fq-codel-queue-disc"
+   $ NS_LOG="FqCoDelQueueDisc" ./ns3 --run "test-runner --suite=fq-codel-queue-disc"
 
 Set associative hashing is tested by generating a probability collision graph. 
 This graph is then overlapped with the theoretical graph provided in the original 
diff --git a/src/traffic-control/doc/fq-pie.rst b/src/traffic-control/doc/fq-pie.rst
index 469e5e65f..5776606dc 100644
--- a/src/traffic-control/doc/fq-pie.rst
+++ b/src/traffic-control/doc/fq-pie.rst
@@ -89,10 +89,10 @@ The FqPie model is tested using :cpp:class:`FqPieQueueDiscTestSuite` class defin
 The tests are similar to the ones for FqCoDel queue disc mentioned in first section of this document.
 The test suite can be run using the following commands::
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s fq-pie-queue-disc
 
 or::
 
-  $ NS_LOG="FqPieQueueDisc" ./waf --run "test-runner --suite=fq-pie-queue-disc"
+  $ NS_LOG="FqPieQueueDisc" ./ns3 --run "test-runner --suite=fq-pie-queue-disc"
diff --git a/src/traffic-control/doc/mq.rst b/src/traffic-control/doc/mq.rst
index 3ab31c7ed..ce4164b68 100644
--- a/src/traffic-control/doc/mq.rst
+++ b/src/traffic-control/doc/mq.rst
@@ -70,13 +70,13 @@ The test suite can be run using the following commands:
 
 ::
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s ns3-wifi-ac-mapping
 
 or
 
 ::
 
-  $ NS_LOG="WifiAcMappingTest" ./waf --run "test-runner --suite=ns3-wifi-ac-mapping"
+  $ NS_LOG="WifiAcMappingTest" ./ns3 --run "test-runner --suite=ns3-wifi-ac-mapping"
 
diff --git a/src/traffic-control/doc/pie.rst b/src/traffic-control/doc/pie.rst
index c87d183db..d3dfb52ec 100644
--- a/src/traffic-control/doc/pie.rst
+++ b/src/traffic-control/doc/pie.rst
@@ -72,8 +72,8 @@ command-line options):
 
 .. sourcecode:: bash
 
-   $ ./waf --run "pie-example --PrintHelp"
-   $ ./waf --run "pie-example --writePcap=1" 
+   $ ./ns3 --run "pie-example --PrintHelp"
+   $ ./ns3 --run "pie-example --writePcap=1"
 
 The expected output from the previous commands are ten .pcap files.
 
@@ -103,13 +103,13 @@ The test suite can be run using the following commands:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s pie-queue-disc
 
 or alternatively (to see logging statements in a debug build):  
 
 .. sourcecode:: bash
 
-  $ NS_LOG="PieQueueDisc" ./waf --run "test-runner --suite=pie-queue-disc"
+  $ NS_LOG="PieQueueDisc" ./ns3 --run "test-runner --suite=pie-queue-disc"
 
diff --git a/src/traffic-control/doc/prio.rst b/src/traffic-control/doc/prio.rst
index ed7d583f5..1fea1397d 100644
--- a/src/traffic-control/doc/prio.rst
+++ b/src/traffic-control/doc/prio.rst
@@ -63,12 +63,12 @@ The test suite can be run using the following commands:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s prio-queue-disc
 
 or
 
 .. sourcecode:: bash
 
-  $ NS_LOG="PrioQueueDisc" ./waf --run "test-runner --suite=prio-queue-disc"
+  $ NS_LOG="PrioQueueDisc" ./ns3 --run "test-runner --suite=prio-queue-disc"
diff --git a/src/traffic-control/doc/tbf.rst b/src/traffic-control/doc/tbf.rst
index 4ac489702..de597bb1e 100644
--- a/src/traffic-control/doc/tbf.rst
+++ b/src/traffic-control/doc/tbf.rst
@@ -113,8 +113,8 @@ The example for TBF is `tbf-example.cc` located in ``examples/traffic-control/``
 
 .. sourcecode:: bash
 
-   $ ./waf --run "tbf-example --PrintHelp"
-   $ ./waf --run "tbf-example --burst=125000 --rate=1Mbps --peakRate=1.5Mbps"
+   $ ./ns3 --run "tbf-example --PrintHelp"
+   $ ./ns3 --run "tbf-example --burst=125000 --rate=1Mbps --peakRate=1.5Mbps"
 
 The expected output from the previous commands are traced value changes in the number of tokens in the first and second buckets.
 
@@ -134,8 +134,8 @@ The test suite can be run using the following commands:
 
 .. sourcecode:: bash
 
-  $ ./waf configure --enable-examples --enable-tests
-  $ ./waf build
+  $ ./ns3 configure --enable-examples --enable-tests
+  $ ./ns3 build
   $ ./test.py -s tbf-queue-disc
 
 or
@@ -144,4 +144,4 @@ or
 
 .. sourcecode:: bash
 
-  $ NS_LOG="TbfQueueDisc" ./waf --run "test-runner --suite=tbf-queue-disc"
+  $ NS_LOG="TbfQueueDisc" ./ns3 --run "test-runner --suite=tbf-queue-disc"
diff --git a/src/visualizer/examples/readme.txt b/src/visualizer/examples/readme.txt
index c23f9a361..7b3c2b685 100644
--- a/src/visualizer/examples/readme.txt
+++ b/src/visualizer/examples/readme.txt
@@ -3,7 +3,7 @@ For activating the visualizer, with any example, just pass the option
 script uses ns-3's command line parser (class CommandLine), and add 'visualizer'
 as a module dependency to that program.
 
-Alternatively, run the example with waf --run adding the --visualize option.
+Alternatively, run the example with ns3 --run adding the --visualize option.
 For example:
 
-./waf --run wifi-simple-adhoc-grid --visualize
+./ns3 --run wifi-simple-adhoc-grid --visualize
diff --git a/src/wave/examples/vanet-routing-compare.cc b/src/wave/examples/vanet-routing-compare.cc
index 5166c0953..0a6918620 100644
--- a/src/wave/examples/vanet-routing-compare.cc
+++ b/src/wave/examples/vanet-routing-compare.cc
@@ -81,10 +81,10 @@
  * several different simulation scenarios.
  * For example, to set up a scenario and save the configuration
  * as "scenario1.txt":
- *   ./waf --run "vanet-routing-compare --scenario=1 --saveconfig=scenario1.txt"
+ *   ./ns3 --run "vanet-routing-compare --scenario=1 --saveconfig=scenario1.txt"
  * Then, to re-play the scenario using the save configuration
  * settings:
- *   ./waf --run "vanet-routing-compare --loadconfig=scenario1.txt"
+ *   ./ns3 --run "vanet-routing-compare --loadconfig=scenario1.txt"
  *
  * Class Diagram:
  *   main()
diff --git a/src/wifi/doc/source/wifi-design.rst b/src/wifi/doc/source/wifi-design.rst
index cc91a05c1..0b2cba55b 100644
--- a/src/wifi/doc/source/wifi-design.rst
+++ b/src/wifi/doc/source/wifi-design.rst
@@ -633,7 +633,7 @@ The 802.11b model was split from the OFDM model when the NIST error rate
 model was added, into a new model called DsssErrorRateModel.
 
 Furthermore, the 5.5 Mbps and 11 Mbps models for 802.11b rely on library
-methods implemented in the GNU Scientific Library (GSL).  The Waf build
+methods implemented in the GNU Scientific Library (GSL).  The ns3 build
 system tries to detect whether the host platform has GSL installed; if so,
 it compiles in the newer models from [pursley2009]_ for 5.5 Mbps and 11 Mbps;
 if not, it uses a backup model derived from MATLAB simulations.
diff --git a/src/wifi/doc/source/wifi-testing.rst b/src/wifi/doc/source/wifi-testing.rst
index 89ddf5d31..74bc7986a 100644
--- a/src/wifi/doc/source/wifi-testing.rst
+++ b/src/wifi/doc/source/wifi-testing.rst
@@ -141,7 +141,7 @@ interval enabled (cases 9-16), and then with channel bonding enabled and
 short guard first disabled then enabled (cases 17-32).  Cases 33-64 repeat
 the same configurations but for two spatial streams (MIMO abstraction).
 
-When run with the legacy YansWifiPhy, as in ``./waf --run "wifi-spectrum-saturation-example --wifiType=ns3::YansWifiPhy"``, the same output is observed:
+When run with the legacy YansWifiPhy, as in ``./ns3 --run "wifi-spectrum-saturation-example --wifiType=ns3::YansWifiPhy"``, the same output is observed:
 
 ::
 
@@ -204,7 +204,7 @@ Some sample output with default arguments (no interference) is:
 
 ::
 
-  ./waf --run "wifi-spectrum-per-interference"
+  ./ns3 --run "wifi-spectrum-per-interference"
 
   wifiType: ns3::SpectrumWifiPhy distance: 50m; time: 10; TxPower: 16 dBm (40 mW)
   index   MCS  Rate (Mb/s) Tput (Mb/s) Received Signal (dBm)Noi+Inf(dBm) SNR (dB)
@@ -223,7 +223,7 @@ higher order modulations, due to lower SNR:
 
 ::
 
-  ./waf --run "wifi-spectrum-per-interference --waveformPower=0.001"
+  ./ns3 --run "wifi-spectrum-per-interference --waveformPower=0.001"
 
   wifiType: ns3::SpectrumWifiPhy distance: 50m; sent: 1000 TxPower: 16 dBm (40 mW)
   index   MCS Rate (Mb/s) Tput (Mb/s) Received Signal (dBm)Noi+Inf(dBm)  SNR (dB)
@@ -266,7 +266,7 @@ generate an eps file using gnuplot and vizualize the graph.
 
 ::
 
-  ./waf --run "wifi-bianchi"
+  ./ns3 --run "wifi-bianchi"
 
 .. _fig-wifi-bianchi-11a-54-adhoc:
 
@@ -283,7 +283,7 @@ When run for 802.11g 6 Mbit/s in infrastucture mode, the output is:
 
 ::
 
-  ./waf --run "wifi-bianchi --standard=11g --phyRate=6 --duration=500 --infra"
+  ./ns3 --run "wifi-bianchi --standard=11g --phyRate=6 --duration=500 --infra"
 
 .. _fig-wifi-bianchi-11g-6-infra:
 
diff --git a/src/wifi/examples/wifi-trans-example.sh b/src/wifi/examples/wifi-trans-example.sh
index f8c83bae8..4c88633d0 100644
--- a/src/wifi/examples/wifi-trans-example.sh
+++ b/src/wifi/examples/wifi-trans-example.sh
@@ -32,14 +32,14 @@ control_c()
 }
 trap control_c SIGINT
 
-#Save waf and script locations. Have to be run from where they are (otherwise won't find executables)
+#Save ns3 and script locations. Have to be run from where they are (otherwise won't find executables)
 scriptDir=`pwd`
 cd ../../../
-wafDir=`pwd`
+ns3Dir=`pwd`
 cd $scriptDir
 
 #Test where script is run from
-if test ! -f ${wafDir}/waf ; then
+if test ! -f ${ns3Dir}/ns3 ; then
   echo "Please run this script from within the directory `dirname $0`, like this:"
   echo "cd `dirname $0`"
   echo "./`basename $0`"
@@ -75,8 +75,8 @@ do
     bw=${bw_leg[${i}]}
     echo "==============================================="
     echo "Run for wifi-trans-example for ${std} and ${bw} MHz"
-    cd $wafDir
-    ./waf --run "wifi-trans-example --standard=$std --bw=$bw"
+    cd $ns3Dir
+    ./ns3 --run "wifi-trans-example --standard=$std --bw=$bw"
     echo "Generate PSD using ${file}.tr"
     file="${pre}${std}-${bw}MHz${suf}"
     gnuplot ${file}.plt
@@ -98,8 +98,8 @@ do
   do
     echo "==============================================="
     echo "Run for wifi-trans-example for ${std} and ${bw} MHz"
-    cd $wafDir
-    ./waf --run "wifi-trans-example --standard=$std --bw=$bw"
+    cd $ns3Dir
+    ./ns3 --run "wifi-trans-example --standard=$std --bw=$bw"
     echo "Generate PSD using ${file}.tr"
     file="${pre}${std}-${bw}MHz${suf}"
     gnuplot ${file}.plt
@@ -125,8 +125,8 @@ do
     #for all other combinations continue
     echo "==============================================="
     echo "Run for wifi-trans-example for ${std} and ${bw} MHz"
-    cd $wafDir
-    ./waf --run "wifi-trans-example --standard=$std --bw=$bw"
+    cd $ns3Dir
+    ./ns3 --run "wifi-trans-example --standard=$std --bw=$bw"
     echo "Generate PSD using ${file}.tr"
     file="${pre}${std}-${bw}MHz${suf}"
     gnuplot ${file}.plt
diff --git a/src/wifi/test/wifi-mac-ofdma-test.cc b/src/wifi/test/wifi-mac-ofdma-test.cc
index b80764a1d..ca5f47f84 100644
--- a/src/wifi/test/wifi-mac-ofdma-test.cc
+++ b/src/wifi/test/wifi-mac-ofdma-test.cc
@@ -314,7 +314,7 @@ TestMultiUserScheduler::ComputeUlMuInfo (void)
  *
  * Run this test with:
  *
- * NS_LOG="WifiMacOfdmaTestSuite=info|prefix_time|prefix_node" ./waf --run "test-runner --suite=wifi-mac-ofdma"
+ * NS_LOG="WifiMacOfdmaTestSuite=info|prefix_time|prefix_node" ./ns3 --run "test-runner --suite=wifi-mac-ofdma"
  *
  * to print the list of transmitted frames only, along with the TX time and the
  * node prefix. Replace 'info' with 'debug' if you want to print the debug messages
diff --git a/utils/bench-packets.cc b/utils/bench-packets.cc
index 20eef934c..dbf4a79ac 100644
--- a/utils/bench-packets.cc
+++ b/utils/bench-packets.cc
@@ -20,7 +20,7 @@
 
 // This program can be used to benchmark packet serialization/deserialization
 // operations using Headers and Tags, for various numbers of packets 'n'
-// Sample usage:  ./waf --run 'bench-packets --n=10000'
+// Sample usage:  ./ns3 --run 'bench-packets --n=10000'
 
 #include "ns3/command-line.h"
 #include "ns3/system-wall-clock-ms.h"