## The Setup and Motivation#

The most basic packet transfer service offered by the Internet is called the "datagram" service, in which a series of packets are transmitted to a receiver without any packet loss recovery, flow control, or congestion control. The Internet's UDP protocol implements the datagram service. In this experiment, we will study the performance of UDP transfers from a server on a wireline local area network to WiFi Stations (STA), via WiFi Access Points (AP). The schematic of the network that we will be simulating in NetSim is shown in the figure below Figure 11‑1.

{width="5.4434787839020125in" height="4.250100612423447in"}

Figure 11‑1: Network topology and application flow from server to STA via a single AP

The server, which contains the data that needs to be transferred to the STAs (say, laptops), is connected by a 100 Mbps switched Ethernet link to an Ethernet switch, which is, in turn, connected to the Wi-Fi APs. Each AP is associated (i.e., connected) at a phy rate of 54Mbps (802.11g standard) to a single STA. The objective is to transfer a large number of packets (say, constituting a video) from the server to each of the STAs, the packet stream to each of the STAs being different (e.g., each STA is receiving a different video from the server). In this experiment, we are interested in studying the limitation that the Wi-Fi link places on the data transfers. We assume that the server transmits the packets at a saturation rate of wireless link (i.e. above 54Mbps) so that the queues at the APs fill up, and the rate of the UDP transfers is therefore, governed by the Wi-Fi link. It may be noted that, in practice, there will be a flow control mechanism between each STA and the server, that will control the rate at which the server releases packets, in order to prevent buffer overflow at the APs.

In this setting, this experiment will ask one precise question. With the buffers at the AP full, at what rate will the Wi-Fi protocol transfer the packets from the APs to the STAs over the wireless link. We will study two cases:

1. A single AP and a single STA: Since there is only one transmitter in this wireless network (namely, the AP), there is no contention, and the rate of packet transfer over the link will be governed by the basic overheads in the protocol, such as the interframe spacings, packet header overheads, transmit-receive turn-around times, and acknowledgement times. We will begin by a simple calculation (essentially timing book-keeping) that will predict the UDP throughput, and then we will verify our calculation using the NetSim simulator.

2. Multiple APs and one STA for each AP: This is the more common situation (for example neighboring apartments in a building, each with one AP and one laptop, all drawing data from the Internet service provider). The performance of such a system depends on the wireless propagation path-loss between the various APs. A predictive analysis is difficult in the general case. For deriving some insight, we will study the case where all the APs are close to each other (i.e. setting channel characteristics as No Pathloss), and thus exactly one transmission from AP to an STA can be successful at any time. If two or more APs transmit together, then all the transmissions are not successful. Even in this case, the analysis mathematically complex and is available in, Anurag Kumar, D. Manjunath and Joy Kuri. 2008: Wireless Networking. Sec 7.4

## Predicting the UDP Throughput#

### One AP and one STA#

As stated above, in the setup described, the AP queue is full. Thus, after a packet is completely transmitted over the wireless link, immediately the process for transmitting the next packet starts. This is illustrated by the upper part of the Figure 112, where the successive packets from the AP are shown as being sent back-to-back. The time taken to send a packet is, however, not just the time to clock out the physical bits corresponding to the packet over the Wi-Fi medium. After the completion of a packet transfer, the AP's Wi-Fi transmitter waits for a Distributed Coordination Function Inter-Frame Space (DIFS), followed by a backoff that is chosen randomly between 1 and 32 slots. Upon the completion of the backoff, the packet transmission starts. Each packet carries physical layer overheads, MAC layer overheads, and IP overheads. After the transmission of the packet, there is a Short Inter-Frame Space (SIFS), which gives time to the receiver (namely, the STA) to transition from the listening mode to the transmit mode. After the SIFS, the STA sends back a MAC acknowledgement (ACK). This completes the transmission of one UDP packet from the AP to the STA. Immediately, the process for sending the next packet can start. The details of the various timings involved in sending a single UDP packet are shown in the lower part of the figure below Figure 11‑2.

