i
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
ii
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.
iii
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.
iv
TABLE OF CONTENTS
Declaration of Authorship ii
Abstract iii
Table of Content iv
List of Figures v
List of Tables vi
Glossary 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
v
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
vi
LIST OF TABLES
Table 1: List of components needed for experiment purposes 4
Table 2: Metric parameters for threshold calculation 11
vii
GLOSSARY
Asterisk Open source private branch exchange that gives a network
telephony capability, acting as a server of some sort.
AP Access point
CAC Call Admission Control
D-ITG Distributed Internet Traffic Generator - used to generate traffic
on a network.
GUI Graphical User Interface
HLD High-Level Design
iPerf A tool to measure the amount of bandwidth being consumed
when sent from one node to another.
LLD Low-Level Design
MP Mesh Potato – a device used to gain access to a mesh network
where the MP is an access point.
OS Operating System
QoS Quality of Service – terms that govern network performance
such as throughput, jitter and delay.
Wireshark A network tool a network administrator can use to monitor a
network and get various kinds of statistics relating to the
network performance.
WMN Wireless mesh network
1
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.
2
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.
3
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.
4
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.
5
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
http://villagetelco.org/get-started/flash-your-mesh-potato/ as well as various other
instruction that can help with setting up the MP.
Figure 2: Example of how the Mesh Potato looks like.
6
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 10.04 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.
7
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.
8
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.
9
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.
10
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:
11
Metric Parameter Value
Packet Loss Less than (<) 1 %
Delay Less than (<) 150 ms
Jitter Less than (<) in the range of 20 – 30 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 = ThpacketLoss < 1% && Thdelay < 150ms && Thjitter
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.
12
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.
14
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.108-113.
[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.2148-2158.
[4] Sarr, C. and Lassous, I. (2007) Estimating Average End-to-End Delays in
IEEE802.11 Multihop Wireless Networks. [report] Montbonnot Saint Ismier
(France): INRIA.