Measuring the Performance of VoIP over Wireless LAN

Transcription

1 Measuring the Performance of VoIP over Wireless LAN Keshav Neupane, Student Victor Kulgachev, Student Department of Computer Science Northern Kentucky University Highland Heights, KY, USA, Andrew Elam, Student Sri Harsha Vasireddy, Student Department of Computer Science Northern Kentucky University Highland Heights, KY, USA, Hetal Jasani, Ph.D. Department of Computer Science Northern Kentucky University Highland Heights, KY, USA, ABSTRACT IEEE wireless local area network (WLAN) has become popular and has been providing excellent solution for wireless networking. With the popularity of WLAN and Voice over the Internet (VoIP) protocol, it is very essential to measure the performance of the VoIP over WLAN. The main goal of this paper is to compare the performance of the Voice over IP protocol in both LAN (802.3) and WLAN (802.11). This paper examines how this communication protocol performs in two different network setups and analyzes the results obtained using OPNET modeler. It also examines the optimization of e for Quality of Service (QoS) using the priorities to provide real-time service for voice over the Internet protocol. Categories and Subject Descriptors C.4 [Computer Systems Organization]: Performance of Systems, Modeling techniques. General Terms Performance, Measurement Keywords IEEE e; WLAN; OPNET; Modeling and Simulation; QoS; Frame Relay; PPP. 1. INTRODUCTION Wireless Local Area Network (WLAN) has become more popular because of the simple deployment scheme. Voice over IP (VoIP) can save a lot for the small business and corporations by cutting down the cell phone and telephone bills. Now with the corporations and small business moving into the WLAN infrastructure, it is important to look at the performance of VOIP over the WLAN and be aware of potential issues and what can possibly be done to remediate those issues. With the rapid movement of business infrastructure towards WLAN, it is important to implement the real time traffic over WLAN. Implementation of real time traffic such as VOIP in WLAN demands for a dependable Quality of Service (QoS). This project has addressed the VOIP over WLAN using Frame Relay, VOIP using Point to Point and compared it against VOIP over Wired LAN and explored the possibilities and options in enhancing VOIP over WLAN. Quality of Service: The e enhances the DCF (distributed coordination function) and the PCF (point coordination function), through a new coordination function: the hybrid coordination function (HCF). Within the HCF, there are two methods of channel access, similar to those defined in the legacy MAC: HCF Controlled Channel Access (HCCA) and Enhanced Distributed Channel Access (EDCA). Both EDCA and HCCA define Traffic Categories (TC). For example, s could be assigned to a low priority class, and Voice over Wireless LAN could be assigned to a high priority class. The QoS guarantee of HCF is based on negotiation of service level agreement between AP and wireless nodes. HCF realizes QoS mechanism by extending PCF definition and applying one-direction stream of service level agreement between APs and wireless nodes. [5] EDCA is designed to provide traffic differentiation by implementing four queues (Access Categories (AC)) in each QoS enhanced station (QSTA) to support eight user priorities as defined in IEEE 802.1D. Each AC works as an independent DCF STA and uses its own access parameters (CWmin[AC], CWmax[AC], AIFS[AC], TXOPlimit[AC]), which are announced by QAP periodically in beacon frames. The new IEEE e standard allows the QAP to adapt these parameters dynamically depending on the network conditions. [8] Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGITE 11, October 20 22, 2011, West Point, New York, USA. Copyright 2011 ACM /11/10...$ PERFORMANCE MODELING VoIP over wireless LAN was simulated using OPNET modeler and analyzed the performance of VoIP over WLAN system. The performance statistics was collected and also captured the measurement of packet loss, delays and throughput in order to determine the VOIP quality over WLAN. 269

