Implementation and performance analysis of modified DCF MAC in OPNET

IT601 Mobile Computing Course Project Report By

Jeevan Chalke (06329011) Avadhoot Punde (06329029) Kedar Rudre (06329036)

Under the guidance of

Prof. Anirudha Sahoo

November 2006

Abstract
In the last few years there has been rapid growth in the 802.11 based wireless devices. Now days these devices have made their way in many domains and will continue to do so in the coming years. Yet there is no support for advance features such as service differentiation, etc in 802.11 required in specific application domains. Running real time applications such as real time video and voice require QoS in terms of delay, throughput, etc. But there is no such QoS support in 802.11. Here we study and implement a modified MAC protocol based on 802.11 which provide QoS in terms of delay, throughput etc, to real time applications. Here we discuss two MAC protocols, Overlapping Windows and Non-overlapping Windows which provide service differentiation using two priority classes. Service differentiation is provided by assigning different contention windows to different priorities.

ii

Acknowledgement
Apart from our efforts, the success of any project depends largely on the encouragement and guidelines of many others. We take this opportunity to express our gratitude to the people who have been helpful in the successful completion of this project. We would like to thank Prof. Anirudha Sahoo for giving us this opportunity to do the project and supporting it with his ideas. We would also like to thank Mr. Mayank Mishra for providing guidance and to Mr. Venkat Reddy who helped us regarding code modification and programming in OPNET.

Jeevan Chalke Avadhoot Punde Kedar Rudre

iii

Table of Contents
Abstract Acknowledgement List of Figures 1 Introduction 1.1 Motivation Distributed coordination Function (DCF) Modified DCF 3.1 Non-overlapping window modified DCF 3.2 Overlapping window modified DCF Implementation Performance Evaluation 5.1 Low Load Analysis 5.2 Medium Load Analysis 5.3 High Load Analysis Conclusion Bibliography ii iii v 1 1 2 3 3 3 5 6 6 9 11 16 17

2 3

4 5

iv

List of Figures
Figure 1: Distributed Coordination Function Figure 2: Normal 802.11 Contention Window Figure 3: Non-Overlapping Contention Window Figure 4: Overlapping Contention Window Figure 5: Low Load Throughput Figure 6: Low Load Delay Figure 7: Received voice Traffic low Load Figure 8: Voice End to End Delay Figure 9: Jitter Low Load Figure 10: Throughput Medium Load Figure 11: Delay in Medium load Figure 12: Voice traffic received, Medium load Figure 13: Voice End to End Delay Medium load Figure 14: Jitter, Medium Load Figure 15: Throughput, High Load Figure 16: Delay, High Load Figure 17: Voice Traffic Received, High Load Figure 18: Voice Delay, High Load Figure 19: Jitter, High Load Figure 20: Voice Traffic Received Figure 21: Video End to End Delay Figure 22: Video Delay Variation 2 3 3 4 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15

1. Introduction
Wireless networks based on the 802.11 suite of protocols are becoming a very popular and common means of networking in both enterprise and home environments. Due to its advantages it has been adopted by various domains each with its own set of requirement. But due to diverse applications requirement 802.11 could not accommodate all the fulfillments. The 802.11 protocol was designed to create a high-speed data network with shared access to the wireless spectrum and some basic guarantees on packet delivery. The QoS parameters like throughput and delay requirements are not fully addressed in the original standard.

1.1 Motivation
Real time applications involving voice and video transmission over a network have stringent requirements of QoS in terms of delay, throughput, etc. The underlying network should provide these QoS for the proper functioning of the applications. The 802.11 do not have any inherent QoS support for real time applications. To solve these problems 802.11e standard is proposed which has QoS enhancement. But the problem with the implementation of 802.11e is that the most of the current WLAN infrastructure is 802.11 based. Thus there is need of IEEE 802.11 based QoS mechanism. Here we study two MAC protocols that are based on 802.11 and will provide QoS using service differentiation by assigning two priority levels. The priorities are assigned on the node basis. Thus either nodes priority is enabled or it is disabled. The nodes carrying real time traffic will have their priority enabled. The modified DCF assigns different Contention Window size to different priorities. In one protocol the nodes carrying real time traffic, that is, nodes having high priorities select a backoff slot between 1 to CW/2 and the low priority nodes select a backoff between CW/2 +1 to CW. Here the backoff slots selected by a low priority station and a high priority station are from non-overlappping parts; hence we call this scheme as Non-overlapping window. In the other protocol the high priority stations select a backoff slot from 1 to CW/2 whereas the low priority stations select a random backoff from 1 to CW. Thus the two parts from where the low and high priority stations select random backoff slot overlaps; hence we call this scheme as Overlapping Windows. The report proceeds with the study and analysis of the DCF (Distributed Coordination Function). Then we present the Modified DCF protocols, where we discuss both the protocols in details, which is followed by the implementation details of the protocols. Then we move on to the analysis of the protocols and finally we conclude our results depending upon the analysis done.