{width="4.887435476815398in" height="1.984009186351706in"}

Figure 11‑2: Detailed view of transmission of a single packet in WiFi involving single AP-STA.

In this experiment, the payload in each packet is the same (1450 Bytes). Since the packets are sent back-to-back, and the state of the system is identical at the beginning of each packet transmission, the throughput (in Mbps) is computed by the following simple (and intuitive) relation.

#### Without RTS-CTS#

$$UDP\ Throughput\ (Mbps) = \ \frac{Application\ Payload\ in\ Packet\ (bits)}{Average\ Time\ per\ Packet(µs)}$$

$$Average\ time\ per\ packet\ \ (µs) = \ DIFS\ + \ Average\ Backoff\ time\ + \ Packet\ Transmission\ Time\ + \ SIFS\ + \ Ack\ Transmission\ Time$$

$$Packet\ Transmission\ Time\ (µs) = \ Preamble\ time\ + \ \left( \frac{MPDUSize}{PHYrate} \right)$$

$$Average\ Backoff\ time\ (µs)\ = \ \left( \frac{CWmin}{2} \right)\ \times \ Slot\ Time$$

$$Ack\ Transmission\ Time\ (µs) = \ Preamble\ time\ + \ \left( \frac{AckPacketSize}{AckPHYRate}\ \right)$$

$$DIFS\ (µs) = \ SIFS\ + \ 2\ \times \ Slot\ Time$$

$$Average\ Backoff\ time\ (µs) = \ \left( \frac{CWmin}{2} \right)\ \times \ Slot\ Time$$

$$Preamble\ time = 20\ \mu s\ for\ 802.11g$$

$$MPDU\ Size = 1450 + 8 + 20 + 40 = 1518\ Bytes$$

$$Application\ Payload = 1450\ Bytes$$

$$SIFS = 10\ \mu s\ and\ Slot\ Time = 9\ \mu s$$

$${CW}_{\min} = 15\ slots\ for\ 802.11g$$

$$DIFS = SIFS + 2 \times Slot\ Time = 16\ \mu s + 2 \times 9\mu s = 34\ \mu s$$

$$Average\ Backoff\ Time = \ \left( \frac{CWmin}{2} \right) \times \ Slot\ Time = \left( \frac{15}{2} \right) \times 9 = 67.5\ \mu s$$

$$Packet\ Transmission\ Time = 20\mu s + \frac{1518\ (B) \times 8\ }{54\ (Mbps)} = 244.88\ \mu s$$

$$Ack\ Transmission\ Time = 20\mu s + \frac{14\ (B) \times 8}{6\ (Mbps)} = 38.66\ \mu s$$

$$Average\ time\ per\ packet = 34 + 67.5 + 244.88 + 16 + 38.66 = 401.04\ \mu s$$

$$UDP\ Throughput = \frac{1450 \times 8}{401.04} = 28.92\ Mbps$$

#### With RTS-CTS#

$$UDP\ Throughput\ (Mbps) = \ \frac{Application\ Payload\ in\ Packet\ (bits)}{Average\ Time\ per\ Packet(µs)}$$

$$Average\ time\ per\ packet\ \ (µs) = \ DIFS + \ RTS\ Packet\ Transmission\ Time + SIFS + \ CTS\ Packet\ Transmission\ Time + SIFS + \ Average\ Backoff\ time\ + \ Packet\ Transmission\ Time\ + \ SIFS\ + \ Ack\ Transmission\ Time$$

$$RTS\ packet\ transmission\ time = Preamble\ time + \left( \frac{RTS\ Packet\ payload}{Data\ Rate} \right) = 20 + \left( \frac{20 \times 8}{6} \right) = 46.66\ µs$$