2 Voice transmission is more sensitive than data transmission. Since VOIP is real time application dropped calls and low voice qualities are not accepted by the customers, so it is important to implement quality of service (QoS) to ensure the better quality of the signal. [4] The following parameters were considered as the principal parameters during the simulation: voice payload size: voice payload size is the size in bytes of packet; packet size: packet size is the size in bytes of a packet including RTP/UDP/IP; packets per seconds: number of packets generated per second; packet duration: packet duration is the time between the start bits of two consecutive packets. During the simulation of the design topology, statistics was collected on packet loss, delay, latency and jitter. Packet loss is the main reason for the degradation in the voice quality. Below are the details of each of the global statistics that were collected which were analyzed in different scenarios. Following are performance metrics regarding Frame Relay: throughput (bits/sec): average bits per second forwarded to the next-higher layers by all frame relay access devices (FRADs) in the network; traffic dropped (packets/sec): represents the rate at which packets get dropped in this cloud. [12] Following are performance metrics regarding voice: Jitter (Sec): If two consecutive packets leave the source node with time stamps t1 & t2 and are played back at the destination node at time t3 & t4, then: Jitter = (t4 - t3) - (t2 - t1), Negative jitter indicates that the time difference between the packets at the destination node was less than that at the source node; packet delay variation: Variance among end-to-end delays for voice packets; packet Endto-End Delay (Sec): the total voice packet delay, called "analogto-analog" or "mouth-to-ear" delay = network_delay + encoding_delay + decoding_delay + compression_delay + decompression_delay; traffic received (bytes/sec): average number of bytes per second forwarded to all Voice applications by the transport layers in the network. [12] Following are the performance metrics regarding Wireless LAN: Throughput (bits/sec): represents the total number of bits (in bits/sec) forwarded from wireless LAN layers to higher layers in all WLAN nodes of the network; delay (sec): represents the end to end delay of all the packets received by the wireless LAN MACs of all WLAN nodes in the network and forwarded to the higher layer; data dropped (retry threshold exceeded) (bits/sec): Total higher layer data traffic (in bits/sec) dropped by the all the WLAN MACs in the network as a result of consistently failing retransmissions. If the network contains QSTAs (802.11e-capable WLAN MACs) that use Block-ACK mechanism as originator for some or all of their communication with other QSTAs, then this statistic will also include any higher layer data traffic of those MACs that is transmitted and retransmitted within blocks, not acknowledged in following Block-ACKs and dropped due to reaching the transmit lifetime limit. [12] Following are the performance metrics regarding WLAN (PER HCF Access Category) :delay (in sec): represents the end-to-end delay of all the data packets, collected separately for each e EDCA access category, that are successfully received by all the e-capable WLAN MACs in the network and forwarded to higher layer. Another one is throughput (bits/sec): total data traffic in bits/sec, collected separately for each e EDCA access category, successfully received and forwarded to the higher layer by all the e-capable WLAN MACs in the network. [12] 3. SIMULATION MODEL This simulation was run in many different scenarios to see the difference in performance and to explore the best method of utilizing VoIP over WLAN. The first scenario was called Baseline ; this scenario was the basic implementation and was used as a starting point of reference. In this scenario there was no QoS implemented. The QoS scenario was used to show the impact of implementing e in a wireless network that was using VoIP. This scenario was compared against the baseline scenario to measure the effectiveness and was used as the new baseline in comparing the rest of the scenarios. The network performance was tested during peak time and downtime in the QoS_Heavy_Traffic Scenario. The result from this gave an indication of the degradation of the QoS as the network load increases. This same model also was implemented in all wired network scenario titled wired_baseline. This was done to create a base to compare the results of the wireless implementation. The results of the two scenarios were graphed in a stacked graph to show variation from a wired and wireless network. This made it easier to identify the bottleneck areas in the WLAN. The QoS_PPP scenario was tested using a point-to-point connection instead of a frame relay WAN. These results showed the affects of the network due to the frame relay. 3.1 Topology and Model for Baseline, QoS and QoS_Heavy_Traffic Scenarios The model being implemented for the Wide Area Network (WAN) was a frame relay model supporting Permanent Virtual Circuit (PVC). At each end of the frame relay we had subnets. Inside these subnets was a WLAN environment. The WLAN environments consisted of 3 access points and 5 workstations in each access point. All the access points were connected together using a switch. Two servers were connected to the switch titled VoIP_Server_# and Server_#. The VoIP_Server_# handled all the VOIP traffic and the Server_# handled the FTP, HTTP, etc. The WLAN was connected to the frame relay via a router that connected the switch. The WAN and WLAN were both star topologies. Figure 1. Network Model of Frame Relay 270