2. Distributed coordination Function (DCF)

DCF is the fundamental access mechanism in the IEEE 802.11 MAC. In this section we will briefly describe the basic access mechanism of DCF. When a node (station) receives a packet to transmit, if the node senses the medium has been idle for a period of time longer than or equal to a Distributed Inter Frame Space (DIFS), the packet transmission may begin at the beginning of the immediately following slot. Otherwise, the node should defer the packet transmission as follows. The node waits until the medium is idle for a DIFS and then sets its backoff timer. The backoff timer is set to a value which is randomly selected between 0 to CW-1 with equal probability, where CW represents contention window size, see Figure 1. Initially, contention window size is set to its minimum CWmin for the first transmission attempt of a packet. Every time the packet is involved in a collision, contention window size is doubled for the next transmission attempt. However, the contention window size cannot exceed its maximum CWmax.

Figure 1: Distributed Coordination Function [1] The backoff timer is decreased by 1 every slot time after the medium has been idle for a DIFS, but is frozen when the medium becomes busy. When the backoff timer becomes zero, the station transmits the packet. If the destination node receives the packet correctly, it sends a positive acknowledgment (ACK) packet after a Short Inter Frame Space (SIFS). When the source node does not receive an ACK, it assumes the packet has experienced a collision and updates the contention window size CW according to Binary Exponential Backofff algorithm as described above, then sets its backoff timer to a newly selected backoff values after a Extended Inter Frame Space (EIFS). Since the number of transmission retries is bounded by N, a packet must be dropped after N transmission retries, that is, after experiencing N times of packet collision.

3. Modified DCF
There are two protocols in which DCF is modified Overlapping window modified DCF and Non-overlapping window modified DCF. Both of them provide two levels of priorities to the nodes high level and low level. Low level is intended for nodes running normal network applications whereas high level is intended for nodes running real time applications such as voice over IP and video transmission. Priorities are decided by changing contention window for backoff mechanism. This does not define priority of a node in a strict way, but as compared to 802.11 protocols, this is an attempt to provide service differentiation. If medium is idle then all nodes have equal priority to send a packet, but in case the medium is found busy, nodes choose to backoff with contention window. As nodes are choosing CW based on their priority, priority assignment is evident here. The protocols are described in detail as follows. Figure 1 shows normal 802.11 contention window.

Figure 2: Normal 802.11 Contention Window

3.1 Non-overlapping window modified DCF

In this protocol, high priority nodes use contention window from 0 to CW/2 and low priority nodes use contention window CW/2 to CW, as shown in Figure 3. In this case, high priority node is bound to get less contention window than low priority node. However, two high priority nodes compete with each other as they are using same contention window. Since the nodes with high priority selects less number of backoff slots they get transmission chance early as compared to low priority stations, thus increasing their throughput and reducing the delay.

Figure 3: Non-Overlapping Contention Window

3.2 Overlapping window modified DCF

In this protocol, as shown in Figure 4, high priority nodes use contention window from 0 to CW/2 and low priority nodes use contention window 0 to CW. In this case, a high priority node is more probable to choose less value for contention window as compared

to a low priority node. Nevertheless, it is possible that a low priority node gets preference over a high priority node in some situations.

Figure 4: Overlapping Contention Window Theoretically, first protocol should give better throughput for high priority nodes as compared to second protocol. On the other hand, second protocol is trying to assign priorities and at the same time, it is reducing starvation of low priority nodes.

