A network resource availability model for IEEE802.11a/b-based WLAN carrying different service types

Abstract

Operators of integrated wireless systems need to have knowledge of the resource availability in their different access networks to perform efficient admission control and maintain good quality of experience to users. Network availability depends on the access technology and the service types. Resource availability in a WLAN is complex to gather when UDP and TCP services co-exist. Previous study on IEEE802.11a/b derived the achievable throughput under the assumption of inelastic and uniformly distributed traffic. Further study investigated TCP connections and derived a model to calculate the effective transmission rate of packets under the assumption of saturated traffic flows. The assumptions are too stringent; therefore, we developed a model for evaluating WLAN resource availability that tries to narrow the gap to more realistic scenarios. It provides an indication of WLAN resource availability for admitting UDP/TCP requests. This article presents the assumptions, the mathematical formulations, and the effectiveness of our model.

1. Introduction

Operators that control integrated wireless systems with multiple radio access technologies (RATs) need to have a very good knowledge of the current context of each radio access network (RAN) to perform efficient call admission control and at the same time maintain a good quality of experience to their users. With the emergence of various service types, such as video call and streaming services, RAN selection needs to be intelligent and context aware. The selection not only should consider the user/service requirements, but it also should take into account the resource availability and the load of the networks. Network resource availability is an important attribute of the context information. The network availability is dynamic and dependent on the access technology and the service type. In order to develop a context aware RAN selection algorithm and investigate its performance, we have built a call level simulator which implements models of different wireless networks, where the resource availability of each network can be calculated at any time. We have developed models for UMTS and WLAN networks. In this article, we focus on the presentation of the mathematical formulations for the resource availability model we developed for IEEE802.11a/b networks. It is a simple but effective model for evaluating IEEE802.11a/b-based WLAN resource availability having in mind the prospective service requests of a heterogeneous wireless environment. We evaluated the effectiveness of the proposed mathematical model in providing resource availability information with simulations of a WLAN IEEE 802.11b network under the same traffic demands.

This rest of the article is organized as follows: Section 2 describes the basic operation of the IEEE 802.11 standard and presents some typical parameter values. Section 3 presents previous study on IEEE 802.11 standard analysis. Section 4 explains the proposed formulations for calculating the resource availability in IEEE802.11b WLAN. Section 5 shows the effectiveness of the proposed model and Section 6 presents the conclusion.

2. The IEEE 802.11 Standard

The IEEE 802.11 standard supports two MAC schemes: distributed coordination function (DCF) and point coordination function (PCF). PCF is a centralized mechanism which uses a central coordinator. The central coordinator polls the wireless stations and provides a contention free (CF) access to the channel. However, many commercial products do not implement the PCF scheme. On the other hand, the carrier sense multiple access with collision avoidance (CSMA/CA) based on DCF is widely used for supporting asynchronous data transfer on a best effort basis and provides fairness among the wireless stations.

The basic operation of the DCF can be described as follows. Before transmitting the first packet, the wireless station monitors the channel activity. If the channel remains idle for a DCF interframe space (DIFS) period, the station transmits the packet. If the channel is sensed as busy either immediately or during the DIFS period, the wireless station keeps monitoring the channel until it is idle for a DIFS period. Then, to minimize the probability of collision with the packets transmitted by other wireless stations, a random backoff time is generated. In order to avoid channel capture, the station also waits for a random backoff time between two consecutive packet transmissions, even though the channel is sensed as idle for a DIFS interval.

The backoff time is slotted. The size of a time slot depends on the physical layer and accounts for the propagation delay. At each packet transmission, the wireless station randomly selects the number of time slots in the range from 0 to the contention window (CW) - 1. The value of the CW depends on the number of unsuccessful packet transmissions. At the first transmission attempt, the value of the CW is equal to CW_min. CW_min is the minimum contention window. After each unsuccessful packet transmission, the value of the CW is doubled up to the maximum value CW_max.

After sensing the channel as idle for a DIFS period, the wireless station begins to decrease the backoff time counter. Before the counter reaches zero, if the channel is sensed as busy, the wireless station pauses the counter, and it reactivates the counting down only when the channel is sensed as idle for a DIFS period. When the backoff time counter reaches zero, the wireless station transmits the packet.

In the wireless channel, the stations cannot detect a packet collision by hearing their own transmissions. Therefore, after receiving a packet, the destination station waits for a short interframe space (SIFS) period and then transmits an acknowledgement (ACK) back to the transmitting station to signal the successful packet reception. Because the SIFS period and the consequent propagation delay are shorter than the DIFS period, other wireless stations cannot sense the channel as idle for a DIFS period until the ACK is transmitted. If the transmitting station cannot receive the ACK within a specific timeout or it senses a different packet in the channel, it considers the former packet transmission as unsuccessful and it schedules a retransmission according to the backoff rules.