3 Figure 2. Network Model of WLAN 3.2 Topology and Model for Wired_Baseline The wired_baseline topology was exactly the same as the previous topology the only difference was inside the subnet. A LAN environment was implemented instead of a WLAN. All the workstations were directly connected to the switch via 100baseT network cable. Figure 3. Network Model of LAN 3.3 Topology and Model for QoS_PPP The QoS_PPP topology was same as the QoS topology inside the subnet. The difference was that the WAN environment utilized a Point-to-Point connection to connect the two subnets instead of a Frame Relay. 3.4 Basic Parameters The frame relay WAN model was connected using a T1 line that was capable of 1.54 Mbps. The OPNET model name for this media was FR_T1. The T1 line was set up with a Committed Information Rate (CIR) of 64,000 bits per second for outgoing and incoming traffic. The router that connected the WAN and LAN was a frame relay router. The OPNET model name for the router was fr4_tr2_gtwy_175_upgrade. The dotted line in the WAN that connected directly to the two routers was the frame relay demand object. This was more of logical line and was used to define the endpoints of the PVC. The Point to Point WAN was connected using a T1 (1.54Mbps) line that connected directly to the router in each subnet. The model name of the link was point_to_point_link_adv. The WLAN model used 100BaseT for all the wired connections to the access point, switch, and servers. A 3com switch was used in the LAN model. The OPNET model name was 3C_a16_e24_fe16_switch_adv. The OPNET model name for the servers was ethernet_server. The wireless access points and workstations were using g running at a data rate of 54 Mbps. The WLAN environment consisted of 3 fixed wireless workstation and 2 moving wireless workstations in each access point. There were a total of 15 workstations in each subnet. The workstations were generating traffic across the frame relay and traffic within the WLAN environment only to simulate a real office environment. The access points OPNET model name was wlan_ethernet_slip4_adv_21_upgrade. The fixed workstations model name was ethernet_wlan and the moving node model name was wlan_station_adv. The wired LAN had all the workstations connected directly to the 3com switch via 100Base T. The LAN consisted of 9 node models named workstation. These were generating the traffic across the WAN. The LAN also consisted of 6 node models named station. These were generating random traffic inside the LAN only. 3.5 QoS Parameters To enable QoS, the first thing configured was the access points. All the access points had the HCF parameter set to support Default QAP. The EDCA parameters had to be changed to enable. [12] The EDCA parameters Specifies the configuration of the parameters of the HCF EDCA (Enhanced Distributed Channel Access) mechanism. Then under EDCA parameters the CW max needed to be set to 15. [12]The CW max specified the maximum size of the "Contention Window" for the Voice access category, which was used to pick the random number of slots for the backoff periods. Under that CWmax was set to 15 for AP specific also. Finally the Block ACK parameter is set to support. The workstations had the HCF parameter set to support. They also had the CW max set to 15 but only under AP Specific Parameters. Then the Traffic Category Parameters had to be set no Acknowledgement for TID 6 (Interactive Voice). The Traffic Category Parameter attribute contains the attributes that can be used to configure the Traffic Category (TC) specific parameters. 3.6 Application and Profile Configurations Application Definitions was where the applications were created for traffic generation on the network. The important parameter was VoIP. The VoIP was set up in the Voice category under the description drop down menu. In the drop down menu for voice IP Telephony was selected. In the voice selection G.729, a compression algorithm was used for voice compression. G.729 operates at a bit rate of 8 kbit/s. For the QoS scenarios the VoIP table ToS was changed to 6 to give voice priority. Other parameters that were set for this project were , file transfer, file print, web browsing and database access. For each of these applications mentioned there was a heavy and light usage parameters set for each one. This was used to simulate the difference of use during peak hours and down time. Profile Configuration describes the activity patterns of a user or group of users in terms of the application used over a period of time [6]. The sales_light profile was using VoIP, Database, and file print applications with light usage parameters. The admin_light profile was using VoIP, Database, FTP, Web Browsing, File Transfer and File Print with light usage parameters. VoIP_Profile was only using VOIP applications these were the dedicated IP phones. All the Profiles had the operation mode variable set to simultaneous, this setting allowed more than one application to run at the same time. The start time [seconds] was set to uniform 10, 20. The start time defines when the applications start to run in the beginning of the simulation. The Duration [seconds] was set to end of simulation. This setting allows for the profiles to continue operating until the end of the simulation. The VoIP profile had a few different changes from the other profiles. 271