$$\ CTS\ packet\ transmission\ time = Preamble\ time + \left( \frac{CTS\ Packet\ payload}{Data\ Rate} \right) = 20 + \left( \frac{14 \times 8}{6} \right) = 38.66\ µs$$

$$Average\ time\ per\ packet = 34 + 46.66 + 16 + \ 38.66 + 16 + \ 67.5 + 244.88 + 16 + 38.66 = 518.36\ µs\$$

$$UDP\ throughput = \frac{1450 \times 8}{518.36} = 22.37\ Mbps$$

### Multiple APs (near each other) and one STA per AP#

Since the AP queues are full, on the WiFi medium the packet transmission can still be viewed as being back-to-back as shown in the upper part of the figure below

Figure 11‑3. However, since there are multiple contending AP-STA links, there are two differences between this figure and the one shown above (for the single AP and single STA case Figure 11‑2).

{width="4.834037620297463in" height="2.0808770778652668in"}

Figure 11‑3: Detailed view of transmission of a single packet in WiFi involving Multiple AP-STA

a. Within each transmission period, there is now a "backoffs and collisions" period, where in the figure above we only showed a "backoff" period. Access to the channel is by contention, collision, and backoff, and this "backoffs and collisions" duration is the time taken to select one transmitting AP.

b. The other difference is that, after each "backoffs and collisions" period, any one AP-STA pair "wins" the contention, and the corresponding AP can then send a packet. It turns out that the contention mechanism is such that each of the AP-STA pairs can succeed with equal probability, independent of the pair that has previously been successful. Thus, if there are, say, 5 AP-STA pairs, then each successful packet transmission will be from any of these pairs with a probability of 0.2.

With reference to the figure above, note that, all the APs are contending to send their packets to their respective STAs, and the "Backoffs and Collisions" time is due to all the APs. However, finally, only one packet transmission succeeds. We will attribute all the contention overheads to the successful transmission of this packet. Thus, we will call the time duration from the beginning of a DIFS until the end of the ACK for the transmitted packet as the "effective" time taken to transmit that packet on the wireless medium. The average of these effective packet transmission times can be called the "Average time per Packet."

With this discussion, and the upper part of the figure above, it follows that the following expression still holds.

$$Total\ UDP\ Throughput\ (Mbps) = \ \frac{Application\ Payload\ in\ Packet\ (bits)}{Average\ Time\ per\ Packet(µs)}$$

