diff --git a/doc/manual/source/nodes-and-devices.rst b/doc/manual/source/nodes-and-devices.rst index d82b2176d..e68dec982 100644 --- a/doc/manual/source/nodes-and-devices.rst +++ b/doc/manual/source/nodes-and-devices.rst @@ -15,3 +15,4 @@ Node and NetDevices uan energy openflow-switch + propagation diff --git a/doc/manual/source/propagation.rst b/doc/manual/source/propagation.rst new file mode 100644 index 000000000..bc3ddf2fd --- /dev/null +++ b/doc/manual/source/propagation.rst @@ -0,0 +1,32 @@ +.. include:: replace.txt + +Propagation +----------- + +The |ns3| propagation module defines two generic interfaces, namely ``PropagationLossModel`` and ``PropagationDelayModel``, for the modeling of respectively propagation loss and propagation delay. + +The following propagation loss models are implemented: + +* ``JakesPropagationLossModel`` +* ``PropagationLossModel`` +* ``RandomPropagationLossModel`` +* ``FriisPropagationLossModel`` +* ``TwoRayGroundPropagationLossModel`` +* ``LogDistancePropagationLossModel`` +* ``ThreeLogDistancePropagationLossModel`` +* ``NakagamiPropagationLossModel`` +* ``FixedRssLossModel`` +* ``MatrixPropagationLossModel`` +* ``RangePropagationLossModel`` + + +The following propagation delay models are implemented: + +* ``PropagationDelayModel`` +* ``RandomPropagationDelayModel`` +* ``ConstantSpeedPropagationDelayModel`` + +All the above models can be used within any model using the ``PropagationLossModel`` and ``PropagationDelayModel`` interfaces, such as Wifi and Wimax. + + + diff --git a/doc/manual/source/wifi.rst b/doc/manual/source/wifi.rst index 9bf577066..bd17a8d47 100644 --- a/doc/manual/source/wifi.rst +++ b/doc/manual/source/wifi.rst @@ -1,7 +1,7 @@ .. include:: replace.txt -Wifi NetDevice --------------- +Wifi +---- |ns3| nodes can contain a collection of NetDevice objects, much like an actual computer contains separate interface cards for Ethernet, Wifi, Bluetooth, etc. @@ -13,11 +13,11 @@ Overview of the model ********************* The WifiNetDevice models a wireless network interface controller based -on the IEEE 802.11 standard. We will go into more detail below but in brief, +on the IEEE 802.11 standard [ieee80211]_. We will go into more detail below but in brief, |ns3| provides models for these aspects of 802.11: * basic 802.11 DCF with **infrastructure** and **adhoc** modes -* **802.11a** and **802.11b** physical layers +* **802.11a**, **802.11b** and **802.11g** physical layers * QoS-based EDCA and queueing extensions of **802.11e** * various propagation loss models including **Nakagami, Rayleigh, Friis, LogDistance, FixedRss, Random** @@ -46,7 +46,7 @@ non-AP Station (STA) (``ns3::StaWifiMac``), and STA in an Independent 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 +The simplest of these is ``ns3::AdhocWifiMac``, which implements a Wi-Fi MAC that does not perform any kind of beacon generation, probing, or association. The ``ns3::StaWifiMac`` class implements an active probing and association state machine that handles automatic @@ -82,12 +82,16 @@ The **MAC low layer** is split into three components: There are also several **rate control algorithms** that can be used by the Mac low layer: -* ``ns3::ArfMacStations`` -* ``ns3::AArfMacStations`` -* ``ns3::IdealMacStations`` -* ``ns3::CrMacStations`` -* ``ns3::OnoeMacStations`` -* ``ns3::AmrrMacStations`` +* ``OnoeWifiManager`` +* ``IdealWifiManager`` +* ``AarfcdWifiManager`` +* ``AarfWifiManager`` +* ``ArfWifiManager`` +* ``AmrrWifiManager`` +* ``ConstantRateWifiManager`` +* ``MinstrelWifiManager`` +* ``CaraWifiManager`` +* ``RraaWifiManager`` The PHY layer implements a single model in the ``ns3::WifiPhy class``: the physical layer model implemented there is described fully in a paper entitled @@ -263,16 +267,9 @@ The WifiChannel and WifiPhy models The WifiChannel subclass can be used to connect together a set of ``ns3::WifiNetDevice`` network interfaces. The class ``ns3::WifiPhy`` is the -object within the WifiNetDevice that receives bits from the channel. A -WifiChannel contains a ``ns3::PropagationLossModel`` and a -``ns3::PropagationDelayModel`` which can be overridden by the -WifiChannel::SetPropagationLossModel and the -WifiChannel::SetPropagationDelayModel methods. By default, no propagation models -are set. +object within the WifiNetDevice that receives bits from the channel. +For the channel propagation modeling, the propagation module is used; see section :ref:`propagation` for details. -The WifiPhy models an 802.11a channel, in terms of frequency, modulation, and -bit rates, and interacts with the PropagationLossModel and PropagationDelayModel -found in the channel. This section summarizes the description of the BER calculations found in the yans paper taking into account the Forward Error Correction present in 802.11a @@ -321,30 +318,13 @@ SNIR function. *SNIR function over time.* -From the SNIR function we can derive bit error rates for BPSK and QAM -modulations. Then, for each interval l where BER is constant, we define the -upper bound of a probability that an error is present in the chunk of bits -located in the interval l for packet k. If we assume an AWGN channel, binary -convolutional coding (which is the case in 802.11a) and hard-decision Viterbi -decoding, the error rate is thus derived, and the packet error probability for -packet k can be computed. +From the SNIR function we can derive the Bit Error Rate (BER) and Packet Error Rate (PER) for the modulation and coding scheme being used for the transmission. Please refer to [pei80211validation]_ and [lacage2006yans]_ for a detailed description of the available BER/PER models. + WifiChannel configuration -+++++++++++++++++++++++++ +++++++++++++++++++++++++++ -WifiChannel models include both a PropagationDelayModel and a -PropagationLossModel. The following PropagationDelayModels are available: - -* ConstantSpeedPropagationDelayModel -* RandomPropagationDelayModel - -The following PropagationLossModels are available: - -* RandomPropagationLossModel -* FriisPropagationLossModel -* LogDistancePropagationLossModel -* JakesPropagationLossModel -* CompositePropagationLossModel +The WifiChannel implementation uses the propagation loss and delay models provided within the ns-3 *propagation* module. The MAC model ************* @@ -352,7 +332,7 @@ The MAC model The 802.11 Distributed Coordination Function is used to calculate when to grant access to the transmission medium. While implementing the DCF would have been particularly easy if we had used a recurring timer that expired every slot, we -chose to use the method described in *(missing reference here from Yans paper)* +chose to use the method described in [ji2004sslswn]_ where the backoff timer duration is lazily calculated whenever needed since it is claimed to have much better performance than the simpler recurring timer solution. @@ -372,45 +352,21 @@ deal with: Wifi Attributes *************** -The WifiNetDevice makes heavy use of the |ns3| :ref:`Attributes` subsystem for -configuration and default value management. Presently, approximately 100 values -are stored in this system. - -For instance, class ``ns-3::WifiMac`` exports these attributes: - -* CtsTimeout: When this timeout expires, the RTS/CTS handshake has failed. -* AckTimeout: When this timeout expires, the DATA/ACK handshake has failed. -* Sifs: The value of the SIFS constant. -* EifsNoDifs: The value of EIFS-DIFS -* Slot: The duration of a Slot. -* Pifs: The value of the PIFS constant. -* MaxPropagationDelay: The maximum propagation delay. Unused for now. -* MaxMsduSize: The maximum size of an MSDU accepted by the MAC layer.This value - conforms to the specification. -* Ssid: The ssid we want to belong to. +Should link to the list of attributes exported by Doxygen Wifi Tracing ************ -*This needs revised/updating based on the latest Doxygen* +Should link to the list of traces exported by Doxygen -|ns3| has a sophisticated tracing infrastructure that allows users to hook into -existing trace sources, or to define and export new ones. -Wifi-related trace sources that are available by default include::: +References +********** -* ``ns3::WifiNetDevice`` +.. [ieee80211] IEEE Std 802.11-2007 *Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications* - * Rx: Received payload from the MAC layer. - * Tx: Send payload to the MAC layer. +.. [pei80211validation] \G. Pei and Tom Henderson, `Validation of ns-3 802.11b PHY model* `__ -* ``ns3::WifiPhy`` +.. [lacage2006yans] \M. Lacage and T. Henderson, `Yet another Network Simulator `__ - * State: The WifiPhy state - * RxOk: A packet has been received successfully. - * RxError: A packet has been received unsuccessfully. - * Tx: Packet transmission is starting. - -Briefly, this means, for example, that a user can hook a processing function to -the "State" tracing hook above and be notified whenever the WifiPhy model -changes state. +.. [ji2004sslswn] \Z. Ji, J. Zhou, M. Takai and R. Bagrodia, *Scalable simulation of large-scale wireless networks with bounded inaccuracies*, in Proc. of the Seventh ACM Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems, October 2004. diff --git a/src/wifi/doc/wifi.h b/src/wifi/doc/wifi.h deleted file mode 100644 index 8a570700c..000000000 --- a/src/wifi/doc/wifi.h +++ /dev/null @@ -1,176 +0,0 @@ -/** - * \ingroup devices - * \defgroup Wifi Wifi Models - * - * \section WifiModelOverview Wifi Models Overview - * - * The set of 802.11 models provided in ns-3 attempts to provide - * an accurate MAC-level implementation of the 802.11 specification - * and to provide a not-so-slow PHY-level model of the 802.11a - * and 802.11b specifications. - * - * The current implementation provides roughly 4 levels of models: - * - the PHY layer models - * - the so-called MAC low models: they implement DCF and EDCAF - * - the so-called MAC high models: they implement the MAC-level - * beacon generation, probing, and association state machines. - * - a set of Rate control algorithms used by the MAC low models. - * - * There are presently three MAC high models, corresponding to the - * three primary Wi-Fi topological elements - Access Point (AP) - * (implemented in ns3::ApWifiMac), non-AP Station (STA) (implemented - * in ns3::StaWifiMac), and STA in an Independent Basic Service Set - * (IBSS - also commonly referred to as an ad hoc network. Implemented - * in ns3::AdhocWifiMac). - * - * - * The simplest of these is ns3::AdhocWifiMac, which implements a - * Wi-Fi MAC that does not perform any kind of beacon generation, - * probing, or association. The ns3::StaWifiMac class implements an - * active probing and association state machine that handles automatic - * re-association whenever too many beacons are missed. Finally, - * ns3::ApWifiMac implements an AP that generates periodic beacons, - * and that accepts every attempt to associate. - * - * These three MAC high models share a common parent in - * ns3::RegularWifiMac, which exposes, among other MAC configuration, - * an attribute (QosSupported) that allows configuration of - * 802.11e/WMM-style QoS support. With QoS-enabled MAC models it is - * possible to work with traffic belonging to four different Access - * Categories (ACs): AC_VO for voice traffic, AC_VI for video traffic, - * AC_BE for best-effort traffic and AC_BK for background traffic. In - * order for the MAC to determine the appropriate AC for an MSDU, - * packets forwarded down to these MAC layers should be marked using - * ns3::QosTag in order to set a TID (traffic id) for that packet - * otherwise it will be considered belonging to AC_BE. - * - * How TIDs are mapped to access classes are shown in the table below. - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
TID Access Category
7 AC_VO
6 AC_VO
5 AC_VI
4 AC_VI
3 AC_BE
0 AC_BE
2 AC_BK
1 AC_BK
- * - * The MAC low layer is split in 3 components: - * - ns3::MacLow which takes care of RTS/CTS/DATA/ACK transactions. - * - ns3::DcfManager and ns3::DcfState which implements the DCF function. - * - * - ns3::DcaTxop and ns3::EdcaTxopN which handle the packet queue, - * packet fragmentation, and packet retransmissions if they are - * needed. The ns3::DcaTxop object is used by high MACs that are - * not QoS-enabled, and for transmission of frames (e.g., of type - * Management) that the standard says should access the medium - * using the DCF. ns3::EdcaTxopN is used by QoS-enabled high MACs - * and also performs QoS operations like 802.11n-style MSDU - * aggregation. - * - * The PHY layer implements a single 802.11a model in the ns3::WifiPhy class: the - * physical layer model implemented there is described fully in a paper titled - * "Yet Another Network Simulator", available at: http://cutebugs.net/files/wns2-yans.pdf - * and recently extended to cover 802.11b physical layer. - * - * The Wifi Model also provides a set of Rate control algorithms: - * - ns3::ArfWifiManager - * - ns3::AarfWifiManager - * - ns3::IdealWifiManager - * - ns3::CrWifiManager - * - ns3::OnoeWifiManager - * - ns3::AmrrWifiManager - * - ns3::CaraWifiManager - * - ns3::AarfcdWifiManager - * - * \section WifiTracingModel Wifi Tracing Model - * - * Like all ns-3 devices, the Wifi Model provides a number of trace sources. - * These trace sources can be hooked using your own custom trace code, or you - * can use our helper functions to arrange for tracing to be enabled on devices - * you specify. - * - * \subsection WifiTracingModelUpperHooks Upper-Level (MAC) Hooks - * - * From the point of view of tracing in the net device, there are several - * interesting points to insert trace hooks. The first is at the interface - * between the device and higher layers. We provide trace hooks at this point - * in packet flow, which corresponds to a transition from the network to data - * link layer, and call them collectively the device MAC hooks. - * - * The first trace hook is called "Rx" and is fired using the - * ns3::WifiNetDevice::m_rxLogger trace hook. The perspective here is looking - * down into the WifiNetDevice so a receive indicates a packet being sent up - * from the channel to be forwarded up to higher layers. - * - * The second trace hook is called "Tx" and is fired using the - * ns3::WifiNetDevice::m_txLogger trace hook. This trace hook indicates a - * packet has been sent from higher layers down to the net device for - * transmission onto the network. - * - * \subsection WifiTracingModelLowerHooks Low-Level (PHY) Hooks - * - * Another interesting place to insert trace hooks is in the state machine - * that is driving the actual device transmission and reception logic. We - * provide the following hooks to instrument the lower levels of the device. - * - * First, we provide a trace hook to indicate state changes. This trace - * source is called "State" and is fired using the - * ns3::WifiPhyStateHelper::m_stateLogger trace source. - * - * We also provide a trace hook to indicate the successful reception of a - * packet from the channel. This trace source is called "RxOk" and is - * accessed using the ns3::WifiPhyStateHelper::m_rxOkTrace trace source. - * - * There also exists a trace hook to indicate an unsuccessful reception of a - * packet from the channel. This trace source is called "RxError" and is - * accessed using the ns3::WifiPhyStateHelper::m_rxErrorTrace trace source. - * - * There is a trace hook to indicate that transmission of a packet is - * starting onto the channel. This trace source is called "Tx" (don't - * confuse it with the higher layer "Tx" hook) and is - * fired using the ns3::WifiPhyStateHelper::m_txTrace trace source. - * - * \subsection WifiTracingModelRemoteHooks Remote Station Hooks - * - * We provide access to changes in the the per-remote-station RTS counter - * through the "Ssrc" trace source which is fired using the - * ns3::WifiRemoteStation::m_ssrc trace hook. - * - * Finally, we provide access to the per-remote-station SLRC counter that - * indications the number of retransmissions of data. Changes to this - * counter are traced using the ns3::WifiRemoteStation::m_slrc source. - * - * \subsection wifil2stack Layer 2 Stack Overview - * \image html WifiArchitecture.png "Overview of the Wifi L2 sublayers traversed for transmitting and receiving a packet" - */