4 The repeatability was configured to repeat at a constant 150 seconds with an unlimited number of repetitions. PVC Configuration allows for the defining of traffic patterns for PVC. It allows setting up characteristics based on types of services (ToS). In this simulation the Application Type was IP over FR. The PVC characteristics were set for excellent effort ToS supported. Mobility Configuration holds the parameters for the wireless mobile nodes in the LAN models. This was where the trajectory of where the nodes were moving to was set up. There were two random mobility profiles. The differences in the profiles were the domain mobility and speed. 3.7 Applying QoS over Baseline on In the first comparison the baseline and QoS were matched up, the only difference between the two was that the QoS scenario had an e implementation and the baseline did not. This scenario was created to test whether the e should be deployed or not. The simulations showed the QoS scenario produced much greater results than the baseline scenario. With the QoS 12,000 less byte per second were dropped from the network. The delay within the WLAN was also greatly reduced in the e implementation. The jitter was almost eliminated through the use of QoS parameters. The positive results and no negative impact from the QoS parameters proved that e could be implemented in testing VoIP inside WLAN over Frame Relay. Figure 4. Voice Traffic Sent and Received for QoS and Baseline 3.8 QoS vs. QoS_heavy_traffic To measure the impact of traffic volume a simulation was created that generated more network traffic. This was done to test the threshold of voice quality. As a result of the heavy traffic about 6,000 more bytes per second of voice traffic were dropped from the network. This was an indication that high volumes of data can make a significant impact on the network. In the heavy traffic scenario the jitter and delay were worse. However, neither jitter nor delay was bad enough to affect the VoIP call quality. This means jitter and delay were not the problem but dropped traffic was. The heavy network load was causing much more traffic to be dropped. Figure 5. Comparison of Traffic Received for QoS and QoS_heavy_traffic After looking over all of the graphs the problem became clear, it was the frame relay itself. The frame relay was taking on more traffic than it can handle so it dropped traffic. The more traffic it received the more traffic it began to drop. The major limitation in this network at this point was not WLAN but the frame relay. This was because the frame relay uses packet switching technology which is ideal for data but not for voice. The graph below shows about 5 packets more per second were dropped in the heavy traffic simulation. Figure 6. Frame Relay Network Cloud- Packets Dropped 3.9 Replacing Frame Relay with Point to Point T1 Line The topology with the Frame Relay was replaced with point to point (as shown in Figure 6) connection using T1 line. This scenario was based off of QoS scenario and was named QoS_PPP. In this scenario two subnets were connected using T1 line and the simulation was run for 10 minutes. The parameters used for the scenario with Frame Relay (QoS Scenario) remained the same. Thus the Quality of Service that was implemented over was not affected on this scenario. The link model that was used to connect Subnet_0 with Wireless Subnet_1 was point_to_point_adv. The voice traffic received (bytes/sec) in case of QoS_PPP was higher than the baseline (refer to Figure 7) and the scenario with QoS (with Frame Relay). Figure 7. Traffic Received The reason for point to point to have higher voice traffic received as compared to Frame Relay was the drop of the data in Frame Relay. Below is the graph, which shows the average Frame Relay traffic, forwarded and traffic received in bits/sec. The graph shows that in case of Frame Relay the forwarded traffic was little less than the received traffic. While Frame Relay was receiving an average of 250,000 bits/sec of data it was forwarding over 240,000 bits/sec but less than 250,000 bits/sec as shown in Figure 8. The average in voice jitter (in sec) in case of point-to-point scenario (QoS_PPP) resembled to what was obtained in case of QoS scenario. It was little below seconds. 272