For a multicast or broadcast packet, the transmitting station does not wait for the ACK because multicast destination stations do not transmit ACK. As a result, no retransmissions are made for multicast and broadcast packets in IEEE 802.11 DCF. The transmitting station or access point (AP) proceeds to the next packet regardless of whether the previous packet has successfully been received. Typical values for the IEEE 802.11b DCF parameters are described in Table 1[1].

Table 1 Typical values for the IEEE 802.11b DCF parameters

3. Previous work on IEEE 802.11a/b network analysis

The IEEE 802.11a/b-based WLAN uses CSMA/CA mechanism for the multiple access control. The performance of IEEE 802.11a/b-based WLAN has been investigated in [1, 2]. The authors of these articles attempted to model the IEEE 802.11a/b backoff mechanism and derive the achievable throughput and maximum channel utilization taking in account different network conditions and configurations. The models presented in these two articles have been used as basic analytical methods for investigating IEEE 802.11a/b-based WLAN performance and they are cited in many latter publications in the field. However, the authors of these articles assume that the traffic in the network is inelastic, which does not adjust its transmitting rate according to the available channel bandwidth. The authors also assume that the senders operate in an asymptotic (or saturated) condition, which means that their traffic sources have unlimited amount of data and in each sender's queue always there is a packet ready to send. Furthermore, the traffic is assumed to be uniformly distributed. That means each packet sent by one station is directed to another randomly selected station [3]. These assumptions are not very consistent with the reality. First, a IEEE 802.11a/b-based WLAN primarily provides users with non-real-time data services, e.g., web browsing, FTP, etc. 95% of the traffic in WLANs is composed of packets carried over the transport control protocol (TCP) [3]. The TCP traffic is elastic, because the TCP employs the flow control and the congestion control mechanisms to regulate its transmitting rate and avoid continuous packet transmission [3]. Moreover, even for inelastic traffic, the senders may not operate in the asymptotic condition. For example, in voice over IP (VoIP) services, the voice data will be segmented into packets and these packets are not transmitted continuously, but they are transmitted at fixed intervals. The size of the voice data packet and the length of the transmission interval depend on the voice encoder being used. Second, most WLANs operate in infrastructure-based mode, where the stations access network services through an AP. Therefore, the traffic is not uniformly distributed but all the packets are destined to/transmitted from the AP.

Bruno et al. [3] pointed out the above inconsistencies with real scenarios and investigated the performance of the TCP connections over IEEE802.11a/b-based WLANs. Bruno et al. [3] assume that the size of the TCP congestion window of each TCP flow is identical and, after an initial phase, the congestion window of each TCP flow grows to its maximum value. This assumption ensures that the TCP flows will have a fair access to the channel bandwidth. Bruno et al. also assume that each station in the WLAN possesses a single "long-live" TCP session, which has an unlimited amount of data at the source and at least one packet to transmit. However, this assumption is inconsistent with the reality when considering the characteristics of different service applications. For example, a typical Web Browsing service session is not a "long-live" TCP session and it can be divided into ON/OFF periods [4]. The ON period represents the web page download comprising of packet calls. The OFF period represents the intermediate reading time.

Based on the assumptions made in [3], Bruno et al. also presented a throughput analysis of UDP and TCP flows in WLANs [5]. However, they only considered the competition of multiple TCP downlink and uplink connections, with UDP uplink flows. Moreover, the UDP flows are still assumed to be saturated.

4. Network resource availability analysis

We realized that the assumptions of previous study are too stringent abstractions of the real scenarios. Therefore, we have developed a simple but effective model for evaluating resource availability in IEEE802.11a/b-based WLAN that tries to narrow the gap to more realistic network scenarios. Our model analysis various service types, including VoIP, Video Call, Audio Streaming, Video Streaming, Web Browsing, and File Transfer. The first four services are real-time and UDP-based. The others are non-real-time and TCP-based. For the TCP-based services, we assume the size of the TCP congestion window of each TCP flow is identical, the same assumption that was made by [3] to insure fairness.

We calculate the expected number of contending packets over the wireless channel, which is denoted by e_ncp. Assuming a new service request is made to the network, if e_ncp is greater than 1, it means that, on average, there is more than one packet in contention to access the network channel at any time. We have to consider the requested and the existing service types within the network before performing any decision. If the requested and the existing service types are hybrid (e.g., UDP-based and TCP-based services coexist) the connection request will be rejected. This is because packet collisions will cause unacceptable delays and packet loss for the real-time UDP-based services. If the requested and the existing service types are all TCP-based, the analysis method proposed in [3] will be implemented to calculate the effective transmission rate (excluding traffic and protocol overheads) of each packet generated by the requested connection and the existing users. If the effective transmission rate satisfies the requirements of all the users, the connection request will be admitted. If not, the request will be rejected.

