Chapter 4 QoS Based Call Admission Control
4.2 Virtual Traffic Source Estimation Algorithm
4.2.2 Calculation of Virtual Delay
In this thesis, “virtual delay” is used to represent the delay time of the virtual packet and the estimated possible delay of existing real packet. The first thing in the calculation of the virtual delay is to estimate how long a virtual packet transmission will be taken based on the equations (2-1) ~ (2-7) and the packet transmission plotted in the Fig.2.3. Assuming a success virtual packet transmission takes Tp to finish its transmission. If the nominal MSDU size in the Tspec is Bdata and the PHY data rate the new service requests to transmit packets is R data and the service priority is i, the value of Vp is equal to After the calculation of packet transmission period of virtual packets, another parameter Dp is used to represent the propagated delay time made by virtual packets.
Before the description of Dp, an introduction of how the VTSE controller handles the contention process of virtual packets would help the understanding the estimation of Dp.
Fig.4.3 is plotted to show the state of virtual traffic source in the AP. A real-time service in the WLAN can be seen as a traffic source which generates packets continuously. The buffer of service priority 1 is labeled as buffer[1] in the Fig. 4.3.
Fig. 4. 3Virtual packets contend for the channel with other packets
After the generation of virtual traffic source, the VTSE controller is responded to the contention of virtual packets. The VTSE controller estimates packet delays and packet loss rate to make decision. Estimation rules of virtual delay and virtual packet loss rate are described in the Fig.4.4. The mechanism is described as below:
Fig.4.5 plots the condition that virtual traffic source gets the access of channel after a packet R(k, j) is transmitted. R(k, j) means it is the packet of real-time service j which is stacked into the buffer[k]. When there is no real packet in the buffer[k], the VTSE controller handles the virtual packet contention process itself. The contention procedure in the VTSE controller is the same with real packets. In Fig. 4.5, although there is a real packet “R(m, k)” is transmitted. But packet transmission of the packet
“R(1, j)” will be affected by the virtual packet if the virtual packet is allowed to be transmitted. It means that the packet delay of the packet “R(1, j)” is increased because of the virtual packet. Assume the transmission period of a virtual packet is Vp. Equation (4-2) lists the update process of Dp(1) and Dp(2). Dp(k) is the estimation of the propagated delay of buffer[k] made by virtual traffic source in the nth slottime.
dir_new_service is the variable that indicates the direction of the new service. The
contends success, Dp(1) and Dp(2)is updated based on (4-2).
When the buffer[k] is idle, Dp(k) is decreased continuously when buffer[k] keeps idle longer than a DIFS. Otherwise, the Dp(k) will be frozen. So, the formula of updating Dp(k) is listed as the formula (4-3) and (4-4). The VTSE controller estimates the virtual delay of every real packet of different buffers by adding the Dp(k) to the experienced packet delay of real packets.
When a virtual packet is transmitted
Dp(k) = Dp(k) + Vp * dir_new_service (4-2)
When the buffer[k] idle longer than a DIFS Dp(k) = Dp(k) – idle period
(4-3) When the buffer[k] is busy
Dp(k) = Dp(k) (4.4)
Fig. 4. 4Estimation rules of virtual delay and virtual packet loss rate
Fig. 4. 5VTSE controller contends for the channel directly when there is no packet in the buffer[k]
Fig. 4.6 plots the condition that there are packets waiting in the buffer[1] and buffer[1] gets the access to transmit packet. At this time, the VTSE controller has to compare the longest waiting virtual packet to the longest waiting real packet in the buffer[1]. Assume the interarrival time of the eldest waiting virtual packet is Vint and the interarrival time of the longest waiting real packet is Rint. The virtual packet can be transmitted if Vint < Rint and the virtual packet can be transmitted directly because of the FIFO feature of buffers. The Dp(k) is updated as (4-2) when the virtual packet is transmitted successfully.
When one real packet of service i, which is labeled R(k,i), is transmitted successfully. The VTSE controller estimates the virtual delay of real packet by adding the Dp(k) to its real queuing delay. Suppose the queuing delay of packet the R(k, i), is Doriginal(R(k, i))and the estimated virtual delay is Vr(R(k,i)). The estimated virtual delay is calculated as (4.3).
Vr(R(k ,i)) = Doriginal (R(k, i)) + Dp(k) (4-5)
Fig. 4. 6Virtual packet transmission when the buffer[k] gets the access and the virtual packet’s interval time is earlier than the transmitting real packet in the buffer[k]. D(k) and V(R(k, i)) are also updated
VTSE controller will simulate the virtual packet transmission during an admission period the QoS of every service is estimated when the admission period is finished.
The proposed QoS threshold in the VTSE algorithm is packet loss rate. Assume the delay bound of service i is labeled as DI. A packet of service i will be dropped when its queuing delay is larger than DI. So the virtual packet loss rate of service i, which is labeled as V(i), will be calculated. The number of packets that would be dropped are labeled as Vd(i) . Assume VT(i) is the number of packets transmitted in the admission period.
Virtual packet loss rate V(i)
= Number of estimated dump packets / number of estimated transitted packets.
=Vd(i)/VT(i) (4-6)
The new service request will be rejected when there are any real-time service that its V(i) is larger than its acceptable packet loss rate, which is labeled as D(i). Another rule to reject the new service request is the QoS record packet loss rate of existing services. The new service request will be rejected when the recorded packet loss rate of existing real-time services exceeds its QoS threshold.
4.3 Bandwidth Reservation
The goal of the bandwidth reservation is to protect the QoS of real-time services from being degraded by unstable system loading. The major concept of this algorithm is preserve a period of time that is available for those high priority services. In other words, the proposed bandwidth reservation limits the access of Non-real-time services based on the traffic loading of real-time services.
Procedures of this mechanism are described in Fig.4.8 and they will be explained below:
Calculate the duration that the real-time services have occupied the channel in the nth beacon interval, which is labeled as Treal(n).
The AP calculates the average time period that real time services occupies during a beacon interval and updates the value after every beacon interval.
Assume the average time period is labeled R avg. R avg is updated likes (4-7).
Ravg (n+1)= α* Ravg(n) + (1-α) * Treal(n) (4-7)
In the next n+1th beacon interval, AP limits the duration which all Non-real-time services can occupy under the value of Ttoken calculated in (4-8).
Ttoken(n+1)=Tbeacon-surplus factor*Ravg(n+1) (4-8) Where T beacon is a constant value, which is equal to 100 ms in [1].
Surplus factor represents a ratio that real-time services require for bandwidth reservation. Surplus factor is contained in the Tspec when a new real-time service requirement is transmitted.
Based on the specification of [2], AP broadcasts the beacon frame in the beginning of every beacon interval. Ttoken can be attached in the beacon frame so stations in the network can update Ttoken in the beginningof every beacon interval.
After stations in the network receive beacon frame, a bandwidth reservation process starts in this way:
Stations that have non-real-time services will record the duration that non-real-time services have occupied, which is labeled as T non-real.
T non-real is equal to Ttoken in the beginning of every beacon interval.
When a station transmits a packet of non-real-time service, which is labeled Pk, from its MAC buffer, it calculates the period that Pk will occupy, which is labeled as T k. According to the description in chapter 2, Pk can be received by other stations in the network and other stations can use T k to update their NAV.
Assume stations can identify the service type of the transmitting packets. It can be achieved because there are many reserved field in the MAC header and the transmitting stations can attach this information in these reserved field.
When stations receive the information of P k, eachstation updates their T non-real
as:
if Tnon-real(Pk) decreased to lower than zero.
Flow chart of thes procedures are posted in Fig. 4.7. Since all the computation are already defined in [1] and [2], the bandwidth reservation would not increase the complexity of WLAN system.
Fig. 4. 7Flow chart of the proposed bandwidth reservation process towards non-real-time services in the WLAN network
Chapter 5 Simulation Results
This chapter describes the simulation platform and simulation results. Section 5.1 is the introduction of the simulation platform and settings in the platform. Section 5.2 is simulation results of the proposed VTSE algorithm and bandwidth reservation. Section 5.3 is conclusion of simulation results.
5.1 Simulation Platform
An event driven simulation platform is developed based on the specification of [1] and [2]. This platform simulates contention process and packets transmission in the infrastructure network, which means an access point (AP) centralizes the network control.
AP and all the stations in the simulation platform contend for the channel in EDCA mode.
RTS/CTS mode is implemented in the platform because of the recommendation in [2].
Fig. 5. 2 802.11 WLAN infrastructure network
Table 5.1 lists the assumptions used in the simulation. In order to verify the proposed VTSE algorithm and the bandwidth reservation, real-time services and non-real-time services are simulated in this platform. Traffic models of real-time and non-real-time services are explained in section 5.1.1 and 5.1.2. Section 5.1.3 describes the assumption in the PHY layer and the channel model. Section 5.1.4 explains the QoS criteria of real-time services in the WLAN.
Table5. 1 Settings of parameters of real-time services in the platform
Parameters VoIP FTP HTTP 1.1
Continuous
Periodic traffic
Markov on/off
Burst Burst
Bi-directionality Bidirectional User Defined User Defined
Delivery priority 3 0 1
Delay bound 50 ms N.A. N.A.
5.1.1 Real-time Services
The simulation platform selects VoIP to simulate real-time services in the network because VoIP service is common in the network. This platform simulates VoIP traffic in constant bit rate (CBR) mode and Markov on/off model. In the CBR mode, VoIP traffic source generates packets every 20 ms. Payload size of a VoIP packet is 160 bytes and the data rate is fixed at 64 Kbps (160 bytes per 20 ms).
The Markov on/off model [24, 25] is plotted in Fig. 5.2. Traffic source operated in the Markov on/off model generates packets in an uncertain way. There are “on” state and
“off” state. Traffic source generates packets periodically when it is in “on” state. The duration of on state is followed by an exponential distribution. Then, the traffic source will change its condition to “off” state and it will keep idle. The duration of traffic sources stay in the off state is also followed by an exponential distribution. The Mean values of the on and off state continues are equal to 1 second and 1.35 seconds [24, 25].
Table 5.2 lists the traffic model of real-time services in the simulation platform.
Fig. 5. 3 Traffic model of Markov on/off model
Table5. 2 Simulation model of VoIP services in this platform
Applications Interarrival time Packet size
VoIP CBR
20 ms per packet.
Fixed
packet length 160 bytes
VoIP Markov on/off model
On state
packet length 160 bytes
5.1.2 Non-real-time Services
Two types of the non-real-time services are simulated in this simulation platform. One is the web browsing service and another is file transport protocol (FTP) service. The traffic model of web browsing and FTP services is explained below.
Fig. 5.3 shows the packet trace of a typical web browsing session. The session is divided into ON/OFF periods representing web-page downloads and the intermediate reading times. In Fig. 5.3, the web-page downloads are referred to as packet calls.
Therefore, a packet call, like a packet session, is divided into ON/OFF periods. Unlike a packet session, the ON/OFF periods within a packet call are attributed to machine interaction rather than human interaction. When receiving a page, the web-browser will parse the HTML page for additional references to embedded image files such as the graphics on the tops and sides of the page as well as the stylized buttons. The retrieval of the initial page and each of the constituent objects is represented by ON period within the packet call while the parsing time and protocol overhead are represented by the OFF periods within a packet call. For simplicity, the term “page” will be used in this thesis to
object” and the each of the constituent objects referenced from the main object are referred to as an “embedded object”.
Fig. 5. 4 Packet trace of typical web browsing session
Fig. 5. 5 Contents in a packet call
Parameters for the web browsing traffic are as follows:
SM: Size of the main object in a page.
SE: Size of an embedded object in a page.
Nd: Number of embedded objects in a page.
Dpc:Reading time.
Tp: Parsing time for the main page.
Packet traffic characteristics within a packet call will depend on the version of HTTP used by the web servers and browsers. Currently two versions of the protocol, HTTP/1.0 and HTTP/1.1, are widely used by the servers and browsers. In this platform, the traffic model of HTTP/1.1 is accepted.
Parameters of web browsing service in the platform are listed in Table 5.3. In HTTP/1.1, persistent TCP connections are used to download the objects, which are located at the same server and the objects are transferred serially over a single TCP
connection; this is known as HTTP/1.1-persistent mode transfer. The TCP overhead of slow-start and congestion control occur only once per persistent connection. The distributions of the parameters for the web browsing traffic model were determined based on the literature on web browsing traffic characteristics [17].
Table5. 3 HTTP traffic model parameters
Component Distribution Parameters PDF Main object
Subtract k from the generated random value to obtain Nd. Reading time
(Dpc)
Exponential Mean = 30 sec
033
Exponential Mean = 0.13
69
Parameters for icat e ble5.4. Fig.5.5 plots the acket trace in a typical FTP session. In FTP applications, a session consists of a sequence of file transfers, separated by reading times. The two main parameters of an FTP session are:
the FTP appl ion sessions ar described in Ta p
S : the size of a file to be transferred
Dpc : reading time, i.e., the time interval between end of download of the previous file and the user request for the next file.
Fig. 5. 6 Packet trace in a typical FTP session
Table5. 4 FTP traffic model parameters
Component Distribution Parameters PDF File size (S) Truncated Mean = Lognormal 2Mbytes Std.
π
Dev. = 0.722
Exponential Mean = 180
006
5.
based on [18] are listed in table 2.3 and table 2.4. A simple link
ad ation ission modes. According to the studies
of channel conditions in WLAN [26-28], channel of this platform is set as AWGN
ch el a n and
variance ar l is listed in table 5.5.
e can assume that error probability of packet transmission is ignorable by using link .
1.3 PHY Layer Assumption
Many values such as SIFS, slottime or the time period each packets occupies the channel are correlated with the assumption of PHY layer. The transmission modes and value assumptions
apt is implemented based on these transm
ann nd the distribution of SNR will be log normal distribution which the mea e equal to 15 dB and 8 dB. Decision rule of rate contro
W
adaptation since good link adaptations would decrease error probability to very low
Table5. 5 Decision rule of link adaptation
Transmission Mode SNR Data rate(Mbps)
Mode 1 SNR< 7dB 6
5.1.4 Performance Crite lation Platform
Following performance criteria
ria in Simu
are considered:
Packet delay: The packet
e time interval from the time thatpacket arrives at the MAC layer to the ission.
delay is defined as th
beginning of a successful transm
Delay Jitter: Delay jitter is the standard deviation of the packet delay. Delay jitter
also affects the quality of real-time services when the delay jitter is large.Packet loss rate: In the simulation platform, packet loss happens because
packets stay in the buffer of the local transmitter longer than the delay bound thatthe real-time service can tolerate.
Capacity: The number of stations that the WLAN system allows to serve in the
system when the QoS is taken into account.Unsatisfied condition: Unsatisfied condition means that there is at least one
active real-time service which its packet loss rate larger than 1%. Unsatisfied condition is defined because the proposed VTSE algorithm reject a new real-time service request when is estimated that the unsatisfied condition will happen or the unsatisfied condition already happens.5.2 Simulation Results
In order to discuss rios are created for the
cation. n 5.2.1 discusses the proposed
ffic source estimation algorithm when all servi n the network are VoIP which generate pack . In sect 5.2.2, best effort services comparison towards a simple algorithm is discussed in section 5.2.3. Observation period of VTSE is 1 second when
oIP services are Markov de.
cenario I
sion in this scenario traffic features of VoIP users in WLAN and e performance of the proposed VTSE algorithm. All VoIP users generate packets in he performance.
ndition. The observed data is focus on
generat st
the sys cord of
Fig.5
the traffic features. Some scena
convenience of verifi Sectio performance of the
virtual tra ces i
services ets in the CBR mode ion
are added to observe the performance of VTSE. A
VoIP services are CBR mode and it will be set 5 seconds when V on/off mo
5.2.1 S
Discus is focus on the
th
CBR mode and the number of active VoIP users is adjusted to examine t Since the VTSE estimates the downlink traffic co
the downlink direction. In scenario I, there are some existing VoIP services begin to e packets in the beginning of simulation. Then, a new VoIP service reque appears during the simulation period. The proposed call admission control will estimate
tem condition and make decision according to its estimation and QoS re existing VoIP services after an observation period equal to 5 seconds.
.6 shows the VTSE estimated delay time and the observed packet queuing delay
in the d SE algorithm can estimated the transmission
conditi ervices is adjusted form 21 to 32.The
a new accepts close to
27th and the service performance begins to degrade
seriously. This phenomenon can be observed from the Fig.5.8. Fig.5.8 plots the average hen there are fixed number of VoIP services. Fig.5.8 reveals that the average unsatisfied users be
ownlink direction. It shows the VT
delay precisely. Fig.5.7 shows the observed conditional probability that unsatisfied on happens when the number of active VoIP s
conditional reject probability of VTSE algorithm is also plotted in Fig.5.7. VTSE rejects service request when it predicts that the network will be unsatisfied if the system the new VoIP service. Fig.5.7 reveals that the reject probability of VTSE basically the probability that unsatisfied condition happens in realistic except when the 28th VoIP service request. It is because
unsatisfied users in the system w
gin to increase seriously when there are 27 active VoIP users in the system.
Number of VoIP Services in the WLAN system
22 24 26 28 30 32
Delay
0.030
0.015 0.025
0.020
(Sec)
0.000 0.005 0.010
Predicted downlink packet delay Observed downlink packet delay
Fig. 5. 7VTSE estimated delay and the observed packet queuing delay in the downlink direction
Number of VoIP Users
22 24 26 28 30 32
Probability (%)
0 20 40 60 80 100
Probability which unsatisfied condition happens VTSE Reject Probability
Fig. 5. 8 Observed conditional probability that unsatisfied condition happens and the conditional reject probability of VTSE algorithm
Number of VoIP Services in the system
22 24 26 28 30 32
Number of Unsatisfied VoIP Users
0 5 10 15 20 25 30
Average number of unsatisfied VoIP Users in the system
Fig. 5. 9 Average unsatisfied users in the system when the number of VoIP services in fixed
Fig.5.9 tion
happens in the system ets in
Markov on/of te the average
length of on/of de and the VTSE
plots the VTSE reject probability and the probability that unsatisfied condi when VoIP users are fixed and all VoIP services generate pack f mode. It is assumed that the proposed VTSE can estima
plots the VTSE reject probability and the probability that unsatisfied condi when VoIP users are fixed and all VoIP services generate pack f mode. It is assumed that the proposed VTSE can estima