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.

13

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.