For example, assuming e_ncp is 2, that means, on average there are two packets in contention to access the network channel at any time. In reality, not all services' sessions behave as a "long-live" TCP session, one example is the web browsing mentioned before. The packets transmitted over the network channel may be generated by more than two traffic sources. Therefore, these packets are supposed to be generated by two virtual TCP sessions coexisting in the network. These virtual TCP sessions always have packets in their queues and they are ready to send the packets at any time. Compared to the "long-live" TCP session assumed in [3], these two virtual TCP sessions behave in the same way. Therefore, the analytical method presented in [3] can be used to calculate the effective data transmission rate for each packet of the requested service and the existing services. For the IEEE802.11b-based WLAN, as an example, these two virtual "long-live" TCP sessions can have a fair access to the channel whose effective packet transmission rate is about 4,500 kbps. This value is derived from the analytical method presented in [3], which assumes that the size of the congestion window of each TCP flow is the same, the size of a data packet is 1,500 bytes (including the IP and TCP headers), and it uses the typical values of the IEEE 802.11b DCF parameters. The method in [3] was validated with realistic discrete-event simulations. Consequently, each virtual "long-live" TCP session can transmit each packet at an effective transmission rate of about 2,250 kbps. That means the payload of each packet generated by these two virtual "long-live" TCP sessions can be transmitted at the data rate of 2,250 kbps in the IEEE802.11b-based WLAN. The calculation of e_ncp takes into account the requested service and the existing services in the network. As mentioned before, the virtual "long-live" TCP session may comprise several real TCP-based service sessions. As a consequence, on average, each packet generated by each service session can be transmitted at an effective transmission rate of 2,250 kbps. If the minimum QoS requirements (e.g., data rate) of all the TCP-based services can be complied with, then the service request will be admitted. Otherwise, the service request will be rejected.

In a situation where the value of e_ncp is equal to or less than 1, on average there is less than one packet in contention to access the network channel at any time. For the UDP-based real-time services in the network, such as VoIP, the data packets do not have to compete with other packets for channel access, so that packet loss and severe delay can be avoided and the effective data rates are identical to the transmission rates of the encoders. For the TCP-based non-real-time services, without channel contention, each data packet can be transmitted at the maximum effective packet transmission rate (e.g., 4,500 kbps in the IEEE802.11b-based WLAN). If the minimum QoS requirements of the requested service and the existing services can be satisfied, the request will be admitted. Otherwise, the service request will be rejected.

The calculation of e_ncp is presented below. As we stated before, e_ncp is the expected number of contending packets over the wireless channel. For each connection in the network, two outcomes are possible: or there is a packet contending for the channel or there is not. The number of contending packets over a wireless channel can be considered as a random variable because of the characteristics of the CSMA/CA mechanism and the DCF scheme. Therefore, the e_ncp is the expected value of this random variable and can be calculated as the weighted average of its possible values multiplied by their probabilities:

$$e_{\mathsf{\text{ncp}}}=\sum _{i=0}^{N}i\times \left(\begin{array}{c}\hfill N\hfill \\ \hfill i\hfill \end{array}\right)\times {e_p}^i\times {\left(1-e_{{}_p}\right)}^{\left(N-i\right)}$$

(1)

where N is the number of existing connections in the network plus the new requested connection. e _p is the expected probability that the channel is occupied by a packet transmission. The number of connections considered per request depends on the type of service. For a VoIP service, two connection requests are considered (one in the uplink and one in the downlink), because the VoIP service is duplex and bi-directional. For an audio streaming, web browsing, or File Transfer service, only one connection request is considered. This is because the above services are asymmetrical and the downlink traffic plays a major role. Therefore, for simplicity reasons, the evaluation model neglects the uplink traffic and concentrates only on the downlink. For a video call service, four connection requests are considered, because the video call service not only is duplex and bi-directional, but it also consists of two parts: video and voice. Similarly, a video streaming service introduces two connections requests. Below we show an example of how e_ncp is calculated when there are three audio streaming sessions in the network. e_ncp is calculated as the weighted average of zero, one, two and three contending packet(s) over the wireless channel:

$$\begin{array}{lll}\hfill e_{\mathsf{\text{ncp}}}& =0\times \left(\begin{array}{c}\hfill 3\hfill \\ \hfill 0\hfill \end{array}\right)\times {e_p}^0\times {\left(1-e_{{}_p}\right)}^{\left(3-0\right)}+& \hfill \\ =1\times \left(\begin{array}{c}\hfill 3\hfill \\ \hfill 1\hfill \end{array}\right)\times e_p^1\times {\left(1-e_p\right)}^{\left(3-1\right)}+& \hfill \\ =2\times \left(\begin{array}{c}\hfill 3\hfill \\ \hfill 2\hfill \end{array}\right)\times e_p^2\times {\left(1-e_p\right)}^{\left(3-2\right)}+& \hfill \\ =3\times \left(\begin{array}{c}\hfill 3\hfill \\ \hfill 3\hfill \end{array}\right)\times e_p^3\times {\left(1-e_p\right)}^{\left(3-3\right)}& \hfill \\ \hfill \end{array}$$