5 Average WLAN (per HCF Access Category) throughput in bits/sec was slightly higher in case of point to point as compared to Frame Relay as shown in Figure 12. Figure 8. Frame Relay Traffic Received Vs. Forwarded Figure 9: Average Delay Variation There was little to no packet delay variation in case of QoS_PPP scenario. Frame relay had average packet delay in variation of about (as shown in Figure 9). Average wireless LAN throughput (in bits/sec) in case of point to point was about 1,750,000 bits/sec which was higher as compared to the scenario with frame relay as shown in Figure 10. Average WLAN (PER HCF Access Category) delay (in sec) was higher in case of point to point as compared to the one with frame relay. For frame relay it was about seconds whereas for point to point it was about seconds as shown in Figure 11. Figure 10. Average wireless LAN throughput (in bits/sec) Figure 12. Average WLAN (per HCF Access Category) throughput in bits/sec 3.10 WLAN replaced with LAN on a Frame Relay without QoS The wireless workstations were replaced with the wired workstations and switched the AP to a 3com switch and used a 100BaseT to connect to the layer 3 switches from the wired workstations. When replacing the WLAN with a wired LAN on a baseline scenario where QoS was not implemented the overall results were better for the wired LAN. However, not as good as we got with e. Please refer to Figure 11 for traffic sent and received comparison of WLAN Vs. LAN Result Comparison Below are the tables which comprises of the results in a tabular form for different scenarios stated above: Table 1. Result Comparisons Avg. Traffic Sent Avg. Traffic Avg. Avg. Packet (bytes/sec Received Jitter Delay Scenarios ) (bytes/sec) (sec) variation Baseline 40,000 25,000 1E Baseline with QoS 40,000 36, QoS with Heavy Traffic 40,000 30, Replacing FR with T1 with QoS 40,000 40, WLAN replaced with LAN without QoS 40,000 27, Figure 11. Average WLAN (PER HCF Access Category) delay 273

6 Table 2. Result Comparisons Average Average WLAN (per Avg. Wireless WLAN (PER HCF Access LAN HCF Access Category) Throughput Category) Throughput Scenarios (bits/sec) delay (in sec) (bits/sec) Baseline 1,300, Baseline with QoS 1,500, ,300,000 QoS with Heavy Traffic 1,200, ,200,000 Replacing FR with T1 with QoS 1,775, ,350,000 WLAN replaced with LAN on FR without QoS N/A N/A N/A **Baseline was with Wireless LAN with FR 4. CONCLUSIONS With the simulation analysis it seems that the point to point has more advantages than on frame relay however it boils down to various factors such as distance, cost, speed of the connection. Point to point could prove to be the better in QoS, but Frame Relay is more cost effective. However, when implementing an optimized VoIP network a point-to-point WAN connection should be used with an e LAN. The simulation results showed that QoS on e can be optimized using the priorities and provide real-time service for voice. 5. REFERENCES [1] Kuhn, Richard, Thomas Walsh, and Steffen Freiss. "Security Considerations for Voice Over IP Systems." National Institute of Standards and Technology. U.S. Department of Commerce, n.d. Web. 16 Oct 201 [2] Bibis, Konstantinos. "Contributed Models. VoIP over g and the need for QoS" OPNET. Web. < escription?modelid=630>. [3] Salah, K., and A. Alkhoraidly. "An OPNET-based Simulation Approach for Deploying VoIP." Web. [4] "Frame Relay Network Performance." Opnet Lab Manual. Web. [5] Li, Jie, and Cui Qi-Fan. "The QoS Research of VoIP over WLAN." Web. 22 Sep 2010 [6] "OPNET Modeler Documentation Set." OPNET Technologies, Inc., 07 Jul Web. 18 Oct [7] Solution & Interoperability Test Lab Application Notes." Avaya Inc., 6/25/2004. Web. 22 Sep <support.avaya.com/css/p8/documents/ >. [8] Lammle, Todd. "Cisco Press 6th Edition." Wiley Publishing Inc (2009): Web. 18 Oct [9] El-fishawy, N, M Zahara, and M El-gamala. "Capacity estimation of VoIP transmission over WLAN." 24th NATIONAL RADIO SCIENCE CONFERENCE (NRSC 2007) (2007): n. pag. Web. 2 Dec [10] Kuhn, Richard, Thomas Walsh, and Steffen Freiss. "Security Considerations for Voice Over IP Systems." National Institute of Standards and Technology. U.S. Department of Commerce, n.d. Web. 16 Oct 201 [11] "Full Rate." Wikipedia, the Free Encyclopedia. Web. 22 Nov < [12] "G.711." Wikipedia, the Free Encyclopedia. Web. 22 Nov < [13] OPNET Modeler Documentation Set." OPNET Technologies, Inc, Web. 3 Dec <Web: 274