Wi-Fi: IEEE 802.11
Wi-Fi: Throughput variation with distance (Level 1)
Introduction
In this experiment we will study how the downlink UDP throughput from an Access Point (AP) and a Station (STA) varies with the distance between these two devices. While the wireless link scheduling mechanism remains the same (as per the standard), the bit rate at which the AP and STA digital transceivers reliably operate depends on the received signal power at the receiver (i.e., the PHY rate), and the noise plus interference at the receiver. In this experiment, since we have only one AP-STA pair, there is no interference. Further, since the STA has no data to send, there is also no contention. Hence, the transfer of UDP packets from the AP to the STA comprises alternating back-off periods at the AP and packet transmission times. The back-off periods are random but from the initial back-off distribution. The transmission times depend on the PHY rate. Thus, effective transmission time will vary as per the following express.
Of the three terms on the right, the third term depends on the AP-STA distance, since the PHY rate decreases for increasing distance. Since we are interested in the packet throughput, we can write:
The above expression is correct only if every packet sent by the AP is correctly decoded by the STA. Even if the PHY rate is correctly chosen so that the SNR at the mean received power renders every packet decodable, in practice, the received power varies randomly due to the phenomenon of shadowing and multipath fading. Due to these phenomena, while the mean received power may be adequate, the actual received power can drop so much that there are packet losses. Although, NetSim can model the phenomenon of shadowing and fading for this experiment we turn this feature off and consider a constant pathloss model.
Simplified pathloss model
The complexity of signal propagation makes it difficult to obtain a single model that characterizes path loss accurately across a range of different environments. For general tradeoff analysis of various system designs it is sometimes best to use a simple model that captures the essence of signal propagation without resorting to complicated path loss models, which are only approximations to the real channel anyway. The following simplified model for path loss as a function of distance is commonly used for system design:
In this approximation, \(P_{r}\) is the received power sometimes called received signal strength (RSS), \(P_{t}\) is the transmit power, \(c_{0}\) is the path loss at the “reference” distance, \(d_{0}\) (usually 1m), \(\eta\) is the path-loss exponent and \(d\) is the distance between the transmitter and the receiver. The dB attenuation is thus
As \(d\ \)increases, the received power decreases, e.g., doubling the distance reduces the received power by approximately \(3\eta\), since \(\log_{10}{2 \approx 0.3}\). Typical values of \(\eta\), indoors, could be 3 to 5, resulting in 9 dB to 15 dB additional path loss for doubling the value of \(d\).
The IEEE 802.11g PHY Rates Table
IEEE 802.11g utilizes OFDM over the entire 20 MHz channel. There are 52 OFDM carriers, of which 48 carriers are used for data transmission and 4 are used for control. The OFDM symbol rate is 250 Ksps. With 48 symbols being sent together (across the 48 carriers), we obtain 12 Msps. In principle, each symbol can be modulated according to any of the modulation and coding schemes (MCS) shown in table 1.
The bit rate shown in the last column of the table assumes the situation in which all the symbols are modulated using the same MCS. Thus, for example, the MCS in the row indexed by 4 uses 16 QAM (i.e., 4 bits per symbol) with a coding rate of 1/2 (i.e., half the bits are data bits, and the rest are channel error protection bits), yielding 2 data bits per symbol, and, therefore, 24 Mbps overall bit rate, assuming that all OFDM symbols use the MCS.
MCS stands for modulation and coding scheme. The MCS defines the numbers of useful bits which can carried by one symbol. In Wi-Fi IEEE 802.11g standard, the MCS depends on the received signal strength (RSS). The higher the signal strength the higher the MCS and more useful bits can be transmitted in a symbol. Thus, the PHY bit rate depends on the MCS chosen. IEEE 802.11g devices can transmit at speeds of 6, 9, 12, 18, 24, 36, 48 and 54Mbps as shown in the table below.
Index |
Rx Sensitivity (dBm) |
Modulation |
Code Rate |
Bit Rate |
|---|---|---|---|---|
0 |
-82 |
BPSK |
\[1/2\]
|
6 Mbps |
1 |
-81 |
BPSK |
\[3/4\]
|
9 Mbps |
2 |
-79 |
QPSK |
\[1/2\]
|
12 Mbps |
3 |
-77 |
QPSK |
\[3/4\]
|
18 Mbps |
4 |
-74 |
16 QAM |
\[1/2\]
|
24 Mbps |
5 |
-70 |
16 QAM |
\[3/4\]
|
36 Mbps |
6 |
-66 |
64 QAM |
\[2/3\]
|
48 Mbps |
7 |
-65 |
64 QAM |
\[3/4\]
|
54 Mbps |
Table-1: 802.11g bit rates for different modulation schemes, and the minimum received signal power for achieving each bit rate.
In the above table, Rx Sensitivity is the minimum RSS. A simulation assumption in NetSim is that the transmitter knows the RSS at the receiver. Thus, the transmitter chooses the MCS by comparing the RSS against the Receiver-Sensitivity for different MCSs. The highest possible MCS is then chosen.
Calculating distances at which the PHY rate changes
In this section, we predict the AP-STA distance thresholds for the different PHY rates. We know that
At 2.4 GHz, \(c_{0}\) is \(40.09\ dB\). For \(P_{t} = 100\ mW\ (20\ dBm)\), \(\eta = 3.5,\) and setting \(P_{r}\) as equal to the receive sensitivity (Ref: Table 5‑1), and we get the following inequality for the 6 Mbps PHY rate
This gives \(54.99m < \ d \leq 58.72\ m.\) Similarly, we compute the AP-PHY distance for all the rates and arrive at the table below
Rx Sensitivity (dBm) |
Bit Rate |
\[\mathbf{d}_{\mathbf{\max}}\mathbf{\ (m)}\]
|
\(\mathbf{d}_{\mathbf{\min}}\mathbf{\ (m}\)) |
|---|---|---|---|
-82 |
6 Mbps |
58.72 |
55.00 |
-81 |
9 Mbps |
54.99 |
48.22 |
-79 |
12 Mbps |
48.21 |
42.28 |
-77 |
18 Mbps |
42.27 |
34.69 |
-74 |
24 Mbps |
34.68 |
26.68 |
-70 |
36 Mbps |
26.67 |
20.52 |
-66 |
48 Mbps |
20.50 |
19.20 |
-65 |
54 Mbps |
19.19 |
1.00 |
Table-2: We see the maximum and minimum AP-STA distances for different 801.11g PHY bit rates. The PHY rate is 0 for \( \mathbf{d \geq 58.72m} \). We have chosen \( \mathbf{P_t = 100\,mW} \) and \( \mathbf{\eta = 3.5} \).
Table-2 can be visualized as shown below.
Figure-1: Illustration of variation in AP data (PHY) rate vs. distance for \( \mathbf{P_t = 100\,mW} \) and \( \mathbf{\eta = 3.5} \).
Predicting the throughput
From the experiment Wi-Fi-UDP-Download-Throughput we know that application throughput, \(\theta\) is
Therefore,
In the above formula \(\theta\) is in Mbps as the time in the denominator is in \(\mu s\).
The predicted application throughput for a 1450B packet, with 68B overheads, ACK size of 14B, and PHY Rate of 54 Mbps is
Doing the same computation for the different PHY rates leads to the following application throughput predictions. Users just need to replace 54 in the above equation with the appropriate PHY rate.
PHY rate (Mbps) |
Predicted Application Throughput (Mbps) |
|---|---|
54 |
28.92 |
48 |
27.02 |
36 |
22.59 |
24 |
17.00 |
18 |
13.63 |
12 |
9.76 |
9 |
7.60 |
6 |
5.27 |
Table-3: Predicted application throughput for various PHY rates
In the following section we create scenarios with varying AP-STA distances in NetSim, model the same pathloss equation and compare simulation results against predictions.
Network Setup
Open NetSim and click on Experiments> Internetworks> Wi-Fi> Wi-Fi Throughput variation with distance then click on the tile in the middle panel to load the example as shown in below Figure-2.
Figure-2: List of scenarios for the example of Impact of distance on Wi Fi throughput
NetSim UI displays the configuration file corresponding to this experiment as shown below in Figure-3.
Figure-3: Network set up for studying the Impact of distance on Wi-Fi throughput
Procedure
The following set of procedures were done to generate this sample.
Step 1: A network scenario is created in NetSim GUI comprising of 1 Wired Node, 1 Router, 1 Access Point and 1 Wireless Node in the “Internetworks” Network Library.
Step 2: In Access Point and Wireless Node 4, the Interface 1 (WIRELESS) > Physical Layer, Protocol Standard is set to IEEE802.11g and in the Interface 1 (WIRELESS) > Datalink Layer, Rate Adaptation is set to False.
To configure any properties in the nodes, click on the node, expand the property panel on the right side, and change the properties as mentioned above.
Step 3: The position of the Wireless Node and the Access Point in the grid environment is set according to the values given in the below table see Table-4. The properties are configured in position layer of device properties.
Device Positions |
||
|---|---|---|
Wireless Node 4 |
Access Point |
|
X |
60 |
60 |
Y |
20 |
10 |
Table-4: Device Positions
Step 4: Click on Wireless node and expand the property panel on the right, set the media access protocol to DCF in datalink layer of Interface (Wireless) layer. Similarly, set the same in Access point.
Step 5: Click on the link and expand property panel on right and parameters are set according to the values given in the below Table-5/Table-6.
Wireless Link Properties |
|
|---|---|
Channel Characteristics |
Path Loss Only |
Path Loss Model |
Log Distance |
Path Loss Exponent |
3.5 |
Table-5: Wireless Link Properties
Wired Link Properties |
|
|---|---|
Max Uplink Speed (Mbps) |
100 |
Max Downlink Speed (Mbps) |
100 |
Uplink BER |
0 |
Downlink BER |
0 |
Uplink Propagation Delay (µs) |
0 |
Downlink Propagation Delay (µs) |
0 |
Table-6: Wired Link properties
Step 6: Configure CBR application from Wired Node 2 i.e., Source to Wireless Node 4 i.e., Destination by clicking on the set traffic tab from the ribbon at the top. Click on created application and expand the property panel on right and set packet size to 1450 Bytes, inter arrival time to 200 µs, and transport protocol is set to UDP.
Step 7: Packet Trace is enabled from Configure Reports tab in NetSim GUI. At the end of the simulation, a large .csv file contains all the packet information and is available for the users to perform packet level analysis.
Step 8: Run simulation for 10 sec.
Go back to the scenario and change the distance between Access Point and Wireless Node (i.e., Change the Y axis of Wireless Node (STA)) as 20, 25, 30, 35, 45, 50, 55 and 60 in position layer.
Simulation Output
Data rate can be calculated from packet trace by using the formula given below:
\(20\mu s\ \)is the preamble time for 802.11g.
Given below are the steps to calculate the PHY rate for a 10m AP-STA distance of STA using the packet trace.
Step 1: Make sure that the packet trace is enabled before the simulation, and then run the simulation for a desired time.
Step 2: Click on ‘Packet Trace’.
Step 3: Filter CONTROL PACKET TYPE/APP NAME as App1 CBR (Only data packets) and TRANSMITTER ID as ACCESSPOINT-3 (Only wireless channel).
Step 4: Add a column ‘Phy Rate (Mbps)’ after PHY LAYER PAYLOAD(Bytes)
Step 5: Add formula in the first cell of newly added column.
=([@[PHY_LAYER_PAYLOAD(Bytes)]]*8)/([@[PHY_LAYER_END_TIME(US)]]-[@[PHY_LAYER_ARRIVAL_TIME(US)]]-20)
Step 6: We get the Phy Rate as 54Mbps. (The column Phy Rate is formatted to zero decimal places)
Figure-4: Calculating the Phy Rate using its formula in packet trace.
Results
Simulation results with PHY rates and application throughputs are tabulated in Table-7.
802.11g PHY rate and Application Throughput Comparison |
|||||
|---|---|---|---|---|---|
\(\mathbf{d}_{\mathbf{\min}}\mathbf{-}\mathbf{d}_{\mathbf{\max}}\) (m) |
Sample Distance (m) |
PHY rate NetSim (Mbps) |
PHY Rate Predicted (Mbps) |
Application Throughput NetSim (Mbps) |
Application Throughput Predicted (Mbps) |
0 - 19.19 |
10 |
54 |
54 |
29.15 |
28.92 |
19.20 - 20.50 |
20 |
48 |
48 |
27.24 |
27.02 |
20.51 – 26.67 |
25 |
36 |
36 |
22.71 |
22.59 |
26.68 – 34.68 |
30 |
24 |
24 |
17.09 |
17.00 |
34.69 – 42.27 |
40 |
18 |
18 |
13.68 |
13.63 |
42.28 – 48.21 |
45 |
12 |
12 |
9.79 |
9.76 |
48.22 – 54.99 |
50 |
9 |
9 |
7.61 |
7.60 |
55.00 – 58.71 |
57 |
6 |
6 |
5.28 |
5.27 |
Beyond 58.72 |
60 |
0 |
0 |
0 |
0 |
Table-7: We see how PHY rate, Application Throughput varies with AP-STA distance
Figure-5: Data Rate vs. Distance
Figure-6: Application Throughput vs. Distance
Discussion
It is interesting to note that for 54Mbps PHY rate the application throughput is 29.21 Mbps, which is about 54.1% of the PHY rate. However, for 6 Mbps PHY rate the application throughput is 5.28 Mbps which is 88% of the PHY rate. Why is this so?
Let us go back to the average time per packet – the denominator of the throughput expression - which is
Per the 802.11g standards the 14 Byte MAC ACK is always sent at the control rate or \(PHYRate_{\min}\) which is 6 Mbps. Therefore, all terms in the above expression except \(\frac{{(L}_{pkt} + OH) \times 8}{PHYRate}\) do not vary with the PHY rate.
We observe that, since all the “overheads” do not decrease with PHY rate, the lower PHY rates are more “efficient” than the higher PHY rates. This motivates the aggregation of packets in the newer standards (11n, 11ac, etc.), so that the fixed overheads are amortized over substantial number of data bits.
Conclusion
To summarize, we understood the log distance pathloss model and saw how Wi-Fi PHY rates and Application throughputs vary with AP-STA distance. Then we predicted the Wi-Fi PHY rate and application throughputs. Simulation results show excellent agreement with theory.
References
Some of the theoretical content is from the books (i) Wireless Communications by Andrea Goldsmith, and (ii) Wireless Networking by Anurag Kumar.
Exercises
Keeping other variables fixed, change the transmit power \({(P}_{t})\) to a different value. Predict \(d\) for different PHY rates. Compare against simulation
Keeping other variables fixed, change the pathloss exponent \(\eta\) (generally, in the range of 2 to 5). Predict \(d\) for different PHY rates. Compare against simulation.
Keeping other variables fixed, change the packet size \(L_{pkt}\) (from between 100B to 1460B). Take care to ensure the generation rate is sufficiently high to ensure full buffers (saturation) at the transmitting node. Predict \(\theta\) for different PHY rates. Compare against simulation
Wi-Fi: UDP Download Throughput (Level 1)
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 Wi-Fi Stations (STA), via Wi-Fi Access Points (AP). The schematic of the network that we will be simulating in NetSim is shown in the figure below Figure-7.
Figure-7: 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 many 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, 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:
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.
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 5 8, 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-8.
Figure-8: Detailed view of transmission of a single packet in Wi-Fi 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
With RTS-CTS
Multiple APs (near each other) and one STA per AP
Since the AP queues are full, on the Wi-Fi medium the packet transmission can still be viewed as being back-to-back as shown in the upper part of the figure.
Figure-9. 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-8).
Figure-9: Detailed view of transmission of a single packet in Wi-Fi involving Multiple AP-STA
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.
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.
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 1/N of the total throughput.
Network Setup
Open NetSim and click on Experiments> Internetworks> Wi-Fi> Wi-Fi UDP Download Throughput then click on the tile in the middle panel to load the example as shown in below Figure-10.
Figure-10: 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.
Figure-11: 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 4, 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: Configure a CBR application from Wired Node 1 (Source) to Wireless Node 4 (Destination). Click on the created application, expand the property panel on the right, and set the packet size to 1450 bytes, the inter-arrival time to 200 µs, and the transport protocol to UDP.
The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 58 Mbps. Generation Rate can be calculated using the formula:
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-12.
Figure-12: 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-13.
Figure-13: Results for Single AP-STA
Name of Samples |
Predicted Throughput (Mbps) |
Simulated Throughput (Mbps) |
|---|---|---|
Without RTS-CTS |
28.92 |
29.15 |
With RTS-CTS |
22.37 |
22.49 |
Table-8:UDP throughput for a single AP-STA, with and without RTS-CTS
Output of Multiple AP-STA Without and with RTS-CTS
After running simulation, check throughput in Application metrics as shown in the below screenshot Figure-14.
Figure-14: Results for Multiple AP-STA
Name of Samples |
Throughput (Mbps) with 1 AP |
Throughput (Mbps) with 2 APs |
Throughput (Mbps) with 3 APs |
Throughput (Mbps) with 4 APs |
Throughput (Mbps) with 5 APs |
|---|---|---|---|---|---|
Multiple AP-STA Basic Access |
App 1: 29.15 |
App 1: 14.48 App 2: 14.36 Total: 28.84 |
App 1: 9.67 App 2: 9.43 App 3: 9.49 Total: 28.59 |
App 1: 7.18 App 2: 6.89 App 3: 7.13 App 4: 6.98 Total: 28.19 |
App 1: 5.44 App 2: 5.28 App 3: 5.71 App 4: 5.76 App 5: 5.53 Total: 27.73 |
Multiple AP-STA With RTS-CTS |
App 1: 22.49 |
App 1: 12.00 App 2: 11.85 Total: 23.85 |
App 1: 9.36 App 2: 8.02 App 3: 6.78 Total: 24.18 |
App 1: 8.20 App 2: 6.51 App 3: 4.91 App 4: 4.58 Total: 24.21 |
App 1: 7.45 App 2: 5.44 App 3: 4.37 App 4: 3.82 App 5: 3.09 Total: 24.17 |
Table-9: UDP throughput for 2, 3, 4, and 5 AP-STA pairs, with and without RTS-CTS.
Discussion
Table-8 shows the AP-STA UDP throughput (predicted and simulated) for a single AP-STA. Table-9 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.
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.
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.
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}{244.88} = 47.37\ \)Mbps. Thus, the total throughput with DCF is smaller than if the UDP packets were being sent back-to-back, about 28 Mbps rather than \(47.37\ \)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.
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.
How many downloads can a Wi-Fi access point simultaneously handle?(Level 2)
Motivation
Wi-Fi has become the system of choice for access to Internet services inside buildings, offices, malls, airports, etc. In order to obtain access to the Internet over Wi-Fi a user connects his/her mobile device (a laptop or a cellphone, for example) to a nearby Wi-Fi access point (AP). A popular use of such a connection is to download a document, or a music file; in such an application, the user’s desire is to download the file as quickly as possible, i.e., to get a high throughput during the download. It is a common experience that as the number of users connected to an AP increase, the throughput obtained by all the users decreases, thereby increasing the time taken to download their files. The following question can be asked in this context.
If during the download, a user expects to get a throughput of at least \(\theta\) bytes per second, what is the maximum number of users (say, \(n_{\theta})\ \)up to which the throughput obtained by every user is at least \(\theta.\) We can say that \(n_{\theta}\) is the capacity of this simple Wi-Fi network for the Quality of Service (QoS) objective \(\theta\).
Objective
In this experiment we will learn how to obtain n_θ in a simple Wi-Fi network where the packet loss due to channel errors is 0. In this process we will understand some interesting facts about how Wi-Fi networks perform when doing file transfers.
Theory
In NetSim, we will set up a network comprising a server that carries many large files that the users would like to download into their mobile devices. The server is connected to a Wi-Fi AP, with the IEEE 802.11b version of the protocol, via an Ethernet switch. Several mobile devices (say, N) are associated with the AP, each downloading one of the files in the server. The Ethernet speed is 100Mbps, whereas the mobile devices are connected to the AP at 11Mbps, which is one of the IEEE 802.11b speeds.
We observe, from the above description, that the file transfer throughputs will be limited by the wireless links between the AP and the mobile devices (since the Ethernet speed is much larger than the Wi-Fi channel speed). There are two interacting mechanisms that will govern the throughputs that the individual users will get:
The Wi-Fi medium access control (MAC) determines how the mobile devices obtain access to the wireless medium. There is one instance of the Wi-Fi MAC at each of the mobile devices.
The end-to-end protocol, TCP, controls the sharing of the wireless bandwidth between the ongoing file transfers. In our experiment, there will be one instance of TCP between the server and each of the mobile devices.
For simplicity, the default implementation of TCP in NetSim does not implement the delayed ACK mechanism. This implies that a TCP receiver returns an ACK for every received packet. In the system that we are simulating, the server is the transmitter for all the TCP connections, and each user’s mobile device is the corresponding receiver.
Suppose each of the \(N\) TCP connection transmits one packet to its corresponding mobile device; then each mobile device will have to return an ACK. For this to happen, the AP must send \(N\) packets, and each of the \(N\ \)mobile devices must send back \(N\) ACKs. Thus, for the file transfers to progress, the AP needs to \(N\) packets for each packet (i.e., ACK) returned by each mobile device. We conclude that, in steady state, the AP must send as many packets as all the mobile devices send, thus requiring equal channel access to the AP as to all the mobile devices together.
At this point, it is important to recall that when several nodes (say, an AP and associated mobile devices) contend for the channel, the Wi-Fi medium access control provides fair access at the packet level, i.e., each contending device has an equal chance of succeeding in transmitting a packet over the channel. Now consider the system that we have set up in this present experiment. There are \(N\) mobile devices associated with one AP. Suppose, for example, \(10\ \) of them (\(N \geq 10)\) all have a packet to transmit (and none other has a packet). By the fair access property of the Wi-Fi MAC, each of these \(10\) nodes, along with the AP, has an equal probability of successfully transmitting. It follows, by the packet level fair access property, that each node will have a probability of \(\frac{1}{11}\ \)of succeeding in transmitting its packet. If this situation continues, the channel access ratio to the AP will be inadequate and the equal channel access argued in the previous paragraph will be violated. It follows from this that, on the average, roughly only one mobile device will have an ACK packet in it; the AP will contend with one other node, thus getting half the packet transmission opportunities.
With the just two nodes contending, the collision probability is small (~ 0.06) and the probability of packet discard is negligibly small. Thus, the TCP window for every transfer will grow to the maximum window size. The entire window worth of TCP data packets for the \(N\ \)sessions will be in the AP buffer, except for a very small number of packets (averaging to about 1) which will appear as ACKs in the mobile devices.
It follows that, in steady state, the system will look like two contending Wi-Fi nodes, one with TCP data packets and the other with TCP ACK packets. This will be the case no matter how many downloading mobile devices there are. The total throughput can be obtained by setting up the model of two saturated nodes, one with TCP data packets, and the other with TCP ACK packets. The data packets of all the TCP connections will be randomly ordered in the AP buffer, so that the head-of-the-line packet will belong to any particular mobile device with probability \(\frac{1}{N}.\ \)This throughput is shared equally between the \(N\) mobile devices.
Now suppose that the TCP data packet throughput with the two-node model is \(\Theta\). Then
where the \(\lfloor x\rfloor\) denotes the largest integer less than or equal to \(x.\) Use NetSim to verify that for an 11Mbps Wi-Fi speed, with RTS/CTS enabled the total TCP throughput is 3.4 Mbps. If \(\theta = 0.65\ Mbps\), then \(n_{\theta} = \left\lfloor \frac{3.4}{0.65} \right\rfloor = 5.\ \)In this example, if \(N = 5\) the download throughput obtained by each of them will be \(0.68Mbps,\ \)but if one more downloading device is added then each will get a throughput less than \(\theta = 0.65\ Mbps\). We say that the capacity of this network for a target throughput of \(0.65Mbps\) is 5.
Network Setup
Open NetSim and click on Experiments>Internetworks> Wi-Fi> How many downloads can a Wi-Fi access point simultaneously handle? then click on the tile in the middle panel to load the example as shown in below Figure-15.
Figure-15: List of scenarios for the example of How many downloads can a Wi-Fi access point simultaneously handle
NetSim UI displays the configuration file corresponding to this experiment Figure-16.
Figure-16: Network set up for studying the Wi-Fi Network with Single TCP Download
Procedure
1-WN-1AP
The following set of procedures were done to generate this sample.
Step 1: A network scenario is designed in the NetSim GUI comprising of 1 Wired Node, 1 Wireless Node, 1 Access Point, and 1 Router in the “Internetworks” Network Library.
Step 2: Click on the wireless node, expand the property panel on the right, go to the data link layer of the interface (wireless), and set the short retry limit to 7, the long retry limit to 4, the RTS threshold to 1000 bytes, and the medium access protocol to DCF, as shown in Figure 5 17.Similarly, set the same properties in the access point.
Figure-17: Data Link Layer Properties
Step 3: Click on the link and expand the link properties on the right and set the below properties.
Wired Link |
|
|---|---|
Max Uplink Speed (Mbps) |
100 |
Max Downlink Speed (Mbps) |
100 |
Uplink BER |
0 |
Downlink BER |
0 |
Uplink Propagation Delay (µs) |
0 |
Downlink Propagation Delay (µs) |
0 |
Table-10: Wired link properties
Wireless Link |
|
|---|---|
Channel Characteristics |
No path loss |
Table-11: Wireless Link properties.
Step 4: Configure FTP application between Wired node 2 and Wireless node 4 by clicking on the set traffic tab from the ribbon on the top. Click on the created application and expand the property panel on right and set the File Size set to 10,000,000 Bytes and Inter Arrival Time set to 20 s.
Step 5: Run the Simulation for 15 Seconds and note down the throughput.
5WN-1AP
The following changes in settings are done from the previous sample:
Step 1: The number of Wireless Nodes is increased to 5 and FTP applications are generated from Wired Node 2 to each of the Wireless Nodes as shown below Figure-18.
No. of wireless nodes = 5
Figure-18: Wi-Fi Network with Multiple TCP Download
Application Properties
Properties |
App1 |
App2 |
App3 |
App4 |
App5 |
|---|---|---|---|---|---|
Application Type |
FTP |
FTP |
FTP |
FTP |
FTP |
Source Id |
1 |
1 |
1 |
1 |
1 |
Destination Id |
4 |
5 |
6 |
7 |
8 |
File size (Bytes) |
10,000,000 |
10,000,000 |
10,000,000 |
10,000,000 |
10,000,000 |
File Inter arrival time |
20 s |
20 s |
20 s |
20 s |
20 s |
Table-12: Detailed Application properties
Step 2: Run the Simulation for 15 Seconds and note down the throughput.
NOTE: Follow the same procedure for next samples with wireless nodes 10, 15, 20, 25 and note down the sum of throughputs for all applications.
Measurements and Output
Aggregated download throughput with different values of N (wireless nodes) is shown below Table-13.
Samples Name |
Number of Devices |
Sum of throughputs (Mbps) |
Throughput Per Device (Mbps) |
|---|---|---|---|
1-WN-1AP |
1 |
3.55 |
3.55 |
5-WN-1AP |
5 |
3.55 |
0.71 |
10-WN-1AP |
10 |
3.55 |
0.35 |
15-WN-1AP |
15 |
3.54 |
0.23 |
20-WN-1AP |
20 |
3.53 |
0.17 |
25-WN-1AP |
25 |
3.51 |
0.14 |
Table-13: Aggregated download throughput for different number of wireless nodes
Plot
Figure-19: Plot of Number of devices vs. Throughputs (Mbps)
NOTE: In the referred paper we see that, a throughput value for 11 Mbps WLAN is 3.8 Mbps. Please note that this is the aggregate PHY throughput of the AP. However, in NetSim, we are calculating the total Application throughput.
To derive the PHY layer throughput from the APP layer throughput, we need to add overheads of all layers observe Table-14.
Layer |
Overhead (Bytes) |
|---|---|
Transport Layer |
20 |
Network Layer |
20 |
MAC Layer |
40 |
PHY layer |
48µs = (11*48)/8 = 66 |
Total Overhead |
146 |
Table-14: Overhead of different layers
Observations
We see that as the number of devices increase, the aggregate (combined) throughput remains constant, whereas the throughput per user decreases.
As discussed earlier, our goal was to identify that if during the download, a user expects to get a throughput of at least \(\theta\) bytes per second, what is the maximum number of users (say, \(n_{\theta})\)?
If we set \(\theta\) to be 650 Kbps, then we see that from the output table that the maximum number of users who can simultaneously download files is 5 \({(n}_{\theta})\)
Reference Documents
Analytical models for capacity estimation of IEEE 802.11 WLANs using DCF for internet applications. George Kuriakose, Sri Harsha, Anurag Kumar, Vinod Sharma.
Multi-AP Wi-Fi Networks: Channel Allocation (Level 2)
Introduction
A single Wi-Fi Access Point (AP) can connect laptops and other devices that are a few meters distance from the AP, the actual coverage depending on the propagation characteristics of the building in which the Wi-Fi network is deployed. Thus, for large office buildings, apartment complexes, etc., a single AP does not suffice, and multiple APs need to be installed, each covering a part of the building. We will focus on 2.4GHz and 5GHz systems. In each of these systems the available bandwidth is organized into channels, with each AP being assigned to one of the channels. For example, 2.4GHz Wi-Fi systems operate in the band 2401MHz to 2495MHz, which has 14 overlapping channels each of 22MHz. There are 3 nonoverlapping channels, namely, Channels 1, 6, and 11, which are centered at 2412MHz, 2437MHz, and 2462MHz. Evidently, if neighboring APs are assigned to the same channel or overlapping channels they will interfere, thereby leading to poor performance. On the other hand, since there are only three nonoverlapping channels, some care must be taken in assigning channels to APs so that nearby APs have nonoverlapping channels, whereas APs that are far apart can use the same or overlapping channels.
In this experiment we will understand some basic issues that arise in multi-AP networks, particularly with attention to channel allocation to the APs.
Network Setup
Open NetSim and click on Experiments>Internetworks> Wi-Fi> Multi AP Wi-Fi Networks Channel Allocation> APs on the Same channel then click on the tile in the middle panel to load the example as shown in below
Figure-20: List of scenarios for the example of Multi AP Wi-Fi Networks Channel Allocation
NetSim UI displays the configuration file corresponding to this experiment as shown below Figure-21.
APs in the same channel
Figure-21: Network set up for studying the Multiple APs-Wi-Fi Networks with APs in same Channel -Interfering-I
Interfering-I: The following set of procedures were done to generate this sample:
Step 1: Environment Grid length: 40m x 20m.
Step 2: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 1 L2 Switch, 3 Wireless Nodes and 3 Access Points in the “Internetworks” Network Library.
Step 3: The device positions are set as per the table given below Table-15.
General Properties |
||
|---|---|---|
Device Name |
X / Lon |
Y / Lat |
AP 3 |
15 |
5 |
AP 4 |
15 |
10 |
AP 5 |
15 |
15 |
Wireless Node 6 |
20 |
5 |
Wireless Node 7 |
20 |
10 |
Wireless Node 8 |
20 |
15 |
Table-15: Device positions for APs-STA - Interfering-I
Step 4: In the INTERFACE (WIRELESS) > PHYSICAL LAYER Properties of all the Wireless Nodes and Access Points, the Protocol Standard is set to IEEE 802.11 b. In the INTERFACE (WIRELESS) > DATALINK LAYER Properties of all the Wireless Nodes and Access Points, Medium Access Protocol is set to DCF.
Step 5: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. For all the Wired Links, Bit Error Rate and Propagation Delay is set to 0.
Step 6: The Wireless Link Properties are set according to the values given in the below Table-16.
Channel Characteristics |
PATH LOSS ONLY |
|---|---|
Path Loss Model |
LOG DISTANCE |
Path Loss Exponent |
3.5 |
Table-16: Wireless Link Properties
Step 7: Configure the application between any two nodes by selecting an application from the Set Traffic tab. Right click on the Application and select properties.
A CBR Application is generated from Wired Node 1 i.e., Source to Wireless Node 6 i.e., Destination with Packet Size set to 1460 Bytes and Inter Arrival Time set to 1168µs.
Transport Protocol is set to UDP instead of TCP.
The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 10 Mbps. Generation Rate can be calculated using the formula:
Similarly, two more CBR applications are generated from Wired Node 1 to Wireless Node 7 and Wired Node 1 to Wireless Node 8.
No Interfering: The following changes in settings are done from the previous sample:
Step 1: Before we start designing the network scenario, the Grid Length is set to 1000m x 500 m. This can be set by choosing the Menu Options>Change Grid/Map settings>Grid/Map settings from the GUI.
Step 2: From the previous sample, we have removed App2 CBR (i.e., from Wired Node1 to Wireless Node7), set distance between the other 2 Access Points (AP 1 and AP 3) as 400m and distance between APs and Wireless nodes as 10m as shown below Figure-22.
Figure-22: Network set up for studying the Multiple APs-Wi-Fi Networks with APs in same Channel No-Interfering
Step 3: The device positions are set according to the table given below Table-17.
General Properties |
||
|---|---|---|
Device Name |
X / Lon |
Y / Lat |
AP 3 |
400 |
0 |
AP 4 |
400 |
200 |
AP 5 |
400 |
400 |
Wireless Node 6 |
410 |
0 |
Wireless Node 7 |
410 |
200 |
Wireless Node 8 |
410 |
400 |
Table-17: Device positions for APs-STA – No Interfering
Interfering-II: The following changes in settings are done from the previous sample:
Step 1: From the previous sample, Add App2 CBR (i.e., from Wired Node1 to Wireless Node7), The distance between the Access Points (AP 1 and AP 3) is set to 400m and distance between APs and Wireless nodes as 10m as shown below Figure-23.
Figure-23: Network set up for studying the Multiple APs-Wi-Fi Networks with APs in same Channel Interfering-II
Step 2: The device positions are set according to the table given below Table-18.
General Properties |
||
|---|---|---|
Device Name |
X / Lon |
Y / Lat |
AP 3 |
400 |
120 |
AP 4 |
400 |
200 |
AP 5 |
400 |
280 |
Wireless Node 6 |
420 |
120 |
Wireless Node 7 |
420 |
200 |
Wireless Node 8 |
420 |
280 |
Table-18: Device positions for APs-STA - Interfering-II
Interfering-III: The following changes in settings are done from the previous sample:
Step 1: From the previous sample, we have removed App1 CBR (i.e., from Wired Node 1 to Wireless Node 6), set distance between the other 2 Access Points (AP 2 and AP 3) as 200m and distance between APs and Wireless nodes as 10m as shown below Figure-24.
Figure-24: Network set up for studying the Multiple APs-Wi-Fi Networks with APs in same Channel Interfering - III
Step 2: The device positions are set according to the table given below Table-19.
General Properties |
||
|---|---|---|
Device Name |
X / Lon |
Y / Lat |
AP 3 |
400 |
85 |
AP 4 |
400 |
135 |
AP 5 |
400 |
185 |
Wireless Node 6 |
420 |
85 |
Wireless Node 7 |
420 |
135 |
Wireless Node 8 |
420 |
185 |
Table-19: Device positions for APs-STA – Interfering III
No Interfering-I: The following changes in settings are done from the previous sample:
Step 1: From Interfering-II, we have removed first, and third applications as shown below Figure-25.
Figure-25: Network set up for studying the Multiple APs-Wi-Fi Networks with APs in same Channel No Interfering-I
Step 2: The device positions are set according to the table given below Table-20.
General Properties |
||
|---|---|---|
Device Name |
X / Lon |
Y / Lat |
AP 3 |
400 |
0 |
AP 4 |
400 |
200 |
AP 5 |
400 |
400 |
Wireless Node 6 |
410 |
0 |
Wireless Node 7 |
410 |
200 |
Wireless Node 8 |
410 |
400 |
Table-20: Device positions for APs-STA - No Interfering-I
APs on the different channel: The following changes in settings are done from the previous sample:
Step 1: From previous sample, we have changed standard channel to 11_2462 under INTERFACE (WIRELESS) >PHYSICAL LAYER Properties of AP 2.
Output
After running simulation, check throughput in Application metrics as shown in the below screenshot Figure-26.
Figure-26: Application Metrics Table in Result window
Sample |
Throughput (Mbps) |
||
|---|---|---|---|
AP1 |
AP2 |
AP3 |
|
All APs in the same channel |
|||
Interfering-I |
2.09 |
2.06 |
2.00 |
No Interfering |
5.94 |
N/A |
5.92 |
Interfering-II |
5.50 |
0.03 |
5.46 |
Interfering-III |
N/A |
3.08 |
3.05 |
No Interfering-I |
N/A |
5.92 |
N/A |
Each AP in a different nonoverlapping channel |
|||
Different channel |
5.94 |
5.92 |
5.92 |
Table-21: Throughput for APs on the Same and different Channels
NOTE: Please refer “Wi-Fi UDP Download Throughput” experiment for theoretical WLAN throughput calculations in NetSim Experiment Manual.
Discussion
We recall that each AP is associated with one station (STA; e.g., a laptop). All the APs are connected to the same server which is sending separate UDP packet streams to each of the STAs via the corresponding AP. The packet transmission rate from the server is large enough so that the AP queue in permanently backlogged, i.e., the rate at which the server transmits packets is larger than the rate at which the AP can empty the packet queue.
All APs in the same channel
Interfering-I: All the APs and their associated STAs are close together, so that all devices (APs and STAs) can sense every other device.
The table shows that all the AP-STA links achieve the same UDP throughput. This is because all the AP-STA links are equivalent (since all interfere with each other), and only one can be active at one time. The throughput for this scenario can be predicted from the analysis in Section 7.4 of the book Wireless Networking by Anurag Kumar, D. Manjunath and Joy Kuri.
No Interfering: AP1 and AP3 are close to their associated STAs but are 400m apart. The link from AP2 to its STA is half-way between the other two APs and is not carrying any traffic.
The table shows that both the links from AP1 and AP3 to their respective STAs carry the same throughput, of 5.94Mbps and 5.92Mbps. These are also the throughputs that each link would have if the other was not present, indicating that the two links are far enough apart that they do not interfere.
Interfering-II: This is the same scenario as No Interfering, but the AP2-STA link is now carrying traffic.
We find that, in comparison with No Interfering, the AP1-STA and AP3-STA carry slightly lower throughputs of about 5.21Mbps, whereas the AP2-STA link carries a small throughput of 0.92Mbps. Comparing Interfering-I and II we conclude that in these networks there can be severe unfairness depending on the relative placement of the AP-STA links. In Interfering-I, all the links could sense each other, and each got a fair chance. In Interfering-II, we have what is called the “link-in-the-middle problem.” The AP2-STA link is close enough to interfere with the AP1-STA link and the AP3-STA link, whereas the AP1-STA link and the AP3-STA link do not “see” each other. The AP2-STA link competes with the links on either side, whereas the other links compete only with the link in the center, which thereby gets suppressed in favour of the outer links.
Interfering-III: Here we stop the traffic to AP1 but send the traffic to the AP2-STA link and the AP3-STA link.
The two active links interfere with each other, but the situation is symmetric between them (unlike in Interfering-II), and they obtain equal throughput. Again, the throughput obtained by these two links can be predicted by the analysis mentioned earlier in this section.
No Interfering-I: Now we send traffic only to AP2.
The throughput is now 5.92Mbps, since the AP2-STA link can transmit without interference; there are no collisions. The reason that this throughput is less than the sum of the two throughputs in Interfering-III is that the single link acting by itself, with all the attendant overheads, is unable to occupy the channel fully.
Each AP in a different nonoverlapping channel
There is only one case here. Having observed the various situations that arose in the previous subsection when all the APs are in the same channel, now we consider the case where all the AP-STA pairs are each on a different nonoverlapping channel. As expected, every AP-STA pair gets the same throughput as when they are alone on the network.
Wi-Fi Multimedia Extension (IEEE 802.11 EDCA) (Level 3)
Introduction
In this experiment, we will study an enhancement to Wi-Fi that enables APs and STAs to handle various packet flows in such a way so as to provide differentiated quality of service (QoS) to these flows. In the original Wi-Fi standard (IEEE 802.11 DCF), every device in the network has one output buffer (queue) for all packets to be transmitted onto the wireless channel. The consequence of this would be that a packet stream with strict delivery constraints and another will relatively loose delivery objectives are queued in the same output buffer at every device. Each such queue is scheduled by the DCF CSMA/CA (see the experiment “Wi-Fi: UDP Download Throughput”), and when a queue gets its transmission opportunity the first (head-of-the-line (HOL)) packet is transmitted. This might result in packets with strict delivery constraints being kept waiting, while other, less urgent, packets get transmitted.
For example, an interactive voice call might have 200-byte packets being transmitted periodically, with a period of 20 ms. Ideally, for perfect voice playout at the receiver, this voice stream must arrive exactly as it was transmitted: every 200-byte packet must arrive, and with the gaps of 20 ms intact. If the voice packets are delayed excessively, or if the delay is highly variable, the playout is affected, and voice quality (and speaker interaction) is affected. On the other hand, TCP controlled file transfers can adapt to network delay and delay variability. Evidently, the solution is to create multiple output buffers in each device, of different transmit priorities, queue the more urgent packets in higher priority buffers, and create a mechanism for preferential transmission of the packets with tighter QoS requirements.
In this experiment we will study the EDCAF mechanism, an extension to DCF, which implements service differentiation in Wi-Fi.
EDCAF: Access Categories
In the year 2005, the standard IEEE 802.11e (EDCAF-Enhanced Distributed Channel Access Function) was introduced, with the above issues in mind. In EDCAF, there are four Access Categories (AC0, AC1, AC2, and AC3), with AC3 being the highest priority and AC0 being the lowest. The assignment of application usage to these ACs was
Access Category |
Application |
Example |
|---|---|---|
AC0 |
Background |
Background print job |
AC1 |
Best Effort |
TCP File Transfer |
AC2 |
Video |
Video Conference Video |
AC3 |
Voice |
Video Conference Voice |
Table-22: EDCA 4 access categories for 802.11 both AP and STA
Now, if a device (an AP or a STA) is sending interactive voice packets then these packets can be queued in the AC3 buffer of the device, whereas packets of a simultaneous TCP file transfer can be queued in the AC1 buffer. The human brain is less sensitive to video packet losses, and delays in the rendering of video frames (than the human hearing system is of voice corruption), hence video is given a priority between voice and TCP. The lowest category, AC0, can be used for any application whose packets need to just be delivered, without any well-defined quality of service, for example, a low urgency bulk printing service.
Having created buffers into which the various priority packets are queued, a mechanism is needed to schedule transmissions from these buffers so that service differentiation is achieved. Ideally, strict priority service could be enforced, i.e., assuming that there is only AC3 and AC2 traffic in the network, if any device has a nonempty AC3 buffer, all packets from AC3 category should be served before any AC2 traffic is served. Further, ideally, the video and the TCP file transfers could have been assigned a guaranteed service rate, to meet their QoS requirements. Such strict priorities and guaranteed service would belong to the concept of Integrated Services. However, the IEEE 802.11 wireless access mechanism is distributed, and there is no central entity that has the instantaneous state of all the buffers in all the devices. Hence, strict priority or a guaranteed service rate is not possible to. Instead, the IEEE 802.11 series of standards adopted EDCAF (an extension to DCF) for scheduling the service of the access category queues at the contending devices. The EDCAF mechanism achieves Differentiated Services. How does the MAC layer in a device know which access category buffer to queue a packet in? This is achieved by the corresponding application using the DSCP (Differentiated Service Code Point) field in the IPV4 header to indicate the Differentiated Services class of the packet. The MAC layer of the device would have a table that maps the DSCP value to the access category.
EDCAF: Service Differentiation Mechanisms
We begin by recalling how the basic EDCF works, since EDCAF is built as an extension of EDCF. In EDCF, after handling the HOL packet in its (single) buffer (which could result in the packet being transmitted successfully or discarded (due to exceeding the maximum number of reattempts)), a device waits for DIFS, samples an initial back-off for the next packet in the buffer, and begins to count down (at slot boundaries) until the back-off counter reaches zero, at which instant the first attempt for the next packet is made. A collision leads to a new back-off being sampled from a distribution with a larger mean. All nodes behave in exactly the same manner, thus getting opportunities to transmit packets whenever their back-off counters reach zero. Thus, all devices (STAs and APs) have the same behavior (statistically), and there is no service differentiation.
Now consider an AP with AC3 packets to be transmitted (say, voice), and an STA with AC1 packets (say, TCP). After the AP transmits a voice packet, in EDCAF, the AP’s MAC waits for AIFS3 (Arbitration Inter Frame Space for Category 3) which is 2 slots, and samples a back-off from a uniform distribution over 1 slot to \(2^{7}\)slots. On the other hand, at this point the STA waits for AIFS1, which is 3 slots. In addition, after a TCP packet has been transmitted (or dropped) the STA samples a back-off for the next packet from a uniform distribution over 1 slot to \(2^{31}\)slots. Thus, the HOL packet waiting in the AC3 buffer has two advantages over the HOL packet waiting in the AC1 buffer:
The back-off counter of the AC3 category starts counting down one slot earlier than the AC1 category.
The back-off counters are smaller for AC3 than for AC1.
These two mechanisms conspire to differentiate the wireless access service in favour of AC3. Note that we do not get strict priority. For example, if a voice packet has been transmitted by the AP, and after AIFS3, the back-off sampled is 3 slots, whereas the residual back-off of the TCP transfer (at the STA) was 2 slots, then the TCP packet will be transmitted next. However, the service differentiation is significant as the simulation results from NetSim will demonstrate later in this chapter. The following is the table of all EDCAF parameters as specified by the standard.
Access Category |
CWmin |
CWmax |
AIFSN |
Max TXOP (\(\mathbf{\mu s}\)) |
|---|---|---|---|---|
Background (AC_BK) |
31 |
1023 |
7 |
3264 |
Best Effort (AC_BE) |
31 |
1023 |
3 |
3264 |
Video (AC_VI) |
15 |
31 |
2 |
6016 |
Voice (AC_VO) |
7 |
15 |
2 |
3264 |
Table-23: EDCA access parameters for 802.11 b for both AP and STA
The Experimental Plan
Voice over DCF: We first want to understand the limitation when carrying interactive voice over DCF.
With this in mind, we will set up several full-duplex voice calls between several STAs and the wired network, one such call for each STA. Each full-duplex voice call will be modelled by a periodic stream of 200-byte UDP packets (160B voice plus 40B of UDP/IP headers), generated at 20 ms intervals, from the STA to the wired network, and another such, independent stream from the wired network to the STA. We will increase the number of STAs, thereby increasing the number full-duplex voice calls, and will determine the number of calls that can be handled.
Then we will add on TCP controlled file transfer from the wired network to another STA. Due to reasons explained earlier in this chapter, the voice performance should degrade, leading to fewer calls being possible to handle along with the TCP transfer.
Voice over EDCAF: Next we repeat the above two experiments with the EDCAF mechanism enabled. We should find that it is possible to maintain a substantial number of voice conversations even while running the TCP file transfer. Next we will study what happens if the number of TCP file transfers is increased, the question being whether the number of voice conversations that can be handled gets affected.
Simulation Experiments to Study IEEE 802.11 EDCAF
Open NetSim and click on Experiments> Internetworks> Wi-Fi> Wi Fi WME 802.11e QoS EDCA>DCF Voice Only then click on the tile in the middle panel to load the example as shown in below Figure-27.
Figure-27: List of scenarios for the example of Wi Fi WME 802.11e QoS EDCA
Case 1: DCF with full-duplex voice calls only
Network Scenario
Figure-28: Network set up for studying the DCF with full-duplex voice calls only
Network Setup
AP and STA operate in DCF.
There is no error in all wired and wireless links.
Applications
Two-way UDP voice calls from Node to Wireless Node i, with i being incremented. Each voice calls in NetSim is modelled as 2 one-way voice applications. The voice modelling option in NetSim UI currently allows transfer in one direction only. Hence, we model a two-way voice call as 2 one-way voice applications.
\(WN_{i} \rightarrow N\) and \(N \rightarrow WN_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
Each voice call runs G.711 at 64 Kbps.
Case 2: DCF with full-duplex voice calls and a single TCP download
Network Scenario
Figure-29: Network set up for studying the DCF with full-duplex voice calls and a single TCP download
Network Setup
AP and STA operate in DCF.
There is no error in all wired and wireless links.
Applications
TCP full buffer (or saturated case) download from\(\ N\) to \(WN_{1}\). The saturation is generated by using a CBR application with Packet Size of 1460 Bytes and Inter packet arrival time of 1000 \(\mu s\). Since this generation rate is higher than the Wi-fi link it rate as a saturated (full buffer) TCP flow is achieved. The reason for emulating a TCP download using a CBR session, is that a TCP file download would take a longer time to simulate.
Voice calls from \(N\) to \(WN_{i + 1}\) with \(i\) being incremented. Two-way UDP voice calls from Node to Wireless_Node_i. Each voice calls in NetSim is modelled as 2 one-way voice applications
\(WN_{i + 1} \rightarrow N\) and \(N \rightarrow WN_{i + 1}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
Each voice call runs G.711 at 64 Kbps.
Case 3: EDCAF with full-duplex voice calls only
Network Scenario
Figure-30: Network set up for studying the EDCAF with full-duplex voice calls only
Network Setup
AP and STA operate in EDCAF, with EDCAF parameters set per reference paper
There is no error in all wired and wireless links.
Applications
Two-way UDP voice calls from Node to Wireless Node i, with i being incremented. Each voice calls in NetSim is modelled as 2 one-way voice applications. The voice modelling option in NetSim UI currently allows transfer in one direction only. Hence, we model a two-way voice call as 2 one-way voice applications.
\(WN_{i} \rightarrow N\) and \(N \rightarrow WN_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
Each voice call runs G.711 at 64 Kbps.
Case 4: EDCAF with full-duplex voice calls and a single TCP download
Network Scenario
Figure-31: Network set up for studying the EDCAF with full-duplex voice calls and a single TCP download.
Network Setup
AP and STA operate in EDCAF, with EDCAF parameters set per reference paper. In the AP, TCP would be queued in AC_BE while Voice packets would be queued in AC_VO.
There is no error in all wired and wireless links.
Applications
TCP full buffer (or saturated case) download from \(N\) to \({WN}_{1}\). The saturation is generated by using a CBR application with Packet Size of 1460 Bytes and Inter packet arrival time of 1000 \(\mu s\). Since this generation rate is higher than the Wi-fi link it rate as a saturated (full buffer) TCP flow is achieved.
- Voice calls from \(N\) to \(WN_{i + 1}\) with \(i\) being incremented. Two-way UDP voice calls from Node to Wireless Node i. Each voice calls in NetSim is modelled as 2 one-way voice applications
\(WN_{i + 1} \rightarrow N\) and \(N \rightarrow WN_{i + 1}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
Each voice call runs G.711 at 64 Kbps.
Case 5: EDCAF with full-duplex voice calls and multiple TCP downloads
Network Scenario
Figure-32: Network set up for studying the EDCAF with full-duplex voice calls and multiple TCP downloads
Network Setup
AP and STA operate in EDCAF mode.
There is no error in all wired and wireless links.
Applications
10 TCP downloads from \(N\) to \({WN}_{1}\) through \({WN}_{11}\)
TCP full buffer (or saturated case) download from \(N \rightarrow WN\). The saturation is generated by using a CBR application with Packet Size of 1460 B and Inter packet arrival time of 1000 \(\mu s\). Since this generation rate is higher than the Wi-fi link it rate as a saturated (full buffer) TCP flow is achieved.
UDP Voice calls from \(N\) to \({WN}_{11 + i}\) with i being incremented.
Each voice calls in NetSim is modelled as 2 one-way voice applications
\({WN}_{i}\ \rightarrow \ N\) and \(N \rightarrow \ {WN}_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
Each G.711 at 64 Kbps.
Simulation Results
Case 1: DCF with full-duplex voice calls only
Tabulated separately for applications going \({WN}_{i} \rightarrow \ N\) and \(N \rightarrow \ {WN}_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
A mean delay of 20,000 \(\mu s\) is considered as a threshold.
For the case \(N \rightarrow \ {WN}_{i}\) this threshold is crossed at 11 calls
For the case \({WN}_{i} \rightarrow \ N\) this threshold is crossed at 20 calls
No of voice calls |
Mean Delay Voice \(\mathbf{N\ \rightarrow \ }\mathbf{WN}_{\mathbf{i}}\) |
Mean Delay Voice \(\mathbf{WN}_{\mathbf{i}}\mathbf{\ \rightarrow \ N}\) |
|---|---|---|
1 |
1130.97 |
1082.48 |
2 |
2333.61 |
1653.72 |
3 |
3618.41 |
2115.09 |
4 |
4946.16 |
2578.05 |
5 |
6298.87 |
3026.74 |
6 |
7632.79 |
3516.05 |
7 |
9004.97 |
3979.66 |
8 |
10395.65 |
4434.80 |
9 |
11780.73 |
4937.34 |
10 |
13384 |
5498.42 |
11 |
3569361 |
6354 |
12 |
11267144 |
6985 |
13 |
17921294 |
7568 |
14 |
23235201 |
8232 |
15 |
28389497 |
9221 |
16 |
32526177 |
10326 |
17 |
36062048 |
12060.73 |
18 |
39589934 |
14635.82 |
19 |
42859790 |
21222.59 |
20 |
44960901 |
39404.71 |
21 |
45684937.21 |
210834.19 |
22 |
46312147.7 |
2102284.78 |
Table-24: DCF with full-duplex voice calls only. \( \mathbf{N \rightarrow WN_{f(i)}} \) and \( \mathbf{WN_{f(i)} \rightarrow N} \), where \( \mathbf{N} \) represents the wired node and \( \mathbf{WN_{f(i)}} \) represents the \( \mathbf{f(i)} \)-th wireless node. Therefore, \( \mathbf{N \rightarrow WN_{f(i)}} \) represents the flows from AP to STAs while \( \mathbf{WN_{f(i)} \rightarrow N} \) represents the flows from STAs to AP.
Mean Delay Voice \({WN}_{i} \rightarrow \ N\) = Average of the delay of all the applications flowing \({WN}_{i} \rightarrow N\)
Case 2: DCF with full-duplex voice calls and single TCP download
Tabulated separately for applications going \({WN}_{i} \rightarrow \ N\) and \(N \rightarrow \ {WN}_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
A mean delay of 20,000 \(\mu s\) is considered as a threshold.
For the case \(N \rightarrow \ {WN}_{i}\) this threshold is crossed at 1 call itself
No of TCP Connections |
No of voice calls |
Mean Delay Voice \(\mathbf{N\ \rightarrow \ }\mathbf{WN}_{\mathbf{i}}\) |
Mean Delay Voice \(\mathbf{WN}_{\mathbf{i}}\mathbf{\rightarrow \ N}\) |
|---|---|---|---|
1 |
1 |
106287.82 |
3313.02 |
2 |
139670.90 |
3574.49 |
Table-25: DCF with full-duplex voice calls and single TCP download \( \mathbf{N \rightarrow WN_{f(i)}} \) and \( \mathbf{WN_{f(i)} \rightarrow N} \).
Case 3: EDCAF with full-duplex voice calls
Tabulated separately for applications going \({WN}_{i} \rightarrow \ N\) and \(N \rightarrow \ {WN}_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
A mean delay of 20,000 \(\mu s\) is considered as a threshold.
For the case \(N \rightarrow \ {WN}_{i}\) this threshold is crossed at 13 calls, for the case \({WN}_{i} \rightarrow \ N\) this threshold is crossed at 21 calls
No of voice calls |
Mean Delay Voice \(\mathbf{N \rightarrow \ }\mathbf{WN}_{\mathbf{i}}\) |
Mean Delay Voice \(\mathbf{WN}_{\mathbf{i}}\mathbf{\rightarrow \ N}\) |
|---|---|---|
1 |
1000.70 |
704.67 |
2 |
1720.33 |
1575.46 |
3 |
2460.84 |
2464.80 |
4 |
3231.19 |
3356.52 |
5 |
4084.78 |
4274.85 |
6 |
5092.33 |
5068.09 |
7 |
6090.03 |
5872.13 |
8 |
7083.65 |
6648.27 |
9 |
8193.41 |
7373.58 |
10 |
9226.28 |
8115.11 |
11 |
10508.87 |
8671.12 |
12 |
11697.43 |
9477.25 |
13 |
473970.92 |
12243.88 |
14 |
509835 |
12656.72 |
15 |
513948.31 |
13302.09 |
16 |
512255.59 |
13890.68 |
17 |
507689 |
14612 |
18 |
502026 |
15251 |
19 |
498552 |
16611 |
20 |
493342 |
17863 |
21 |
488076.26 |
20317.288 |
Table-26: EDCAF with full-duplex voice calls \( \mathbf{N \rightarrow WN_{f(i)}} \) and \( \mathbf{WN_{f(i)} \rightarrow N} \).
Case 4: EDCAF with full-duplex voice calls and single TCP download
Tabulated separately for applications going \({WN}_{i} \rightarrow \ N\) and \(N \rightarrow \ {WN}_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
A mean delay of 20,000 \(\mu s\) is considered as a threshold.
For the case \(N \rightarrow \ {WN}_{i}\) this threshold is crossed at 13 calls
No of TCP Connections |
No of Voice calls |
Mean Delay Voice \(\mathbf{N \rightarrow \ }\mathbf{WN}_{\mathbf{i}}\) |
Mean Delay Voice \(\mathbf{WN}_{\mathbf{i}}\mathbf{\rightarrow \ N}\) |
|---|---|---|---|
1 |
1 |
2669.87 |
2969.59 |
2 |
3742.81 |
4204.35 |
|
3 |
4653.75 |
5087.94 |
|
4 |
5599.46 |
5954.40 |
|
5 |
6631.17 |
6799.18 |
|
6 |
7877.11 |
7551.42 |
|
7 |
9081.65 |
8221.35 |
|
8 |
10353.74 |
8932.09 |
|
9 |
11761.94 |
9617.73 |
|
10 |
13781.53 |
10379.25 |
|
11 |
16629.97 |
10723.95 |
|
12 |
28475.08 |
9966.17 |
|
13 |
489968.54 |
12295.56 |
|
14 |
512965.29 |
12765.90 |
Table-27: EDCAF with full-duplex voice calls and single TCP download \( \mathbf{N \rightarrow WN_{f(i)}} \) and \( \mathbf{WN_{f(i)} \rightarrow N} \).
Case 5: EDCAF with full-duplex voice calls and multiple TCP downloads
Tabulated separately for applications going\({\ WN}_{i}\) \(\rightarrow \ N\) and \(N\ \rightarrow \ {WN}_{i}\). \(WN_{i}\) represent wireless node \(i\), while \(N\) represents the wired node or remote host.
A mean delay of 20,000 \(\mu s\) is considered as a threshold.
For the case \(N\ \rightarrow \ {WN}_{i}\) this threshold is crossed at 13 calls
No of TCP Connections |
No of voice calls |
Mean Delay Voice .. math:: mathbf{N rightarrow}mathbf{WN}_{mathbf{i}} |
Mean delay Voice \(\mathbf{WN}_{\mathbf{i}}\) → \(\mathbf{N}\) |
|---|---|---|---|
10 |
1 |
2631.65 |
2922.68 |
2 |
3640.44 |
4079.23 |
|
3 |
4624.32 |
5079.30 |
|
4 |
5386.83 |
5838.45 |
|
5 |
6447.83 |
6602.43 |
|
6 |
7186.98 |
7472.08 |
|
7 |
8801.21 |
8097.06 |
|
8 |
10052.13 |
8645.98 |
|
9 |
11660.75 |
9466.26 |
|
10 |
13281.74 |
9931.90 |
|
11 |
16146.43 |
10759.76 |
|
12 |
43567.50 |
11347.94 |
|
13 |
506122.33 |
12439.36 |
|
14 |
511198.25 |
12980.59 |
Table-28: EDCAF with full-duplex voice calls and multiple TCP downloads \( \mathbf{N \rightarrow WN_{f(i)}} \) and \( \mathbf{WN_{f(i)} \rightarrow N} \).
Comparison Charts
(a)
(b)
Figure-33: The plot of Mean Delay Vs. Number of Calls for DCF and EDCAF (a & b)
Discussion of the Simulation Results
Results for DCF
1. Observations
Only voice calls: With one voice conversation, the mean packet delay for the wired-to-wireless (downlink) direction (i.e., these packets queue in the AP) is 1.18161 ms, whereas in the wireless-to-wired (uplink) direction (i.e., these packets queue in the STA) the mean packet delay is 1.11924 ms (we will, henceforth, report these delays in milliseconds and round-off to two decimal places). These mean delays increase as the number of voice conversations increase. We notice that with 10 conversations the downlink mean packet delay is 13.69 ms, whereas the uplink packet delay is 5.47 ms. An increase of one more call result in the downlink mean packet delay becoming 4027.85 ms and the uplink mean packet delay being 6.28 ms.
One TCP download to one STA from a wired node and increasing number of full-duplex voice calls: With just one voice call the mean delay is 116.00 ms in the downlink and 3.18 ms in the uplink. These values should be compared with 1.18 ms and 1.12 ms, respectively. Thus, with just one TCP connection, a single voice call experiences substantially larger mean delay.
2. Discussion
With increasing number of voice calls (without any simultaneous TCP download) the dramatic change in the downlink delay, when the number of voice calls is increased from 10 to 11 is due to the downlink queue becoming unstable, i.e., the arrival rate of bits exceeds the rate at which the DCF wireless access mechanism can service the bits queued at the AP. The sudden transition from low delays to very high delays is typical of a queue going a stable regime to an unstable regime.
It is interesting to note that at this transition point, the uplink delays have not increased as dramatically. In fact, in the uplink direction the transition from stability to instability appears in going from 22 calls to 23 calls. This difference in the downlink and uplink directions is because all the downlink voice packet streams are handled at one queue (the AP’s Wi-Fi buffer), with one contention process, whereas each uplink voice packet stream has its own buffer with its own contention process. If all the uplink voice streams had also been from one STA then the same phenomenon would have been observed in both directions.
Next, we saw that with a single downlink TCP transfer the downlink mean delay of a single voice call is almost 100 times that without TCP. This occurs because the TCP transfer over a the local area network builds up a large window, most of which resides in the AP buffer. The TCP file transfer packets are large (about 1500 bytes). A single voice stream generates 200-byte packets at 20 ms intervals. The downlink voice packets see a very large buffer, due to the TCP packets queued in the AP buffer. It may be noted here, that with this kind of delay, even a single interactive voice call will not be supported.
Results for EDCAF
1. Observations
With voice calls alone the transition in downlink delay occurs in going from 12 to 13 calls.
With TCP downloads (1 or 10 downloads) the transition in downlink voice packet delay does not change as compared to without TCP
2. Discussion
EDCAF creates different buffers for voice and for TCP file transfers (AC3 and AC1, respectively). The service differentiation mechanism between these buffers is described earlier in this chapter. The experimental results show that voices call performance is not seriously affected by the TCP controlled file transfers.
As before, and for the same reasons, the voice capacity is limited by the service rendered to the AP buffers.