We calculate the value of e _p by the equation below:

$$e_p=\sum _s^{}\left(p\text{\_}o{n}_s\times n_s∕N\right)$$

(2)

where s represents the service type and p_on _s is the probability that the channel is occupied by the transmission of the packets belonging to the service type s. n _s is the number of connections of service type s and its value is service dependent.

The calculation of p_on _s is service dependent. For the inelastic real-time services, p_on _s can be derived as:

$$p\text{\_}o{n}_s=e\text{\_}t\text{\_}{p}_s∕in\text{\_}{p}_s$$

(3)

in_p _s represents the packet interarrival time of service type s. e_t_p _s is the expected time spent in completing the transmission for a packet of service type s. It consists of not only the time used for transmitting the packet payload and the headers, but also the overheads introduced by the CSMA/CA mechanism [6]. Below, we explicitly show how in_p _s and e_t_p _s are calculated for different real-time services.

For example, a VoIP codec that generates 50 packets per second at a data rate of 8 kbps, provides a packet interarrival time in_p_voip of 20 ms and a packet size of 20 bytes, corresponding to the payload. As the IP/UDP/RTP header size is 40 bytes, the expected time spent in completing the transmission for a packet of VoIP service, denoted as e_t_p_voip, can be calculated as follows:

$$\begin{array}{lll}\hfill e\text{\_}t\text{\_}{p}_{\mathsf{\text{voip}}}=& DIFS+e\text{\_}idle+phy\text{\_}mac\text{\_}hdr+& \hfill \\ t\text{\_}b\times \left(20+40\right)+delay+SIFS+delay+t\text{\_}ack& \hfill \\ \hfill \end{array}$$

(4)

DIFS represents the DCF inter-frame space and SIFS represents the short inter-frame space [6]. e_idle is the average backoff time based on [1]. phy_mac_hdr is the time spent in transmitting the physical and MAC layer headers. t_b means the time used for transmitting a byte in the WLAN. delay represents the maximum propagation delay between two wireless stations [1]. t_ack is the time used to transmit an ACK packet. Table 1 shows typical values for most of the overheads above for an IEEE802.11b DCF network.

A video call service consists of two parts: video and voice. Let us assume the video codec generates 10 frames per second at a data rate of 64 kbps. That means the frame interarrival time in_p _{video_call_video_part} is 10 ms and the frame size is 800 bytes. However, considering the instability of the radio channel, the packet size of the real-time services is suggested to be around 100 bytes [7]. Therefore, one video frame is divided into eight blocks and on average the size of each block is 100 bytes. e_t_p _{video_call_video_part} can be derived as:

$$e\text{\_}t\text{\_}{p}_{video\text{\_}call\text{\_}video\text{\_}part}=\left(\begin{array}{c}DIFS+e\text{\_}idle+phy\text{\_}mac\text{\_}hdr+\\ t\text{\_}b\times \left(100+40\right)+delay+SIFS+\\ delay+t\text{\_}ack\end{array}\right)\times 8$$

(5)

Assuming the voice codec generates 33 packets per second at a data rate of 6.3 kbps, the packet interarrival time in _p _{video_call_voice_part} is 30 ms and the packet size is 24 bytes. e_t_p _{video_call_audio_part} can be calculated based on Equation 4 only changing the value of the payload to 24 bytes.

For an audio streaming service, let us assume that a G.726 voice codec is used and it generates 50 packets per second, the packet interarrival time is 20 ms and therefore the in _p _{audio_str} is 20 ms. Two service classes can be considered: a basic class and a premium class. For the basic service class, let us assume a data rate of 32 kbps, which means that the packet payload is 80 bytes. Therefore, e _t _p _{audio_str} the can be calculated as:

$$\begin{array}{lll}\hfill e\text{\_}t\text{\_}{p}_{audio\text{\_}str}& =DIFS+e\text{\_}idle+phy\text{\_}mac\text{\_}hdr+& \hfill \\ t\text{\_}b\times \left(80+40\right)+delay+SIFS+delay+t\text{\_}ack& \hfill \\ \hfill \end{array}$$

(6)

For a premium service class, let us assume a data rate of 64 kbps. Therefore, the size of the packet payload is 160 bytes. We can use Equation 6 and only change the value of 80 to 160 to calculate the value of e _t _p _{audio_str} for the premium service.

