Table Of Contents
Table Of Contents

IEEE 802.11 Fragmentation

Goals

Fragmentation is a way of improving 802.11 performance in the presence of interference, noise, or in a network with large distances. It works by splitting up large frames to a number of shorter framents called fragments, thereby increasing the chance of successful data transfer.

This showcase demonstrates 802.11 MAC-level fragmentation.

INET version: 4.0

About 802.11 Fragmentation

Fragmentation in 802.11 reduces packet errors in certain situations, e.g. in a noisy environment. A larger frame has a higher chance of getting corrupted than a smaller one. The error correcting mechanism can correct some erroneous bits in a received frame, but as the bit error rate increases, it becomes less likely that it can correct all bit errors. In 802.11, a frame can be fragmented to a maximum of 16 fragments.

The downside is that fragmentation increases overhead, and thus decreases throughput and channel utilization. The smaller packets resulting from fragmentation each have PHY and MAC headers, and each packet transmission might be followed by a contention period and ACK (depending on block ack policy and whether TXOP is used). Also, fragmentation increases delay, because an incoming packet only arrives at the application when all of its fragments have been received.

802.11 Fragmentation in INET

In INET, 802.11 fragmentation is controlled by fragmentation policies in Ieee80211Mac. By default, the Dcf and Hcf submodules of Ieee80211Mac contain a fragmentation policy submodule (at mac.dcf.originatorMacDataService.fragmentationPolicy and mac.hcf.originatorMacDataService.fragmentationPolicy). The default fragmentation policy type is BasicFragmentationPolicy.

BasicFragmentationPolicy has just one parameter, fragmentationThreshold. Frames larger than this value are fragmented. The value includes the MAC header, the payload, and the MAC trailer. The MAC overhead (header + trailer) is 28 bytes with DCF and 30 bytes with HCF. The default for this parameter is 1500 bytes.

Note

Caveat: In addition to fragmentationThreshold, Ieee80211Mac also has a parameter named mtu (maximum transfer unit), which appears to be similar in purpose. However, MTU controls IP level fragmentation on the interface the MAC is part of, i.e. it is actually used by the IP module instead of the MAC. The two are related; for example, by setting MTU to an appropriately small value, one can achieve that 802.11 fragmentation is never triggered (for IP packets at least).

The Model

The example simulation contains two wireless nodes. One of them sends large UDP packets to the other via Wifi in a noisy environment. The simulation will be run with fragmentation turned off and turned on. We’ll examine the effect of fragmentation on the Wifi performance. We’ll also see how TXOP and block acknowledgments affect the performance. Furthermore, we’ll examine the domain of effectiveness for fragmentation.

The example simulation uses the following network:

../../../../_images/network31.png

The network contains two AdhocHost’s named wifiHost1 and wifiHost2. It also contains an Ipv4NetworkConfigurator, an IntegratedVisualizer, and an Ieee80211ScalarRadioMedium module.

Configuration keys for the UDP traffic, the radio, and the radio medium are defined in the General configuration in omnetpp.ini.

wifiHost1 sends 2000-byte UDP packets to wifiHost2 every 0.5 seconds, which corresponds to about 32 Mbps of application-level traffic. The hosts operate in 802.11g mode with 54 Mbps data rate. Here is the traffic configuration in omnetpp.ini:

*.wifiHost1.numApps = 1
*.wifiHost1.app[0].typename = "UdpBasicApp"
*.wifiHost1.app[0].destAddresses = "wifiHost2"
*.wifiHost1.app[0].destPort = 4000
*.wifiHost1.app[0].sendInterval = 0.5ms
*.wifiHost1.app[0].messageLength = 2000Byte

*.wifiHost2.numApps = 1
*.wifiHost2.app[0].typename = "UdpSink"
*.wifiHost2.app[0].localPort = 4000

We make the environment noisy by lowering the transmission power. Also, to make the simulation more precise, we lower various thresholds to prevent certain shortcuts in the computations from kicking in. Here is the configuration in omnetpp.ini:

*.wifiHost*.wlan[*].radio.receiver.energyDetection = -105dBm
*.wifiHost*.wlan[*].radio.receiver.sensitivity = -105dBm
*.wifiHost*.wlan[*].radio.receiver.snirThreshold = 0dB

*.wifiHost*.wlan[*].radio.transmitter.power = 0.08mW

We want to demonstrate that fragmenting packets is advantageous in a noisy environment, so we set the transmission power accordingly. If there is too much noise, the fragmentation doesn’t make any difference, as communication becomes impossible. If there is too little noise, fragmentation is disadvantageous due to the extra overhead.

The simulation will be run with four scenarios. Each scenario aims to improve the noisy channel performance of the previous one. They are defined in the following configurations:

  • DCFnofrag: The MAC uses DCF, and there is no fragmentation. It is expected that only a few of the large packets will be received successfully; throughput will be low.

  • DCFfrag: The MAC uses DCF, and packets are fragmented. Due to the smaller fragments, packet error rate should decrease, and throughput should increase compared to the previous scenario.

  • HCFfrag: The MAC uses HCF, packets are fragmented, and transmitted during a TXOP. Throughput should increase even more, as the sender node doesn’t have to contend for channel access before transmitting each packet (although packets are ACKed individually).

  • HCFfragblockack: This is the same as the previous scenario, but block acknowledgments are enabled. Throughput should increase yet again, as the receiver node doesn’t have to ACK each packet individually.

