Queue size Prediction (QP) using Computation of Additional Transmission (CAT)Transmission (CAT)

The best way to decide the admission of a new VoIP flow is to measure the queue size of the AP after it has been admitted. However, it is not appropriate to disconnect the admitted flow when it was discovered that it degrades the QoS of all VoIP flows. Another way is that as in the call admission control methods for wired networks, probing flows can be transmitted instead of actual VoIP flows [49], but this wastes a certain amount of bandwidth because clients should keep probing in wireless networks, which is a critical disadvantage because of the limited bandwidth.

QP-CAT is a simple and accurate technique to predict the queue size, without wasting any band-width, but achieving the same performance as using actual probing. The basic concept of the QP (Queue size Prediction) is to predict the future queue size of the AP using the simulation of a new VoIP flow and the Computation of Additional Transmission (CAT), where the number of packets to be transmitted additionally is computed in real time by monitoring the channel status. The basic operation of QP-CAT is shown in Fig. 8.3. First, VoIP packets from a new virtual VoIP flow is generated following the behavior of the traffic and inserted into a virtual queue (Fig. 8.3 (a)). Then, by monitoring the channel, we compute how many VoIP frames can be additionally transmitted using CAT (Fig. 8.3 (b)). Lastly, the number of additionally transmittable frames is subtracted from the virtual queue size, and then the total number of

116

Figure 8.4: Emulation of a new VoIP flow with 20 ms packetization interval

Figure 8.5: Computing the number of additionally transmittable VoIP packets

packets in the actual queue and virtual queue becomes the predicted queue size.

8.3.1 Emulation of new VoIP flows

In order to emulate a new VoIP flow, two counters, UpCounter and DnCounter, which count the number of the uplink and downlink packets of a new VoIP flow, respectively, are introduced. The counters are incremented following the behavior of the new VoIP flow. For example, for the VoIP traffic with 20 ms packetization interval, both of the counters are incremented by one every 20 ms (Fig. 8.4). The counters are decremented in real time according to the number of packets computed using CAT. They are decre-mented alternatively because the chance to transmit packets is the same between the uplink and downlink.

Consequently, the actual queue size of the AP plus DnCounter becomes the predicted future queue size of the case when the VoIP flow is admitted.

8.3.2 Computation of Additional Transmission (CAT)

The number of additionally transmittable packets (np) is computed by looking at the current packet trans-mission behavior. That is, a clock starts when medium becomes idle and stops when busy medium is detected (Fig. 8.5). When the clock stops,np is computed by dividing the clock time (Tc) by the total transmission time (Tt) of a VoIP packet (Eqn. 8.1).

np= ⌊Tc/Tt⌋ (8.1)

The transmission time of a VoIP packet comprises all headers in each layer, IFSs, backoff and an ACK frame (Fig. 8.5). Thus, the transmission time (Tt) is computed as follows:

Tt= TDIF S+ Tb+ Tv+ TSIF S+ TACK,

Table 8.1: IEEE 802.11b parameters (11 Mb/s) Parameters Time (µs) Size (bytes)

PLCP Preamble 72.00 18

PLCP Header 24.00 6

MAC Header+CRC 24.73 34

SIFS 10.00

DIFS 50.00

Slot 20.00

CWM IN 31 slots

Figure 8.6: Handling the remaining time (Tr): whenTr> Tb

whereTvandTACKare the time for sending a voice packet and an ACK frame, respectively,Tbis the back-off time,TDIF SandTSIF Sare the durations of DIFS and SIFS. The backoff time is Number of Backoff Slots×

TslotwhereTslotis a slot time, and Number of Backoff Slots has a uniform distribution over(0, CWM IN) with an average of(Tslot× CWM IN/2) (Fig. 8.5).

