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

Merge tag 'ns-3.46.1' into unison

Browse Source 
ns-3.46.1 release
This commit is contained in:
F5
2025-10-26 21:24:06 +08:00
parent 136a6e22bf 51387bce7e
commit d3b620b1c8
30 changed files with 1110 additions and 507 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
CHANGES.md
View File

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

38
RELEASE_NOTES.md
View File

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

2
VERSION
View File

@@ -1 +1 @@
3.46
3.46.1

2
build-support/custom-modules/ns3-coverage.cmake
View File

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

4
doc/contributing/source/conf.py
View File

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

1
doc/doxygen.conf
View File

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

4
doc/installation/source/conf.py
View File

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

4
doc/manual/source/conf.py
View File

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

4
doc/models/source/conf.py
View File

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

4
doc/tutorial/source/conf.py
View File

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

78
ns3
View File

@@ -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'
)
parser_shell.add_argument(
"shell",
help="Export necessary environment variables and open a shell",
action="store_true",
default=False,
"shell", help="Export necessary environment variables and open a shell"
)
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():
if shutil.which(generator):
for build_tool, generator in cmake_build_tool_to_generator_map.items():
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

2
src/buildings/doc/source/buildings-design.rst
View File

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

7
src/core/model/deprecated.h
View File

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

1
src/core/model/test.cc
View File

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

1
src/lte/model/lte-rrc-header.cc
View File

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

668
src/mobility/doc/mobility.rst
View File