The simulations will be run for 10 seconds, and we’ll examine the number of packets received by the UDP application of wifiHost2, and the application level throughput (the many small packets resulting from fragmentation doesn’t affect the number of packets received by the UDP application, because they are defragmented by the MAC before they arrive at the UDP app).

Let’s look at the details of the four configurations. Here is DCFnofrag from omnetpp.ini:

[Config DCFnofrag]

**.mac.dcf.originatorMacDataService.fragmentationPolicy.fragmentationThreshold = 2250B

It just sets a fragmentation threshold higher than the packet size to avoid fragmentation.

In the next configuration, DCFfrag, we turn on fragmentation. Here is the configuration in omnetpp.ini:

[Config DCFfrag]

**.mac.dcf.originatorMacDataService.fragmentationPolicy.fragmentationThreshold = 250B

It sets a fragmentation threshold value smaller than the packet size. Packets will be fragmented to 250-byte pieces. Each packet is followed by an ACK and a contention period.

Next, we examine how performance is affected if the small packets are sent during a TXOP, so the originator MAC doesn’t have to contend for the channel after transmitting each packet. In the next configuration, HCFfrag, the MAC will use HCF instead of DCF, and take advantage of video priority TXOP. Here is the configuration in omnetpp.ini:

[Config HCFfrag]

*.wifiHost*.wlan[*].mac.qosStation = true
*.wifiHost*.wlan[*].classifier.typename = "QosClassifier"
**.mac.hcf.originatorMacDataService.msduAggregationPolicy.typename = ""
**.mac.hcf.originatorMacDataService.fragmentationPolicy.fragmentationThreshold = 250B

It sets the same fragmentation threshold as the previous configuration. QoS is enabled (so the MAC uses HCF). A classifier is added to sort packets into the video priority category. Frame aggregation is turned off, because we don’t want to aggregate our fragments into a larger frame.

Packets are transmitted without contention during the TXOP, but all of them are ACKed individually.

In the final configuration, HCFfragblockack, we extend the previous configuration and turn on block acks, so a group of packets can be ACKed.

When block acks are enabled, the sender node sends a block ack request after transmitting a certain number of frames (by default, five). The receiver node then sends a block ack, which contains information about which packets were received correctly, and which weren’t. The incorrectly received ones can be retransmitted by the sender.

Here is the configuration:

[Config HCFfragblockack]
extends = HCFfrag

*.wifiHost*.wlan[*].mac.hcf.isBlockAckSupported = true

This configuration just enables block acks. The default block ack threshold is used, i.e. block ack requests are sent after five frames.

Results

Here are the results from the simulations:

../../../../_images/numberofpackets.png
../../../../_images/throughput.png

In our setup, the throughput is the lowest when packets are not fragmented (DFCnofrag line), because very few packets are received correctly. Throughput improves considerably (by a factor of 20) when fragmentation is turned on (DCFfrag line). The use of TXOPs (HCFfrag line) again brings a two-fold increase in througput by eliminating contention periods. The use of block ACKs (HCFfragblockack line) brings another two-fold improvement.

Further Analysis

We ran some parameter studies to examine the domain of effectiveness for fragmentation. We based the parameter studies on the above simulations. We examined the average application-level throughput. (The noise level, transmission power, and other settings are the same as in the above configurations unless otherwise noted.)

First, the iteration variable was the packet size (going from 100B to 2500B), with a constant fragmentation threshold of 250 bytes:

../../../../_images/onlypacketsize.png

Performance decreases with packet size in the DCFnofrag case, as larger packets have more chance for becoming corrupted. In the cases where fragmentation is enabled, the throughput follows a similar curve (increasing at the beginning, and fairly constant after that). At small packet sizes, the 802.11 overhead is significant. As the packet size increases above 1000B, throughput doesn’t change substantially. The difference in magnitude between the three curves of DCFfrag, HCFfrag, and HCFfragblockack is due to the improvements of each configuration: the use of TXOP increases throughput, and the use of TXOP + block acks increases it further.

Secondly, the fragmentation threshold was iterated, using a 1000-byte packet size:

../../../../_images/threshold.png

The three curves are similar in shape to each other in this case. The difference in magnitude between them can be attributed to the use of TXOP and TXOP + block ack.

Next, the packet size was iterated, but on a wider range (from 100B to 6000B). The MAC can fragment packets to a maximum of 16 fragments. Due to the larger packets, the fragmentation threshold was set to around 1/16th of the packet size (taking MAC headers into account), so that the MAC always fragments packets to 16 pieces.

../../../../_images/packetsize.png

DCFnofrag has an advantage when packets are small since fragmenting small packets to 16 fragments entails a lot of overhead. Otherwise, the three curves where fragmentation is enabled are similar, and the difference in magnitude is attributed to the use of TXOP and TXOP + block ack.

Then, the transmission power was iterated to examine performance at different noise levels.

../../../../_images/snir.png

It is apparent that in this scenario, the domain in which fragmentation is useful is a very small range. Above a certain SNIR threshold, the fragmentation decreases performance, and below another threshold, it doesn’t make any difference because all packets are lost.

Note

The parameter study configurations are defined in parameterstudy.ini. The charts are available in ParameterStudy.anf.

Sources: omnetpp.ini, FragmentationShowcase.ned

Discussion

Use this page in the GitHub issue tracker for commenting on this showcase.