Similar to the video call service, a video streaming service also comprises of two parts: video and audio. Therefore, two probabilities should be considered: p _on _{video_str_video_part} and p _on _{video_str_audio_part} . p _on _{video_str_video_part} is the probability that the channel is occupied by the transmission of the video packets of the video streaming service. p _on _{video_str_audio_part} is the probability that the channel is occupied by the transmission of the audio packets of the video streaming service.

Let us assume that the video part employs H.264, which generates 30 frames per second, with consequent frame inter-arrival time of 33 ms. Therefore, the value of in _p _{video_str_video_part} is 33 ms. Two service classes could be considered: the basic class and the premium class. For the basic service class, the video data rate could be assumed to be 64 kbps, which means that, on average, the frame payload is 266 bytes. One frame is divided into four blocks and the size of each block is 66 bytes. Therefore, e _t _p _{video_str_video_part} can be calculated as:

$$e\text{\_}t\text{\_}{p}_{video\text{\_}str\text{\_}video\text{\_}part}=\left(\begin{array}{c}DIFS+e\text{\_}idle+phy\text{\_}mac\text{\_}hdr+t\text{\_}b\times \left(66+40\right)\\ +delay+SIFS+delay+t\text{\_}ack\end{array}\right)\times 4$$

(7)

For the premium service class, the video data rate could be assumed to be 128 kbps. On average, the frame payload is 533 bytes. One frame is divided into eight blocks and the size of each block is 67 bytes. e _t _p _{video_str_video_part} can be calculated as in Equation 7 by only changing the value of the payload from 66 to 67 and multiplying by 8 instead of 4.

Similarly, for the audio component, the p _on _{video_str_audio_part} can be calculated. Let us assume that the audio part employs G.726, which generates 50 packets per second and its data rate is 32 kbps. It means that, the packet inter-arrival time is 20 ms and the packet payload is 80 bytes. This is similar to the audio streaming service in Equation 6 and it can be calculated in the same way.

The calculation of in_p _s and e_t_p _s is different for non-real time services based on TCP. For example, for an active File Transfer service session, the user receives data packets from the FTP server, and replies with TCP acknowledgement packets. Before the file is completely transferred, there is a packet, which can be a data packet or a TCP acknowledgement packet, in contention to access the network channel at any time. Therefore, the value of p_on _{file_transfer} is 1 and an active File Transfer service session can be considered as one "long-live" TCP session [3].

For a Web Browsing service, the following characteristics (based on [4, 8]) are taken into account for the calculation of p_on _{web_browsing} . The Web Browsing service is based on the HTTP protocol. A Web Browsing service session can be divided into ON/OFF periods, which are the result of human interaction. An ON period represents the download of a web page, which can be referred to a "packet call" shown in Figure 1[4]. An OFF period represents the intermediate reading time for digesting the downloaded web page. During ON periods, the user receives data packets from the HTTP server and replies with TCP acknowledgement packets. Before the web page is completely downloaded, there is a packet, which can be a data packet or a TCP acknowledgement packet, in contention to access the network channel at any time. Therefore, during the ON period, the Web Browsing service session can be considered as one "long-live" TCP session. During the OFF periods, the user reads the web page and no data transmissions take place between the user and the HTTP server. p_on _{web_browsing} can be calculated as:

Figure 1

Packet trace of a typical web browsing session.

$$p\text{\_}o{n}_{web\text{\_}browsing}=\frac{e\text{\_}t\text{\_}{p}_{web\text{\_}page}}{e\text{\_}t\text{\_}{p}_{web\text{\_}page}+avg\text{\_}reading\text{\_}time}$$

(8)

e_t_p _{web_page} is the expected time spent in completing the transmission of a web page. avg_reading_time is the average time spent in reading a downloaded web page, which could be assumed to be 30 seconds from the values published in [9].

Depending on the traffic condition in the WLAN, the value of e_t_p _{web_page} can be firstly estimated in two ways. If the value of e_ncp is smaller than the number of active File Transfer service sessions plus one, e_t_p _{web_page} can be approximated as:

$$e\text{\_}t\text{\_}{p}_{web\text{\_}browsing}=\frac{avg\text{\_}size\text{\_}web\text{\_}page\times 8}{wlan\text{\_}data\text{\_}rate/\left(n\text{\_}ftp\text{\_}session+1\right)}$$

(9)

avg_size_web_page is the average size of a web page in bytes, which could be assumed to be 312,000 bytes based on the values published in [8]. wlan_data_rate is the effective TCP packet transmission rate in the WLAN (e.g., 4,500 kbps for the IEEE802.11b-based WLAN). n_ftp_session is the number of active File Transfer service sessions in the WLAN.

