From 04d15534991e692f76827fd230a9d6d1be79df75 Mon Sep 17 00:00:00 2001 From: "Mohit P. Tahiliani" Date: Tue, 10 Mar 2020 20:18:24 +0530 Subject: [PATCH] wifi: Minor improvements and fix typos --- src/wifi/doc/source/wifi-design.rst | 35 ++++++++++++++--------------- src/wifi/doc/source/wifi-user.rst | 26 ++++++++++----------- 2 files changed, 30 insertions(+), 31 deletions(-) diff --git a/src/wifi/doc/source/wifi-design.rst b/src/wifi/doc/source/wifi-design.rst index fcf9e6a7d..4fa5bd436 100644 --- a/src/wifi/doc/source/wifi-design.rst +++ b/src/wifi/doc/source/wifi-design.rst @@ -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 diff --git a/src/wifi/doc/source/wifi-user.rst b/src/wifi/doc/source/wifi-user.rst index 6a104e413..882197321 100644 --- a/src/wifi/doc/source/wifi-user.rst +++ b/src/wifi/doc/source/wifi-user.rst @@ -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 nd = wifiStaDevices.Get (0); Ptr wnd = nd->GetObject (); @@ -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 nd = wifiStaDevices.Get (0); Ptr wnd = nd->GetObject ();