According to the specification of backoff procedure recommended in the IEEE 802.11 [1], we can estimate the performance of each packet will be impacted seriously because of the expansion method of the backoff selection window especially when the environment has heavy traffics.
We concentrate on the performance of the DCF architecture. Assuming there exists some STAs along with one AP, and they construct a BSS environment. Using the RTS/CTS handshaking mechanism prior to the real data packets exchange to emulate the complete IEEE 802.11 standard [1]. The ACK frame is assumed to be received correctly by the sender without any exception after each data transmission is completed. Here, the hidden-terminal problems will be left for future discussion, and we don’t put this issue into consideration because we already implement an ideal RTS/CTS algorithm to prevent this problem. The difference of air propagation delay, dependent on the characteristics of the PHY, can be ignored too, which means the real collisions will happen only when there are more than two STAs initiating to transmit packets at the same time and all of them don’t figure out the medium is busy until they finish their transmission without any positive ACK frame receiving. Based on the CSMA/CA mechanism of the IEEE 802.11 MAC, we can assume that the probability of this condition is zero since the STA follows the collision avoidance scheme. Under these assumptions, we emulate an environment by every packet is with the same length of frame body, no hidden-terminal exists, and every possible collision will be sensed by each STA immediately and then get into backoff procedure without destroying the data neither wasting the channel utilization.
The Figure 9 shows the timing required for the normal data transmission. For a single packet transmission, the medium shall be sensed as idle again by all STAs after:
Data
The slot time aSlotTime and the short inter-frame space aSIFSTime are assumed to be fixed per PHY, and the value of aSlotTime is 20µs defined in the IEEE 802.11.
(Refer to 15.4.6.8 Slot time). Based on the requirement defined in the IEEE 802.11, the aSIFSTime, as measured on the medium, is not allowed to vary from the nominal SIFS value by more than 10% of one aSlotTime for the PHY in use. 5µs is recommended for the aSIFSTime value in the standard and we can ignore the propagation delay compared with the aSIFSTime. The durations of PIFS and DIFS are derived by the following equations specified in the IEEE 802.11:
aSlotTime
In our simulation case, the retransmission is ignored. That means no collision will happen or degrade the throughput of the medium, and every transmission is successful with an ACK frame is received by the transmitting STA.
The throughput is defined as the average data transfer rate. It can be also taken for the utilization of the wireless channel, but different dealing with the dummy
RTS CTS Data ACK
DIFS SIFS SIFS SIFS DIFS
Next Packet
Figure 9. Data Transmission Timing Required
26
RTS/CTS/ACK frames. The medium which is determined to be not idle and used for the real data exchange is the transmission time we put into our calculation. Those auxiliary packets, like RTS, CTS or ACK frames, used to complete the real wireless environment are not taken into consideration. But they do exist in the simulation model. We also have to put the inter-frame space (IFS) into consideration, like the aDIFStime and the aSIFStime in the DCF mode. Based on this assumption, we can formulate the throughput rule as:
%
As we know, the aDIFStime is 45µs comes from the aSIFStime 5µs plus twice the aSlotTime 20µs, and we can get the aPIFStime 25µs from the same time units.
Obviously, the extra PLCP bits for the PHY required are viewed as the useful data, and we put those bits into the throughput consideration.
Some parameters are fixed, like the distribution of the time interval between continuous packets is Exponential with mean rate 50msec, which constructs a Poisson distribution for packet generating in one STA shown in the Figure 10.
w X1 X
Xn
t
-1t
0t
1t
2z t
n-1t
nt
Figure 10. Poisson Distribution Density
And, the Poisson distribution function is [31], [32]:
? ? ? ?
0,1,2?!
1 ?
? t e? n
x n
fn ? n ?t
? ?
2.10In the simulation cases, we have tested different traffic loadings with station numbers 10, 30 and 50 along with an AP in a BSS infrastructure to emulate as the light, meddle and heavy loadings. The packet length is fixed at 1000 bytes, including the MAC Header, Frame body field and the FCS field. Add the 192 bits PLCP Preamble and Header to form the data packet we used in the emulation. The contention window range is from 7 to 255 as recommended in the IEEE 802.11, and this is referred as the aCWmin is 7 and the aCWmax is 255. And definitely no hidden terminal exists when the RTS/CTS packets are exchanged prior to the real data transmission. The whole emulation is stopped at the 100,000th data transmission.
The Figure 11 shows the average delay time of each collision number when there are 10 stations in the case.
Figure 11. Average delay time of each collision number under light load with the MPDU 1000 bytes
28
We can tell the average delay time is increasing as the collision number increases.
The channel utilization is quiet less. Since the loading is light, the medium is not too busy. If a packet doesn’t collide, its delay time always keeps at 115µs, including aDIFStime, aSIFStime, aRTStime and aCTStime.
The mean delay time and the standard deviation are shown in the Figure 12, which is for the frame size 1000 bytes. We can predict easily that the packet numbers of higher collision number is less than that of fewer collision number. Most packets can be transmitted out within 1msec as the Delay Time Distribution in Figure 12 shows. The meanings of delay time and standard deviation are the fairness of each packet. If the overall delay time is small, the delay of each packet can be viewed as small. Whenever the standard deviation is small, we can predict more exactly the timing this packet been transmitted out.
Figure 12. Delay time distribution under light load with the MPDU 1000 bytes
We are much interested at the packets with collisions. Narrow down from the Figure 12, we generate the Figure 13 to see what is the delay time distribution for those collided packets.
There are more simulation results under middle and heavy loadings shown in the Figure 14 to the Figure 19.
Figure 14. Average delay time of each collision number under middle load with the MPDU 1000 bytes
Figure 13. Delay time distribution under light load with the MPDU 1000 bytes, and without no-collision packets
30
Figure 15. Delay time distribution under middle load with the MPDU 1000 bytes
Figure 16. Delay time distribution under middle load with the MPDU 1000 bytes, and without no-collision packets
Figure 17. Average delay time of each collision number under heavy load with the MPDU 1000 bytes
Figure 18. Delay time distribution under heavy load with the MPDU 1000 bytes
32
The Figure 11, Figure 14 and Figure 17 show the obvious trend that the average delay time grows up along with the collision numbers and traffic loadings. According to the simulations, the maximum average delay is 2.1 msec in the light loading, but almost 90 msec in the heavy loading. This can explain why the performance of heavily collided packet is so bad. As recommended in the IEEE 802.11 [1], when the packet is collided, the contention window size is double unless it already reaches the maximum value and stands at the value, or if the collision number reaches the threshold, SLRC.
The contention window will not reset to the initial value until this packet is transmitted successfully. This property will result in that the heavily collided packet chooses a larger backoff timer more possible and so that the delay time is much more.
Figure 19. Delay time distribution under heavy load with the MPDU 1000 bytes, and without no-collision packets
And, we can figure out the collision numbers grow also along with the traffic loadings.
More heavy traffics will introduce more serious collisions. When there are more collided packets waiting for the chance to access the medium, the much more delay time and worse throughput will happen. It forms a negative loop.
We can understand how is the performance from the Figure 12, Figure 15 and Figure 18. The mean delay time is worse when the loading is getting heavy in the simulation environment. This time value stands for the loading status. There is another phenomenon we should pay more attention on that. The standard deviation varies fast when the traffic loading is heavy. In DCF mode, what we can not control well is the delay time of each collided packet. The exact transmitting time is so different for each packet because of the collisions. In other words, if we can estimate more precisely the possible delay time of most packets, we can make the packet to be transmitted more smoothly. In such case, we can roughly do some bandwidth allocation and data flow control, and can also sense the possible throughput before the real transmission starts.
This information plays a very important role in the quality requirement.
The figure 20 shows the throughput under different station numbers.
Figure 20. Throughput vs. Loadings with contention window 7-255
34
When the station number increases, the throughput increases too. Since there are many stations waiting for the chance to access the medium especially under heavy loading, the idle time of the medium can be reduced; which means the medium is quite busy and the deferring time of packets is longer. We also know some parameters will impact the throughput, like aCWmin and aCWmax. When aCWmin is set to be small, the packets will be collided more if there are many active stations in the BSS.
Because the possibility of more than two stations choosing the same backoff timer will increase along with a smaller aCWmin. However, if the aCWmin is set to be large, the waiting time for accessing the medium will be longer. Also, a smaller aCWmax can limit the expansion rate of the contention window, but also induces more collisions when the loading is heavy.