@@ -1,29 +1,24 @@
.. include:: replace.txt
.. _Mobility:
Mobility
--------
========
.. heading hierarchy:
------------- Chapter
************* Section (#.#)
============= Subsection (#.#.#)
############# Paragraph (no number)
============= Chapter
------------- Section (#.#)
~~~~~~~~~~~~~ Subsection (#.#.#)
^^^^^^^^^^^^^ 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.
- 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).
The |ns3| mobility system consists of three main components:
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``.
Design
======
Most mobility-related source code is located in the ``src/mobility`` directory. For building-related mobility models, see ``src/buildings``.
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
them. Currently, |ns3| provides support for the Cartesian, Geocentric Cartesian,
and Geographic coordinate systems, which are defined as:
**Current Support**:
* **Cartesian coordinates**: They represent a point in 3D space using the set of coordinates (x,y,z).
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.
- Cartesian, geocentric cartesian, and geographic coordinates are presently supported
- 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
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.
**Current Limitations**:
* **Geocentric Cartesian coordinates**: Cartesian coordinate system where the
origin is fixed in the Earth's center of mass. The implementation follows the description in Sec. 6.3 of [38811]_.
- Z-axis movement support varies by model
- 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
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.
Available Mobility Models
-------------------------
There are also some additional related structures used to support
mobility models.
- Rectangle
- Box
- Waypoint
Core Classes
~~~~~~~~~~~~
MobilityModel
#############
**MobilityModel Base Class**
Describe base class
The ``ns3::MobilityModel`` class is the foundation of the mobility system:
- GetPosition ()
- Position and Velocity attributes
- GetDistanceFrom ()
- CourseChangeNotification
.. sourcecode:: cpp
MobilityModel Subclasses
########################
// Key methods
Vector GetPosition() const; // Current position
Vector GetVelocity() const; // Current velocity
double GetDistanceFrom(Ptr<const MobilityModel> other) const;
- ConstantPosition
- ConstantVelocity
- ConstantAcceleration
- GaussMarkov
- Hierarchical
- RandomDirection2D
- RandomWalk2D
- RandomWaypoint
- SteadyStateRandomWaypoint
- Waypoint
- GeocentricConstantPosition
// Attributes
Vector Position; // Current position
Vector Velocity; // Current velocity
PositionAllocator
#################
// Trace sources
TracedCallback<Ptr<const MobilityModel>> CourseChange;
Position allocators usually used only at beginning, to lay out the nodes
initial position. However, some mobility models (e.g. RandomWaypoint) will
use a position allocator to pick new waypoints.
**Key Features**:
- ListPositionAllocator
- GridPositionAllocator
- RandomRectanglePositionAllocator
- RandomBoxPositionAllocator
- RandomDiscPositionAllocator
- UniformDiscPositionAllocator
- **Position Tracking**
- **Velocity Tracking**
- **Distance Calculation**: Calculates distance to another mobility model object
- **Course Change Notifications**: Trace source for movement events
- **Node Aggregation**: Typically aggregated to ``ns3::Node`` objects
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
documentation is available at: http://www.isi.edu/nsnam/ns/doc/node172.html
MobilityHelper
~~~~~~~~~~~~~~
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.
Also, this ``set`` can be specified for a future time, such as in the
last three statements above.
Supported ns-2 Commands
~~~~~~~~~~~~~~~~~~~~~~~
The command ``setdest`` instructs the simulation to start moving the
specified node towards the coordinate (x2, y2) at the specified time.
Note that the node may never get to the destination, but will
proceed towards the destination at the specified speed until it
either reaches the destination (where it will pause), is set to
a new position (via ``set``), or sent on another course change
(via ``setdest``).
- ``$node set X_ x1``: Set initial X position
- ``$node set Y_ y1``: Set initial Y position
- ``$node set Z_ z1``: Set initial Z position
- ``$ns at $time $node setdest x2 y2 speed``: Move to destination at specified time
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
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.
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.
Helper
======
Basic Configuration
~~~~~~~~~~~~~~~~~~~
A typical usage pattern can be found in the ``third.cc`` program in the
tutorial.
First, the user instantiates a ``MobilityHelper`` object and sets some
``Attributes`` controlling the "position allocator" functionality.
Random Walk Setup
^^^^^^^^^^^^^^^^^
.. sourcecode:: cpp
// Create nodes
NodeContainer nodes;
nodes.Create(10);
// Configure mobility
MobilityHelper mobility;
// Grid initial placement
mobility.SetPositionAllocator("ns3::GridPositionAllocator",
"MinX", DoubleValue(0.0),
"MinY", DoubleValue(0.0),
"DeltaX", DoubleValue(5.0),
"DeltaY", DoubleValue(10.0),
"GridWidth", UintegerValue(3),
"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
"MinX", DoubleValue(0.0),
"MinY", DoubleValue(0.0),
"DeltaX", DoubleValue(10.0),
"DeltaY", DoubleValue(10.0),
"GridWidth", UintegerValue(5),
"LayoutType", StringValue("RowFirst"));
// 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
NodeContainers during the configuration of an |ns3| scenario.
// Parent mobility (reference point)
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
|ns2| mobility helper:
// Set reference point waypoints
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
- bonnmotion-ns2-example.cc
groupMobility.Install(groupNodes);
ns2-mobility-trace
##################
Geographic Positioning
^^^^^^^^^^^^^^^^^^^^^^
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``.
.. sourcecode:: cpp
// Use geocentric coordinates
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.
- 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 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.
- 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
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.
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.
Class ``MobilityModel`` and class ``PositionAllocator`` both have public
API to assign streams to underlying random variables:
The example illustrates configuration using the GroupMobilityHelper and manual configuration without a helper; the configuration option is selectable by command-line argument.
.. 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.
/**
* 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);
Tests
~~~~~
The class ``MobilityHelper`` also provides this API. The typical usage
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.
Specific validation results and test cases are documented in the |ns3| test suite under ``src/mobility/test/``.
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

1
src/mobility/helper/ns2-mobility-helper.cc
View File

@@ -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_"
/**

6
src/olsr/model/olsr-routing-protocol.cc
View File

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

656
src/propagation/doc/propagation.rst
View File

@@ -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
* FixedRssLossModel
* FriisPropagationLossModel
* ItuR1411LosPropagationLossModel
* ItuR1411NlosOverRooftopPropagationLossModel
* JakesPropagationLossModel
* Kun2600MhzPropagationLossModel
* LogDistancePropagationLossModel
* MatrixPropagationLossModel
* NakagamiPropagationLossModel
* OkumuraHataPropagationLossModel
* RandomPropagationLossModel
* RangePropagationLossModel
* ThreeLogDistancePropagationLossModel
* TwoRayGroundPropagationLossModel
* ThreeGppPropagationLossModel
**Simple Range Models**
* ThreeGppRMaPropagationLossModel
* ThreeGppUMaPropagationLossModel
* ThreeGppUmiStreetCanyonPropagationLossModel
* ThreeGppIndoorOfficePropagationLossModel
* ThreeGppNTNDenseUrbanPropagationLossModel
* ThreeGppNTNUrbanPropagationLossModel
* ThreeGppNTNSuburbanPropagationLossModel
* ThreeGppNTNRuralPropagationLossModel
- FriisPropagationLossModel
- TwoRayGroundPropagationLossModel
- LogDistancePropagationLossModel
- ThreeLogDistancePropagationLossModel
- RangePropagationLossModel
**Fading Models**
- 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 propagation loss is totally random, and it changes each time the model is called.
As a consequence, all the packets (even those between two fixed nodes) experience a random
propagation loss.
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
-1000 dBm (effectively zero).
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.
Receivers at or within MaxRange meters receive the transmission at the
transmit power level. Receivers beyond MaxRange receive at power
-1000 dBm (effectively zero).
COST (COopération européenne dans le domaine de la recherche Scientifique et Technique) is a European Union
Forum for cooperative scientific research which developed this model based on various experiments and research
studies. This model is specifically applicable to urban areas and can be extended to evaluate path loss in
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,
the COST231 [cost231]_ extends it for the frequency range from 1500 MHz to 2000 MHz.
Hata model [4]_ is designed for frequencies ranging from 150 MHz to 1500 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
described in TR 38.901 [38901]_ to simulate wireless channels in vehicular environments.
The 3GPP TR 37.885 [10]_ specifications extends the channel modeling framework
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).

2
src/visualizer/model/pyviz.cc
View File

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

2
src/wifi/model/rate-control/amrr-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/aparf-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/arf-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/cara-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/minstrel-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/onoe-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/parf-wifi-manager.cc
View File

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

2
src/wifi/model/rate-control/rraa-wifi-manager.cc
View File

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

92
utils/tests/gitlab-ci-fedora.yml
View File

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

17
utils/tests/gitlab-ci-ubuntu.yml
View File

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