Merge tag 'ns-3.46.1' into unison

ns-3.46.1 release

CHANGES.md

@@ -12,6 +12,13 @@ Note that users who upgrade the simulator across versions, or who work directly
 
 This file is a best-effort approach to solving this issue; we will do our best but can guarantee that there will be things that fall through the cracks, unfortunately. If you, as a user, can suggest improvements to this file based on your experience, please contribute a patch or drop us a note on ns-developers mailing list.
 
+## Changes from ns-3.46 to ns-3.46.1
+
+The ns-3.46.1 contains some small build system fixes discovered after the ns-3.46 release, and two
+new module documentation chapters (see [RELEASE_NOTES.md](RELEASE_NOTES.md)). There are no API
+changes, changes to how the build system works, or changed behavior of the models, compared with
+the ns-3.46 release.
+
 ## Changes from ns-3.45 to ns-3.46
 
 ### New API

RELEASE_NOTES.md

@@ -12,6 +12,44 @@ a [GitLab.com issue tracker](https://gitlab.com/nsnam/ns-3-dev/-/issues) number,
 and references prefixed by '!' refer to a
 [GitLab.com merge request](https://gitlab.com/nsnam/ns-3-dev/-/merge_requests) number.
 
+## Release 3.46.1
+
+ns-3.46.1 is a small update to ns-3.46 to fix build issues discovered after release.
+There should be no model behavior or API changes compared with ns-3.46.
+
+This release is available from:
+<https://www.nsnam.org/release/ns-3.46.1.tar.bz2>
+
+### Supported platforms
+
+This release is intended to work on systems with the following minimal
+requirements (Note: not all ns-3 features are available on all systems):
+
+- g++-11.1 or later, or LLVM/clang++-17 or later
+- Python 3.8 or later
+- CMake 3.20 or later
+- (macOS only) Xcode 16.2 or later
+- (Windows only) Msys2/MinGW64, Msys2/UCRT64 and ClangCL/MSVC toolchains, or WSL2
+
+The version of clang-format enforced by the check-style-clang-format.py script for
+this release is version 20 only.
+
+Version 20 of the clang-tidy linter is now supported and recommended, although versions 15-19
+are still compatible.
+
+Python API requires [Cppyy](https://cppyy.readthedocs.io/en/latest/installation.html) and has only
+been tested on Linux. As of this release, the latest known version to work with ns-3 is cppyy==3.5.0.
+
+### New user-visible features
+
+- (doc) New module documentation for mobility and propagation modules
+
+### Bugs fixed
+
+- (build) The ns3 script was not compatible with Python 3.14
+- (build) A missing header include in test.cc was breaking the g++-12 build
+- (build) Fixed OpenMPI-based build on Alpine Linux
+
 ## Release 3.46
 
 This release is available from:

VERSION

@@ -1 +1 @@
-3.46
+3.46.1

build-support/custom-modules/ns3-coverage.cmake

@@ -33,7 +33,7 @@ if(${NS3_COVERAGE})
   add_custom_target(
     coverage_gcc
     COMMAND lcov -o ns3.info -c --directory ${CMAKE_BINARY_DIR} ${zero_counters}
-            --keep-going --ignore-errors inconsistent
+            --keep-going --ignore-errors inconsistent,negative
     WORKING_DIRECTORY ${CMAKE_OUTPUT_DIRECTORY}/coverage
     DEPENDS run_test_py
   )

doc/contributing/source/conf.py

@@ -49,9 +49,9 @@ copyright = "2015, ns-3 project"
 # built documents.
 #
 # The short X.Y version.
-version = "ns-3.46"
+version = "ns-3.46.1"
 # The full version, including alpha/beta/rc tags.
-release = "ns-3.46"
+release = "ns-3.46.1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/doxygen.conf

@@ -2299,6 +2299,7 @@ EXPAND_AS_DEFINED      = ATTRIBUTE_ACCESSOR_DEFINE \
                          ATTRIBUTE_VALUE_IMPLEMENT_WITH_NAME \
                          NS_UNUSED_GLOBAL \
                          NS_DEPRECATED \
+                         NS_DEPRECATED_3_47 \
                          NS_DEPRECATED_3_46 \
                          NS_DEPRECATED_3_45 \
                          NS_DEPRECATED_3_44 \

doc/installation/source/conf.py

@@ -49,9 +49,9 @@ copyright = "2018, ns-3 project"
 # built documents.
 #
 # The short X.Y version.
-version = "ns-3.46"
+version = "ns-3.46.1"
 # The full version, including alpha/beta/rc tags.
-release = "ns-3.46"
+release = "ns-3.46.1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/manual/source/conf.py

@@ -74,9 +74,9 @@ copyright = "2006-2019, ns-3 project"
 # built documents.
 #
 # The short X.Y version.
-version = "ns-3.46"
+version = "ns-3.46.1"
 # The full version, including alpha/beta/rc tags.
-release = "ns-3.46"
+release = "ns-3.46.1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/models/source/conf.py

@@ -74,9 +74,9 @@ copyright = "2006-2019, ns-3 project"
 # built documents.
 #
 # The short X.Y version.
-version = "ns-3.46"
+version = "ns-3.46.1"
 # The full version, including alpha/beta/rc tags.
-release = "ns-3.46"
+release = "ns-3.46.1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/tutorial/source/conf.py

@@ -71,9 +71,9 @@ copyright = "2006-2019, ns-3 project"
 # built documents.
 #
 # The short X.Y version.
-version = "ns-3.46"
+version = "ns-3.46.1"
 # The full version, including alpha/beta/rc tags.
-release = "ns-3.46"
+release = "ns-3.46.1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

ns3

@@ -88,7 +88,7 @@ def add_argument_to_subparsers(
     # Instead of copying and pasting repeated arguments for each parser, we add them here
     for subparser in parsers:
         subparser_name = subparser.prog.replace("ns3", "").strip()
-        destination = ("%s_%s" % (subparser_name, dest)) if subparser_name else dest
+        destination = (f"{subparser_name}_{dest}") if subparser_name else dest
         subparser.add_argument(
             *arguments, help=help_msg, action=action, default=default_value, dest=destination
         )
@@ -96,13 +96,19 @@ def add_argument_to_subparsers(
 
 def parse_args(argv):
     py39args = {"exit_on_error": False}
+    py314args = {"color": False}
     if sys.version_info < (3, 9):
         py39args = {}
+    if sys.version_info < (3, 14):
+        py314args = {}
     parser = argparse.ArgumentParser(
-        description="ns-3 wrapper for the CMake build system", add_help=False, **py39args
+        description="ns-3 wrapper for the CMake build system",
+        add_help=False,
+        **py39args,
+        **py314args,
     )
 
-    sub_parser = parser.add_subparsers()
+    sub_parser = parser.add_subparsers(dest="subparser")
 
     parser.add_argument(
         "-h",
@@ -126,9 +132,7 @@ def parse_args(argv):
         metavar="compile_or_die",
     )
     parser_help = sub_parser.add_parser("help", help="Print a summary of available commands")
-    parser_help.add_argument(
+
-        "help", help="Print a summary of available commands", action="store_true", default=False
-    )
     # parser.add_argument('--docset',
     #               help=(
     #                   'Create Docset, without building. This requires the docsetutil tool from Xcode 9.2 or earlier.'
@@ -145,7 +149,7 @@ def parse_args(argv):
         formatter_class=argparse.RawTextHelpFormatter,
     )
     parser_build.add_argument(
-        "build",
+        "target",
         help=(
             "Build the entire project or the specified target and its dependencies.\n"
             "To get the list of targets, use:\n"
@@ -153,14 +157,11 @@ def parse_args(argv):
         ),
         action="store",
         nargs="*",
-        default=None,
-        metavar="target",
     )
 
     parser_configure = sub_parser.add_parser(
         "configure", help='Try "./ns3 configure --help" for more configuration options'
     )
-    parser_configure.add_argument("configure", action="store_true", default=False)
     parser_configure.add_argument(
         "-d",
         "--build-profile",
@@ -322,18 +323,14 @@ def parse_args(argv):
     )
 
     parser_clean = sub_parser.add_parser("clean", help="Removes files created by ns3")
-    parser_clean.add_argument("clean", action="store_true", default=False)
 
     parser_distclean = sub_parser.add_parser(
         "distclean", help="Removes files created by ns3, tests and documentation"
     )
-    parser_distclean.add_argument("distclean", action="store_true", default=False)
 
     parser_install = sub_parser.add_parser("install", help="Install ns-3")
-    parser_install.add_argument("install", action="store_true", default=False)
 
     parser_uninstall = sub_parser.add_parser("uninstall", help="Uninstall ns-3")
-    parser_uninstall.add_argument("uninstall", action="store_true", default=False)
 
     parser_run = sub_parser.add_parser(
         "run",
@@ -341,7 +338,7 @@ def parse_args(argv):
         formatter_class=argparse.RawTextHelpFormatter,
     )
     parser_run.add_argument(
-        "run",
+        "target",
         help=(
             "Build and run the target executable.\n"
             "If --no-build is present, the build step is skipped.\n"
@@ -354,7 +351,6 @@ def parse_args(argv):
         ),
         default="",
         nargs="?",
-        metavar="target",
     )
     parser_run.add_argument(
         "--no-build", help="Skip build step.", action="store_true", default=False
@@ -427,20 +423,14 @@ def parse_args(argv):
     )
 
     parser_shell = sub_parser.add_parser(
-        "shell", help='Try "./ns3 shell --help" for more shell options'
+        "shell", help="Export necessary environment variables and open a shell"
-    )
-    parser_shell.add_argument(
-        "shell",
-        help="Export necessary environment variables and open a shell",
-        action="store_true",
-        default=False,
     )
 
     parser_docs = sub_parser.add_parser(
         "docs", help='Try "./ns3 docs --help" for more documentation options'
     )
     parser_docs.add_argument(
-        "docs",
+        "target",
         help="Build project documentation",
         choices=[
             "contributing",
@@ -546,8 +536,31 @@ def parse_args(argv):
         print("\n".join(textwrap.wrap(error_message, width=TERMINAL_WIDTH)))
         exit(1)
 
+    # Since Python 3.14, we cannot store_true positional arguments.
+    # To keep same behavior, we emulate what we had: one flag set to false for every subparser
+    # not set to anything. And build is an empty string.
+    def set_subparser_flags(parser, args):
+        sub_parser_actions = list(
+            filter(lambda x: isinstance(x, argparse._SubParsersAction), parser._actions)
+        )
+        sub_parsers = list(sub_parser_actions[0].choices.keys())
+        if args.subparser in sub_parsers:
+            sub_parsers.remove(args.subparser)
+
+        for parser in sub_parsers:
+            setattr(args, parser, "" if parser in ["build", "run", "show"] else False)
+
+        if args.subparser not in [None, "build", "run", "show"]:
+            setattr(args, args.subparser, True)
+
+        if args.subparser in ["build", "run", "docs"]:
+            setattr(args, args.subparser, args.target)
+        return args
+
+    args = set_subparser_flags(parser, args)
+
     # If run doesn't have a target, print the help message of the run parser
-    if "run" in args and args.run == "":
+    if args.subparser == "run" and args.run == "":
         parser_run.print_help()
         exit(-1)
 
@@ -793,23 +806,24 @@ def search_cmake_cache(build_profile):
                     current_cmake_generator = line.split("=")[-1]
 
     if not current_cmake_generator:
+        supported_cmake_generators = subprocess.check_output(["cmake", "--help"]).decode()
         # Search for available generators
-        cmake_generator_map = {
+        cmake_build_tool_to_generator_map = {
             "msbuild": "Visual Studio 17 2022",
             "ninja": "Ninja",
             "make": "Unix Makefiles",
             "xcodebuild": "Xcode",
         }
         available_generators = []
-        for generator in cmake_generator_map.keys():
+        for build_tool, generator in cmake_build_tool_to_generator_map.items():
-            if shutil.which(generator):
+            if shutil.which(build_tool) and generator in supported_cmake_generators:
                 available_generators.append(generator)
 
         # Select the first one
         if len(available_generators) == 0:
             raise Exception("No generator available.")
 
-        current_cmake_generator = cmake_generator_map[available_generators[0]]
+        current_cmake_generator = available_generators[0]
 
     return current_cmake_cache_folder, current_cmake_generator
 
@@ -1528,7 +1542,11 @@ def run_step(args, target_to_run, target_args):
             if target_to_run in ["mpiexec", "mpirun"] and os.getenv("MPI_CI"):
                 if shutil.which("ompi_info"):
                     try:
-                        subprocess.check_call([target_to_run, "--allow-run-as-root", "dir"])
+                        subprocess.check_call(
+                            [target_to_run, "--allow-run-as-root", "cmake", "--version"],
+                            stdout=subprocess.DEVNULL,
+                            stderr=subprocess.DEVNULL,
+                        )
                         target_args = ["--allow-run-as-root"] + target_args
                     except subprocess.CalledProcessError:
                         pass

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

@@ -117,7 +117,7 @@ The BuildingsPropagationLossModel provides an additional set of building-depende
 External Wall Loss (EWL)
 -------------------------
 
-This component models the penetration loss through walls for indoor to outdoor communications and vice-versa. The values are taken from the [cost231]_ model.
+This component models the penetration loss through walls for indoor to outdoor communications and vice-versa. The values are taken from the COST231 model.
 
   * Wood ~ 4 dB
   * Concrete with windows (not metallized) ~ 7 dB

src/core/model/deprecated.h

@@ -83,6 +83,13 @@
  */
 #define NS_DEPRECATED(msg) /** \deprecated msg */ [[deprecated(msg)]]
 
+/**
+ * @ingroup deprecation
+ * @def NS_DEPRECATED_3_47
+ * Tag for things deprecated in version ns-3.47.
+ */
+#define NS_DEPRECATED_3_47(msg) NS_DEPRECATED("Deprecated in ns-3.47: " msg)
+
 /**
  * @ingroup deprecation
  * @def NS_DEPRECATED_3_46

src/core/model/test.cc

@@ -15,6 +15,7 @@
 #include "singleton.h"
 #include "system-path.h"
 
+#include <algorithm>
 #include <cmath>
 #include <cstring>
 #include <list>

src/lte/model/lte-rrc-header.cc

@@ -29,7 +29,6 @@
 #define MAX_CELL_REPORT 8
 
 #define MAX_SCELL_REPORT 5
-#define MAX_SCELL_CONF 5
 
 namespace ns3
 {

src/mobility/doc/mobility.rst

@@ -1,29 +1,24 @@
 .. include:: replace.txt
-
 .. _Mobility:
 
 Mobility
---------
+========
 
 .. heading hierarchy:
-   ------------- Chapter
+   ============= Chapter
-   ************* Section (#.#)
+   ------------- Section (#.#)
-   ============= Subsection (#.#.#)
+   ~~~~~~~~~~~~~ Subsection (#.#.#)
-   ############# Paragraph (no number)
+   ^^^^^^^^^^^^^ Paragraph (no number)
 
-The mobility support in |ns3| includes:
+The mobility framework in |ns3| provides support for modeling movement and position in network simulations. This system enables simulation of mobile networks, wireless protocols, and location-dependent phenomena.
 
-- a set of mobility models which are used to track and maintain the *current* cartesian position and speed of an object.
+The |ns3| mobility system consists of three main components:
-- a "course change notifier" trace source which can be used to register listeners to the course changes of a mobility model
-- a number of helper classes which are used to place nodes and setup mobility models (including parsers for some mobility definition formats).
 
-Model Description
+- **Mobility Models**: Track and report on the current position, velocity, and movement patterns of network nodes
-*****************
+- **Position Allocators**: Determine initial node placement
+- **Helper Classes**: Simplify configuration and provide parsers for external mobility trace formats
 
-The source code for mobility lives in the directory ``src/mobility``.
+Most mobility-related source code is located in the ``src/mobility`` directory. For building-related mobility models, see ``src/buildings``.
-
-Design
-======
 
 The design includes mobility models, position allocators, and helper
 functions.
@@ -48,26 +43,52 @@ mobility capability on a set of nodes.
 We first describe the coordinate system and issues
 surrounding multiple coordinate systems.
 
-Coordinate system
+Scope and Limitations
-#################
+---------------------
 
-There are many possible coordinate systems and possible translations between
+**Current Support**:
-them. Currently, |ns3| provides support for the Cartesian, Geocentric Cartesian,
-and Geographic coordinate systems, which are defined as:
 
-* **Cartesian coordinates**: They represent a point in 3D space using the set of coordinates (x,y,z).
+- Cartesian, geocentric cartesian, and geographic coordinates are presently supported
-  This is the default coordinate system in |ns3|, and it is the most suitable for simulation scenarios whose size is in the order of a few km.
+- Twelve (12) open-field mobility models and one (1) buildings aware mobility model
+- Integration with external mobility trace generators
 
-  * **Topocentric coordinates**: Cartesian coordinates where a specific reference
+**Current Limitations**:
-    point on the Earth's surface, such as lat-lon, for the origin is given.
-    This coordinate system is useful for converting to and from Geocentric/Geographic coordinates.
 
-  * **Geocentric Cartesian coordinates**: Cartesian coordinate system where the
+- Z-axis movement support varies by model
-    origin is fixed in the Earth's center of mass. The implementation follows the description in Sec. 6.3 of [38811]_.
+- Limited built-in support for obstacle-aware movement
+- No native support for indoor mobility patterns
 
-* **Geographic coordinates**: They represent a point in 3D space by assuming it
+
-  is located on the surface or in the orbit of the Earth. Positions are uniquely
+
-  described by three values: latitude, longitude and altitude. The latter reference is the Earth's surface.
+Coordinate Systems
+------------------
+
+|ns3| supports multiple coordinate systems to accommodate different simulation scenarios and real-world applications.
+
+**Cartesian Coordinates (Default)**:
+
+- **Format**: (x, y, z) coordinates in 3D space
+- **Use case**: Most suitable for simulation scenarios spanning a few kilometers
+- **Implementation**: ``ns3::Vector`` class represents both positions and velocities
+
+**Topocentric Coordinates**:
+
+- **Format**: Cartesian coordinates with a specific Earth surface reference point
+- **Use case**: Converting between local and global coordinate systems
+- **Implementation**: Extends Cartesian with geographic origin reference (``GeographicPositions::TopocentricToGeographicCoordinates`` in ``src/mobility/model/geographic-position.cc``)
+
+**Geocentric Cartesian Coordinates**:
+
+- **Format**: Earth-centered Cartesian system with origin at Earth's center of mass
+- **Use case**: Satellite communications and global-scale simulations
+- **Implementation**: ``GeocentricConstantPositionMobilityModel``
+- **Reference**: Follows 3GPP TR 38.811, Section 6.3 [2]_
+
+**Geographic Coordinates**:
+
+- **Format**: Latitude, longitude, and altitude relative to Earth's surface
+- **Use case**: GPS-based applications and real-world location mapping
+- **Implementation**: ``GeographicPosition`` class with conversion utilities
 
 At the moment, the geocentric Cartesian coordinates are adopted by the
 GeocentricConstantPositionMobilityModel only.
@@ -77,63 +98,100 @@ Additionally, users can set the position of a node by its geographical coordinat
 via the methods Get/SetGeographicPosition.
 
 
-Coordinates
-###########
 
-The base class for a coordinate is called ``ns3::Vector``.  While
+Available Mobility Models
-positions are normally described as coordinates and not vectors in
+-------------------------
-the literature, it is possible to reuse the same data structure to
-represent position (x,y,z) and velocity (magnitude and direction
-from the current position).  |ns3| uses class Vector for both.
 
-There are also some additional related structures used to support
-mobility models.
 
-- Rectangle
+Core Classes
-- Box
+~~~~~~~~~~~~
-- Waypoint
 
-MobilityModel
+**MobilityModel Base Class**
-#############
 
-Describe base class
+The ``ns3::MobilityModel`` class is the foundation of the mobility system:
 
-- GetPosition ()
+.. sourcecode:: cpp
-- Position and Velocity attributes
-- GetDistanceFrom ()
-- CourseChangeNotification
 
-MobilityModel Subclasses
+   // Key methods
-########################
+   Vector GetPosition() const;           // Current position
+   Vector GetVelocity() const;          // Current velocity
+   double GetDistanceFrom(Ptr<const MobilityModel> other) const;
 
-- ConstantPosition
+   // Attributes
-- ConstantVelocity
+   Vector Position;                     // Current position
-- ConstantAcceleration
+   Vector Velocity;                     // Current velocity
-- GaussMarkov
-- Hierarchical
-- RandomDirection2D
-- RandomWalk2D
-- RandomWaypoint
-- SteadyStateRandomWaypoint
-- Waypoint
-- GeocentricConstantPosition
 
-PositionAllocator
+   // Trace sources
-#################
+   TracedCallback<Ptr<const MobilityModel>> CourseChange;
 
-Position allocators usually used only at beginning, to lay out the nodes
+**Key Features**:
-initial position.  However, some mobility models (e.g. RandomWaypoint) will
-use a position allocator to pick new waypoints.
 
-- ListPositionAllocator
+- **Position Tracking**
-- GridPositionAllocator
+- **Velocity Tracking**
-- RandomRectanglePositionAllocator
+- **Distance Calculation**: Calculates distance to another mobility model object
-- RandomBoxPositionAllocator
+- **Course Change Notifications**: Trace source for movement events
-- RandomDiscPositionAllocator
+- **Node Aggregation**: Typically aggregated to ``ns3::Node`` objects
-- UniformDiscPositionAllocator
 
-Helper
+Child Classes
-######
+~~~~~~~~~~~~~
+
+**Static Models:**
+
+- **ConstantPositionMobilityModel**: Nodes remain at fixed positions throughout the simulation. The position is set once during initialization and only changes if explicitly set by the user during runtime. This model is ideal for stationary infrastructure nodes, base stations, or scenarios where mobility is not required. It has near zero computational overhead during simulation runtime.
+
+- **GeocentricConstantPositionMobilityModel**: Similar to ConstantPositionMobilityModel but with geographic coordinate support. Positions can be specified using latitude, longitude, and altitude coordinates, which are internally converted to the simulation's Cartesian coordinate system. Useful for real-world GPS-based scenarios and satellite communication simulations.
+
+**Linear Motion Models:**
+
+- **ConstantVelocityMobilityModel**: Nodes move in a straight line with constant speed. The velocity vector (speed and direction) is set once and remains unchanged unless explicitly modified by external events. This model is commonly used with |ns2| mobility traces where setdest commands update the velocity.
+
+- **ConstantAccelerationMobilityModel**: Implements uniformly accelerated motion following kinematic equations. The node starts with an initial velocity and acceleration vector, with position updated according to:
+
+.. math::
+
+  \vec{p}(t) = \vec{p_0} + \vec{v_0} \cdot t + \frac{1}{2} \vec{a} \cdot t^2
+
+This model is useful for scenarios involving vehicle acceleration/deceleration or projectile motion.
+
+**Random Motion Models:**
+
+- **RandomWalk2dMobilityModel**: Implements a two-dimensional random walk where nodes change direction and speed at regular time intervals. At each step, a new direction is randomly selected from a uniform distribution [0, 2pi], and speed is drawn from a configurable random variable. Movement is constrained within specified rectangular bounds, with reflection or wrapping behavior at boundaries. The model includes configurable parameters for step time, speed distribution, and boundary behavior.
+
+- **RandomWalk2dOutdoorMobilityModel**: Enhanced version of RandomWalk2dMobilityModel that incorporates building awareness. Nodes avoid moving through building obstacles by checking for intersections with building polygons before committing to movement. When a building collision is detected, the node selects an alternative direction. This model requires integration with building models and is particularly useful for urban mobility scenarios.
+
+- **RandomDirection2dMobilityModel**: Nodes move in straight lines for random durations, then pause and select new random directions. Unlike RandomWalk2d, movement occurs in longer straight-line segments rather than frequent small steps. The model alternates between movement and pause periods, with both durations drawn from configurable random variables. Direction changes occur uniformly over [0, 2pi], and speed is constant during each movement phase.
+
+- **RandomWaypointMobilityModel**: Classic random waypoint model where nodes move from their current position to randomly selected destination waypoints. Upon reaching a waypoint, the node pauses for a random duration, then selects a new random destination. Movement between waypoints follows straight-line paths at constant speeds drawn from a configurable distribution. This model exhibits well-known characteristics including non-uniform spatial distribution and speed decay over time.
+
+- **SteadyStateRandomWaypointMobilityModel**: Addresses the initial transient behavior of the standard RandomWaypointMobilityModel by starting nodes with positions and velocities drawn from the model's steady-state distribution. This eliminates the artificial clustering and speed artifacts present during the initial simulation phase of the standard random waypoint model, providing more realistic results from simulation start.
+
+**Advanced Models:**
+
+- **GaussMarkovMobilityModel**: Implements a Gaussian-Markov stochastic process where velocity components are correlated over time. The model balances between random movement and momentum conservation using a tunable randomness parameter alpha in the range [0,1]. When alpha=0, movement is completely random; when alpha=1, movement maintains constant velocity. The velocity update equation is:
+
+.. math::
+
+  v_n = alpha \cdot v_{n-1} + (1-alpha) \cdot \bar{v} + \sqrt{1-alpha^2} \cdot v_{random}
+
+This model produces more realistic mobility patterns with temporal correlation, suitable for human pedestrian movement.
+
+- **WaypointMobilityModel**: Follows user-defined sequences of waypoints with precise timing control. Each waypoint specifies a position and arrival time, allowing deterministic or scripted mobility patterns. The model supports complex trajectories, synchronized movement scenarios, and replay of real-world mobility traces. Waypoints can be added dynamically during simulation, enabling adaptive mobility patterns based on simulation events.
+
+- **HierarchicalMobilityModel**: Supports group mobility scenarios using parent-child relationships. Child nodes move relative to a parent mobility model, with the final position being the vector sum of parent and child positions. The parent model defines the group's overall movement pattern, while child models define individual member movements relative to the group. This architecture enables scenarios like vehicular convoys, pedestrian groups, or mobile sensor clusters where individual nodes maintain local mobility within a moving group context.
+
+**Position Allocators**:
+
+- **ListPositionAllocator**: Uses a predefined list of positions
+- **GridPositionAllocator**: Arranges nodes in regular grid patterns
+- **RandomRectanglePositionAllocator**: Uniform distribution within rectangular areas
+- **RandomBoxPositionAllocator**: Uniform distribution within 3D box regions
+- **RandomDiscPositionAllocator**: Uniform distribution within circular areas
+- **UniformDiscPositionAllocator**: Even distribution on disc circumference
+
+A position allocator is not always required, as some mobility models generate initial positions during initialization. Among the built-in ns-3 models, **SteadyStateRandomWaypointMobilityModel** is the only one with this capability.
+
+Helper Classes
+--------------
 
 A special mobility helper is provided that is mainly aimed at supporting
 the installation of mobility to a Node container (when using containers
@@ -149,15 +207,53 @@ model positions (i.e., the child position is defined as an offset to
 the parent position).  In the GroupMobilityHelper, the parent mobility
 model is not associated with any node, and is used as the parent mobility
 model for all (distinct) child mobility models.  The reference point group
-mobility model [Camp2002]_ is the basis for this |ns3| model.
+mobility model [1]_ is the basis for this |ns3| model.
 
-ns-2 MobilityHelper
-###################
 
-The |ns2| mobility format is a widely used mobility trace format.  The
+MobilityHelper
-documentation is available at: http://www.isi.edu/nsnam/ns/doc/node172.html
+~~~~~~~~~~~~~~
 
-Valid trace files use the following |ns2| statements:
+The ``MobilityHelper`` class simplifies mobility configuration:
+
+.. sourcecode:: cpp
+
+   // Basic configuration
+   MobilityHelper mobility;
+   mobility.SetPositionAllocator("ns3::GridPositionAllocator",
+                                 "MinX", DoubleValue(0.0),
+                                 "MinY", DoubleValue(0.0),
+                                 "DeltaX", DoubleValue(5.0),
+                                 "DeltaY", DoubleValue(10.0));
+
+   mobility.SetMobilityModel("ns3::RandomWalk2dMobilityModel",
+                            "Bounds", RectangleValue(Rectangle(-50, 50, -50, 50)));
+
+   // Installation
+   mobility.Install(nodeContainer);
+
+GroupMobilityHelper
+~~~~~~~~~~~~~~~~~~~
+
+Supports group mobility scenarios using the reference point group mobility model [1]_:
+
+.. sourcecode:: cpp
+
+   GroupMobilityHelper groupMobility;
+   groupMobility.SetReferencePointMobilityModel("ns3::RandomWaypointMobilityModel");
+   groupMobility.SetMemberMobilityModel("ns3::RandomWalk2dMobilityModel");
+   groupMobility.Install(groupNodes);
+
+Ns2MobilityHelper
+~~~~~~~~~~~~~~~~~
+
+Parses |ns2| format mobility traces for compatibility with existing tools:
+
+.. sourcecode:: cpp
+
+   Ns2MobilityHelper ns2mobility("mobility-trace.ns_movements");
+   ns2mobility.Install();
+
+The |ns2| mobility format is a widely used mobility trace format. Valid trace files use the following |ns2| statements:
 
 .. sourcecode:: bash
 
@@ -165,130 +261,245 @@ Valid trace files use the following |ns2| statements:
    $node set Y_ y1
    $node set Z_ z1
    $ns at $time $node setdest x2 y2 speed
-   $ns at $time $node set X_ x1
-   $ns at $time $node set Y_ Y1
-   $ns at $time $node set Z_ Z1
 
-In the above, the initial positions are set using the ``set`` statements.
+Supported ns-2 Commands
-Also, this ``set`` can be specified for a future time, such as in the
+~~~~~~~~~~~~~~~~~~~~~~~
-last three statements above.
 
-The command ``setdest`` instructs the simulation to start moving the
+- ``$node set X_ x1``: Set initial X position
-specified node towards the coordinate (x2, y2) at the specified time.
+- ``$node set Y_ y1``: Set initial Y position
-Note that the node may never get to the destination, but will
+- ``$node set Z_ z1``: Set initial Z position
-proceed towards the destination at the specified speed until it
+- ``$ns at $time $node setdest x2 y2 speed``: Move to destination at specified time
-either reaches the destination (where it will pause), is set to
-a new position (via ``set``), or sent on another course change
-(via ``setdest``).
 
-Note that in |ns3|, movement along the Z dimension is not supported.
+Note that in |ns3|, movement along the Z dimension is not supported by all mobility models.
 
-Some examples of external tools that can export in this format include:
-
-- `BonnMotion <http://net.cs.uni-bonn.de/wg/cs/applications/bonnmotion/>`_
-
-  - `Installation instructions <https://www.nsnam.org/wiki/HOWTO_use_ns-3_with_BonnMotion_mobility_generator_and_analysis_tool>`_ and
-  - `Documentation <https://sys.cs.uos.de/bonnmotion/doc/README.pdf>`_ for using BonnMotion with |ns3|
-
-- `SUMO <https://sourceforge.net/apps/mediawiki/sumo/index.php?title=Main_Page>`_
-- `TraNS <http://trans.epfl.ch/>`_
-- |ns2| `setdest <http://www.winlab.rutgers.edu/~zhibinwu/html/ns2_wireless_scene.htm>`_ utility
-
-A special Ns2MobilityHelper object can be used to parse these files
-and convert the statements into |ns3| mobility events.  The underlying
-ConstantVelocityMobilityModel is used to model these movements.
-
-See below for additional usage instructions on this helper.
-
-Scope and Limitations
-=====================
-
-- Cartesian, geocentric cartesian, and geographic coordinates are presently supported
-
-References
-==========
-
-.. [Camp2002] T. Camp, J. Boleng, V. Davies.  "A survey of mobility models for ad hoc network research",
-   in Wireless Communications and Mobile Computing, 2002: vol. 2, pp. 2483-2502.
-.. [38811] 3GPP. 2018. TR 38.811, Study on New Radio (NR) to support non-terrestrial networks, V15.4.0. (2020-09).
 
 Usage
-*****
+-----
 
-Most |ns3| program authors typically interact with the mobility system
+Most |ns3| program authors typically interact with the mobility system only at configuration time. However, various |ns3| objects interact with mobility objects repeatedly during runtime, such as a propagation model trying to determine the path loss between two mobile nodes.
-only at configuration time.  However, various |ns3| objects interact
-with mobility objects repeatedly during runtime, such as a propagation
-model trying to determine the path loss between two mobile nodes.
 
-Helper
+Basic Configuration
-======
+~~~~~~~~~~~~~~~~~~~
 
-A typical usage pattern can be found in the ``third.cc`` program in the
+Random Walk Setup
-tutorial.
+^^^^^^^^^^^^^^^^^
-
-First, the user instantiates a ``MobilityHelper`` object and sets some
-``Attributes`` controlling the "position allocator" functionality.
 
 .. sourcecode:: cpp
 
+  // Create nodes
+  NodeContainer nodes;
+  nodes.Create(10);
+
+  // Configure mobility
   MobilityHelper mobility;
 
+  // Grid initial placement
   mobility.SetPositionAllocator("ns3::GridPositionAllocator",
-    "MinX", DoubleValue(0.0),
+                                "MinX", DoubleValue(0.0),
-    "MinY", DoubleValue(0.0),
+                                "MinY", DoubleValue(0.0),
-    "DeltaX", DoubleValue(5.0),
+                                "DeltaX", DoubleValue(10.0),
-    "DeltaY", DoubleValue(10.0),
+                                "DeltaY", DoubleValue(10.0),
-    "GridWidth", UintegerValue(3),
+                                "GridWidth", UintegerValue(5),
-    "LayoutType", StringValue("RowFirst"));
+                                "LayoutType", StringValue("RowFirst"));
-
-This code tells the mobility helper to use a two-dimensional grid to initially
-place the nodes.  The first argument is an |ns3| TypeId specifying the
-type of mobility model; the remaining attribute/value pairs configure
-this position allocator.
-
-Next, the user typically sets the MobilityModel subclass; e.g.:
-
-.. sourcecode:: cpp
 
+  // Random walk mobility
   mobility.SetMobilityModel("ns3::RandomWalk2dMobilityModel",
-    "Bounds", RectangleValue(Rectangle(-50, 50, -50, 50)));
+                           "Bounds", RectangleValue(Rectangle(-100, 100, -100, 100)),
+                           "Speed", StringValue("ns3::ConstantRandomVariable[Constant=5.0]"),
+                           "Direction", StringValue("ns3::UniformRandomVariable[Min=0|Max=6.28]"));
 
-Once the helper is configured, it is typically passed a container, such as:
+  mobility.Install(nodes);
+
+Group Mobility Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. sourcecode:: cpp
 
-  mobility.Install(wifiStaNodes);
+  // Reference point group mobility
+  GroupMobilityHelper groupMobility;
 
-A MobilityHelper object may be reconfigured and reused for different
+  // Parent mobility (reference point)
-NodeContainers during the configuration of an |ns3| scenario.
+  groupMobility.SetReferencePointMobilityModel("ns3::WaypointMobilityModel");
 
-Ns2MobilityHelper
+  // Child mobility (group members)
-=================
+  groupMobility.SetMemberMobilityModel("ns3::RandomWalk2dMobilityModel",
+                                       "Bounds", RectangleValue(Rectangle(-10, 10, -10, 10)));
 
-Two example programs are provided demonstrating the use of the
+  // Set reference point waypoints
-|ns2| mobility helper:
+  Ptr<WaypointMobilityModel> reference = groupMobility.GetReferencePointMobilityModel();
+  reference->AddWaypoint(Waypoint(Seconds(0), Vector(0, 0, 0)));
+  reference->AddWaypoint(Waypoint(Seconds(100), Vector(100, 0, 0)));
+  reference->AddWaypoint(Waypoint(Seconds(200), Vector(100, 100, 0)));
 
-- ns2-mobility-trace.cc
+  groupMobility.Install(groupNodes);
-- bonnmotion-ns2-example.cc
 
-ns2-mobility-trace
+Geographic Positioning
-##################
+^^^^^^^^^^^^^^^^^^^^^^
 
-The ``ns2-mobility-trace.cc`` program is an example of loading an
+.. sourcecode:: cpp
-|ns2| trace file that specifies the movements of two nodes over 100
+
-seconds of simulation time.  It is paired with the file
+  // Use geocentric coordinates
-``default.ns_movements``.
+  MobilityHelper mobility;
+  mobility.SetMobilityModel("ns3::GeocentricConstantPositionMobilityModel");
+
+  // Set geographic position
+  Ptr<GeocentricConstantPositionMobilityModel> model =
+      node->GetObject<GeocentricConstantPositionMobilityModel>();
+  model->SetGeographicPosition(Vector(latitude, longitude, altitude));
+
+Advanced Usage
+~~~~~~~~~~~~~~
+
+Random Number Stream Assignment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To avoid the possibility that configuration or parameter changes in a program affect its mobility behavior, it is necessary to assign fixed stream numbers to any random variables associated with mobility models. It is strongly advised to read the section on how to perform independent replications (see "Random Variables", the chapter 3.1 of ns-3 Manual).
+
+.. sourcecode:: cpp
+
+  // Assign specific random streams
+  int64_t streamIndex = 100;
+  MobilityHelper mobility;
+  // ... configure mobility ...
+  mobility.Install(nodes);
+
+  // Assign streams after installation
+  int64_t streamsUsed = mobility.AssignStreams(nodes, streamIndex);
+
+Class ``MobilityModel`` and class ``PositionAllocator`` both have public API to assign streams to underlying random variables:
+
+.. sourcecode:: cpp
+
+  /**
+   * Assign a fixed random variable stream number to the random variables
+   * used by this model. Return the number of streams (possibly zero) that
+   * have been assigned.
+   *
+   * \param stream first stream index to use
+   * \return the number of stream indices assigned by this model
+   */
+  int64_t AssignStreams(int64_t stream);
+
+External Tool Integration
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**BonnMotion**
+
+BonnMotion is a Java software which creates and analyses mobility scenarios [3]_ . It is developed within the Communication Systems group at the Institute of Computer Science 4 of the University of Bonn, Germany, where it serves as a tool for the investigation of mobile ad hoc network characteristics. BonnMotion is being jointly developed by the Communication Systems group at the University of Bonn, Germany, the Toilers group at the Colorado School of Mines, Golden, CO, USA, and the Distributed Systems group at the University of Osnabrück, Germany.
+
+- **Installation**: `Installation instructions <https://www.nsnam.org/wiki/HOWTO_use_ns-3_with_BonnMotion_mobility_generator_and_analysis_tool>`_ for using BonnMotion with |ns3|
+- **Documentation**: `Documentation <https://sys.cs.uos.de/bonnmotion/doc/README.pdf>`_ available
+- **Output Format**: |ns2| compatible traces
+
+**SUMO (Simulation of Urban Mobility)**
+
+Literature on the subject of urban wireless network often use SUMO to model the mobility in a given scenario, either based on a fictionnal setup or on real urban environment extracted through tools like OpenStreetMap.
+
+- **Purpose**: Realistic vehicular mobility simulation
+- **Website**: `SUMO <https://sourceforge.net/apps/mediawiki/sumo/index.php?title=Main_Page>`_
+- **Integration**: Exports |ns2| format traces
+- **Use Case**: Urban traffic scenarios
+
+**TraNS**
+
+- **Purpose**: Traffic and network simulation environment
+- **Website**: `TraNS <http://trans.epfl.ch/>`_
+- **Features**: Combines SUMO with network simulation
+- **Output**: Compatible mobility traces
+
+**|ns2| setdest Utility**
+
+The |ns2| `setdest <http://www.winlab.rutgers.edu/~zhibinwu/html/ns2_wireless_scene.htm>`_ utility can generate basic mobility patterns.
+
+Tracing and Visualization
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Tracing provides access to mobility models whenever the mobility model declares a course change (a change in position or velocity).  Mobility models can also be polled at any time to find the current position of the model.
+
+**Course Change Tracing**
+
+An example of this tracing method is the Waypoint Mobility Model. When a node selects a new waypoint, the ``NotifyCourseChange()`` function of the ``MobilityModel`` class (parent to the ``WaypointMobilityModel`` class) is called, triggering the course change trace. This allow the user to log when an object has reached certain points.
+
+.. sourcecode:: cpp
+
+  // Enable course change logging
+  void CourseChangeCallback(Ptr<const MobilityModel> model) {
+      Vector pos = model->GetPosition();
+      Vector vel = model->GetVelocity();
+      std::cout << "Node moved to: " << pos << " with velocity: " << vel << std::endl;
+  }
+
+  // Connect trace source
+  Config::Connect("/NodeList/*/$ns3::MobilityModel/CourseChange",
+                  MakeCallback(&CourseChangeCallback));
+
+**Mobility Model Polling**
+
+If client code needs access to a mobility model's position or other state information outside of course change events, it may directly query the mobility model at any time.  Mobility models are often aggregated (using ns-3 Object aggregation) to ns-3 nodes, so the mobility model pointer can usually be easily obtained from a node pointer using ``GetObject()``.
+
+.. sourcecode:: cpp
+
+  // Periodic position printing
+  void PrintPositions(NodeContainer nodes) {
+      for (auto i = nodes.Begin(); i != nodes.End(); ++i) {
+          Ptr<MobilityModel> mobility = (*i)->GetObject<MobilityModel>();
+          Vector pos = mobility->GetPosition();
+          std::cout << "Node " << (*i)->GetId() << ": " << pos << std::endl;
+      }
+      Simulator::Schedule(Seconds(1.0), &LogPositions, nodes);
+  }
+
+Common Use Cases
+~~~~~~~~~~~~~~~~
+
+**Wireless Network Evaluation**
+
+- **Scenario**: Mobile ad-hoc networks (MANETs)
+- **Models**: RandomWaypoint, RandomWalk2d
+- **Considerations**: Realistic speed distributions, pause times
+
+**Vehicular Networks**
+
+- **Scenario**: Vehicle-to-vehicle (V2V) communication
+- **Tools**: SUMO integration
+- **Models**: Trace-based mobility from traffic simulators
+
+**Sensor Networks**
+
+- **Scenario**: Environmental monitoring
+- **Models**: ConstantPosition with occasional RandomWalk
+- **Considerations**: Energy-efficient movement patterns
+
+**Satellite Communications**
+
+- **Scenario**: Low Earth Orbit (LEO) constellations
+- **Models**: GeocentricConstantPosition or custom orbital models
+- **Coordinates**: Geocentric Cartesian system
+
+Examples and Tests
+------------------
+
+The following example programs demonstrate mobility usage:
+
+- ``main-random-topology.cc`` - Random initial placement
+- ``main-random-walk.cc`` - Random walk mobility
+- ``main-grid-topology.cc`` - Grid-based positioning
+- ``ns2-mobility-trace.cc`` - |ns2| trace file parsing
+- ``reference-point-group-mobility-example.cc`` - Group mobility demonstration
+
+ns2-mobility-trace Example
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``ns2-mobility-trace.cc`` program is an example of loading an |ns2| trace file that specifies the movements of two nodes over 100 seconds of simulation time. It is paired with the file ``default.ns_movements``.
 
 The program behaves as follows:
 
-- a Ns2MobilityHelper object is created, with the specified trace file.
+- A Ns2MobilityHelper object is created, with the specified trace file.
 - A log file is created, using the log file name argument.
-- A node container is created with the number of nodes specified in the command line.  For this particular trace file, specify the value 2 for this argument.
+- A node container is created with the number of nodes specified in the command line. For this particular trace file, specify the value 2 for this argument.
-- the Install() method of Ns2MobilityHelper to set mobility to nodes. At this moment, the file is read line by line, and the movement is scheduled in the simulator.
+- The Install() method of Ns2MobilityHelper to set mobility to nodes. At this moment, the file is read line by line, and the movement is scheduled in the simulator.
 - A callback is configured, so each time a node changes its course a log message is printed.
 
-The example prints out messages generated by each read line from the ns2 movement trace file.   For each line, it shows if the line is correct, or of it has errors and in this case it will be ignored.
-
 Example usage:
 
 .. sourcecode:: bash
@@ -309,7 +520,7 @@ Sample log file output:
   +204480076.0ns POS: x=205.667, y=150, z=0; VEL:0, y=0, z=0
 
 bonnmotion-ns2-example
-######################
+~~~~~~~~~~~~~~~~~~~~~~
 
 The ``bonnmotion-ns2-example.cc`` program, which models the movement of
 a single mobile node for 1000 seconds of simulation time, has a few
@@ -375,100 +586,31 @@ so there is a chance that the position in |ns2| may be slightly
 different than the respective position when using the trace file
 in |ns3|.
 
-Use of Random Variables
+reference-point-group-mobility-example
-=======================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A typical use case is to evaluate protocols on a mobile topology that
+The reference point group mobility model [1]_ is demonstrated in the example program ``reference-point-group-mobility-example.cc``. This example runs a short simulation that illustrates a parent WaypointMobilityModel traversing a rectangular course within a bounding box, and three member nodes independently execute a two-dimensional random walk around the parent position, within a small bounding box.
-involves some randomness in the motion or initial position allocation.
-To obtain random motion and positioning that is not affected by
-the configuration of the rest of the scenario, it is recommended to
-use the "AssignStreams" facility of the random number system.
 
-Class ``MobilityModel`` and class ``PositionAllocator`` both have public
+The example illustrates configuration using the GroupMobilityHelper and manual configuration without a helper; the configuration option is selectable by command-line argument.
-API to assign streams to underlying random variables:
 
-.. sourcecode:: cpp
+The example outputs two mobility trace files, a course change trace and a time-series trace of node position. The latter trace file can be parsed by a Bash script (``reference-point-group-mobility-animate.sh``) to create PNG images at one-second intervals, which can then be combined using an image processing program such as ImageMagick to form a basic animated gif of the mobility.
 
-  /**
+Tests
-   * Assign a fixed random variable stream number to the random variables
+~~~~~
-   * used by this model. Return the number of streams (possibly zero) that
-   * have been assigned.
-   *
-   * \param stream first stream index to use
-   * \return the number of stream indices assigned by this model
-   */
-  int64_t AssignStreams(int64_t stream);
 
-The class ``MobilityHelper`` also provides this API.  The typical usage
+Specific validation results and test cases are documented in the |ns3| test suite under ``src/mobility/test/``.
-pattern when using the helper is:
-
-.. sourcecode:: cpp
-
-  int64_t streamIndex = /*some positive integer */
-  MobilityHelper mobility;
-  ... (configure mobility)
-  mobility.Install(wifiStaNodes);
-  int64_t streamsUsed = mobility.AssignStreams(wifiStaNodes, streamIndex);
-
-If AssignStreams is called before Install, it will not have any effect.
-
-Advanced Usage
-==============
-
-A number of external tools can be used to generate traces read by
-the Ns2MobilityHelper.
-
-ns-2 scengen
-############
-
-TBD
-
-BonnMotion
-##########
-
-http://net.cs.uni-bonn.de/wg/cs/applications/bonnmotion/
-
-SUMO
-####
-
-http://sourceforge.net/apps/mediawiki/sumo/index.php?title=Main_Page
-
-TraNS
-#####
-
-http://trans.epfl.ch/
-
-Examples
-========
-
-- main-random-topology.cc
-- main-random-walk.cc
-- main-grid-topology.cc
-- ns2-mobility-trace.cc
-- ns2-bonnmotion.cc
-
-reference-point-group-mobility-example.cc
-#########################################
-
-The reference point group mobility model ([Camp2002]_) is demonstrated
-in the example program `reference-point-group-mobility-example.cc`.
-This example runs a short simulation that illustrates a parent
-WaypointMobilityModel traversing a rectangular course within a bounding
-box, and three member nodes independently execute a two-dimensional
-random walk around the parent position, within a small bounding box.
-The example illustrates configuration using the GroupMobilityHelper
-and manual configuration without a helper; the configuration option
-is selectable by command-line argument.
-
-The example outputs two mobility trace files, a course change trace and
-a time-series trace of node position.  The latter trace file can be
-parsed by a Bash script (`reference-point-group-mobility-animate.sh`)
-to create PNG images at one-second intervals, which can then be combined
-using an image processing program such as ImageMagick to form a
-basic animated gif of the mobility.  The example and animation program
-files have further instructions on how to run them.
 
 Validation
-**********
+----------
 
-TBD
+No formal validation has been done.
+
+References
+----------
+
+.. [1] T. Camp, J. Boleng, V. Davies. "A survey of mobility models for ad hoc network research",
+   in Wireless Communications and Mobile Computing, 2002: vol. 2, pp. 2483-2502.
+
+.. [2] 3GPP. 2018. TR 38.811, Study on New Radio (NR) to support non-terrestrial networks, V15.4.0. (2020-09).
+
+.. [3] BonnMotion documentation, https://sys.cs.uos.de/bonnmotion/doc/README.pdf

src/mobility/helper/ns2-mobility-helper.cc

@@ -49,7 +49,6 @@ NS_LOG_COMPONENT_DEFINE("Ns2MobilityHelper");
 #define NS2_Z_COORD "Z_"
 #define NS2_SETDEST "setdest"
 #define NS2_SET "set"
-#define NS2_NODEID "$node_("
 #define NS2_NS_SCH "$ns_"
 
 /**

src/olsr/model/olsr-routing-protocol.cc

@@ -88,12 +88,6 @@
 /// Maximum number of messages per packet.
 #define OLSR_MAX_MSGS 64
 
-/// Maximum number of hellos per message (4 possible link types * 3 possible nb types).
-#define OLSR_MAX_HELLOS 12
-
-/// Maximum number of addresses advertised on a message.
-#define OLSR_MAX_ADDRS 64
-
 namespace ns3
 {
 

src/propagation/doc/propagation.rst

@@ -4,13 +4,46 @@
 .. _Propagation:
 
 Propagation
------------
+===========
+
+.. heading hierarchy:
+   ============= Chapter
+   ------------- Section (#.#)
+   ~~~~~~~~~~~~~ Subsection (#.#.#)
+   ^^^^^^^^^^^^^ Paragraph (no number)
 
 The |ns3| ``propagation`` module defines two generic interfaces, namely :cpp:class:`PropagationLossModel`
 and :cpp:class:`PropagationDelayModel`, to model respectively the propagation loss and the propagation delay.
 
+Scope and Limitations
+---------------------
+
+**Current Support**
+
+- A wide range of propagation loss models (Friis, Two-Ray Ground, Log-Distance, Nakagami, etc.) covering free-space, empirical, and stochastic channel conditions
+
+- Propagation delay modeling including constant speed and random delay models
+
+- Frequency-dependent propagation loss models for different simulation scenarios
+
+- Support for spectrum-aware propagation loss calculations
+
+- Compatibility with both PHY and channel modules in |ns3|
+
+
+**Current Limitations**
+
+- Some empirical models may have limited validity outside their intended environments
+
+- Computational cost can increase significantly when using complex models with large node counts
+
+- Limited built-in support for site-specific or ray-tracing–based propagation models
+
+- Integration with terrain and obstacle-aware models requires external tools or extensions
+
+
 PropagationLossModel
-********************
+--------------------
 
 Propagation loss models calculate the Rx signal power considering the Tx signal power and the
 mutual Rx and Tx antennas positions.
@@ -21,41 +54,51 @@ fading model (for example), or model separately different fading effects.
 
 The following propagation loss models are implemented:
 
-   * Cost231PropagationLossModel
+**Simple Range Models**
-   * FixedRssLossModel
-   * FriisPropagationLossModel
-   * ItuR1411LosPropagationLossModel
-   * ItuR1411NlosOverRooftopPropagationLossModel
-   * JakesPropagationLossModel
-   * Kun2600MhzPropagationLossModel
-   * LogDistancePropagationLossModel
-   * MatrixPropagationLossModel
-   * NakagamiPropagationLossModel
-   * OkumuraHataPropagationLossModel
-   * RandomPropagationLossModel
-   * RangePropagationLossModel
-   * ThreeLogDistancePropagationLossModel
-   * TwoRayGroundPropagationLossModel
-   * ThreeGppPropagationLossModel
 
-      * ThreeGppRMaPropagationLossModel
+- FriisPropagationLossModel
-      * ThreeGppUMaPropagationLossModel
+- TwoRayGroundPropagationLossModel
-      * ThreeGppUmiStreetCanyonPropagationLossModel
+- LogDistancePropagationLossModel
-      * ThreeGppIndoorOfficePropagationLossModel
+- ThreeLogDistancePropagationLossModel
-      * ThreeGppNTNDenseUrbanPropagationLossModel
+- RangePropagationLossModel
-      * ThreeGppNTNUrbanPropagationLossModel
+
-      * ThreeGppNTNSuburbanPropagationLossModel
+**Fading Models**
-      * ThreeGppNTNRuralPropagationLossModel
+
+- NakagamiPropagationLossModel
+- JakesPropagationLossModel
+
+**Abstract Models**
+
+- FixedRssLossModel
+- RandomPropagationLossModel
+- MatrixPropagationLossModel
+
+**Macro and Standard Models**
+
+- Cost231PropagationLossModel
+- OkumuraHataPropagationLossModel
+- Kun2600MhzPropagationLossModel
+- ItuR1411LosPropagationLossModel
+- ItuR1411NlosOverRooftopPropagationLossModel
+- ThreeGppPropagationLossModel
+   - ThreeGppRMaPropagationLossModel
+   - ThreeGppUMaPropagationLossModel
+   - ThreeGppUmiStreetCanyonPropagationLossModel
+   - ThreeGppIndoorOfficePropagationLossModel
+   - ThreeGppNTNDenseUrbanPropagationLossModel
+   - ThreeGppNTNUrbanPropagationLossModel
+   - ThreeGppNTNSuburbanPropagationLossModel
+   - ThreeGppNTNRuralPropagationLossModel
 
 Other models could be available thanks to other modules, e.g., the ``building`` module.
 
-Each of the available propagation loss models of ns-3 is explained in
+Each ofT the available propagation loss models of ns-3 is explained in
 one of the following subsections.
 
 FriisPropagationLossModel
-=========================
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
-This model implements the Friis propagation loss model. This model was first described in [friis]_.
+This model implements the Friis propagation loss model. This model was first described in the work of H.T. [1]_.
 The original equation was described as:
 
 .. math::
@@ -147,7 +190,7 @@ not affected.
 
 
 TwoRayGroundPropagationLossModel
-================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This model implements a Two-Ray Ground propagation loss model ported from NS2
 
@@ -180,7 +223,7 @@ the user via the Frequency attribute.
 
 
 LogDistancePropagationLossModel
-===============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This model implements a log distance propagation model.
 
@@ -207,7 +250,7 @@ When the path loss is requested at a distance smaller than
 the reference distance, the tx power is returned.
 
 ThreeLogDistancePropagationLossModel
-====================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This model implements a log distance path loss propagation model with three distance
 fields. This model is the same as ns3::LogDistancePropagationLossModel
@@ -261,21 +304,18 @@ distance :math:`d_0`, the tx power (with no path loss) is returned. The
 reference distance defaults to 1m and reference loss defaults to
 :cpp:class:`FriisPropagationLossModel` with 5.15 GHz and is thus :math:`L_0` = 46.67 dB.
 
-JakesPropagationLossModel
+RangePropagationLossModel
-=========================
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
-ToDo
+This propagation loss depends only on the distance (range) between transmitter and receiver.
-````
 
-RandomPropagationLossModel
+The single MaxRange attribute (units of meters) determines path loss.
-==========================
+Receivers at or within MaxRange meters receive the transmission at the
-
+transmit power level. Receivers beyond MaxRange receive at power
-The propagation loss is totally random, and it changes each time the model is called.
+-1000 dBm (effectively zero).
-As a consequence, all the packets (even those between two fixed nodes) experience a random
-propagation loss.
 
 NakagamiPropagationLossModel
-============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This propagation loss model implements the Nakagami-m fast fading
 model, which accounts for the variations in signal strength due to multipath
@@ -306,8 +346,77 @@ for three different distance ranges:
 For :math:`m = 1` the Nakagami-m distribution equals the Rayleigh distribution. Thus
 this model also implements Rayleigh distribution based fast fading.
 
+JakesPropagationLossModel
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This model implements a single path stationary Jakes propagation loss model for simulating Rayleigh fading channels.
+This model was first described in Microwave Mobile Communications [2]_, but the implementation available in ns-3 is based on a later document by Zheng et al. [3]_ (Section II.A).
+The Jakes method is used to model effective Rayleigh fading channels through a deterministic approach, providing a
+computational simplification at the cost of slightly decreased accuracy compared to statistical methods.
+This model considers one transmitter-receiver pair and calculates the complex channel coefficients that represent the fading envelope.
+
+The model generates complex channel coefficients using the sum-of-sinusoids approach:
+
+.. math::
+
+  X(t) = X_c(t) + j X_s(t)
+
+where the in-phase and quadrature components are given by:
+
+.. math::
+
+  X_c(t) = \frac{2}{\sqrt{M}}\sum_{n=1}^{M}\cos(\psi_n)\cos(\omega_d t\cos(\alpha_n)+\phi_n)
+
+.. math::
+
+  X_s(t) = \frac{2}{\sqrt{M}}\sum_{n=1}^{M}\sin(\psi_n)\cos(\omega_d t\cos(\alpha_n)+\phi_n)
+
+with the angle of arrival for the n-th sinusoid:
+
+.. math::
+
+  \alpha_n = \frac{2\pi n - \pi + \theta}{4M}, \quad n=1,2, \ldots,M
+
+where:
+
+  :math:`M` : number of sinusoids (determines accuracy vs. computational complexity)
+  :math:`\omega_d` : maximum Doppler frequency (rad/s)
+  :math:`\theta` : uniformly distributed random variable over :math:[-\pi, \pi)
+  :math:`\phi_n` : uniformly distributed random phase over :math:[-\pi, \pi) for each sinusoid
+  :math:`\psi_n` : uniformly distributed random variable over :math:[-\pi, \pi) for each sinusoid
+  :math:`t` : time variable
+
+The parameters :math:\theta, :math:\phi_n, and :math:\psi_n are statistically independent and uniformly distributed over :math:[-\pi, \pi) for all :math:n. The resulting complex coefficient :math:X(t) has a magnitude that follows a Rayleigh distribution, making it suitable for modeling non-line-of-sight propagation scenarios.
+
+The channel gain in dB is calculated from the complex coefficient as:
+
+.. math::
+
+  G_{dB}(t) = 10 \log_{10}\left(\frac{\left|X(t)\right|^2}{2}\right)
+
+where :math:\left|X(t)\right|^2 = X_c(t)^2 + X_s(t)^2 is the squared magnitude of the complex coefficient.
+The implementation uses oscillators where each oscillator contributes:
+
+.. math::
+
+  \text{oscillator}_n(t) = A_n e^{j(\omega_n t + \phi)}
+
+with complex amplitude:
+
+.. math::
+
+  A_n = \frac{2}{\sqrt{M}} e^{j\psi_n} = \frac{2}{\sqrt{M}}(\cos(\psi_n) + j\sin(\psi_n))
+
+and angular frequency:
+
+.. math::
+
+  \omega_n = \omega_d \cos(\alpha_n)
+
+The total complex gain is the sum of all oscillator contributions.
+
 FixedRssLossModel
-=================
+~~~~~~~~~~~~~~~~~
 
 This model sets a constant received power level independent of the transmit power.
 
@@ -316,31 +425,150 @@ must set received power level.  Note that if this loss model is chained to other
 models, it should be the first loss model in the chain.
 Else it will disregard the losses computed by loss models that precede it in the chain.
 
+RandomPropagationLossModel
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This model implements a completely random propagation loss mechanism where the attenuation varies
+randomly for each transmission, regardless of the distance or environmental conditions between nodes.
+The propagation loss changes every time the model is called, meaning that all packets (even those
+transmitted between two fixed nodes) experience independent random propagation losses.
+
+*Purpose and Use Cases*:
+
+The Random Propagation Loss Model is primarily designed for software testing purposes
+rather than for modeling a real-world channel. It serves several specific use cases:
+
+* Show how to randomize results and work with the random stream module
+
+* Fuzzing Testing: Provides random inputs to test the robustness of networking protocols and applications under unpredictable channel conditions
+
+* Development Testing: Helps developers identify edge cases and validate that their code handles a wide range of signal strength variations
+
+* Statistical Analysis: Enables Monte Carlo simulations where propagation effects need to be decoupled from spatial relationships
+
+This model could also be used to generate something akin to small scale
+fading effects when paired with a path loss model, if the user wanted to
+create some new model from scratch using a specially-designed random
+variable.
+
+
+*Mathematical Formulation*:
+
+The received power is calculated as:
+
+.. math::
+
+  P_r = P_t - X
+
+where:
+
+  :math:`P_r` : received power in dBm
+  :math:`P_t` : transmitted power in dBm
+  :math:`X` : random attenuation value in dB, drawn from the configured random variable
+
+The attenuation value :math:X is generated independently for each call to the model, ensuring complete randomness across all transmissions.
+Configuration:
+The model uses a configurable random variable to determine the attenuation values:
+
+
+Default: ns3::ConstantRandomVariable[Constant=1.0] (constant 1 dB attenuation)
+
+Configurable: Any random variable stream can be used (uniform, exponential, normal, etc.)
+
+Example Configurations:
+
+.. sourcecode:: cpp
+
+  // Uniform random attenuation between 0 and 10 dB
+  randomLoss->SetAttribute("Variable", StringValue("ns3::UniformRandomVariable[Min=0.0|Max=10.0]"));
+
+  // Normal distribution with mean 5 dB, standard deviation 2 dB
+  randomLoss->SetAttribute("Variable", StringValue("ns3::NormalRandomVariable[Mean=5.0|Variance=4.0]"));
+
+  // Exponential distribution with mean 3 dB
+  randomLoss->SetAttribute("Variable", StringValue("ns3::ExponentialRandomVariable[Mean=3.0]"));
+
+Important Characteristics:
+
+* No Spatial Correlation: The loss is completely independent of distance between transmitter and receiver
+
+* No Environmental Modeling: Physical obstacles, terrain, or atmospheric conditions are ignored
+
+* Temporal Independence: Each packet transmission experiences an independent random loss
+
+* Deterministic Reproducibility: When using the same random seed, results are reproducible for testing
+
+Stream Management:
+
+The model supports proper random stream assignment for reproducible results across simulation runs. The random variable stream can be configured to ensure deterministic behavior when needed for regression testing.
+
 MatrixPropagationLossModel
-==========================
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The propagation loss is fixed for each pair of nodes and doesn't depend on their actual positions.
 This model should be useful for synthetic tests. Note that by default the propagation loss is
 assumed to be symmetric.
 
-RangePropagationLossModel
+Cost231PropagationLossModel
-=========================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-This propagation loss depends only on the distance (range) between transmitter and receiver.
+This model implements the COST 231 [5]_ propagation loss model, also known as the Hata Model PCS Extension.
+It is a radio propagation model that extends the Hata Model (which in turn is based on the Okumura Model)
+to cover a more elaborate range of frequencies.
 
-The single MaxRange attribute (units of meters) determines path loss.
+COST (COopération européenne dans le domaine de la recherche Scientifique et Technique) is a European Union
-Receivers at or within MaxRange meters receive the transmission at the
+Forum for cooperative scientific research which developed this model based on various experiments and research
-transmit power level. Receivers beyond MaxRange receive at power
+studies. This model is specifically applicable to urban areas and can be extended to evaluate path loss in
--1000 dBm (effectively zero).
+suburban or rural quasi-open/open areas.
+
+*Model Applicability*:
+
+* Frequency Range: 1500 MHz to 2000 MHz
+* Mobile Station Antenna Height: 1 to 10 meters
+* Base Station Antenna Height: 30 to 200 meters
+* Link Distance: up to 20 kilometers
+* Environment: Urban areas (primary), extensible to suburban/rural
+
+*Mathematical Formulation*:
+
+The path loss in dB is calculated using the COST 231 formula:
+
+.. math::
+
+  L = 46.3 + 33.9 \log_{10}(f) - 13.82 \log_{10}(h_b) - C_H + (44.9 - 6.55 \log_{10}(h_b)) \log_{10}(d) + S
+
+where the mobile antenna height correction factor :math:`C_H` is given by:
+
+.. math::
+  C_H = 0.8 + (1.11 \log_{10}(f) - 0.7) h_m - 1.56 \log_{10}(f)
+
+*Parameters*:
+
+  :math:`f` : frequency in MHz
+  :math:`h_b` : base station antenna height in meters
+  :math:`h_m` : mobile station antenna height in meters
+  :math:`d` : distance between transmitter and receiver in kilometers
+  :math:`S` : shadowing factor in dB (default: 10 dB)
+  :math:`L` : path loss in dB
+
+Model Behavior:
+
+For distances smaller than the minimum distance threshold (default 0.5m), the model returns 0 dB path loss
+The model includes a configurable shadowing factor to account for environmental variations
+Default parameters are set for 2.3 GHz frequency with base station height of 50m and mobile station height of 3m
+
+Implementation Notes:
+
+The model uses logarithmic calculations in base 10, with frequency converted to MHz, distance to kilometers, and all height measurements in meters. The final result represents the path loss that should be subtracted from the transmitted power to obtain the received power level.
 
 OkumuraHataPropagationLossModel
-===============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This model is used to model open area pathloss for long distance (i.e., > 1 Km).
 In order to include all the possible frequencies usable by LTE we need to consider
 several variants of the well known Okumura Hata model. In fact, the original Okumura
-Hata model [hata]_ is designed for frequencies ranging from 150 MHz to 1500 MHz,
+Hata model [4]_ is designed for frequencies ranging from 150 MHz to 1500 MHz,
-the COST231 [cost231]_ extends it for the frequency range from 1500 MHz to 2000 MHz.
+the COST231 [5]_ extends it for the frequency range from 1500 MHz to 2000 MHz.
 Another important aspect is the scenarios considered by the models, in fact the all
 models are originally designed for urban scenario and then only the standard one and
 the COST231 are extended to suburban, while only the standard one has been extended
@@ -416,15 +644,19 @@ The extension for the standard OH in open area is
 The literature lacks of extensions of the COST231 to open area (for suburban it seems that
 we can just impose C = 0); therefore we consider it a special case of the suburban one.
 
+Kun2600MhzPropagationLossModel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Cost231PropagationLossModel
+This is the empirical model for the pathloss at 2600 MHz for urban areas which is described in Kun et al. [8]_.
-===========================
+The model is as follows. Let :math:`d` be the distance between the transmitter and the receiver
+in meters; the pathloss :math:`L` in dB is calculated as:
 
-ToDo
+.. math::
-````
+
+  L = 36 + 26\log{d}
 
 ItuR1411LosPropagationLossModel
-===============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This model is designed for Line-of-Sight (LoS) short range outdoor communication in the
 frequency range 300 MHz to 100 GHz.  This model provides an upper and lower bound
@@ -464,14 +696,14 @@ The value used by the simulator is the average one for modeling the median pathl
 
 
 ItuR1411NlosOverRooftopPropagationLossModel
-===========================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This model is designed for Non-Line-of-Sight (LoS) short range outdoor communication over
 rooftops in the frequency range 300 MHz to 100 GHz. This model includes several scenario-dependent
 parameters, such as average street width, orientation, etc. It is advised to set the values of
 these parameters manually (using the ns-3 attribute system) according to the desired scenario.
 
-In detail, the model is based on [walfisch]_ and [ikegami]_, where the loss is expressed
+In detail, the model is based on work by Walfisch et al. [6]_ and Ikegami et al. [7]_, where the loss is expressed
 as the sum of free-space loss (:math:`L_{bf}`), the diffraction loss from rooftop to
 street (:math:`L_{rts}`) and the reduction due to multiple screen diffraction past
 rows of building (:math:`L_{msd}`). The formula is:
@@ -577,23 +809,11 @@ where:
 
   \rho = \sqrt{\Delta h_b^2 + b^2}
 
-
-Kun2600MhzPropagationLossModel
-==============================
-
-This is the empirical model for the pathloss at 2600 MHz for urban areas which is described in [kun2600mhz]_.
-The model is as follows. Let :math:`d` be the distance between the transmitter and the receiver
-in meters; the pathloss :math:`L` in dB is calculated as:
-
-.. math::
-
-  L = 36 + 26\log{d}
-
 ThreeGppPropagationLossModel
-============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The base class :cpp:class:`ThreeGppPropagationLossModel` and its derived classes implement
-the path loss and shadow fading models described in 3GPP TR 38.901 [38901]_.
+the path loss and shadow fading models described in 3GPP TR 38.901 [9]_.
 3GPP TR 38.901 includes multiple scenarios modeling different propagation
 environments, i.e., indoor, outdoor urban and rural, for frequencies between
 0.5 and 100 GHz.
@@ -669,7 +889,7 @@ implementation is left to the derived classes. The shadow fading is computed by
 the method GetShadowing, which generates an additional random loss component
 characterized by Gaussian distribution with zero mean and scenario-specific
 standard deviation. Subsequent shadowing components of each BS-UT link are
-correlated as described in 3GPP TR 38.901, Sec. 7.4.4 [38901]_.
+correlated as described in 3GPP TR 38.901, Sec. 7.4.4 [9]_.
 
 *Note 1*: The TR defines height ranges for UTs and BSs, depending on the chosen
 propagation model (for the exact values, please see below in the specific model
@@ -688,7 +908,7 @@ There are four derived class, each one implementing the propagation model for a
 ThreeGppRMaPropagationLossModel
 ```````````````````````````````
 
-This class implements the LOS/NLOS path loss and shadow fading models described in 3GPP TR 38.901 [38901]_, Table 7.4.1-1 for the RMa scenario.
+This class implements the LOS/NLOS path loss and shadow fading models described in 3GPP TR 38.901 [9]_, Table 7.4.1-1 for the RMa scenario.
 It supports frequencies between 0.5 and 30 GHz.
 It is possible to configure some scenario-related parameters through the attributes AvgBuildingHeight and AvgStreetWidth.
 
@@ -703,7 +923,7 @@ ThreeGppUMaPropagationLossModel
 ```````````````````````````````
 
 This implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.901 [38901]_, Table 7.4.1-1 for the UMa scenario. It supports frequencies
+TR 38.901 [9]_, Table 7.4.1-1 for the UMa scenario. It supports frequencies
 between 0.5 and 100 GHz.
 
 As specified in the TR, the 2D distance between the transmitter and the receiver
@@ -716,7 +936,7 @@ ThreeGppUmiStreetCanyonPropagationLossModel
 ```````````````````````````````````````````
 
 This implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.901 [38901]_, Table 7.4.1-1 for the UMi-Street Canyon scenario. It
+TR 38.901 [9]_, Table 7.4.1-1 for the UMi-Street Canyon scenario. It
 supports frequencies between 0.5 and 100 GHz.
 
 As specified in the TR, the 2D distance between the transmitter and the receiver
@@ -731,7 +951,7 @@ ThreeGppIndoorOfficePropagationLossModel
 ````````````````````````````````````````
 
 This implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.901 [38901]_, Table 7.4.1-1 for the Indoor-Office scenario. It supports
+TR 38.901 [9]_, Table 7.4.1-1 for the Indoor-Office scenario. It supports
 frequencies between 0.5 and 100 GHz.
 
 As specified in the TR, the 3D distance between the transmitter and the receiver
@@ -747,14 +967,14 @@ implementing the 3GPP propagation loss models.
 The test cases :cpp:class:`ThreeGppRmaPropagationLossModelTestCase`,
 :cpp:class:`ThreeGppUmaPropagationLossModelTestCase`,
 :cpp:class:`ThreeGppUmiPropagationLossModelTestCase` and
-:cpp:class:`ThreeGppIndoorOfficePropagationLossModelTestCase` compute the path loss between two nodes and compares it with the value obtained using the formulas in 3GPP TR 38.901 [38901]_, Table 7.4.1-1.
+:cpp:class:`ThreeGppIndoorOfficePropagationLossModelTestCase` compute the path loss between two nodes and compares it with the value obtained using the formulas in 3GPP TR 38.901 [9]_, Table 7.4.1-1.
 The test case :cpp:class:`ThreeGppShadowingTestCase` checks if the shadowing is correctly computed by testing the deviation of the overall propagation loss from the path loss. The test is carried out for all the scenarios, both in LOS and NLOS condition.
 
 ThreeGppNTNPropagationLossModel
-===============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Four different classes have been derived from the base class :cpp:class:`ThreeGppPropagationLossModel`
-to support Non-Terrestrial Networks, one for each scenario presented in 3GPP TR 38.811 [38811]_, i.e.,
+to support Non-Terrestrial Networks, one for each scenario presented in 3GPP TR 38.811 [12]_, i.e.,
 dense urban, urban, suburban and rural.
 
 *Implemented features:*
@@ -769,30 +989,205 @@ dense urban, urban, suburban and rural.
 ThreeGppNTNDenseUrbanPropagationLossModel
 `````````````````````````````````````````
 This class implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.811 [38811]_, Table 6.6.2-1 for the Dense Urban scenario. It
+TR 38.811 [12]_, Table 6.6.2-1 for the Dense Urban scenario. It
 supports frequencies between 0.5 and 100 GHz.
 
 ThreeGppNTNUrbanPropagationLossModel
 ````````````````````````````````````
 This class implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.811 [38811]_, Table 6.6.2-2 for the Urban scenario. It
+TR 38.811 [12]_, Table 6.6.2-2 for the Urban scenario. It
 supports frequencies between 0.5 and 100 GHz.
 
 ThreeGppNTNSuburbanPropagationLossModel
 ```````````````````````````````````````
 This class implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.811 [38811]_, Table 6.6.2-3 for the Suburban scenario. It
+TR 38.811 [12]_, Table 6.6.2-3 for the Suburban scenario. It
 supports frequencies between 0.5 and 100 GHz.
 
 ThreeGppNTNRuralPropagationLossModel
 ````````````````````````````````````
 This class implements the LOS/NLOS path loss and shadow fading models described in 3GPP
-TR 38.811 [38811]_, Table 6.6.2-3 for the Rural scenario. It
+TR 38.811 [12]_, Table 6.6.2-3 for the Rural scenario. It
 supports frequencies between 0.5 and 100 GHz.
 
 
+Usage
+-----
+
+This section describes how to effectively use propagation models in ns-3 simulations, covering basic configuration, advanced techniques, performance optimization, and common applications.
+
+Basic Configuration
+~~~~~~~~~~~~~~~~~~~
+
+**Setting Up a Propagation Model**
+
+The most fundamental step in using propagation models is configuring them properly in your ns-3 simulation. Here's the basic workflow:
+
+1. Include Required Headers
+
+.. sourcecode:: cpp
+
+   #include "ns3/propagation-loss-model.h"
+   #include "ns3/propagation-delay-model.h"
+   #include "ns3/yans-wifi-helper.h"
+
+2. Create and Configure the Channel
+
+.. sourcecode:: cpp
+
+   // Create the wireless channel
+   YansWifiChannelHelper channel = YansWifiChannelHelper::Default();
+
+   // Set the propagation loss model
+   channel.AddPropagationLoss("ns3::FriisPropagationLossModel");
+
+   // Set the propagation delay model
+   channel.SetPropagationDelay("ns3::ConstantSpeedPropagationDelayModel");
+
+3. Apply to PHY Helper
+
+.. sourcecode:: cpp
+
+   YansWifiPhyHelper phy;
+   phy.SetChannel(channel.Create());
+
+**Setting Model Parameters**
+
+Most propagation models accept parameters that can be configured using attributes:
+
+.. sourcecode:: cpp
+
+   // Configure Friis model parameters
+   channel.AddPropagationLoss("ns3::FriisPropagationLossModel",
+                              "Frequency", DoubleValue(2.4e9),
+                              "SystemLoss", DoubleValue(1.0));
+
+.. sourcecode:: cpp
+
+   // Configure Log Distance model
+   channel.AddPropagationLoss("ns3::LogDistancePropagationLossModel",
+                              "Exponent", DoubleValue(3.0),
+                              "ReferenceDistance", DoubleValue(1.0),
+                              "ReferenceLoss", DoubleValue(46.6777));
+
+**Using Different Models**
+
+ns-3 provides several built-in propagation models:
+
+.. sourcecode:: cpp
+
+   // Free space model (ideal conditions)
+   channel.AddPropagationLoss("ns3::FriisPropagationLossModel");
+
+.. sourcecode:: cpp
+
+   // Log distance model (general purpose)
+   channel.AddPropagationLoss("ns3::LogDistancePropagationLossModel");
+
+.. sourcecode:: cpp
+
+   // Two-ray ground reflection model
+   channel.AddPropagationLoss("ns3::TwoRayGroundPropagationLossModel");
+
+.. sourcecode:: cpp
+
+   // Okumura-Hata model (urban environments)
+   channel.AddPropagationLoss("ns3::OkumuraHataPropagationLossModel");
+
+Model Stacking
+~~~~~~~~~~~~~~
+
+One must be aware of the stackability of propagation models in ns-3. This allows you to combine different propagation effects for more realistic simulations but if not used properly, it may lead to flawed results. The order matters! The Base model should be set first, then additional effects
+
+Propagation loss models can be chained together, where each model in the chain applies its loss calculation to the signal:
+
+.. sourcecode:: cpp
+
+   YansWifiChannelHelper channel = YansWifiChannelHelper::Default();
+   // Free space model (ideal conditions)
+   channel.AddPropagationLoss("ns3::FriisPropagationLossModel");
+   // Add a random propagation loss model for fading
+   channel.AddPropagationLoss("ns3::RandomPropagationLossModel");
+
+As the above example shows, the stacking of models is very easy and does not require any additional tool. This also means that the user must be careful not to stack models by inadvertence.
+
+Classification for stacking
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If we take the list of available loss models and create two categories, base loss model and stacking models, here is the result:
+
+**Base Models (Primary Path Loss - Use ONE (1) as foundation)**:
+
+   * FriisPropagationLossModel
+   * TwoRayGroundPropagationLossModel
+   * LogDistancePropagationLossModel
+   * ThreeLogDistancePropagationLossModel
+   * RangePropagationLossModel
+   * OkumuraHataPropagationLossModel
+   * Cost231PropagationLossModel
+   * ItuR1411LosPropagationLossModel
+   * ItuR1411NlosOverRooftopPropagationLossModel
+   * Kun2600MhzPropagationLossModel
+
+**Stacking Models (Additional Effects - Stack on base models)**:
+
+   * JakesPropagationLossModel
+   * RandomPropagationLossModel
+   * NakagamiPropagationLossModel
+   * FixedRssLossModel
+   * MatrixPropagationLossModel
+
+**Complete 3GPP Models (Self-contained)**:
+
+3GPP models are comprehensive, do not stack other models with them as they already include multiple propagation effects.
+
+   * ThreeGppPropagationLossModel
+
+      * ThreeGppRMaPropagationLossModel
+      * ThreeGppUMaPropagationLossModel
+      * ThreeGppUmiStreetCanyonPropagationLossModel
+      * ThreeGppIndoorOfficePropagationLossModel
+      * ThreeGppNTNDenseUrbanPropagationLossModel
+      * ThreeGppNTNUrbanPropagationLossModel
+      * ThreeGppNTNSuburbanPropagationLossModel
+      * ThreeGppNTNRuralPropagationLossModel
+
+Typical Stacking Patterns
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Pattern 1: Base + Shadowing**
+
+.. sourcecode:: cpp
+
+   // Base path loss
+   channel.AddPropagationLoss("ns3::LogDistancePropagationLossModel");
+   // Add log-normal shadowing
+   channel.AddPropagationLoss("ns3::RandomPropagationLossModel",
+                           "Variable", StringValue("ns3::LogNormalRandomVariable[Mu=0.0|Sigma=4.0]"));
+
+**Pattern 2: Base + Fading**
+
+.. sourcecode:: cpp
+
+   // Base path loss
+   channel.AddPropagationLoss("ns3::FriisPropagationLossModel");
+   // Add Nakagami fading
+   channel.AddPropagationLoss("ns3::NakagamiPropagationLossModel");
+
+**Pattern 3: Base + Shadowing + Fading**
+
+.. sourcecode:: cpp
+
+   // Base path loss
+   channel.AddPropagationLoss("ns3::TwoRayGroundPropagationLossModel");
+   // Add shadowing
+   channel.AddPropagationLoss("ns3::RandomPropagationLossModel",
+                           "Variable", StringValue("ns3::LogNormalRandomVariable[Mu=0.0|Sigma=6.0]"));
+   // Add fading
+   channel.AddPropagationLoss("ns3::JakesPropagationLossModel");
+
 ChannelConditionModel
-*********************
+---------------------
 
 The loss models require to know if two nodes are in Line-of-Sight (LoS) or if
 they are not. The interface for that is represented by this class. The main
@@ -821,72 +1216,72 @@ The two approach are coded, respectively, in the classes:
 * :cpp:class:`BuildingsChannelConditionModel` (see the ``building`` module documentation for further details)
 
 ThreeGppChannelConditionModel
-=============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 This is the base class for the 3GPP channel condition models.
 It provides the possibility to update the condition of each channel periodically,
 after a given time period which can be configured through the attribute "UpdatePeriod".
 If "UpdatePeriod" is set to 0, the channel condition is never updated.
-It has five derived classes implementing the channel condition models described in 3GPP TR 38.901 [38901]_ for different propagation scenarios.
+It has five derived classes implementing the channel condition models described in 3GPP TR 38.901 [9]_ for different propagation scenarios.
 
 ThreeGppRmaChannelConditionModel
 ````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.901 [38901]_, Table 7.4.2-1, for the RMa scenario.
+This class implements the statistical channel condition model described in 3GPP TR 38.901 [9]_, Table 7.4.2-1, for the RMa scenario.
 
 ThreeGppUmaChannelConditionModel
 ````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.901 [38901]_, Table 7.4.2-1, for the UMa scenario.
+This class implements the statistical channel condition model described in 3GPP TR 38.901 [9]_, Table 7.4.2-1, for the UMa scenario.
 
 ThreeGppUmiStreetCanyonChannelConditionModel
 ````````````````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.901 [38901]_, Table 7.4.2-1, for the UMi-Street Canyon scenario.
+This class implements the statistical channel condition model described in 3GPP TR 38.901 [9]_, Table 7.4.2-1, for the UMi-Street Canyon scenario.
 
 ThreeGppIndoorMixedOfficeChannelConditionModel
 ``````````````````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.901 [38901]_, Table 7.4.2-1, for the Indoor-Mixed office scenario.
+This class implements the statistical channel condition model described in 3GPP TR 38.901 [9]_, Table 7.4.2-1, for the Indoor-Mixed office scenario.
 
 ThreeGppIndoorOpenOfficeChannelConditionModel
 `````````````````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.901 [38901]_, Table 7.4.2-1, for the Indoor-Open office scenario.
+This class implements the statistical channel condition model described in 3GPP TR 38.901 [9]_, Table 7.4.2-1, for the Indoor-Open office scenario.
 
 ThreeGppNTNChannelConditionModel
-================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 This is the base class for the 3GPP NTN channel condition models.
 It provides the possibility to update the condition of each channel periodically,
 after a given time period which can be configured through the attribute "UpdatePeriod".
 If "UpdatePeriod" is set to 0, the channel condition is never updated.
-It has four derived classes implementing the channel condition models described in 3GPP TR 38.811 [38811]_
+It has four derived classes implementing the channel condition models described in 3GPP TR 38.811 [12]_
 for the different propagation scenarios. i.e., dense urban, urban, suburban and rural.
 
 ThreeGppDenseUrbanChannelConditionModel
 ```````````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.811 [38811]_,
+This class implements the statistical channel condition model described in 3GPP TR 38.811 [12]_,
 Table 6.6.1-1, for the Dense Urban scenario.
 
 ThreeGppUrbanChannelConditionModel
 ``````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.811 [38811]_,
+This class implements the statistical channel condition model described in 3GPP TR 38.811 [12]_,
 Table 6.6.1-1, for the Urban scenario.
 
 ThreeGppSuburbanStreetCanyonChannelConditionModel
 `````````````````````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.811 [38811]_,
+This class implements the statistical channel condition model described in 3GPP TR 38.811 [12]_,
 Table 6.6.1-1, for the Suburban scenario.
 
 ThreeGppRuralChannelConditionModel
 ``````````````````````````````````
-This class implements the statistical channel condition model described in 3GPP TR 38.811 [38811]_,
+This class implements the statistical channel condition model described in 3GPP TR 38.811 [12]_,
 Table 6.6.1-1, for the Rural office scenario.
 
 
 Testing
-=======
+~~~~~~~
 The test suite :cpp:class:`ChannelConditionModelsTestSuite` contains a single test case:
 
-* :cpp:class:`ThreeGppChannelConditionModelTestCase`, which tests all the 3GPP channel condition models. It determines the channel condition between two nodes multiple times, estimates the LOS probability, and compares it with the value given by the formulas in 3GPP TR 38.901 [38901]_, Table 7.4.2-1
+* :cpp:class:`ThreeGppChannelConditionModelTestCase`, which tests all the 3GPP channel condition models. It determines the channel condition between two nodes multiple times, estimates the LOS probability, and compares it with the value given by the formulas in 3GPP TR 38.901 [9]_, Table 7.4.2-1
 
 
 PropagationDelayModel
-*********************
+---------------------
 
 The following propagation delay models are implemented:
 
@@ -894,7 +1289,7 @@ The following propagation delay models are implemented:
 * RandomPropagationDelayModel
 
 ConstantSpeedPropagationDelayModel
-==================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In this model, the signal travels with constant speed.
 The delay is calculated according with the transmitter and receiver positions.
@@ -902,17 +1297,17 @@ The Euclidean distance between the Tx and Rx antennas is used.
 Beware that, according to this model, the Earth is flat.
 
 RandomPropagationDelayModel
-===========================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The propagation delay is totally random, and it changes each time the model is called.
 All the packets (even those between two fixed nodes) experience a random delay.
 As a consequence, the packets order is not preserved.
 
 Models for vehicular environments
-*********************************
+---------------------------------
 
-The 3GPP TR 37.885 [37885]_ specifications extends the channel modeling framework
+The 3GPP TR 37.885 [10]_ specifications extends the channel modeling framework
-described in TR 38.901 [38901]_ to simulate wireless channels in vehicular environments.
+described in TR 38.901 [9]_ to simulate wireless channels in vehicular environments.
 The extended framework supports frequencies between 0.5 to 100 GHz and provides
 the possibility to simulate urban and highway propagation environments.
 To do so, new propagation loss and channel condition models, as well as new
@@ -921,7 +1316,7 @@ parameters for the fast fading model, are provided.
 .. _sec-3gpp-v2v-ch-cond:
 
 Vehicular channel condition models
-==================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To properly capture channel dynamics in vehicular environments, three different
 channel conditions have been identified:
@@ -963,7 +1358,7 @@ buildings, this process may become computationally demanding and dramatically
 increase the simulation time.
 To solve this problem, we implemented two fully-probabilistic models
 that can be used as an alternative to the ones included in TR 37.885.
-These models are based on the work carried out by M. Boban et al. [Boban2016Modeling]_,
+These models are based on the work carried out by M. Boban et al. [11]_,
 which derived a statistical representation of the three channel conditions,
 With the fully-probabilistic models there is no need to determine the presence of blocking
 buildings in a deterministic way, and therefore the computational effort is
@@ -975,9 +1370,9 @@ scenario, which can be high, medium, or low.
 The classes implementing the fully-probabilistic models are:
 
   * :cpp:class:`ProbabilisticV2vUrbanChannelConditionModel`: implements the model
-    described in [Boban2016Modeling]_ for the urban scenario.
+    described in M. Boban et al. [11]_ for the urban scenario.
   * :cpp:class:`ProbabilisticV2vHighwayChannelConditionModel`: implements the model
-    described in [Boban2016Modeling]_ for the highway scenario.
+    described in M. Boban et al. [11]_ for the highway scenario.
 
 Both the classes own the attribute "Density", which can be used to select the
 proper value depending on the scenario that have to be simulated.
@@ -990,7 +1385,7 @@ modeling of outdoor scenarios, no support is provided for the modeling of
 indoor scenarios.
 
 Vehicular propagation loss models
-=================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The propagation models described in TR 37.885 determines the attenuation caused
 by path loss and shadowing by considering the propagation environment and the
@@ -1017,7 +1412,7 @@ are allowed to test any other combination.
 .. _sec-3gpp-v2v-ff:
 
 Vehicular fast fading model
-===========================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The fast fading model described in Sec. 6.2.3 of TR 37.885 is based on the one
 specified in TR 38.901, whose implementation is provided in the ``spectrum`` module
@@ -1043,7 +1438,7 @@ By means of the attribute "vScatt", it is possible to adjust the value of
 :math:`v_{scatt} = 0` (by default, the value is set to 0).
 
 Example
-=======
+~~~~~~~
 
 We implemented the example ``three-gpp-v2v-channel-example.cc`` which shows how to
 configure the different classes to simulate wireless propagation in vehicular
@@ -1088,28 +1483,33 @@ output file and generates two figures:
 
 
 References
-**********
+----------
 
-.. [friis] Friis, H.T., "A Note on a Simple Transmission Formula," Proceedings of the IRE , vol.34, no.5, pp.254,256, May 1946
+.. [1] Friis, H.T., "A Note on a Simple Transmission Formula," Proceedings of the IRE , vol.34, no.5, pp.254,256, May 1946
 
-.. [hata] M.Hata, "Empirical formula for propagation loss in land mobile radio
+.. [2] W. C. Jakes, Microwave Mobile Communications. Piscataway, NJ:IEEE Press, 1994.
+
+.. [3] ZHENG, Yahong Rosa et XIAO, Chengshan. Simulation models with correct statistical properties for Rayleigh fading channels. IEEE Transactions on communications, 2003,
+   vol. 51, no 6, p. 920-928.
+
+.. [4] M.Hata, "Empirical formula for propagation loss in land mobile radio
    services", IEEE Trans. on Vehicular Technology, vol. 29, pp. 317-325, 1980
 
-.. [cost231] “Digital Mobile Radio: COST 231 View on the Evolution Towards 3rd Generation Systems”, Commission of the European Communities, L-2920, Luxembourg, 1989
+.. [5] “Digital Mobile Radio: COST 231 View on the Evolution Towards 3rd Generation Systems”, Commission of the European Communities, L-2920, Luxembourg, 1989
 
-.. [walfisch]  J.Walfisch and H.L. Bertoni, "A Theoretical model of UHF propagation in urban environments," in IEEE Trans. Antennas Propagat., vol.36, 1988, pp.1788- 1796
+.. [6]  J.Walfisch and H.L. Bertoni, "A Theoretical model of UHF propagation in urban environments," in IEEE Trans. Antennas Propagat., vol.36, 1988, pp.1788- 1796
 
-.. [ikegami] F.Ikegami, T.Takeuchi, and S.Yoshida, "Theoretical prediction of mean field strength for Urban Mobile Radio", in IEEE Trans. Antennas Propagat., Vol.39, No.3, 1991
+.. [7] F.Ikegami, T.Takeuchi, and S.Yoshida, "Theoretical prediction of mean field strength for Urban Mobile Radio", in IEEE Trans. Antennas Propagat., Vol.39, No.3, 1991
 
-.. [kun2600mhz] Sun Kun, Wang Ping, Li Yingze, "Path loss models for suburban scenario at 2.3GHz, 2.6GHz and 3.5GHz",
+.. [8] Sun Kun, Wang Ping, Li Yingze, "Path loss models for suburban scenario at 2.3GHz, 2.6GHz and 3.5GHz",
    in Proc. of the 8th International Symposium on Antennas, Propagation and EM Theory (ISAPE),  Kunming,  China, Nov 2008.
 
-.. [38901] 3GPP. 2018. TR 38.901, Study on channel model for frequencies from 0.5 to 100 GHz, V15.0.0. (2018-06).
+.. [9] 3GPP. 2018. TR 38.901, Study on channel model for frequencies from 0.5 to 100 GHz, V15.0.0. (2018-06).
 
-.. [37885] 3GPP. 2019. TR 37.885, Study on evaluation methodology of new Vehicle-to-Everything (V2X) use cases for LTE and NR, V15.3.0. (2019-06).
+.. [10] 3GPP. 2019. TR 37.885, Study on evaluation methodology of new Vehicle-to-Everything (V2X) use cases for LTE and NR, V15.3.0. (2019-06).
 
-.. [Boban2016Modeling]  M. Boban,  X. Gong, and  W. Xu, “Modeling the evolution
+.. [11]  M. Boban,  X. Gong, and  W. Xu, “Modeling the evolution
    of line-of-sight blockage for V2V channels,” in IEEE 84th Vehicular Technology
    Conference (VTC-Fall), 2016.
 
-.. [38811] 3GPP. 2018. TR 38.811, Study on New Radio (NR) to support non-terrestrial networks, V15.4.0. (2020-09).
+.. [12] 3GPP. 2018. TR 38.811, Study on New Radio (NR) to support non-terrestrial networks, V15.4.0. (2020-09).

src/visualizer/model/pyviz.cc

@@ -25,8 +25,6 @@
 
 NS_LOG_COMPONENT_DEFINE("PyViz");
 
-#define NUM_LAST_PACKETS 10
-
 static std::vector<std::string>
 PathSplit(std::string str)
 {

src/wifi/model/rate-control/amrr-wifi-manager.cc

@@ -12,8 +12,6 @@
 #include "ns3/simulator.h"
 #include "ns3/wifi-tx-vector.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/aparf-wifi-manager.cc

@@ -13,8 +13,6 @@
 #include "ns3/uinteger.h"
 #include "ns3/wifi-phy.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/arf-wifi-manager.cc

@@ -11,8 +11,6 @@
 #include "ns3/log.h"
 #include "ns3/wifi-tx-vector.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/cara-wifi-manager.cc

@@ -11,8 +11,6 @@
 #include "ns3/log.h"
 #include "ns3/wifi-tx-vector.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/minstrel-wifi-manager.cc

@@ -30,8 +30,6 @@
 #include <iomanip>
 #include <limits>
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/onoe-wifi-manager.cc

@@ -12,8 +12,6 @@
 #include "ns3/simulator.h"
 #include "ns3/wifi-tx-vector.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/parf-wifi-manager.cc

@@ -13,8 +13,6 @@
 #include "ns3/uinteger.h"
 #include "ns3/wifi-phy.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

src/wifi/model/rate-control/rraa-wifi-manager.cc

@@ -14,8 +14,6 @@
 #include "ns3/wifi-mac.h"
 #include "ns3/wifi-phy.h"
 
-#define Min(a, b) ((a < b) ? a : b)
-
 namespace ns3
 {
 

utils/tests/gitlab-ci-fedora.yml

@@ -44,52 +44,6 @@ weekly-fedora:
   script:
     - echo "Starting Fedora jobs"
 
-# Fedora 40
-weekly-build-fedora-40-debug:
-  extends: .weekly-build-fedora
-  needs: ["weekly-fedora"]
-  image: fedora:40
-  stage: build
-  variables:
-    MODE: debug
-
-weekly-build-fedora-40-default:
-  extends: .weekly-build-fedora
-  needs: ["weekly-fedora"]
-  image: fedora:40
-  stage: build
-  variables:
-    MODE: default
-
-weekly-build-fedora-40-optimized:
-  extends: .weekly-build-fedora
-  needs: ["weekly-fedora"]
-  image: fedora:40
-  stage: build
-  variables:
-    MODE: optimized
-
-# Fedora 40 test
-weekly-test-fedora-40-default:
-  extends: .weekly-build-fedora
-  image: fedora:40
-  stage: test
-  needs: ["weekly-build-fedora-40-default"]
-  dependencies:
-    - weekly-build-fedora-40-default
-  variables:
-    MODE: default
-
-weekly-test-fedora-40-optimized:
-  extends: .weekly-build-fedora
-  image: fedora:40
-  stage: test
-  needs: ["weekly-build-fedora-40-optimized"]
-  dependencies:
-    - weekly-build-fedora-40-optimized
-  variables:
-    MODE: optimized
-
 # Fedora 41
 weekly-build-fedora-41-debug:
   extends: .weekly-build-fedora
@@ -135,3 +89,49 @@ weekly-test-fedora-41-optimized:
     - weekly-build-fedora-41-optimized
   variables:
     MODE: optimized
+
+# Fedora 42
+weekly-build-fedora-42-debug:
+  extends: .weekly-build-fedora
+  needs: ["weekly-fedora"]
+  image: fedora:42
+  stage: build
+  variables:
+    MODE: debug
+
+weekly-build-fedora-42-default:
+  extends: .weekly-build-fedora
+  needs: ["weekly-fedora"]
+  image: fedora:42
+  stage: build
+  variables:
+    MODE: default
+
+weekly-build-fedora-42-optimized:
+  extends: .weekly-build-fedora
+  needs: ["weekly-fedora"]
+  image: fedora:42
+  stage: build
+  variables:
+    MODE: optimized
+
+# Fedora 42 test
+weekly-test-fedora-42-default:
+  extends: .weekly-build-fedora
+  image: fedora:42
+  stage: test
+  needs: ["weekly-build-fedora-42-default"]
+  dependencies:
+    - weekly-build-fedora-42-default
+  variables:
+    MODE: default
+
+weekly-test-fedora-42-optimized:
+  extends: .weekly-build-fedora
+  image: fedora:42
+  stage: test
+  needs: ["weekly-build-fedora-42-optimized"]
+  dependencies:
+    - weekly-build-fedora-42-optimized
+  variables:
+    MODE: optimized

utils/tests/gitlab-ci-ubuntu.yml

@@ -23,7 +23,7 @@
       libboost-all-dev
       libgtk-3-dev
       libfl-dev
-      libxml2 libxml2-dev
+      $LIBXML2 libxml2-dev
       libopenmpi-dev openmpi-bin openmpi-common openmpi-doc
       libsqlite3-dev sqlite3
       libeigen3-dev
@@ -49,6 +49,7 @@ weekly-build-ubuntu-22.04-debug:
   variables:
     MODE: debug
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-build-ubuntu-22.04-default:
@@ -59,6 +60,7 @@ weekly-build-ubuntu-22.04-default:
   variables:
     MODE: default
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-build-ubuntu-22.04-optimized:
@@ -69,6 +71,7 @@ weekly-build-ubuntu-22.04-optimized:
   variables:
     MODE: optimized
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-test-ubuntu-22.04-default:
@@ -81,6 +84,7 @@ weekly-test-ubuntu-22.04-default:
   variables:
     MODE: default
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-test-ubuntu-22.04-optimized:
@@ -93,6 +97,7 @@ weekly-test-ubuntu-22.04-optimized:
   variables:
     MODE: optimized
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 # Ubuntu 24.04 (Until April 2029)
@@ -104,6 +109,7 @@ weekly-build-ubuntu-24.04-debug:
   variables:
     MODE: debug
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-build-ubuntu-24.04-default:
@@ -114,6 +120,7 @@ weekly-build-ubuntu-24.04-default:
   variables:
     MODE: default
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-build-ubuntu-24.04-optimized:
@@ -124,6 +131,7 @@ weekly-build-ubuntu-24.04-optimized:
   variables:
     MODE: optimized
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-test-ubuntu-24.04-default:
@@ -136,6 +144,7 @@ weekly-test-ubuntu-24.04-default:
   variables:
     MODE: default
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 weekly-test-ubuntu-24.04-optimized:
@@ -148,6 +157,7 @@ weekly-test-ubuntu-24.04-optimized:
   variables:
     MODE: optimized
     LIBGSL: libgsl27
+    LIBXML2: libxml2
     COMPILER: g++
 
 # Ubuntu Rolling (latest released, might be non-LTS)
@@ -159,6 +169,7 @@ weekly-build-ubuntu-rolling-debug:
   variables:
     MODE: debug
     LIBGSL: libgsl28
+    LIBXML2: libxml2-16
     COMPILER: g++
 
 weekly-build-ubuntu-rolling-default:
@@ -169,6 +180,7 @@ weekly-build-ubuntu-rolling-default:
   variables:
     MODE: default
     LIBGSL: libgsl28
+    LIBXML2: libxml2-16
     COMPILER: g++
 
 weekly-build-ubuntu-rolling-optimized:
@@ -179,6 +191,7 @@ weekly-build-ubuntu-rolling-optimized:
   variables:
     MODE: optimized
     LIBGSL: libgsl28
+    LIBXML2: libxml2-16
     COMPILER: g++
 
 weekly-test-ubuntu-rolling-default:
@@ -191,6 +204,7 @@ weekly-test-ubuntu-rolling-default:
   variables:
     MODE: default
     LIBGSL: libgsl28
+    LIBXML2: libxml2-16
     COMPILER: g++
 
 weekly-test-ubuntu-rolling-optimized:
@@ -203,4 +217,5 @@ weekly-test-ubuntu-rolling-optimized:
   variables:
     MODE: optimized
     LIBGSL: libgsl28
+    LIBXML2: libxml2-16
     COMPILER: g++