Equation 9 is derived considering that the Web Browsing service sessions in the WLAN are not able to constitute a virtual " long-live" TCP session. An active File Transfer service session can be considered as one "long-live" TCP session. As the value of e_ncp is smaller than the number of File Transfer service sessions plus one, it means that, by neglecting the File Transfer service sessions, the Web Browsing service sessions cannot make the value of e_ncp greater than or equal to one. Such result indicates that, on average, there is less than one Web Browsing service packet in contention to access the network channel at any time. Therefore, from a Web Browsing service session's point of view, during the ON period, the major competition it will face is from the active File Transfer service sessions rather than the peer Web Browsing service sessions. Therefore, the effective packet transmission rate for the Web Browsing service session can be calculated as wlan_data_rate/(n_ftp_session+1).

If the value of e_ncp is greater than or equal to the number of active File Transfer service session plus one, e_t_p _{web_page} can be approximated as:

$$e\text{\_}t\text{\_}{p}_{web\text{\_}browsing}=\frac{avg\text{\_}size\text{\_}web\text{\_}page\times 8}{wlan\text{\_}data\text{\_}rate/e_{\mathsf{\text{ncp}}}}$$

(10)

Equation 10 is derived considering that the Web Browsing service sessions in the WLAN can constitute virtual "long-live" TCP session(s). As the value of e_ncp is greater than or equal to the number of File Transfer service sessions plus one, it means that, by neglecting the File Transfer service sessions, the Web Browsing service sessions can make the value of e_ncp greater than or equal to one. Such result indicates that, on average, there is at least one Web Browsing service packet in contention to access the network channel at any time. Therefore, from a Web Browsing service session's point of view, during the ON period, the major competition it will face is not only from the active File Transfer service sessions but also from the peer Web Browsing service sessions. Therefore, the effective packet transmission rate for the Web Browsing service session can be calculated as wlan_data_rate/e_ncp.

5. Effectiveness of the e_ncpmodel

In this section, we evaluate the ability of our model in predicting the resource availability in a WLAN. We consider an IEEE802.11b-based WLAN and compare the information provided on the resource availability given by e_ncp with the simulation results obtained from a packet level simulator of an IEEE802.11b network under the same traffic demand.

We used OPNET to simulate the IEEE802.11b network and the service types. The network topology is depicted in Figure 2. In the OPNET simulations, the physical layer parameters needed by the MAC were configured based on the typical values shown in Table 1, and the channel was associated with a data rate of 11 Mbps.

Figure 2

Network topology of the validation model.

In the simulations, the wireless stations (denoted as STA_1, STA_3, etc.) are distributed in a Basic Service Set. These wireless stations communicate with an access point, AP_1. The AP_1 is connected to an Ethernet switch, Switch_1. The Switch_1 communicates with the wired stations, which are denoted as CN_E_2, CN_E_4, etc. The wired stations are acting as the correspondent nodes to the wireless stations. For example, CN_E_2 is the correspondent node to STA_1. For conversational services, such as VoIP and video call, both the wireless and wired stations are acting as packet transmitters and receivers. For streaming services, such as video streaming and audio streaming, only the downlink is simulated and the wired stations act as the packet transmitters and the wireless stations act as the packet receivers.

We have validated our model by evaluating the results of the resource availability given by e_ncp against the OPNET simulations for requests of each service in isolation first. We have evaluated scenarios for VoIP basic services only, for VoIP premium services only, for basic video call services only, for premium video call services only, and so on. After, we evaluated scenarios with several different types of service requests. In all the evaluated scenarios, the results of the OPNET simulations agreed with the expected behaviour of the network from what was informed by resource availability model through the values of the e_ncp. In this article, we present only two of the scenarios we have evaluated. Details of all remaining evaluated scenarios can be found in [10].

The first scenario is composed only by VoIP service requests. The second scenario is a mixed application scenario composed of VoIP, video call, audio streaming, and video streaming services. For each scenario presented in this article, we analyse the network behaviour under two different demands of traffic.

In the first network scenario, all the service requests are Premium VoIP services. For the premium class, we assumed the VoIP service employs GSM610 as the codec with a data rate of 13.2 kbps. The GSM610 codec acts as a CBR traffic source and generates 50 packets per second, which means that the packet inter-arrival time is 20 ms and the packet payload is 33 bytes. Therefore, e _t _p _{VoIP_premium} can be calculated as:

$$\begin{array}{c}e\text{\_}t\text{\_}{p}_{VoIP\text{\_}premium}=DIFS+e\text{\_}idle+phy\text{\_}mac\text{\_}hdr+\\ t\text{\_}b\times \left(payload+ip\text{\_}udp\text{\_}rtp\text{\_}hdr\right)+\\ delay+SIFS+delay+t\text{\_}ack\\ =0.00005+0.0003+\left(0.000192+272/11000000\right)+\\ \left(8/11000000\right)\times \left(33+40\right)+0.000001+0.00001+\\ 0.000001+0.000248=0.0008788\end{array}$$

