INTRODUCING VoIP CALL ADMISSION CONTROL TO A WIRELESS MESH NETWORK

Transcription

1 INTRODUCING VoIP CALL ADMISSION CONTROL TO A WIRELESS MESH NETWORK By Danwin Ambros Francis A report submitted in partial fulfilment of the requirements for the completion of the degree Baccalaureus Scientiae (Honours) University of the Western Cape Supervisor: Prof. William Tucker Advisor: Carlos Rey-Moreno May 2013 i

2 DECLARATION OF AUTHORSHIP I, Danwin Ambros-Francis, hereby certify that the work presented in this mini thesis is, to the best of my knowledge, original and the result of my own research and investigations, except those that have been acknowledged, and has not been previously submitted for a degree at this or any other University. ii

3 ABSTRACT INTRODUCING CALL ADMISSION CONTROL TO A VoIP WIRELESS MESH NETWORK By Danwin Ambros-Francis BSc Honours Computer Science Project Paper, Department of Computer Science, University of the Western Cape. In this report I will be conducting experiments I will investigating the call control logic that is located on Asterisk that runs on the Mesh Potato. The aim is to have that call control logic make a call to investigate the state of the network before a new call can be allowed I will be making use of an existing WMN located in the Department of Computer Science on University of the Western Cape as a test bed. The tools I will be using to monitor and inject traffic into the WMN include Distributed Internet Traffic Generator (D-ITG) for generating traffic over the WMN and Wireshark to grab packets from the WMN to monitor performance of the mesh network. A High-Level Design will provide an overview of how the test bed and all its components operate together and where the CAC will be making the necessary accepting or rejecting of any new call made based on the amount of bandwidth available. iii

4 TABLE OF CONTENTS Declaration of Authorship Abstract Table of Content List of Figures List of Tables Glossary ii iii iv v vi vii Chapter 1: Introduction 1 - Introduction 1 - Motivation/Objective 2 Chapter 2: User Requirements 3 - Introduction 3 - User (Network Manager) view of the problem 3 - Problem domain 3 - What should the experiment achieve 3 - What should the experiment not achieve 4 - Requirements to conduct experiment 4 Chapter 3: Requirements Analysis 5 - Introduction 5 - Experiment description 5 - Experiment objective 7 - Testing solution 8 Chapter 4: Methodology 9 - Introduction 9 - How will he system work 9 - High-Level Design 10 - Low-Level Design 11 - To recap some of the objectives 12 iv

5 LIST OF FIGURES Figure 1: An example of a wireless mesh network 2 Figure 2: Example of how the Mesh Potato looks like 5 Figure 3: Example of the GUI for D-ITG 6 Figure 4: A view of the Wireshark GUI on start up 6 Figure 5: Example of a wireless mesh network 7 Figure 6: The steps involved in call admission control mechanism 10 v

6 LIST OF TABLES Table 1: List of components needed for experiment purposes 4 Table 2: Metric parameters for threshold calculation 11 vi

7 GLOSSARY Asterisk AP CAC D-ITG GUI HLD iperf LLD MP OS QoS Wireshark WMN Open source private branch exchange that gives a network telephony capability, acting as a server of some sort. Access point Call Admission Control Distributed Internet Traffic Generator - used to generate traffic on a network. Graphical User Interface High-Level Design A tool to measure the amount of bandwidth being consumed when sent from one node to another. Low-Level Design Mesh Potato a device used to gain access to a mesh network where the MP is an access point. Operating System Quality of Service terms that govern network performance such as throughput, jitter and delay. A network tool a network administrator can use to monitor a network and get various kinds of statistics relating to the network performance. Wireless mesh network vii

8 1. INTRODUCTION Voice over Internet Protocol (VoIP) is a the use of technology that enables user to communicate via voice over Internet Protocol (IP) networks such as the Internet and has been tested as early as the 1970 s on the Arpanet, the first version of the modern Internet. Call Admission Control is as its name says, it control who gains access to the available resources to either accept or reject a call, and this is all based on the amount of bandwidth available as well as the terms set for the Quality of Service of that specific network. This type of control complements QoS tools to ensure voice traffic is uninterrupted by other voice traffic and congestion so you can call it a preventative measure to ensure that there is enough bandwidth available for new as well as current users on the network. There are many resources/criteria that can be considered to determine how and when calls are rejected or accepted; among these are bandwidth, CPU processing power and the number of calls that can be handled. For this experiment bandwidth consumption will be the main criteria a call on the network is rejected or accepted. The test bed that will be used for the experiment is an already existing WMN that is situated in the Computer Science Department of University of the Western Cape which will serve as the appropriate base to conduct various tests to determine the effectiveness of the CAC algorithm that will be located on the WMN access point (AP). Previous works that relate to this experiment and where the implementation of CAC would be beneficial is the Mankosi Project that consists of a WMN that is located in a rural area in the Eastern Cape where various Mesh Potatos were set up with telephony devices to enable the Chief and his Headmen to communicate with each other as the villages are situated very long distances from each other. It was built with self-sustaining in mind and to better the quality of life in the community of Mankosi. 1