4. Implementation
Simulation is performed in OPNET. OPNET modeler provides a 802.11 wireless LAN station- wlan_wkstn, wlan_ethernet_router and ethernet_server. These are sufficient for our purpose. Following are the steps for changing the code: Step 1: In Node model editor, open process editor by double clicking wireless_lan_mac process model. Step 2: Click on edit properties for Wireless LAN Parameters and add a variable called Priority as a toggle (Boolean) type. Step 3: Compile the code. Now wlan_wkstn has Priority as an attribute. Step 4: Open wlan_mac process model editor. Step 5: Add state variable corresponding to Priority (Boolean type). Step 6: Change the code in BKOFF_NEED state. Here is the C code :
if(Priority) backoff_slots = floor (op_dist_uniform (max_backoff / 2)); else backoff_slots = floor (op_dist_uniform (max_backoff));

Step 7: Compile the code. Step 8: Now OPNET is setup with new protocol. (Here we have shown code for Overlapping window modified DCF protocol. It is quite simple to change it for Non-overlapping window modified DCF protocol). Step 9: Setup appropriate scenario. Change priorities of the node as required and run the simulation.

5. Performance Evaluation
In this section we present the performance analysis of the Modified DCF. We have implemented the Modified DCF in OPNET by and have simulated the result in the same. We have compared modified DCF, both overlapping as well as non-overlapping windows with the 802.11. We have analyzed the performance of the algorithms under low load (1.4Mbps), Medium Load (6.5 Mbps) and High Load (above 11 Mbps). Under different loads we measure the performance of the system throughput, total delay, Voice data received, Jitter, and Voice End to End Delay. We have considered voice traffic as high priority traffic in low and medium load and have also included video traffic for high load scenario. As low priority we have considered best effort traffic such as web and telnet for al the three loads.

5.1 Low Load Analysis

Throughput :

In case of low load the offered load is very less as compared to the capacity of the system. That is why there are very less collisions and the throughput of all the three schemes is almost same, see Figure 5.
Throughput (Low Load, WLAN)
800000 Throughput (bits/sec) 700000 600000 500000 400000 300000 200000 100000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 5: Low Load Throughput Delay :

From Figure 6 we can infer that the Modified DCF works much better as compared to 802.11. The delay experience in case of Modified DCF is much less as compared to the delay in 802.11.

Delay (Low Load, WLAN)

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Delay (sec)

Figure 6: Low Load Delay Received Voice Traffic :

As the load is very less, there is not significant difference between the throughput of the 802.11 and modified DCF. From Figure 7 we can observe that the modified DCF works slightly better than 802.11.
Traffic Received (Low Load, Voice)
45000 40000 35000 30000 25000 20000 15000 10000 5000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Traffic (bytes/sec)

Figure 7: Received voice Traffic low Load Voice End to End Delay :

From Figure 8 we can observe that voice end to end delay in case of Modified DCF is much less as compared to 802.11. Also comparing the Modified DCF graph in fig 6 we can see that the delay in case of voice is less as compared to overall delay of the system.

Delay (Low Load, Voice)

0.8 0.7 0.6 Delay (sec) 0.5 0.4 0.3 0.2 0.1 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 8: Voice End to End Delay Jitter :

From Figure 9 we can infer that the jitter in case of modified DCF is lower as compared to 802.11.
Jitter (Low Load, Voice)
0.0016 0.0014 0.0012 Jitter (sec) 0.001 0.0008 0.0006 0.0004 0.0002 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 9: Jitter Low Load Thus the modified DCF not only reduces the end to end delay but also the jitter is less. These features make modified DCF more suitable for real time voice applications.

5.2 Medium Load Analysis

Throughput :

As the offered load is less than the system capacity the throughput of all the three algorithms is almost same, see Figure 10.
Throughput (Medium Load, WLAN)
800000 700000 600000 500000 400000 300000 200000 100000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW Throughput (bits/sec)

Figure 10: Throughput Medium Load Delay :

From Figure 11 we can observe that the delay in case of modified DCF is much lesser than 802.11. Also comparing it with low load delay (Figure 6) we can see that there is an increase in the delay of 802.11 but the delay of modified DCF almost remains the same.
Delay (Medium Load, WLAN)
1.4 1.2 1 0.8 0.6 0.4 0.2 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Delay (sec)

Figure 11: Delay in Medium load

Voice Traffic Received :

Figure 12 shows the graph of voice traffic received at medium load. As the load is less all the three algorithms performs equally better in terms of throughput.
Traffic Received (Medium Load, Voice)
40000 35000 30000 25000 20000 15000 10000 5000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Traffic (bytes/sec)

Figure 12: Voice traffic received, Medium load Voice End to End Delay :