The average backoff time was assumed to be of 300 μs and the maximum propagation delay between two wireless stations was assumed to be of 1 μs (same assumptions made in [1]). Then, p _on _{VoIP_premium} can be derived based on Equation 3 as:

$$\begin{array}{lll}\hfill p\text{\_}o{n}_{VoIP\text{\_}premium}& =e\text{\_}t\text{\_}{p}_{VoIP\text{\_}premium}∕in\text{\_}{p}_{VoIP\text{\_}premium}& \hfill \\ =0.0008788/0.02& \hfill \\ =0.04394& \hfill \\ \hfill \end{array}$$

Assuming only the premium VoIP service users are in the network, the value of e _p can be obtained:

$$\begin{array}{lll}\hfill e_p& =\sum _{s}p\text{\_}o{n}_s\times n_s∕N& \hfill \\ =p\text{\_}o{n}_{VoIP\text{\_}premium}\times n_{VoIP\text{\_}premium}∕N& \hfill \\ =p\text{\_}o{n}_{VoIP\text{\_}premium}& \hfill \\ =0.04394& \hfill \\ \hfill \end{array}$$

Because this scenario only considers the VoIP service, N (the number of existing connections in the network plus the new requested connection) is equal to n _s (n _s is the number of connections of service type s). Therefore, e _p is equal to p _on _{VoIP_premium} . Then, e _ncp can be calculated using Equation 1. Assuming there are 11 premium VoIP users, the number of user connections in the WLAN is 22 and e _ncp can be derived as:

$$\begin{array}{lll}\hfill e_{\mathsf{\text{ncp}}}& =\sum _{i=0}^{N}i\times \left(\begin{array}{c}\hfill N\hfill \\ \hfill i\hfill \end{array}\right)\times {e_p}^i\times {\left(1-e_p\right)}^{\left(N-i\right)}& \hfill \\ =\sum _{i=0}^{22}i\times \left(\begin{array}{c}\hfill 22\hfill \\ \hfill i\hfill \end{array}\right)\times {0.04394}^i\times {\left(1-0.04394\right)}^{\left(22-i\right)}& \hfill \\ =0.9678& \hfill \\ \hfill \end{array}$$

e _ncp is smaller than one, which means, on average, there is less than one packet in contention to access the network channel. Therefore, when there are 11 users, the contention to access the network channel is still low and the quality requirements for the VoIP service can be satisfied. Assuming a twelfth premium VoIP user is connected to the WLAN, the number of user connections is increased to 24 and e _ncp can be derived as:

$$\begin{array}{lll}\hfill e_{\mathsf{\text{ncp}}}& =\sum _{i=0}^{N}i\times \left(\begin{array}{c}\hfill N\hfill \\ \hfill i\hfill \end{array}\right)\times {e_p}^i\times {\left(1-e_p\right)}^{\left(N-i\right)}& \hfill \\ =\sum _{i=0}^{24}i\times \left(\begin{array}{c}\hfill 24\hfill \\ \hfill i\hfill \end{array}\right)\times {0.04394}^i\times {\left(1-0.04394\right)}^{\left(24-i\right)}& \hfill \\ =1.055782& \hfill \\ \hfill \end{array}$$

e _ncp slightly exceeds 1. These results indicate that the WLAN should be able to support 11 premium VoIP users, but not 12 VoIP premium users.

Now, we evaluate the information given above by e _ncp with the simulations in OPNET. The parameters used in the OPNET simulation are shown in Table 2.

Table 2 Premium VoIP traffic generation parameters

The OPNET simulation results are shown in Figures 3, 4, 5, and 6. Figures 3 and 4 present the average delay of the packets received by a wireless station and the delay variation when there are 11 premium VoIP users. The figures also highlight the value of e _ncp calculated before. When there are 11 premium VoIP users in the WLAN, Figure 3 shows that the average packet delay is about 3.2 ms, which is under the constraint of 400 ms [11, 12]. Therefore, this value is acceptable for the real-time VoIP service. Moreover, Figure 4 depicts the fluctuations in packet delay; note that the packet delay variation is less than 0.85 ms, which is under the constraint of 1 ms [11, 12]. These results show that the WLAN network is capable of providing acceptable quality of service when 11 premium VoIP users are in the network.

Figure 3

Average delay with 11 premium VoIP users ( e _ncp = 0.9678).

Figure 4

Delay variation with 11 premium VoIP users ( e _ncp = 0.9678).

Figure 5

Average delay with 12 premium VoIP users ( e _ncp = 1.055782).