9 Motivation As I have mentioned the Mankosi Project before, I believe it will be of great use to introduce CAC when the implementation of more WMN for telephony such as Mankosi is initiated. This in turn will provide these networks with better QoS and ensure that users can communicate with the least interference as possible. Introducing CAC will also lay the foundation for when introducing video communication to WMN such as the Mankosi Project. Figure 1: An example of a wireless mesh network. The rest of this document is structured as follows. Chapter 2 discusses the user requirements, Chapter 3 will give a description of the requirements analysis, Chapter 4 will discuss the type of interfaces will be encountered, Chapter 5 will specify the High-Level Design (HLD) and Chapter 6 will describe the Low-Level Design. 2

10 CHAPTER 2: USER REQUIREMENTS Introduction In this chapter I will be going over the requirements that need to be fulfilled to address the problem, the user in this case would be the Network Manager that is in charge of administrative duties of the WMN. The problem domain will be discussed as well as the capabilities the end result should yield and what it should not be capable of doing. The requirements have been gathered by reading up on articles relating to call admission control and VoIP for mesh networks. User (Network Manager) view of the problem? There has been occasions where I have experienced communications that was of poor quality and this usually occurred when there was a lot of activity on the network for example UWC s wireless service, Free4All, where sometimes the connection would just be cut off abruptly because of an overload on the network. Problem domain? This brings up the problem that the network manager is faced with, assuring that any communication happening over the WMN, in this case VoIP, is controlled by some mechanism. This mechanism should govern any activity on the network to make sure that resources are distributed fairly and if any new calls are made that there is enough bandwidth available to allow the call, if not the call is rejected. What should this experiment achieve? The aim of this experiment is to monitor the traffic flow on the WMN, namely the on located in the Computer Science Department, and while traffic is being sent over the network there should be a tool grabbing packets off of the WMN to monitor and analyse statistics to see how the WMN handles any new calls made while there is an overload of activity on the network as well as when there is low activity. 3

11 When this baseline has been established to have a visual of how the WMN handles these different types of scenarios then the CAC algorithm should be introduced. When the CAC algorithm is introduced the aim is to establish whether the algorithm does in fact accept/reject new calls depending on the amount of bandwidth consumed on the network at that given time of communication. What should the experiment not achieve? This experiment should not aim to provide CAC based on the amount of calls made as the algorithm will only consider the bandwidth to determine availability on the WMN. The CAC will not be catering for video communication but can be considered in the future. What is needed to conduct this experiment? Table 1: List of components needed for experiment purposes. 4

12 CHAPTER 3: REQUIREMENTS ANALYSIS Introduction Requirements analysis is the next step in forming a better idea of what we will be trying to achieve in the experiments of implementing CAC in a WMN. What follows is an example of how the WMN the experiments will be tested on looks like and all components needed to achieve the desired results with a description of how each will be used. It also looks at how the whole system will interact when the CAC algorithm is introduced and where it is located within the system. Experiment description There is clearly a need for a CAC mechanism to ensure that QoS terms are held at all times to make sure all user, existing and new, have the best possible chance of making a quality voice call over the mesh network. To achieve this we first need to gain access to the WMN named VoIP-Mesh that is located in the Computer Science Department. To gain access we set up a Mesh Potato (MP) in the Honours Lab, which first needed to be flashed as an access point (AP) and configured with a static IP and ESSID to allow any mobile devices to connect wirelessly to the mesh network namely VoIP-Mesh. To achieve this instruction are readily available on the Village Telco site at as well as various other instruction that can help with setting up the MP. Figure 2: Example of how the Mesh Potato looks like. 5

13 The next step is to install D-ITG and Wireshark which was fairly easy to set up on a Linux OS. For the laptop I installed Ubuntu LTS (Lucid Lynx). A D-ITG manual was followed which will be added as an appendix at the end of the report. Installing Wireshark was fairly easy as you could install it via the terminal in Ubuntu, with the following command sudo apt-get install wireshark, or you could install it via Ubuntu Software Center. Figure 3: Example of the GUI for D-ITG Figure 4: A view of the Wireshark GUI on start up. 6

14 To implement all of these tools to monitor the WMN we will need a WMN, below I have sketched my own simple explanation of how a small wireless mesh network looks like. It contains laptops that connect wirelessly to the Mesh Potato nodes that act as access points on this small wireless mesh network. Also attached to the MPs are telephony devices. Keep in mind this is only an example of a wireless mesh network and not the one located in the Computer Science Department. Figure 5: Example of a wireless mesh network. Experiment objective The objective of this experiment is, as mentioned before, to build a CAC algorithm that will be located on the Mesh Potato that will determine whether any new calls made are rejected or accepted depending on the mesh network state in other words, whether there is enough bandwidth available to provide a good connection for communication on the VoIP mesh network. 7