We observe from the figure that the average time per packet will be larger than when there is a single AP-STA pair. Hence, the total UDP throughput will be smaller when there are multiple AP-STA pairs (since the "Application Payload in the Packet" is the same in both cases.

Having obtained the total throughput over all the AP-STA pairs in this manner, by the fact that each packet transmission is with equal probability from any of the AP-STA pairs, the UDP throughput for each AP-STA pair (for $N\$pairs) is just $\frac{1}{N}\$of the total throughput.

## Network Setup#

Open NetSim and click on Experiments> Internetworks> Wi-Fi> WiFi UDP Download Throughput then click on the tile in the middle panel to load the example as shown in below Figure 11‑4.

{width="6.5in" height="3.4430555555555555in"}

Figure 11‑4: List of scenarios for the example of Wi-Fi UDP Download Throughput

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 11‑5.

: {width="4.61295384951881in" height="1.9200929571303587in"}

Figure 11‑5: Network set up for studying the A single AP-STA Without RTS-CTS

## Procedure#

### Basic Access#

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 1 Wireless Node, 1 L2 Switch, and 1 Access Point in the "Internetworks" Network Library.

Step 2: In the Interface Wireless > Physical Layer Properties of Wireless Node 5, Protocol Standard is set to IEEE 802.11g. In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 3000. Medium Access Protocol is set to DCF for all nodes.

Step 3: In the Wired Link Properties, Bit Error Rate and Propagation Delay is set to the default value.

Step 4: In the Wireless Link Properties, Channel Characteristics is set to NO PATH LOSS.

Step 5: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar. A CBR Application is generated from Wired Node 4 i.e., Source to Wireless Node 5 i.e., Destination with Packet Size set to 1450 Bytes and Inter Arrival Time set to 200µs. Transport Protocol is set to UDP.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 100 Mbps. Generation Rate can be calculated using the formula:

$$Generation\ Rate\ (Mbps)\ = \ Packet\ Size\ (Bytes)\ *\ 8/Interarrival\ time\ (µs)$$

Step 6: Run the Simulation for 10 Seconds and note down the throughput.

#### With RTS-CTS#

The following changes in settings are done from the previous sample:

Step 1: In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 1000.

Step 2: Run the Simulation for 10 Seconds and note down the throughput.

### Multiple AP-STA Without RTS-CTS: 2APs#

The following changes in settings are done from the previous sample Figure 11‑6.

{width="5.092533902012248in" height="2.1383366141732285in"}

Figure 11‑6: Network set up for studying the Multiple AP-STA Without RTS-CTS

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 2 Wireless Node, 1 L2 Switch, and 2 Access Points in the "Internetworks" Network Library.

Step 2: In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 3000. Medium Access Protocol is set to DCF for all nodes.

Step 3: Two CBR applications are generated from Wired Node 1 i.e., Source to Wireless Node 4 and Wireless Node 6 i.e., Destination with a Generation Rate of 58 Mbps.

Step 4: Run the Simulation for 10 Seconds and note down the throughput.

Similarly, the subsequent samples are carried out with 3, 4, and 5 Access Points and Wireless Nodes by increasing the number of AP and STA with same PHY and MAC Layer properties set in step 2 and step 3 with applications configured.

### Multiple AP-STA With RTS-CTS: 2APs#

The following changes in settings are done from the previous sample:

Step 1: In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 1000. Medium Access Protocol is set to DCF for all nodes.

Step 2: Run the Simulation for 10 Seconds and note down the throughput.

Similarly, the subsequent samples are carried out with 3, 4, and 5 Access Points and Wireless Nodes.

Note: For the Next sample Newly added devices and links change the properties are per Without RTS/CTS example except RTS Threshold value.

## Output Without and with RTS-CTS#

After running simulation, check throughput in Application metrics as shown in the below screenshot Figure 11‑7.

{width="6.5in" height="3.464646762904637in"}

Figure 11‑7: Results for Single AP-STA

+----------------------+-----------------------+-----------------------+ | Name of Samples | Predicted | Simulated | | | | | | | Throughput | Throughput | | | | | | | (Mbps) | (Mbps) | +======================+=======================+=======================+ | Without RTS-CTS | 28.92 | 29.15 | +----------------------+-----------------------+-----------------------+ | With RTS-CTS | 22.37 | 22.49 | +----------------------+-----------------------+-----------------------+

Table 11‑1:UDP throughput for a single AP-STA, with and without RTS-CTS

## Output Multiple AP-STA Without and with RTS-CTS#

After running simulation, check throughput in Application metrics as shown in the below screenshot Figure 11‑8.

{width="6.5in" height="3.4604166666666667in"}

Figure 11‑8: Results for Multiple AP-STA

+--------+---------+----------+------------+------------+------------+ | | Thr | Th | | Th | Th | | Name | oughput | roughput | Throughput | roughput | roughput | | | ( | (Mbps) | (Mbps) | | | | of | Mbps) | | | (Mbps) | (Mbps) | | | | with 2 | with 3 | | | | Sam | with | APs | APs | with 4 | with 5 | | ples | 1 AP | | | Aps | Aps | +========+=========+==========+============+============+============+ | Mu | App 1: | App 1: | App 1: | App 1: | App 1: | | ltiple | 29.15 | 14.48 | 9.66 | 7.18 | 5.44 | | AP-STA | | | | | | | Basic | | App 2: | App 2: | App 2: | App 2: | | Ac | | 14.36 | 9.43 | 6.89 | 5.28 | | cess | | | | | | | | | Total: | App 3: | App 3: | App 3: | | | | 28.84 | 9.57 | 7.13 | 5.71 | | | | | | | | | | | | Total: | App 4: | App 4: | | | | | 28.65 | 6.98 | 5.76 | | | | | | | | | | | | | Total: | App 5: | | | | | | 28.19 | 5.53 | | | | | | | | | | | | | | Total: | | | | | | | 27.73 | +--------+---------+----------+------------+------------+------------+ | Mu | App 1: | App 1: | App 1: | App 1: | App 1: | | ltiple | 22.49 | 12.00 | 9.36 | 8.20 | 7.40 | | AP-STA | | | | | | | With | | App 2: | App 2: | App 2: | App 2: | | | | 11.85 | 8.02 | 6.51 | 5.32 | | RTS | | | | | | | -CTS | | Total: | App 3: | App 3: | App 3: | | | | 23.85 | 6.78 | 4.91 | 4.54 | | | | | | | | | | | | Total: | App 4: | App 4: | | | | | 24.18 | 4.48 | 3.59 | | | | | | | | | | | | | Total: | App 5: | | | | | | 24.21 | 3.33 | | | | | | | | | | | | | | Total: | | | | | | | 24.18 | +--------+---------+----------+------------+------------+------------+

Table 11‑2: UDP throughput for 2, 3, 4, and 5 AP-STA pairs, with and without RTS-CTS.

## Discussion#

Table 11‑1 shows the AP-STA UDP throughput (predicted and simulated) for a single AP-STA. Table 11‑2 shows the UDP throughputs for 2, 3, 4, and 5 AP-STA pairs; the total throughput is shown along with the individual AP-STA throughputs. We can make the following observations, along with explanations (as bulleted comments) for the observations.

1. The UDP throughput with RTS/CTS turned off is larger than when RTS/CTS is used.

• The reduction in throughput with RTS/CTS is due the RTS/CTS overheads. The RTS/CTS mechanism aims at alerting "hidden" nodes that a transmission is about to start and can reduce collisions if there are hidden nodes. Since in this experiment all nodes can directly hear each other's transmissions, the Basic Access mode suffices, whereas RTS/CTS only adds overhead.
2. In RTS-CTS case, the UDP throughput increases slightly with 2, 3 and 4 AP-STA pairs than with just one.

• With just one AP-STA pair, there is wastage of time due to backoffs, even when there is no possibility of contention. When one more AP-STA is added some of this wastage is compensated by two APs attempting, with the possibility that one of them might finish its backoff early and grab the channel, thus reducing the backoff overhead. There is, of course, the additional time wasted due to collisions, but the balance between these two opposing phenomena is such that there is a small gain in throughput.
3. Further increase in the number AP-STA pairs leads to a decrease in throughput, but the decrease is small.

• The IEEE 802.11 Distributed Coordination Function (DCF) manages the sharing of the Wi-Fi channel in a distributed manner. If there was a centralized scheduler than each AP could be scheduled by turn, without any backoff and collision overheads, and the total throughput would have been just that due to sending UDP packets back-to-back: $\frac{1450 \times 8}{1296} = 8.95\$Mbps. Thus, the total throughput with DCF is smaller than if the UDP packets were being sent back-to-back, about 6 Mbps rather than 8.95 Mbps. However, DCF implements an adaptive attempt rate mechanism, which causes nodes to attempt less aggressively as the number of contending nodes increases. It is this mechanism that prevents the total throughput from dropping steeply as the number of AP-STA pairs increases.
4. The total throughput is distributed roughly equally between the AP-STA pairs.

• This is another feature of DCF. The contending nodes obtain fair access at the packet level, i.e., each successful packet is from any of the contending nodes with equal probability. The downside of this feature is that if an AP-STA is using long packets, then that UDP flow will get a larger throughput. In this experiment, all the AP-STA UDP flows are using the same packet lengths.