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

wifi: Minor improvements and fix typos

Browse Source
This commit is contained in:
Mohit P. Tahiliani
2020-03-10 20:18:24 +05:30
parent b8c935ca9c
commit 04d1553499
2 changed files with 30 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
src/wifi/doc/source/wifi-design.rst
View File

@@ -74,7 +74,7 @@ There are presently three **MAC high models** that provide for the three
parent ``ns3::RegularWifiMac``, is not discussed here) Wi-Fi topological
elements - Access Point (AP) (``ns3::ApWifiMac``),
non-AP Station (STA) (``ns3::StaWifiMac``), and STA in an Independent
Basic Service Set (IBSS - also commonly referred to as an ad hoc
Basic Service Set (IBSS) - also commonly referred to as an ad hoc
network (``ns3::AdhocWifiMac``).
The simplest of these is ``ns3::AdhocWifiMac``, which implements a
@@ -179,7 +179,7 @@ The following details pertain to the physical layer and channel models:
At the MAC layer, most of the main functions found in deployed Wi-Fi
equipment for 802.11a/b/e/g/n/ac/ax are implemented, but there are scattered instances
where some limitations in the models exist. Support for 802.11n and ac is evolving.
where some limitations in the models exist. Support for 802.11n, ac and ax is evolving.
Some implementation choices that are not imposed by the standard are listed below:
@@ -221,7 +221,7 @@ delay model also added. Packets sent from a ``ns3::YansWifiPhy`` object
onto the channel with a particular signal power, are copied to all of the
other ``ns3::YansWifiPhy`` objects after the signal power is reduced due
to the propagation loss model(s), and after a delay corresponding to
transmission (serialization) delay and propagation delay due
transmission (serialization) delay and propagation delay due to
any channel propagation delay model (typically due to speed-of-light
delay between the positions of the devices).
@@ -237,7 +237,7 @@ WifiPhy and related models
The ``ns3::WifiPhy`` is an abstract base class representing the 802.11
physical layer functions. Packets passed to this object (via a
``SendPacket()`` method are sent over a channel object, and
``SendPacket()`` method) are sent over a channel object, and
upon reception, the receiving PHY object decides (based on signal power
and interference) whether the packet was successful or not. This class
also provides a number of callbacks for notifications of physical layer
@@ -368,12 +368,12 @@ all such signals is compared against an energy detection threshold to
determine whether the PHY should enter a CCA_BUSY state.
The ``WifiPhy::CcaEdThreshold`` attribute
corresponds to what the standard calls the "ED threshold" for CCA Mode 1.
In section 16.4.8.5: "CCA Mode 1: Energy above threshold. CCA shall report
a busy medium upon detection of any energy above the ED threshold."
By default, this value is set to the -62 dBm level specified in the standard
for 20 MHz channels. When using ``YansWifiPhy``, there are no non-Wi-Fi
signals, so it is unlikely that this attribute would play much of a role
in Yans wifi models if left at the default value, but if there is a strong
In section 16.4.8.5 in the 802.11-2012 standard: "CCA Mode 1: Energy above
threshold. CCA shall report a busy medium upon detection of any energy above
the ED threshold." By default, this value is set to the -62 dBm level specified
in the standard for 20 MHz channels. When using ``YansWifiPhy``, there are no
non-Wi-Fi signals, so it is unlikely that this attribute would play much of a
role in Yans wifi models if left at the default value, but if there is a strong
Wi-Fi signal that is not otherwise being received by the model, it has
the possibility to raise the CCA_BUSY while the overall energy exceeds
this threshold.
@@ -395,7 +395,7 @@ threshold.
The basic operation of probability of error calculations is shown in Figure
:ref:`snir`. Packets are represented as bits (not symbols) in the |ns3|
model, and the InterferenceHelper breaks the packet into one or more
"chunks" each with a different signal to noise (and interference) ratio
"chunks", each with a different signal to noise (and interference) ratio
(SNIR). Each chunk is separately evaluated by asking for the probability
of error for a given number of bits from the error model in use. The
InterferenceHelper builds an aggregate "probability of error" value
@@ -438,8 +438,7 @@ hard-decision of punctured codes, the coded BER is calculated using
Chernoff bounds.
The 802.11b model was split from the OFDM model when the NIST error rate
model was added, into a new model called DsssErrorRateModel. The current
behavior is that users may
model was added, into a new model called DsssErrorRateModel.
Furthermore, the 5.5 Mbps and 11 Mbps models for 802.11b rely on library
methods implemented in the GNU Scientific Library (GSL). The Waf build
@@ -451,7 +450,7 @@ As a result, there are three error models:
#. ``ns3::DsssErrorRateModel``: contains models for 802.11b modes. The
802.11b 1 Mbps and 2 Mbps error models are based on classical modulation
analysis. If GNU GSL is installed, the 5.5 Mbps and 11 Mbps from
analysis. If GSL is installed, the 5.5 Mbps and 11 Mbps from
[pursley2009]_ are used; otherwise, a backup Matlab model is used.
#. ``ns3::NistErrorRateModel``: is the default for OFDM modes and reuses
``ns3::DsssErrorRateModel`` for 802.11b modes.
@@ -533,7 +532,7 @@ The MAC model
Infrastructure association
##########################
Association in infrastructure (IBSS) mode is a high-level MAC function.
Association in infrastructure mode is a high-level MAC function.
Either active probing or passive scanning is used (default is passive scan).
At the start of the simulation, Wi-Fi network devices configured as
STA will attempt to scan the channel. Depends on whether passive or active
@@ -809,12 +808,12 @@ a reduced power. Otherwise, no TX power restrictions will be applied.
Constant OBSS PD Algorithm
##########################
Constant OBSS PD algorithm is a simple OBSS PD algorithm implemmented in the ``ConstantObssPdAlgorithm`` class.
Constant OBSS PD algorithm is a simple OBSS PD algorithm implemented in the ``ConstantObssPdAlgorithm`` class.
Once a HE preamble and its header have been received by the PHY, ``ConstantObssPdAlgorithm::
ReceiveHeSig`` is triggered.
The algorithm then checks whether this is an OBSS frame by comparing its own BSS color with the BSS color of the received preamble.
If this is an OBSS frame, it compare the received RSSI with its configured OBSS PD level value. The PHY then gets reset to IDLE
If this is an OBSS frame, it compares the received RSSI with its configured OBSS PD level value. The PHY then gets reset to IDLE
state in case the received RSSI is lower than that constant OBSS PD level value, and is informed about a TX power restrictions.
Note: since our model is based on a single threshold, the PHY only supports one restricted power level.
@@ -834,7 +833,7 @@ Depending on your goal, the common tasks are (in no particular order):
* MAC high modification. For example, handling new management frames (think beacon/probe),
beacon/probe generation. Users usually make changes to ``regular-wifi-mac.*``,
``infrastructure-wifi-mac.*``,``sta-wifi-mac.*``, ``ap-wifi-mac.*``, or ``adhoc-wifi-mac.*`` to accomplish this.
* Wi-Fi queue management. The files ``txop.*`` and ``qos-txop.*`` are of interested for this task.
* Wi-Fi queue management. The files ``txop.*`` and ``qos-txop.*`` are of interest for this task.
* Channel access management. Users should modify the files ``channel-access-manager.*``, which grant access to
``Txop`` and ``QosTxop``.
* Fragmentation and RTS threholds are handled by Wi-Fi remote station manager. Note that Wi-Fi remote

26
src/wifi/doc/source/wifi-user.rst
View File

@@ -11,7 +11,7 @@ Using the WifiNetDevice
The modularity provided by the implementation makes low-level configuration of
the WifiNetDevice powerful but complex. For this reason, we provide some helper
classes to perform common operations in a simple matter, and leverage the |ns3|
attribute system to allow users to control the parametrization of the underlying
attribute system to allow users to control the parameterization of the underlying
models.
Users who use the low-level |ns3| API and who wish to add a WifiNetDevice to
@@ -43,11 +43,11 @@ To create a WifiNetDevice, users need to follow these steps:
decoded or not depending on the received signal strength and noise. Thus, the main
configuration of WifiPhy is the error rate model, which is the one that actually
calculates the probability of successfully decoding the frame based on the signal.
* Configure WifiMac: this step is more on related to the architecture and device level.
* Configure WifiMac: this step is more related to the architecture and device level.
The users configure the wifi architecture (i.e. ad-hoc or ap-sta) and whether QoS (802.11e),
HT (802.11n) and/or VHT (802.11ac) and/or HE (802.11ax) features are supported or not.
* Create WifiDevice: at this step, users configure the desired wifi standard
(e.g. **802.11b**, **802.11g**, **802.11a**, **802.11n**, **802.11ac** or **802.11ax**) and rate control algorithm
(e.g. **802.11b**, **802.11g**, **802.11a**, **802.11n**, **802.11ac** or **802.11ax**) and rate control algorithm.
* Configure mobility: finally, mobility model is (usually) required before WifiNetDevice
can be used.
@@ -102,7 +102,7 @@ Users will typically type code such as::
to get the defaults. Specifically, the default is a channel model with a
propagation delay equal to a constant, the speed of light (``ns3::ConstantSpeedPropagationDelayModel``),
and a propagation loss based on a default log distance model (``ns3::LogDistancePropagationLossModel``)), using a default exponent of 3.
and a propagation loss based on a default log distance model (``ns3::LogDistancePropagationLossModel``), using a default exponent of 3.
Please note that the default log distance model is configured with a reference
loss of 46.6777 dB at reference distance of 1m. The reference loss of 46.6777 dB
was calculated using Friis propagation loss model at 5.15 GHz. The reference loss
@@ -180,14 +180,14 @@ For example, this code configures a node with 3 antennas that supports 2 spatial
WifiMacHelper mac;
mac.SetType ("ns3::StaWifiMac",
"Ssid", SsidValue (ssid),
"ActiveProbing", BooleanValue (false));
"Ssid", SsidValue (ssid),
"ActiveProbing", BooleanValue (false));
NetDeviceContainer staDevice;
staDevice = wifi.Install (phy, mac, wifiStaNode);
mac.SetType ("ns3::ApWifiMac",
"Ssid", SsidValue (ssid));
"Ssid", SsidValue (ssid));
NetDeviceContainer apDevice;
apDevice = wifi.Install (phy, mac, wifiApNode);
@@ -425,7 +425,7 @@ arguments:
The pair of (channelNumber, standard) are used as an index to a map that
returns a Frequency and ChannelWidth. By calling this method, one can
dynamically add members to the map. For instance, let's suppose that you
previously configured WIFI_PHY_STANDARD_80211a, and wanted to deine a new
previously configured WIFI_PHY_STANDARD_80211a, and wanted to define a new
channel number '34' of width 20 MHz and at center frequency 5160 MHz.
If you try to simply configure ChannelNumber to the value 34, it will fail,
@@ -485,7 +485,7 @@ different configurations can be obtained. Below are some common use cases.
all of the other configuration details.
* **(interaction between channel number and frequency):** If the user
the user sets Frequency to a different value than the currently configured
sets Frequency to a different value than the currently configured
ChannelNumber (or if ChannelNumber is zero), then the ChannelNumber is
set to a new channel number if known, or to zero if unknown.
@@ -703,7 +703,7 @@ on a set of nodes in a NodeContainer "c"::
This creates the WifiNetDevice which includes also a WifiRemoteStationManager, a
WifiMac, and a WifiPhy (connected to the matching Channel).
The ``WifiHelper::SetStandard`` method set various default timing parameters as defined in the selected standard version, overwriting values that may exist or have been previously configured.
The ``WifiHelper::SetStandard`` method sets various default timing parameters as defined in the selected standard version, overwriting values that may exist or have been previously configured.
In order to change parameters that are overwritten by ``WifiHelper::SetStandard``, this should be done post-install using ``Config::Set``::
WifiHelper wifi;
@@ -747,7 +747,7 @@ policy selector associated with BE AC to 0.5::
"BaThreshold", DoubleValue (0.5));
The WifiHelper is also used to configure OBSS PD spatial reuse for 802.11ax.
The following line configure a WifiHelper to support OBSS PD spatial reuse
The following lines configure a WifiHelper to support OBSS PD spatial reuse
using the ``ConstantObssPdAlgorithm`` with a threshold set to -72 dBm::
WifiHelper wifi;
@@ -768,7 +768,7 @@ user sets the standard to a variant that supports HT capabilities (802.11n,
created for the device. The configuration object is used to store and
manage HT-specific attributes.
802.11n/ac PHY layer can use either either long (800 ns) or short (400 ns) OFDM guard intervals. To configure this parameter for a given device, the following lines of code could be used (in this example, it enables the support of a short guard interval for the first station)::
802.11n/ac PHY layer can use either long (800 ns) or short (400 ns) OFDM guard intervals. To configure this parameter for a given device, the following lines of code could be used (in this example, it enables the support of a short guard interval for the first station)::
Ptr<NetDevice> nd = wifiStaDevices.Get (0);
Ptr<WifiNetDevice> wnd = nd->GetObject<WifiNetDevice> ();
@@ -801,7 +801,7 @@ IEEE 802.11ax is also known as High Efficiency (HE). Once the ``ns3::WifiHelper
HE configuration object will automatically be created to manage HE-specific
attributes for 802.11ax devices.
802.11ax PHY layer can use either either 3200 ns, 1600 ns or 800 ns OFDM guard intervals. To configure this parameter, the following line of code could be used (in this example, it enables the support of 1600 ns guard interval), such as in this example code snippet::
802.11ax PHY layer can use either 3200 ns, 1600 ns or 800 ns OFDM guard intervals. To configure this parameter, the following lines of code could be used (in this example, it enables the support of 1600 ns guard interval), such as in this example code snippet::
Ptr<NetDevice> nd = wifiStaDevices.Get (0);
Ptr<WifiNetDevice> wnd = nd->GetObject<WifiNetDevice> ();