From Figure 13 we can observe that voice end to end delay in case of Modified DCF is much less as compared to 802.11. Comparing the Modified DCF graph in Figure 11 we can see that the delay in case of voice is less as compared to overall delay of the system. Also comparing the graph with the voice end to end delay (Fig 8) we can observe that the delay in 802.11 has increased in medium load but the delay in the modified DCF has in fact decreased.
Delay (Medium Load, Voice)
1.2 1 Delay (sec) 0.8 0.6 0.4 0.2 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 13: Voice End to End Delay Medium load

10

Jitter :

Figure 14 shows the analysis of jitter under medium load. Jitter in case of Modified DCF is less as compared to 802.11.
Jiiter (Medium Load, Voice)
0.0025 0.002 Jitter (sec) 0.0015 0.001 0.0005 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 14: Jitter, Medium Load Comparing with the jitter in the low load (Fig 9) we can observe that the jitter increases in case of medium load for 802.11 but the jitter of the modified DCF almost remain the same in case of medium and low load.

5.3 High Load Analysis

Throughput :

In case of high load, as shown in Figure 15 we see that net throughput of modified DCF is better than normal DCF.
Throughput (High Load, WLAN)
5000000 Throughput (bits/sec) 4000000 3000000 2000000 1000000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 15: Throughput, High Load 11

Delay :

Here from Figure 16 we can see that delay required for modified DCF is more than normal DCF.
Delay (High Load, WLAN)
2.5 Delay (sec) 2 1.5 1 0.5 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 16: Delay, High Load Voice Traffic Received :

In case of voice traffic received, we see that normal DCF performs better than modified DCF, see Figure 17.
Traffic Received (High Load, Voice)
20000 Traffic (bytes/sec) 15000 10000 5000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 17: Voice Traffic Received, High Load Voice End to End Delay :

Here, as shown in Figure 18, modified DCF requires more delay as compared to normal DCF.

12

Delay (High Load, Voice)

3.5 3 2.5 2 1.5 1 0.5 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Delay (sec)

Figure 18: Voice Delay, High Load Jitter :

As shown in Figure 19, Jitter in voice is more for modified DCF than normal DCF.
Jitter (High Load, Voice)
0.007 0.006 0.005 0.004 0.003 0.002 0.001 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Jitter (sec)

Figure 19: Jitter, High Load Video Traffic Received :

For video traffic Figure 20, modified DCF shows more bytes per second as compared to normal DCF.

13

Traffic Received (High Load, Video)

400000 350000 300000 250000 200000 150000 100000 50000 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Traffic (bytes/sec)

Figure 20: Voice Traffic Received Video End to End Delay :

Net delay required for video is almost same for modified DCF and normal DCF, see Figure 21.
Delay (High Load, Video)
0.1 Delay (sec) 0.08 0.06 0.04 0.02 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 21: Video End to End Delay Video Delay Variation

As shown in Figure 22, Modified DCF shows more delay variation as compared to normal DCF.

14

Delay Variation (High Load, Video)

Delay Variation (sec) 0.01 0.008 0.006 0.004 0.002 0 0 50 100 150 200 250 300 350 Time (sec) Normal IEEE 802.11 MAC-DCF MDCF - Non-Overlapping CW MDCF - Overlapping CW

Figure 22: Video Delay Variation Above graphs show that in high load scenario, normal DCF performs better than modified DCF for voice traffic. However, for video traffic, both the protocols perform approximately same. Further investigation is necessary before drawing any conclusion about high load scenario.

15

6. Conclusion
The protocols for modified DCF Overlapping contention window and Non-overlapping contention window are implemented and tested against normal DCF. Results show that for light load and medium load cases, modified DCF protocols perform better than normal DCF protocol for real time applications. Throughput remains almost same. However, delay required is less in former case. Also, jitter is much less in modified DCF. Thus it seems appropriate to use modified DCF for nodes running real time applications such as voice over IP.

16

Bibliography
[1] M. Mishra & A. Sahoo, A contention window differentiation mechanism for providing QoS to high priority data in 802.11, Technical report, KReSIT, IIT Bombay, June 2006 Jochen Schiller, Mobile Communications, Pearson Education, Second edition, 2005 Wanang Xiao, Yin Shi, A Two-Step Backoff Scheme for Improving the Performance of the IEEE 802.11 distributed Coordination Function, ISCIT2005

[2]

[3]

17