15 Testing solution Suggested solution for experiment can be tested by generating traffic over the WMN in the background, the amount of traffic can be set to any desired level as D-ITG allows for setting the amount of traffic and for how long it will be set so various situations can be simulated. With the background traffic running a new call is made from either the laptop or a telephony device, and depending on the amount of bandwidth available the call will be rejected or accepted. The CAC mechanism located in the Mesh Potato OS namely Asterisk contains the call signalling methods that need to be invoked so that the threshold calculation can determine whether call will be allowed or rejected. The objective for third term to have the collection of quality of service metrics read in from files so that the call admission control threshold calculation have the appropriate values to compare to the defined parameters to determine the state of the network. 8

16 CHAPTER 4: METHODOLOGY Introduction In the following section I will be outlining how the system will work, followed by the High-Level design and Low-Level design describing the steps needed to reach the objective of implementing the call admission control mechanism in Asterisk so that quality of service requirements are followed. How will the system work? To give an insight to what is to be achieved, consider the following scenario where a user wants to make a call from one node to another node located on the same wireless mesh network. The user attempts to make a call but before the call can even be put through, Asterisk, located on the Mesh Potato, is responsible for the routing, set-up and maintenance of calls being made on the network. Within Asterisk the proposes call admission control mechanism will be located that invoke methods to firstly determine the state of the wireless mesh network, secondly calculate the acceptance threshold from quality of service metrics collected, and thirdly when metrics are compared to defined parameters then call will either be allowed or rejected. A secondary objective would be to have Asterisk send an automated voice command to the user saying that the call had been rejected because of poor communication quality. 9

17 High-Level Design In this section I will be giving a description of the high-level design, in this case it is the three steps involved in determining whether a call is allowed or rejected. The three steps involve investigating the state of the network, calculating the acceptance threshold and the decision to accept or reject a call based on the acceptance calculation. Figure 6: The steps involved in call admission control mechanism. Figure 6 give an abstract view of what is to be achieved. Firstly the state of the network will need to be investigated based on QoS metrics that include packet loss, average delay, average jitter, throughput/goodput and the latency of the network. These values will then be recorded and compared to threshold parameters in the second step where defined parameters have been set. For this term I have only considered packet loss, delay and jitter and there parameters are listed in the following table: 10

18 Metric Parameter Value Packet Loss Less than (<) 1 % Delay Less than (<) 150 ms Jitter Less than (<) in the range of ms Table 2: Metric parameters for threshold calculation. Low-Level Design For the low-level design I will be going into a the calculation of the acceptance threshold and the parameters used. As mentioned before the QoS metrics considered for the threshold calculation are packet loss, delay and jitter. The reason for this is because these metrics have the biggest impact on voice of IP communication. Packet loss: Packet loss is the amount of packets lost along the way from host to destination and is calculated in percentage ((packets lost/total packets sent)*100) and should be less than 1%. Delay: Delay indicates the time to send a packet from a source to a destination node. Contrary to bandwidth, delay is an additive metric. Thus, the delay along a path is equal to the sum of the delays on the one-hop links of this path [4]. Jitter: Jitter can be defined as a variation in the delay of received packets. From the sender s end, packets are sent in a continuous stream with the packets spaced evenly. As soon as you talk of network congestion, improper queuing or configuration errors the stream that is sending packets steadily can cause the delay between packets to vary instead of keeping constant. Below is the suggested formula that considers metric parameters as well: S = Th packetloss < 1% && Th delay < 150ms && Th jitter This formula contains the threshold for each metric that will be collected when investigating the state of the network, which the S stands for in the above mentioned formula. 11

19 When metric of the network performance is returned, namely the packet loss, delay and jitter, these values are then fed into the formula and if the formula returns a positive network state then any new calls are allowed, if the state is negative any new calls will be rejected and a voice command is sent to the user saying the call has been rejected. To recap some of the objectives: - Automate collection of network state metrics such as packet loss, delay and jitter. - Calculate acceptance threshold by retrieving metric values and have these values compared to parameters set. - On calculation of acceptance threshold call will either be allowed or rejected. - On rejection of call voice command will be sent to user to say that the call has been rejected by the call admission control mechanism invoked. 12

20 13

21 Bibliography [1] Rong, B. and Qian, Y., et al. (2008) An Enhanced SIP Proxy Server for Wireless VoIP in Wireless Mesh Networks. IEEE Communications Magazine, Iss. January p [2] Ergin, M. and Gruteser, M., et al. (2008) Available bandwidth estimation and admission control for QoS routing in wireless mesh networks. Computer Communications, (31). [3] Ganguly, S. and Navda, V., Kim. K., Kashyap, A., Niculescu, D., Izmailov, R., Hong, S., Das, S.R. (2006) Performance Optimizations for Deploying VoIP Services in Mesh Networks. IEEE Journal On Selected Areas In Communications, 24 (11), p [4] Sarr, C. and Lassous, I. (2007) Estimating Average End-to-End Delays in IEEE Multihop Wireless Networks. [report] Montbonnot Saint Ismier (France): INRIA. 14