ITM542 Spring 2004 Feasibility Study of a Wireless LAN network With-VoIP at IIT Rice campus Ninad Narkhede Masaaki Yana Saturday, 1 May 2004 ABSTRACT Wireless technology has gained popularity in enterprises providing portability, mobility and cost feasibility. Voice over IP (VoIP) technology is available for integration with wireless networks and is scalable with the emergence of VoIP compatible equipments like wireless VoIP phones, laptops, PDAs and 3G phones. Although VoIP is an emerging technology, feasibility analysis is important for optimum performance considering Quality of Service (QoS); one of the greatest challenges in VoIP over wireless network. The Illinois Institute of Technology s (IIT) Rice campus has a wireless network supporting 802.11a/b/g. We have simulated the Rice campus network model in OPNET and evaluated the performance of VoIP with 802.11b using G.711 as the codec standard. 1. Introduction The growth of wireless technologies has provided cutting edge enterprise solutions such as portability, mobility, intersystems integration and extensibility. VoIP is another technology that is emerging having integration capabilities with 802.11 wireless networks. It is a breakthrough technology as compared to the Plain Old Telephone System (POTS) and has greater potential for saving costs for voice communication. With the growing popularity of wireless and VoIP technology, along with the emergence of wireless IP phones, end user equipments such as laptops, PDAs and 3G phones have gained compatibility with the technology. The wireless 802.11b networks have been widely deployed at small office home office (SOHO), hot spots such as bookstores/cafes and consumer homes. The emergence of 802.11g standard in mid 2003 provided a more efficient solution with higher data rate that is 5 times faster than the 802.11b technology. Wireless 802.11b/g network operate over the 2.4 GHz Industrial, Scientific and Medical (ISM) unlicensed public radio band. It is shared by other wireless technologies such as cellular phone system, microwaves, or cordless phones. Therefore, there is possibility of contention issue with these other wireless technologies. QoS is one of the greatest challenges in wireless networks. These networks are operating on 2.4 GHz ISM band. Emerging technology has made it possible to transfer bandwidth intensive applications such as video and voice over wireless. This made QoS an important consideration for optimal performance of the network and applications. 2. Background Technology 2.1 Wireless LAN 802.11b/g This IEEE standard for wireless networking defines the physical and MAC layer of the wireless network. It uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for Media Access Control (MAC). Radio does not have the ability to detect collision, as a result of which, it uses collision avoidance (listen and back-off) for transmitting media. This can cause delays in the network. The bandwidth ranges from 1M, 2M, 5.5M and 11Mbps; however, it is said to have rubber bandwidth i.e. bandwidth is not promised. The fundamental access method of 802.11 MAC is Distributed Coordination Function (DCF). This requires ACK after every Short Inter Frame Space (SIFS). The total Direct Sequence Spread Spectrum. (DSSS) time slot in DCF is 30ms. Point Coordinating Function (PCF) is optional access method of contention-free data transfer. PCF is also sensitive to delay which is apt for voice applications. PCF operates along with DCF in a wireless network that is PCF enabled. 2.2 Voice over IP VoIP is a technology that facilitates the use of voice over IP data networks. VoIP uses Session Initiation Protocol (SIP) for signaling and Real Time Protocol (RTP) for transfer of voice over data lines. VoIP equipment includes, IP phone/ip voice enabled host, SIP/proxy server, Gatekeeper, etc. G.711 is a vocoder used in for coding-decoding of voice packets with a data rate of 64kbps and Mean Opinion Score (MOS) of 4.1. G.729 is another widely used vocoder with data rate of 8kbps and MOS of 3.9. Some of the performance issues of VoIP are end to end delay, prioritization of voice over data etc. 2.3 QoS QoS includes jitter, latency, packet loss and bandwidth. It sets standards for optimizing network performance considering the above parameters. Delay is one of the important factors of QoS for VoIP networks. The acceptable value for optimum QoS is around 100ms. Some of the standards of QoS are Resource Reservation Protocol (RSVP), DiffServ and 802.11e. RSVP and Diffserv are implanted in routers and some layer 3 switches i.e. network and upper layers. This however, does not help in wireless networks as they operate only on PHY and MAC layer. 2004 Masaaki Yana & Ninad Narkhede 1
2.4 VoIP over WLAN Some of the limitations of VoIP over WLANs are that there is no guarantee of bandwidth in wireless networks and there is considerable delay caused by CSMA/CA. PCF enabled WLAN improves voice performance. 3. Network Design and parameters 3.1 Current Network Rice Campus to the Internet connected. There are data at IIT-main campus such as FTP, HTTP and email that serve the LAN at main campus as well as the WLAN at Rice campus. Host Name Function WLAN workstations For voice or data application. Four in AP10 and four in AP20 are used as VoIP dedicated hosts. Access Points BSS=10 and BSS=20 are assigned for AP10 and AP20 respectively. AP10 has four WLAN stations. AP20 has 11 WLAN workstations VoIP Phones VoIP phones are used as the call destinations in the main campus when wireless phone calls at Rice campus originated calls. (VoIP phones in Rice campus were not used in the simulation.) Figure 1 Rice Campus to Internet The IIT Rice campus LAN is connected to the WAN through the Cisco 3500 series router (Ricegate). The connection that is used is a T3 connection, which is terminated to a router at IIT-main campus which in turns is connected to a gateway router. This router is connected to the Internet. This is how Rice campus is essentially connected to the Internet. 3.2 Current Network Rice Campus with VoIP network Cisco 3550 switches Cisco 3600 routers 100BaseT LAN Servers IP network This switch is placed to connect voice traffic to the LAN. (However, the other applications are simulated for evaluation purpose.) Inline power enabled switch for VoIP phones. The rest of the function is as same as a general 100BaseT switch. This connects the Rice campus IP network to the main campus network via fractional T1 line. (This simulation used T3 line instead of T1. This difference does not cause any problem for the purpose of the simulation purpose.) This node is used to simulate the Rice and the main campus IP networks. (This node is not an important factor for the purpose of the simulation.) FTP and HTTP are located at both Rice and the main campus LANs. Email server was located only at the main campus LAN. SIP proxy server (Call Manager) is attached to the CISCO 3550 to initiate VoIP calls. (This is not important for the purpose of the simulation.) Placed as T3 network. This is used to simulate latency between the Rice and the main campus. Figure 2 Rice Campus with VoIP network The WLAN at IIT-Rice campus that supports VoIP is connected to the Voice enabled Switch. The wireless IP phones and workstations are served by the wireless APs. All the APs are connected to this switch which in turn is connected to Gateway Router. The VoIP Call Manager and wired IP phones are also connected into the switch. As per mentioned in previous architecture, the gateway router connects to IIT-main campus via the WAN using a T3 connection. At the main campus, the gateway router is connected to the voice switch to which the VoIP phones are 2004 Masaaki Yana & Ninad Narkhede 2
3.3 Current Network OPNET simulation design Campus wireless network perform the following functions 1) Calls between two wireless IP phones in the WLAN 2) Calls between two wireless IP phones in the WLAN along with data applications 3) Calls between wireless IP phones at Rice campus and IP phones at main campus via WAN network 4) Calls between wireless IP phones at Rice campus and IP phones at main campus along with data applications. Some of the important considerations of these simulations are to maximize the number of simultaneous voice calls and also maximize the number of workstations using data applications and still be able to keep delay to an acceptable minimum. Figure 3 OPNET simulation design 3.4 Components and Assumptions: 1) We are evaluating, 1 st floor of the campus that has 2 APs. Both access points are assumed to be VoIP enabled APs. 2) VoIP Maximum 4 simultaneous calls made within IIT. 3) 7 workstations using data applications such as ftp, http and email. 4) More than 134 hosts connected to the LAN including routers, switches and. Common configurations 1) WLAN: 802.11b Even though 802.11a/g is available in the Rice campus, we limited the bandwidth to 11Mbps. It is because the current available wireless IP phones only support 802.11b. 2) Voice application: G.711 G.711 is used in all of the simulation because the quality of G.711 is the same as the PSTN phone. However, default of VoIP is G.729 generally when used in office LANs. Voice data was sent constantly during the simulation time) 3) Other applications: FTP, Email, and HTTP The FTP and HTTP were located in both Rice campus and the main campus. When used, seven wireless workstations sent data at the same period while the voice data was sent 4) QoS As WLAN QoS, PCF function is introduced to evaluate the improvement. 4. Scenarios Scenario 1 VoIP in WLAN at Rice campus The purpose of this simulation is that how many wireless IP phone calls one AP is able to handle. We simulated the scenario with the parameter of voice frames per packet to determine the maximum number. No other applications data like FTP, etc were sent in the scenario. The expected problem is that constant voice traffic creates collision in 802.11b. One solution is to reduce the ratio of the number of the frame per packet. This reduces the amount of WLAN traffic and the overhead by the headers of the lower layers. The downside of this solution is that one packet loss influences more loss of voice information. Therefore, we need to find a reasonable ratio of the parameter and use it in the scenario 2 and the scenario 3. Scenario 2 VoIP and other data applications in a WLAN at Rice campus This scenario evaluates VoIP delay in the same wireless network running other data applications. This scenario considers the busiest AP on the 1 st floor that handles 7 wireless workstations using considerable data applications along with 4 other wireless workstations using voice communication. We expect noticeable delay to be introduced by the other application. Because the voice traffic is constant, whenever the other application traffic is introduced, there must be some delay. The important point is how much delay would be introduced within the acceptable range. Scenario 3 Wireless VoIP phone in WLAN calling main campus The purpose is to evaluate the additional voice delay caused by the WAN between the Rice and the main campus network. This also evaluates the influence of traffic created by other data applications on the voice network using the same AP. PCF is introduced to evaluate the delay performance improvement as PCF helps in the reduction in delay in voice traffic caused by other data applications. Some of the scenarios that we included for our simulation and discussion of the performance of VoIP over IIT-Rice 2004 Masaaki Yana & Ninad Narkhede 3
5. Simulation Results The simulation results primarily focus on voice packet end to end delay. This is because it is very important to maintain a minimum delay to achieve optimum QoS in voice over IP communications. These results cast minimal focus on throughput. The peak throughput results (see Appendix A) vary from 768Kbps to 1.9Mbps depending on the data applications that run along with voice applications on the network. Some of the statistics we did not consider for simulation result are MAC delay and wireless LAN delay because outcome of this data is not sufficient to evaluate performance of voice applications and these delay statistics are already included in the outcome of the end to end delay results. packetizing at 1frame per packet, substantially increased the delay to 1s. The simulation result also showed data dropped in the WLAN. This was due to congestion caused by collision and delay in the network since the rate at which traffic was sent was constant. From these results we realized that only 2 phone calls were possible using one AP. This was not practical because the Rice campus requires the capability of supporting more users in one AP. Figure 4 and 5 shows the E to E delay by packetizing 2 frames per packet between 3, 4 and 5 pairs of wireless workstations respectively using voice applications. The simulation result does not show statistics on data dropped because when considering other factors for simulation like number of workstations, packetizing parameters and latency, we made sure that did not result in any data dropped to help us evaluate all the voice traffic that was sent and received on the network. This in turn also helped us to better evaluate the VoIP end to end delay. 5.1 VoIP in WLAN at IIT Rice campus Figure 3 shows the end to end (E to E) delay by packetizing 1 frame/packet (ft/pkt) between 2 pairs and 3 pairs of wireless workstations respectively using only voice application. Figure 4 Packet E to E delays with 2 fr/pkt 3/4 pair wrkstations Figure 3 Packet E to E Delay with 1 ft/pkt 2/3 pair wrkstations The simulation with 2 pairs of wireless voice enabled workstations with 1frame per packet packetizing introduced a delay of 1.35ms. The addition of another pair, still Figure 5 Packet E to E Delay with 2fr/pkt 5 pair workstation with PCF 2004 Masaaki Yana & Ninad Narkhede 4
The simulation with 3 and 4 pairs of wireless voice enabled workstations (see figure 4) resulted in a delay of 1.1ms and 2.1ms respectively. This enabled us to increase the number of workstations making voice calls and still keep the E to E delay within the acceptable range. The simulation with 5 pairs of wireless voice enabled workstations (see figure 5) resulted in a delay of 570ms. The introduction of PCF, helped in reducing the delay to 290ms. This however, was not feasible because the delay was unacceptable for VoIP communication. Based on the above results, we saw that by increasing the packetizing from 1 fr/pkt to 2 fr/pkt enables the AP to support up to 4 simultaneous voice calls along with 7 workstations using considerable data applications. Since we realize this is the reasonable amount of simultaneous voice and data traffic on Rice campus, we shall consider the above parameters as base for our further simulations. range for VoIP. Based on the above results, we can fairly conclude that Rice campus can support 4 simultaneous VoIP calls along with a class of wireless workstations using considerable data applications. 5.3 VoIP between IIT Rice campus and Main campus with data applications Figure 7 shows the effect on the voice E to E delay between the IIT - main campus and Rice campus. The simulated network includes heavy data applications generated by 7 wireless workstations along with VoIP communication between the 2 campuses. PCF is introduced to evaluate performance in voice E to E delay. 5.2 VoIP with data applications in WLAN Figure 6 shows the E to E delay caused by light, medium and heavy data application traffic generated by 7 wireless workstations along with VoIP communication in the WLAN. 4 simultaneous voice calls are simulated with 2 frames/packet packetizing Figure 7 Packet E to E delays between Rice campus and Main campus with data applications In our initial observation, the peak E to E delay without the introduction of latency, results to 16.1ms (see blue line). In our second observation, after the introducing latency of 50ms, the peak E to E delay increased almost 3 times resulting in 59.3ms (see red line). In our third observation, we increase the latency to 100ms that increased the peak E to E latency to almost 116ms (see green line). Figure 6 Packet E to E delays with 2fr/pkt with data applications Data application traffic in this scenario was sent between the time frame of around 5min and 6.5 min. Evidently data traffic did affect voice E to E delay which was 2.4ms with light data traffic and 23.1ms with medium data traffic. This surge shows that voice E to E delay is substantially increased with the inclusion of data traffic along with voice communication in the WLAN. However, this delay is still in the acceptable By introducing a delay of 100ms in the network, we observed the total voice E to E delay of just over 100ms. This is not efficient as it approaches the acceptable limits of voice E to E delay of 120ms. Due to data applications, we got a peak voice E to E delay of 116ms which is very close to the acceptable limit. This confirms that it is very inefficient to use voice traffic along with data applications in a network with a delay of around 100ms. 2004 Masaaki Yana & Ninad Narkhede 5
In our final observation, upon the introduction of PCF, we see that the voice E to E delay is around 101ms to 102ms. As per previous observations, this eliminated the spikes of around 116ms in voice E to E delay caused by data applications. The ability of PCF of transferring contention free frames is considered an efficient option for using VoIP calls in a network using data applications. 6. Conclusion In our simulation of VoIP over IIT-Rice campus, we found that optimum VoIP performance could be achieved by 4 simultaneous calls by voice enabled workstations packetizing 2 frames per packet along with heavy data applications. This was achieved by making the calls to main campus and evaluating the traffic using one AP. We were successful in achieving acceptable VoIP delay for the above performance. We used G.711 vocoders in our simulations; however, some future extensibility considerations for this project would be evaluating G.729 along with G.711 vocoders and making calls beyond the LAN to the PSTN. 7. References [1] F. Ohrtman, K. Roeder, Wi-Fi HANDBOOK, ISBN 0-07-141251-4, 2003 [2] Simulation of Point Coordination Function for IEEE 802.11 Wireless LAN using Glomosim www.unix.ecs.umass.edu/~aramanat/cn/report697_ne w.doc 2004 Masaaki Yana & Ninad Narkhede 6
Appendix - A # AP10 # of VoIP hosts AP20 # of VoIP hosts fr/pkt Throughput [bps] MAC Delay VoIP E toe delay (pk)(avg) WLAN FTP/HTTP/- Email IP network WLAN Latency 1 2 callers 2 callees 1 960k 0.38ms 1.35ms none - - 2 3 callers 3 callees 1 1.2M 390ms (increasi ng) Main Campus 1sec none - - 3 3 callers 3 callees 5 899k 1.7ms 0.8ms none - - 4 3 callers 3 callees 3 990k 0.48ms 1.67ms none - - 5 3 callers 3 callees 2 1.1M 0.23ms 1.1ms none - - 6 4 callers 4 callees 2 1.48M 0.72ms 2.1ms none - - 7x 5 callers 5 callees 2 1.78M 288ms 570ms none - - 8 5 callers 5 callees PCF 2 1.8M 143ms 290ms none - - 9 2 callers 2 callees 1 990k 1.2ms (pk)2.7ms (avg)1.4ms 10 2 callers 2 callees 1 1.0M 1.0ms (pk)2.4ms (avg)1.4ms 11 2 callers 2 callees 1 1.24M 4.3ms (pk)8.6ms (avg)1.4ms 12 2 callers 2 callees 2 768k 0.3ms (pk)1.0ms (avg)0.9ms 13 4 callers 4 callees 2 14 4 callers 4 callees 2 15 4 callers 4 callees 2 16 0 4 callers 2 17 0 4 callers 2 18 0 4 callers 2 19 0 4 callers 2 20 0 4 callers 2 21 0 4 callers PCF 2 1.5M 1.0ms (pk)2.4ms (avg)1.7ms 1.9M 11.7ms (pk)23.1ms (avg)2.5ms 1.9M 8.3ms (pk)15.9ms (avg)2.5ms L 7hosts - - M 7hosts - - H 7hosts - - L 7hosts - - L 7hosts - - M 7hosts - - H 7hosts - - 553k 0.4ms (pk)1.1ms - - 4 VoIP callees 766k 2.5ms 1.1M 16.2ms 821k 8.7ms 1.1M 15.3ms 824k 4.3ms (pk)3.0ms (avg)1.5ms (pk)16.1ms (avg)1.8ms (pk)59.3ms (avg)51.4ms (pk)115.9ms (avg)101.8ms (pk) (avg)104.6ms L 7hosts - 4 VoIP callees H 7hosts - 4 VoIP callees H 7hosts 0.05s 4 VoIP callees H 7hosts 0.1s 4 VoIP callees H 7hosts 0.1s 4 VoIP callees 2004 Masaaki Yana & Ninad Narkhede 7