Left: | ||
Right: |
OLD | NEW |
---|---|
1 .. include:: replace.txt | 1 .. include:: replace.txt |
2 .. highlight:: cpp | 2 .. highlight:: cpp |
3 | 3 |
4 ++++++++++++++++++++ | 4 ++++++++++++++++++++ |
5 Design Documentation | 5 Design Documentation |
6 ++++++++++++++++++++ | 6 ++++++++++++++++++++ |
7 | 7 |
8 | 8 |
9 |ns3| nodes can contain a collection of NetDevice objects, much like an actual | 9 |ns3| nodes can contain a collection of NetDevice objects, much like an actual |
10 computer contains separate interface cards for Ethernet, Wifi, Bluetooth, etc. | 10 computer contains separate interface cards for Ethernet, Wifi, Bluetooth, etc. |
(...skipping 85 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
96 | 96 |
97 There are also several **rate control algorithms** that can be used by the | 97 There are also several **rate control algorithms** that can be used by the |
98 MAC low layer. A complete list of available rate control algorithms is· | 98 MAC low layer. A complete list of available rate control algorithms is· |
99 provided in a separate section. | 99 provided in a separate section. |
100 | 100 |
101 MAC low layer | 101 MAC low layer |
102 ============== | 102 ============== |
103 | 103 |
104 The **MAC low layer** is split into three main components: | 104 The **MAC low layer** is split into three main components: |
105 | 105 |
106 #. ``ns3::MacLow`` which takes care of RTS/CTS/DATA/ACK transactions. | 106 #. ``ns3::MacLow`` which takes care of RTS/CTS/DATA/ACK transactions and also |
107 performs MPDU aggregation. | |
107 #. ``ns3::DcfManager`` and ``ns3::DcfState`` which implements the DCF and EDCAF | 108 #. ``ns3::DcfManager`` and ``ns3::DcfState`` which implements the DCF and EDCAF |
108 functions. | 109 functions. |
109 #. ``ns3::DcaTxop`` and ``ns3::EdcaTxopN`` which handle the packet queue, | 110 #. ``ns3::Txop`` and ``ns3::QosTxop`` which handle the packet queue, |
110 packet fragmentation, and packet retransmissions if they are needed. | 111 packet fragmentation, and packet retransmissions if they are needed. |
111 The ``ns3::DcaTxop`` object is used high MACs that are not QoS-enabled, | 112 The ``ns3::Txop`` object is used high MACs that are not QoS-enabled, |
Rediet
2018/03/29 16:40:21
used by [missing] high
S. Deronne
2018/03/30 08:58:43
nice spot, originally missing, I will directly fix
| |
112 and for transmission of frames (e.g., of type Management) | 113 and for transmission of frames (e.g., of type Management) |
113 that the standard says should access the medium using the DCF.· | 114 that the standard says should access the medium using the DCF.· |
114 ``ns3::EdcaTxopN`` is is used by QoS-enabled high MACs and also | 115 ``ns3::QosTxop`` is is used by QoS-enabled high MACs and also |
115 performs 802.11n-style MSDU aggregation. | 116 performs MSDU aggregation. |
116 | 117 |
117 PHY layer models | 118 PHY layer models |
118 ================ | 119 ================ |
119 | 120 |
120 In short, the physical layer models are mainly responsible for modeling· | 121 In short, the physical layer models are mainly responsible for modeling· |
121 the reception of packets and for tracking energy consumption. There | 122 the reception of packets and for tracking energy consumption. There |
122 are typically three main components to packet reception: | 123 are typically three main components to packet reception: |
123 | 124 |
124 * each packet received is probabilistically evaluated for successful or | 125 * each packet received is probabilistically evaluated for successful or |
125 failed reception. The probability depends on the modulation, on | 126 failed reception. The probability depends on the modulation, on |
(...skipping 37 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
163 packets. Moreover, interference from other technologies is not modeled. | 164 packets. Moreover, interference from other technologies is not modeled. |
164 The following details pertain to the physical layer and channel models: | 165 The following details pertain to the physical layer and channel models: |
165 | 166 |
166 * 802.11ax is still in draft phase, not all functionalities are implemented yet | 167 * 802.11ax is still in draft phase, not all functionalities are implemented yet |
167 * 802.11ax does not contain any of the high-density improvement | 168 * 802.11ax does not contain any of the high-density improvement |
168 * 802.11ax MU-OFDMA is not supported | 169 * 802.11ax MU-OFDMA is not supported |
169 * 802.11ax can only be used with Constant rate control algorithm | 170 * 802.11ax can only be used with Constant rate control algorithm |
170 * 802.11ax only supports SU PPDU format | 171 * 802.11ax only supports SU PPDU format |
171 * 802.11ac/ax MU-MIMO is not supported, and no more than 4 antennas can be confi gured | 172 * 802.11ac/ax MU-MIMO is not supported, and no more than 4 antennas can be confi gured |
172 * 802.11n/ac/ax beamforming is not supported | 173 * 802.11n/ac/ax beamforming is not supported |
173 * 802.11 PCF and 802.11 HCF/HCCA are not implemented | 174 * 802.11 HCF/HCCA are not implemented |
175 * 802.11 PCF implementation currently assumes a DTIM interval equal to the beaco n interval | |
174 * Authentication and encryption are missing | 176 * Authentication and encryption are missing |
175 * Processing delays are not modeled | 177 * Processing delays are not modeled |
176 * PLCP preamble reception is not modeled | 178 * PLCP preamble reception is not modeled |
177 * PHY_RXSTART is not supported | 179 * PHY_RXSTART is not supported |
178 * The current implementation assumes that secondary channels are always higher t han primary channels | 180 * The current implementation assumes that secondary channels are always higher t han primary channels |
179 | 181 |
180 At the MAC layer, most of the main functions found in deployed Wi-Fi | 182 At the MAC layer, most of the main functions found in deployed Wi-Fi |
181 equipment for 802.11a/b/e/g/n/ac/ax are implemented, but there are scattered ins tances | 183 equipment for 802.11a/b/e/g/n/ac/ax are implemented, but there are scattered ins tances |
182 where some limitations in the models exist.Support for 802.11n and ac is evolvin g. | 184 where some limitations in the models exist.Support for 802.11n and ac is evolvin g. |
183 Some additional details are as follows: | 185 Some additional details are as follows: |
(...skipping 437 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
621 Depending on your goal, the common tasks are (in no particular order): | 623 Depending on your goal, the common tasks are (in no particular order): |
622 | 624 |
623 * Creating or modifying the default Wi-Fi frames/headers by making changes to `` wifi-mac-header.*``. | 625 * Creating or modifying the default Wi-Fi frames/headers by making changes to `` wifi-mac-header.*``. |
624 * MAC low modification. For example, handling new/modified control frames (think RTS/CTS/ACK/Block ACK), | 626 * MAC low modification. For example, handling new/modified control frames (think RTS/CTS/ACK/Block ACK), |
625 making changes to two-way transaction/four-way transaction. Users usually mak e changes to· | 627 making changes to two-way transaction/four-way transaction. Users usually mak e changes to· |
626 ``mac-low.*`` to accomplish this. Handling of control frames is performed in | 628 ``mac-low.*`` to accomplish this. Handling of control frames is performed in |
627 ``MacLow::ReceiveOk``. | 629 ``MacLow::ReceiveOk``. |
628 * MAC high modification. For example, handling new management frames (think beac on/probe),· | 630 * MAC high modification. For example, handling new management frames (think beac on/probe),· |
629 beacon/probe generation. Users usually make changes to ``regular-wifi-mac.*`` ,· | 631 beacon/probe generation. Users usually make changes to ``regular-wifi-mac.*`` ,· |
630 ``sta-wifi-mac.*``, ``ap-wifi-mac.*``, or ``adhoc-wifi-mac.*`` to accomplish t his. | 632 ``sta-wifi-mac.*``, ``ap-wifi-mac.*``, or ``adhoc-wifi-mac.*`` to accomplish t his. |
631 * Wi-Fi queue management. The files ``dca-txop.*`` and ``edca-txop-n.*`` are of interested for this task. | 633 * Wi-Fi queue management. The files ``txop.*`` and ``qos-txop.*`` are of intere sted for this task. |
632 * Channel access management. Users should modify the files ``dcf-manager.*``, w hich grant access to | 634 * Channel access management. Users should modify the files ``dcf-manager.*``, w hich grant access to |
633 ``DcaTxop`` and ``EdcaTxopN``. | 635 ``Txop`` and ``QosTxop``. |
634 * Fragmentation and RTS threholds are handled by Wi-Fi remote station manager. Note that Wi-Fi remote | 636 * Fragmentation and RTS threholds are handled by Wi-Fi remote station manager. Note that Wi-Fi remote |
635 station manager simply indicates if fragmentation and RTS are needed. Fragmen tation is handled by | 637 station manager simply indicates if fragmentation and RTS are needed. Fragmen tation is handled by |
636 ``DcaTxop`` or ``EdcaTxopN`` while RTS/CTS transaction is hanled by ``MacLow`` . | 638 ``Txop`` or ``QosTxop`` while RTS/CTS transaction is hanled by ``MacLow``. |
637 * Modifying or creating new rate control algorithms can be done by creating a ne w child class of Wi-Fi remote | 639 * Modifying or creating new rate control algorithms can be done by creating a ne w child class of Wi-Fi remote |
638 station manager or modifying the existing ones. | 640 station manager or modifying the existing ones. |
639 | 641 |
OLD | NEW |