Figure 6

Delay variation with 12 premium VoIP users ( e _ncp = 1.055782).

Figures 5 and 6 present the average delay of the packets received by a wireless station and the delay variation at a wireless station when there are 12 premium VoIP users and the value of e_ncp is 1.055782. When there are 12 premium VoIP users in the WLAN, Figure 5 shows that after the fluctuations in the early stage of the simulation, the average packet delay stabilises at around 6.2 ms. This value is acceptable for the real-time VoIP service. However, Figure 6 depicts fluctuations in packet delay and the delay variation is greater than 1 ms. The delay variation exceeds the constraint of 1 ms and is unacceptable. The WLAN network is unable to provide acceptable quality of service when 12 premium VoIP users are in the network and should not admit more than 11 premium VoIP users.

The second network scenario contains various service types, including VoIP, video call, audio streaming, and video streaming. The streaming services can belong to two service classes: basic and premium. The basic service class demands a lower bandwidth, which provides the minimum quality constraint and threshold that the service should meet. The premium service class demands a higher bandwidth, which provides better service quality when resources are available. The service parameters and typical values assumed in this article are listed in Table 3.

Table 3 Service parameters and typical values

Assuming that there is one request for each service type and service class shown in Table 3, we have in total 12 connection requests to consider in the WLAN. Based on Equations 2 to 7, e _p can be calculated as 0.077478. Then, e_ncp can be calculated using Equation 1 resulting in a value of 0.929735. e_ncp is smaller than 1, which means, on average, there is less than one packet in contention to access the network channel. Therefore, the IEEE802.11b-based WLAN is evaluated as being capable to support these users.

When one more video call request is added into the network, the number of connection requests increases to 16 and e _p becomes 0.071033. The new calculated value of e_ncp is 1.13652 that exceeds 1. Considering the UDP-based real-time services within the WLAN, the video call request should be rejected to maintain the service quality of the existing users.

The OPNET simulation results, as shown by Figures 7 and 8, also validate the above predictions given by e_ncp. Before adding one more video call user, the packet average delay is about 1.9 ms, as depicted in Figure 7. This value is acceptable for both conversational and streaming services [11, 12]. The simulation results indicate that the WLAN is capable to provide good service quality when the value of e_ncp is 0.929735.

Figure 7

Average packet delay for VoIP service ( e _ncp = 0.929735).

Figure 8

Average packet delay of the VoIP Service with e _ncp = 1.13652.

However, after adding one more video call user into the network, the simulation results indicate that the WLAN performance is worsened and this affects the service quality of all the users. According to Figure 8, the value of the average packet delay increases dramatically and reaches a value around 300 ms. This value is not acceptable for conversational services [11, 12]. Therefore, to maintain an acceptable service quality, the video call request should be rejected.

In all the presented results, the OPNET simulations confirmed the expected behaviour of the network from what was indicated by the resource availability model through the values of the e_ncp. It is important to stress that our mathematical model is an approximate prediction of the expected behaviour of the network based on the assumptions made, and therefore it cannot be taken as an exact model to predict the behaviour of the network. However, it is simple and very effective; consequently it can be used as a conservative measure of the resource availability of the networks in admission control decisions.

We did not perform simulations on IEEE 802.11a, however, in terms of our proposed mathematical model, as the MAC layer mechanisms of IEEE 802.11a and IEEE 802.11b are the same, the calculation of e_ncp would not be different for IEEE 802.11a networks, only the typical parameter values of the IEEE 802.11a standard should be used instead (DIFS, SIFS, etc.). We expect the effectiveness of the predictions of e_ncp would be similar for an IEEE 802.11a network as the ones verified for the IEEE 802.11b network.

6. Conclusion

In this article, we proposed a simple but effective model for evaluating IEEE 802.11a/b-based WLAN resource availability. The mathematical model defines the expected number of contending packets (e_ncp), and combines it with previous research on WLAN to provide an indication of the resource availability of a WLAN network for admitting or not real-time and non-real-time requests. The model has in mind the characteristics of the access technology and the prospective service requests of a heterogeneous wireless environment. Although our model is an abstraction of real networks, it is based on appropriate assumptions, and effectively obtains important network context information that can help in the development and evaluation of efficient RAN selection algorithms. We compared the predictions of our model with numerical results obtained through simulations carried out using OPNET under the same traffic demands. The simulation results have confirmed the effectiveness of our mathematical model and they have shown that our model has the ability to capture the resource availability for a WLAN and provide a fairly good indication of the expected behaviour of the network. Although our mathematical model is not exact and it does not make any explicit guarantees in terms of the delay behaviour, it is very useful as an approximation of the expected behaviour of the network, and it can be used as a conservative indication of the availability of the network for call admission decisions.