For example, with 64 kb/s VoIP traffic with 20 ms packetization interval, the voice data size is 160 B, the VoIP packet size including IP, UDP and RTP [70] headers becomes 200 B, and then the to-tal transmission time becomes 791.82µs including the average backoff time (310 µs)² and 14 B ACK frame (130.18µs), in IEEE 802.11b with 11 Mb/s transmission rate (refer to Table 8.1 for the 802.11b parameters). Thus, for example, whenTcis 1200µs, then npis 1 according to Eqn. 8.1.

However, in real environments, the frames from new VoIP sources are not always transmitted in between the frames from existing sources. Sometimes, they collide with the frames from existing VoIP sources, and the existing VoIP sources need to defer their transmissions due to the new flows. Therefore, the effect of collisions and deferrals need to be also considered in CAT, by handling the remaining clock time (Tr) as described below.

118

Figure 8.7: Handling the remaining time (Tr): whenTr<= Tb

Handling the remaining clock time (Tr)

Generally,Tcis not always a multiple ofTt, and we have remaining time (Tr).Tris defined as follows:

Tr= Tc− np× Tt (8.2)

WhenTr > 0, Tr is added to the next idle time (T_c2), causing an additional DIFS. That is, Tc = T_c2+ Tr− TDIF S. We can check the reason in two possible cases,Tr > Tb andTr ≤ Tb. First, when the remaining time is larger than the backoff time (Tr > Tb), the virtual additional frame needs to be transmitted first, and then the actual frame would be transmitted, if the new VoIP call is admitted. In this case, the additional frame interrupts the backoff time of the actual frame from an existing flow, and another DIFS is required to resume the backoff and transmission according to the 802.11 standard. This is why additionalTDIF Sis added in the next computation ofnp. Fig. 8.6 shows the emulation result and comparison with the result of CAT. We can see that the total number of transmitted frames duringT_C1and T_C2in CAT is the same as the emulation result (three additional frames). Secondly, when the remaining time is larger than or equal to the backoff time (Tr≤ Tb), the actual frame is transmitted first, and then the additional frame can be transmitted (Fig. 8.7). This case corresponds to the real transmission, and we can see that CAT is consistent with the simulation result.

Emulation of collisions

To predict the queue size at the AP more accurately, we need to consider collisions, which congest the channel and cause additional delay. A simple way to emulate collisions is to apply the average retry rate for a certain amount of time to additional transmissions, since the retry rate can be easily measured in the firmware or the driver. For example, if the average retry rate of downlink traffic is 3%, then three is added to DnCounter every time the counter is incremented by 100. However, while this method is easy to implement, it cannot reflect the increase of collisions due to the admission of new calls. Therefore, in CAT we emulate collisions following the actual collision mechanism.

2Even though the average backoff time was used in the example, the backoff time is generated using a random value between 0 and CW size in the implementation, as in the standard.

Figure 8.8: Emulation of collisions: during2Tt, only one additional frame can be transmitted due to the collision, in the end

As we can see in Fig. 8.8, if Tr is exactly the same as the backoff time plus DIFS (that is, Tr = Tb+ TDIF S), transmission of the additional frame is attempted at the same time as transmission of the actual frame (refer to the emulation part in Fig. 8.8). Thus, it is considered as a collision in CAT.

If an actual collision happens, both frames need to be retransmitted (we ignore the capture effect, where a packet can be transmitted through the collision, because it rarely happens). However, the actual frame is not retransmitted here because collision did not happen in the real transmissions. Therefore, the actual frame retransmission needs to be emulated by adding a virtual frame to DnCounter (since the downlink frame transmission is delayed due to the retransmission, the effect is the same). That is, the impact of a collision is transmission of additional two frames, and thus2Ttis considered as one frame transmission in CAT, eventually.

In summary, the algorithm of QP-CAT is shown in Fig. 8.9. First, we measureTc by checking the channel idle and busy time. Next, we check if there is any remaining time (Tr) from the previous computation. If any, check if the virtual collision happened and handle the collision. Otherwise, com-pute newTc using Tr. Then, we compute the number of additionally transmittable frames (np), update DnCounter usingnp, and compute the future queue size (Qp) using the actual queue size of the AP (QA) and DnCounter.